Image credit: undraw.co
How do Mobile Apps Work?
Many of us use apps every day. But we don’t often stop to think: how do mobile apps even work?
In this article I’ll be digging into how apps work to connect people with things they value, and how that works for your business. I’ll talk about app development, the cloud, the app stores, and some other technical stuff – but we are going to be keeping it light on the jargon.
It’s the first post in my series “How do I build an app?”. Check the series introduction for context and links to the other articles.
Let’s dive in.
Apps are part of the fabric of the Internet
Apps seem simple when you look at them! But we know companies like Facebook and Google; Twitter and Snapchat have hundreds, even thousands of people working on apps.
When I tap an icon on my phone the Twitter app opens up. But all those engineers working on code for apps: what happens to all that code?
What about even a simple app like the notes app that comes with my phone? Surely most of that simple app is just what you see on the surface?
Apps use the Cloud to provide functionality
The answer of course is that even a simple app is more than just the icon and the application itself on your phone. Much of the functionality of apps is actually in the cloud. Even the humble notes app is saving data into the cloud. For some apps, and Facebook is a great example, the mobile app is just a small windows onto a huge web-based system. No wonder they need all those engineers!
So what is the cloud? Just in case you need a refresher let’s take a minute to go over ”the cloud” as it relates to apps.
Sidebar: Cloud Refresher
Think about a television station. It broadcasts, day and night, waiting for someone to tune in with their TV set. We don’t know where the television station is. When we tune in we just see the shows that the television station is broadcasting.
The television station is like a server computer. Lots of server computers together form the cloud. You’ve heard of network television? Well the cloud is a network too.
A server is just a computer that is connected to the Internet 24/7. And it serves up stuff.
The cloud is just the word for a large number of remote, interconnected servers all working together.
A great example of the cloud is the World Wide Web. There’s thousands of millions of pages of information on millions of server computers just waiting for us to view them. The way they work together is by linking via clickable links.
All those server computers can receive information as well as broadcasting it. Right, so that’s the “cloud”.
So apps are sending data to the cloud & pulling data from the cloud. But also the cloud is pushing apps to us via our phones.
The best way to think of this two-way street is that apps these days are part of the fabric of the Internet. This is a very important thing to understand about modern day apps. Many new app developers and entrepreneurs fail to understand this. They think about their app just as local to their phone and separate from the internet.
App Programming Interfaces
Think about an example of the lifecycle of an app – we’ll use a fictitious new online shopping app called Zombo:
- Alice sees an app banner promotion on Zombo’s website and clicks on it
- Alice downloads the Zombo app from the App Store to her phone; and
- once installed the app communicates over the Internet so Alice can
- log in to the Zombo store
- fetch special offers,
- save her favourites or
- share with friends
We already know how to use the web on our phone to connect to a website to look at for example special offers. There can be hundreds and thousands of different links and features and menus on a website that we can easily access using our phone or tablet by browsing and clicking or tapping on what we want.
But how does an app do that? How do mobile apps actually work when it comes to the cloud? An app doesn’t work by clicking on a website.
Apps Connect to the Cloud via an API
The answer is something called an API, or Application Programming Interface. That’s a lot: just remember that the I stands for interface.
The Zombo website server in the cloud serves up a page that is written in English so you and I can read it to access the menus and special offers there. But how can an app on a phone read a website? The answer is – via an API which is at its core a set of rules about how to store and retrieve data from that website.
The API provides an Interface so that each link and feature and menu and special offer on the Zombo server is specifically detailed in code written to the API so that the app can know how to access it. The Zombo iPhone or Android app is specifically coded to that API.
And notice this one thing: these APIs have to be specified in advance because once the app is built and uploaded on to Alice’s phone it can’t adapt to changes.
Change the API & You Break the App
Imagine the server today has a link on the website for shirts. But then the developer changes it so that it says tops instead of shirts. You and I will be able to browse and click on tops just the same. We know that that’s what we want. But an app that is already installed doesn’t know the tops and shirts are the same thing.
This is why APIs are important. API just means a set of rules that governs how the information is stored on the server; so that the developers who write the app can know how to connect to it and send the correct commands to it.
To answer the question of how do mobile apps work you need to think about how they interact via API’s to leverage cloud features, and how they need to keep pace with those same API’s. And how they can stop working when they fail to keep up.
Platform API Differences
The Apple App Store is different for every country so there’s actually hundreds of App Stores. Google play has one store but there’s lots of other android stores. All of these places where you can download apps are of course on the cloud.
When Zombo engineers write code and create an app they upload it to the cloud. They upload it to server computers which form the Apple App Store or Google Play Store ready for app users to download.
App Store Package Downloads
Remember Alice with the Zombo app on her phone? After she downloads the app she can log in to see special offers for her from the Zombo website.
Think about that for a minute. The first download was an app. The Zombo app. The second download was special offers from the Zombo Website.
That second download was human readable text information about clothes I can buy from Zombo but the first download was something else. It was an app package.
Apps are not human readable. Apps are functionality wrapped up in a package that your phone can understand and install. To make mobile apps work a phone unwraps that package and maps the content out onto the storage of the phone, where it can then run as an app.
App Package Formats
We call that non-human-readable package a “native app”, or a “binary”. It’s the job of Software Engineers or Developers to build this native app package & upload it to the App Store or Play Store.
Packages for the iPhone are in an IPA file. Whereas packages for android are in an APK file. These details aren’t important but just bear in mind that the app package is a file that gets uploaded to a server. At the core of it the App Store and Google play stores are just servers.
We’ll talk more in the next post about how developers and engineers create apps and add packages. But there’s one more very important thing to cover and that is the differences between app platforms.
Sidebar: Platform Wars
To make things simpler I’ll assume that there are just two platforms: Google’s Android, and Apple’s iPhone and iPad. Also I will refer to Android as being the “Google Android platform” even though Samsung HTC, LG and other companies make android phones.
This is because from the developer point of view Google is responsible for all the APIs that are needed when working with android. In the Apple ecosystem the iPhone and iPad along with other devices like the Apple iPod and Apple TV I will collectively refer to as iOS. Apple controls those API’s.
These days there is iPadOS and tvOS; and of course WatchOS – but just for brevity I’ll go with “iOS” for the family of devices.
Before I go on – one quick comment. It’s not really viable to say which platform is better.
People will choose the platform that suits them. Android is more popular in the developing world, and has a very diverse set of configurations due to its many vendors. Apple is more popular in the USA but sales are growing in China recently.
If you are a business owner looking to build an app, the most important thing is to look at what will serve your customers the best.
Android and Apple API Differences
We’ve already talked about how APIs are the rules that allow developers to know what is available on a website so an app can connect to it. Well there are also APIs so the developers can connect to the features on the phone or tablet itself.
Think about it this way: The app can connect up to the Internet to access features on websites, and it can also connect down to the phone or tablet to access features on that device itself. This is how an app can play music, access payment systems, use the camera, microphone, bluetooth system or use many other features of the phone. It’s the different platform API’s that make mobile apps work with the hardware and software features of a phone or tablet.
One mistake that folks new to app development often make is not realizing how completely different the code is for the Apple iPhone and Google Android phone platforms. Not only are the two platforms written in different computer languages – Apple’s Swift versus Android’s Kotlin & Java – but the platform API rules are different as well.
This means the rules for accessing down to the hardware, and functionality on the platform itself are different from iPhone to Android. And not just cosmetic differences – very fundamentally different in some cases. Notifications is a prime example.
Cross-Platform to the Rescue?
There are cross platform tools that can be used but generally these create problems of their own. Those tools – like Flutter, React Native or Xamarin for apps, and Unity for games – try to wallpaper over the platform differences by making their own API. But cross-platform tools introduce more dependencies, and require new tools for testing the apps. These tools in turn can make releases painful.
To make mobile apps work with their full functionality cross-platform apps have to mirror that new features that the platforms introduce. Sometimes this means that hardware acceleration and platform security features don’t work as well as when developers use the API’s provided by the vendor (Apple or Google).
So back to Alice: she can use the Zombo app to connect to the Zombo website and see special offers. Or on her phone she can use the phone’s web browser to connect to the Zombo website and see special offers as a web page rather than in the app. Either way, app or website, Alice is downloading human readable text.
Now we know that mobile apps work by using API’s and an app accesses its own platform and also cloud functionality via those API’s. And we know that app is a package.
Here’s the thing about native apps: they themselves are not human readable. After developers have built it, an app itself is a binary blob inside of a package, that it gets uploaded by developers to Apple’s App Store or Google’s Play store.
You may have heard that code is compiled into an app as instructions to the computer chip in a phone or tablet. That’s true but native mobile apps work by having efficient, super-fast binary instructions that are gibberish to the human eye.
This makes native apps very different from web-apps – even though both wind up accessing the web – which is human readable, mostly – and are both part of the fabric of the internet.
In the next post I’ll talk more about the difference between web-apps and native apps. And I’ll cover then the in-between case – the hybrid app. But for now let’s just look at how an app works compared to a webpage.
Apps work Offline
If I turn on Aeroplane Mode and shut off my Wi-Fi I can still open the Zombo app and see it’s navigation bar at the bottom; and navigate through content that it still has stored locally.
But if I try to refresh, no new special offers come down because Internet connectivity is not available. But at least the app still works.
If I tried in my web browser to go to Zombo’s website, because Aeroplane Mode and Wi-Fi is turned off I just get “you are not connected to the Internet”. So web-apps will usually give a big blank page of nothing if there is no internet. Or you might get a cached page. Or an error message.
Second big difference is that the native app launches really fast. Faster still if I was already using it and it was just backgrounded. Whereas sometimes the Internet can be slow and loading a webpage like Zombo’s homepage can take awhile.
Apps have a lot of tricks up their sleeve. They can use the phone’s barcode scanner via the camera; they can store login details locally in a secure keychain. And they can save recent copies of online information like the offers in Zombo’s app so that some functionality is still available even when off-line.
When you’re wondering how do mobile apps work so fast for things like image recognition, its because special image hardware on the phone can be accessed by native API’s to do the bulk of the work in hardware accelerated mode.
Some things like photo and movie editing, graphics, games, music, photography, Bluetooth and high-performance applications are only possible when you have access to the full power of the phone or tablet.
If apps are so good why isn’t everything in the app?
One reason is that updating apps is hard: engineers need to write code to make changes to the app. Even just changing Zombo’s navigation bar to a different shade of red would involve a change to the code; re-compiling the code into a package, and then uploading it to the stores. And then waiting. Customers might not download the update.
With a website Zombo’s artistic web designers can get a brief about a new shade of red this afternoon and roll out the change to the website in minutes so that the next time customers click on the website tonight they see the new result.
Changing Cloud API Issues
Another super important problem with apps is that because they’re so hard to update, the website that they connect to can move on and change while the app remains the same.
When that happens the app might not be able to download content the way it used to and it could display an error to the end user instead of displaying for example special offers or logging the user in.
Those were the rules that were used to govern how pages and information was stored on the web server so that the apps could download it.
If the API has changed but the app hasn’t been updated by the developer then we can get errors. The developer might update the app but the end-user may not yet have installed the update. The app may crash.
Releasing App Updates
To get out changes that developers make to an app & put that update in the hands of customers on their phones means a new release. Version 1.2.3 becomes version 1.2.4 and requires a new upload to the app store cloud.
If you want the server to change its API a new app release has to be planned and executed, which can be costly to do. In some cases it will require a review by Apple or Google.
Alright to wrap up let’s go over how apps work.
- Apps these days are part of the fabric of the Internet.
- They are more than just the icon or the install on the phone
- Mobile apps typically contact the Internet to provide additional functionality
- Software engineers and developers have to write code to create apps
- Once an app is created it is uploaded to the App Store or play store
- The code is very different between Android and iOS
- Apps can have problems related to Apis
- The API’s are very different from Android to iOS
- Native Apps can work off-line without the Internet
- When off-line most apps are limited these days
- Apps can have advanced functionality like cameras and microphones
- They launch quickly and can save settings like custom logins
- But apps are difficult to update