Building an app
A smartphone is a small computer: a processor, memory, storage, a screen and sensors such as the camera. Its operating system, iOS on iPhones or Android on most other phones, runs everything. A mobile app is a program you install on it.
Native apps are written in each system's own language: Swift for iOS, Kotlin for Android. They reach every feature of the phone directly, but serving both kinds of phone means writing and looking after two separate programs.
Cross-platform tools build both apps from one set of code: Flutter uses the Dart language, React Native uses JavaScript. A web app needs no store at all: it is a website that runs in the phone's browser, with fewer phone features.
Store and install
To release the app, the developer uploads a finished copy, called a build, to Apple's App Store or Google Play. The store checks it against its rules: does it crash, hide features or misuse personal data? Only approved apps reach people.
You tap Install and the store sends the app to your phone. Every app carries a digital signature, a seal only its signer can make, so the phone checks who signed it and that nobody changed it on the way.
Inside the phone
You open the app and the system runs it in a sandbox: a walled-off space with its own private folder for files. It cannot read other apps' data or change the system. If it crashes, the damage stays inside the walls.
The camera sits outside the walls. To use it, or location, contacts or the microphone, the app must ask. The system shows a dialog; only if you tap Allow does it open that door. You can take it back later in Settings.
Talking to the back end
Your messages live on the company's servers, not in the app. So the app sends an HTTPS request to the back end's API (the set of requests a server answers): GET /messages, exactly as a web page's JavaScript would.
The server answers 200 OK with JSON, plain text any language can read: {"messages":[…]}. Only data travels. The screens are already inside the app, so the app turns the JSON into its own list on your screen.
Life cycle and push
Press Home and the app leaves the screen: it is in the background. Soon the system suspends it, kept in memory but not running. If the phone needs that memory, the system may end it completely, without any warning.
A new message arrives while the app is not running. The server cannot reach your phone directly, so it hands a notification to the push service: Apple Push Notification service for iPhones, Firebase Cloud Messaging for Android.
Your phone keeps one connection open to the push service for all its apps. The notification arrives over it and the system shows it, even though the app is not running. Tap it and the system starts the app again.
What happens
;; step 1/12 · phone a smartphone, inside processor runs the instructions memory holds the apps that are running storage keeps installed apps and their files sensors camera, microphone, GPS (location) operating system iOS (iPhone) or Android mobile app a program installed on top
The phone is drawn as an open tray so you can see inside. The sandbox walls, the permission door and the app block are pictures of rules the operating system enforces in software: on iOS each app gets its own container, on Android each app runs as its own Linux user. iOS names the states active, inactive, background, suspended and not running. Android describes them with activity callbacks (onResume, onPause, onStop) and keeps background apps as cached processes, which Android 14 and later freeze until they are needed.