How Mobile OS (Android & iOS) Work

General OS Article

Introduction: The Silent Conducto

A mobile operating system (OS) is the foundational software that manages all hardware and software on a smartphone. Think of it as a silent conductor of an orchestra: it ensures the touchscreen (violins), the processor (brass), the memory (percussion), and your apps (musicians) all play in perfect harmony. While Android (Google) and iOS (Apple) serve the same purpose, their underlying philosophies, architectures, and operational mechanisms are fundamentally different. Android is built on open-source flexibility, while iOS is engineered for closed-system optimization.

1. The Kernel: The Core Power Manager

At the heart of both OSes lies the kernel, the lowest layer of software that directly communicates with the hardware.

  • Android (Linux Kernel): Android uses a modified version of the Linux kernel. This gives it advantages like hardware abstraction, memory management, and driver support for a vast range of chips (Qualcomm, MediaTek, Samsung Exynos). The Linux kernel handles tasks like process scheduling (which app gets CPU time), memory allocation, and power management.
  • iOS (XNU Kernel): iOS uses the XNU kernel (X is Not Unix), which is a hybrid combining Mach (for memory management) and BSD (for networking and file systems). Unlike Android’s Linux kernel, XNU is tightly coupled with Apple’s custom silicon (A-series and M-series chips), enabling features like unified memory architecture for faster graphics.

How they work: When you tap an icon, the kernel translates that touch event into a process, allocates a slice of CPU time, and ensures the app’s data stays in RAM until you close it.

2. System Architecture: The Layered Cake

Both OSes use layered architectures, but their restrictions differ.

Android’s Stack (Top to Bottom):

  1. Apps: Your downloaded apps (Gmail, TikTok, etc.).
  2. Java API Framework: The core building blocks for developers (e.g., window manager, notification manager, activity manager).
  3. Native C/C++ Libraries: OpenGL ES (graphics), WebKit (browsing), SQLite (database).
  4. Android Runtime (ART): Executes app code. ART compiles apps ahead-of-time (AOT) during installation for better performance.
  5. Linux Kernel: As described above.

iOS’s Stack (Top to Bottom):

  1. Cocoa Touch (UI Framework): The touch-centric APIs for gestures, animations, and interface controls.
  2. Media Layer: Graphics (Metal, Core Graphics), audio, and video.
  3. Core Services: iCloud, networking, security, and SQLite.
  4. Core OS Layer: Low-level services, file system, and the XNU kernel.

Key Difference: Android uses a virtual machine (ART) to run apps, meaning apps run in a sandboxed environment. iOS runs apps natively with a tighter hardware link, leading to faster perceived performance.

3. App Management & Runtime

How each OS launches, runs, and kills apps defines the user experience.

Android: True Multitasking & Activity Lifecycle

  • When you open an app, Android starts an “Activity.” You can have multiple activities in a “back stack.”
  • Apps can run in the background freely using Services (e.g., Spotify playing music while you browse Twitter).
  • Memory Management: Android uses a Low Memory Killer (LMK) daemon. When RAM is low, it kills the least important background processes (not the user’s current app). Apps don’t need to close; the system manages them.

iOS: Freeze-and-Thaw Multitasking

  • iOS uses a more aggressive management model. When you switch away from an app, iOS freezes it (takes a snapshot and stops its code from executing).
  • Only specific background tasks are allowed: playing audio, GPS navigation, VoIP calls, or completing a short task (uploading a photo).
  • Memory Management: iOS uses Reference Counting (Automatic Reference Counting – ARC). The moment an object (e.g., a photo in memory) has no references pointing to it, it is instantly deleted. This prevents memory leaks and keeps RAM efficient.

Verdict: Android allows more true background activity (great for automation), while iOS prioritizes battery life and foreground performance.

4. Hardware Interaction: The Driver & Abstraction Layer

Apps never talk directly to hardware; they ask the OS to do it.

  • Android (HAL – Hardware Abstraction Layer): Android’s HAL is a set of interfaces that allow the OS to communicate with device-specific hardware. Because Android runs on thousands of devices (Samsung, OnePlus, Xiaomi), manufacturers must write their own HAL modules (camera driver, fingerprint sensor driver). This is why some Android phones get slower updates—manufacturers need to adapt their HAL to new OS versions.
  • iOS (Direct Integration): Apple controls both the hardware and the OS. There is no generic HAL; instead, iOS talks directly to known hardware registers. This allows Apple to optimize a single camera sensor or neural engine to an extreme degree. It’s also why iPhones often outperform Androids with double the RAM.

5. Security & Permission Models

Security is architected fundamentally differently.

Android: Sandboxing by User ID (UID)

  • Each app gets its own unique Linux User ID (UID) and runs in its own process sandbox.
  • Permissions: At install time (historically) or first use (modern Android), the app requests permissions (camera, contacts). However, Android allows inter-app communication via Intents. For example, one app can ask another app to take a photo. This is powerful but can be exploited if users grant unnecessary permissions.

iOS: Entitlements & App Store Review

  • iOS uses a concept called Entitlements. Developers must declare exactly what hardware or data their app needs, and Apple verifies this during App Store review.
  • Hardened Runtime: Every iOS app is signed with a developer certificate. No app can execute dynamically generated code (no just-in-time compilation except for browsers). This prevents many malware techniques.
  • Privacy Indicators: iOS introduced recording dots (orange/green) at the OS level—the camera/microphone cannot be activated without your knowledge, even by system apps.

6. The User Interface & Rendering

How the OS draws pixels on your screen.

  • Android (SurfaceFlinger & Choreographer): Android uses SurfaceFlinger to composite all app windows (status bar, navigation bar, app UI) into a single image. The Choreographer syncs UI rendering with the display’s refresh rate (60Hz, 90Hz, 120Hz). Because Android runs on a virtual machine, there is a small overhead called “garbage collection” where the system pauses to clean up memory—this can cause occasional jitter (though much reduced with modern ART).
  • iOS (Core Animation & Metal): iOS renders UI on a dedicated render server with ultra-low latency. Core Animation uses the GPU aggressively for all transitions (even scrolling). Since iOS apps are compiled directly to machine code (no virtual machine), there is no garbage collection pause for the UI thread. This is why iOS scrolling feels “sticky” and smooth even on older devices.

7. Updates & Fragmentation

The operational difference in how updates are delivered.

  • Android (Project Treble & Mainline): Historically, updates were slow because chip makers (Qualcomm) had to update proprietary drivers. Google created Project Treble (a modular HAL) and Mainline (updating core OS components via Google Play Services). Now, many Android security updates bypass manufacturers entirely. However, full OS version updates (Android 13 → 14) still require manufacturer coordination.
  • iOS (Seamless OTA): Because Apple controls the entire stack, when iOS 18 is released, every supported iPhone gets it simultaneously. Updates are delta updates (only changed data), and the system can download and install in the background without using much storage.

8. Power Management: The Battery Life War

  • Android (Doze Mode & App Standby): Starting with Android 6.0, Android detects when the phone is stationary (screen off, not moving) and enters “Doze” mode, allowing apps to sync only in scheduled windows. App Standby restricts network access for rarely used apps.
  • iOS (Adaptive Charging & Background App Refresh): iOS learns your daily charging routine. It delays charging past 80% until just before you wake up. Background App Refresh uses machine learning to fetch new content only when the device is on Wi-Fi and has ample battery, not on a fixed schedule.

9. Development Ecosystem

  • Android (Java/Kotlin + Android Studio): Developers compile code into bytecode, which the Android Runtime (ART) then compiles into native code on the device. This two-step process allows flexibility but requires more RAM to store compiled code.
  • iOS (Swift/Objective-C + Xcode): Developers compile directly to ARM machine code on their Mac. The resulting binary runs natively on the iPhone’s CPU. Swift’s memory safety features (ARC) and compile-time optimizations produce small, fast binaries.

Conclusion: Two Philosophies, One Goal

Both Android and iOS are extraordinarily complex systems that manage hardware resources, security, power, and apps. Android operates like a democratic federal government—flexible, customizable, and running on many different hardware “states,” but occasionally slower to unify updates. iOS operates like a benevolent dictatorship—controlled, efficient, and deeply integrated, but with less user freedom.

Ultimately, when you swipe, tap, or type, both OSes translate your finger’s electricity into logic gates, process interrupts, manage memory pages, and render pixels faster than you can blink. The difference lies not in raw capability, but in the trade-offs each chooses: Android prioritizes choice and openness; iOS prioritizes consistency and polish.