Platform Security Models · iOS vs Android

Mobile operating systems made architectural choices that desktop OSes never could. iOS was designed from the ground up assuming untrusted apps — an iOS app cannot read another app's files, modify the OS, or do most of what a Windows or Linux app can. Android made similar choices with different trade-offs — more user freedom, more attack surface. Understanding the two models explains nearly every mobile security topic that follows.

The five pillars

Both platforms share five fundamental security mechanisms, implemented differently:

AxisiOSAndroid

Code signing

Mandatory. Every binary must be signed by Apple or by an Apple-issued developer certificate. The kernel refuses to execute unsigned code. App Store enforces this absolutely; sideloading requires either jailbreak or Apple's narrow enterprise/TestFlight channels.

Mandatory at install time. APKs must be signed; the system tracks the signing key to verify updates. But: any key works — including self-signed. Sideloading from outside Play Store is a setting away (and unblocked by default on most non-Pixel devices).

App sandboxing

Every app runs as its own UID in a container under /var/mobile/Containers/Data/Application/<UUID>/. Apps cannot read each other's data, period. Sharing happens only through system-mediated APIs (UIDocumentPickerViewController, Keychain access groups, App Groups).

Each app gets a unique UID; the kernel enforces process isolation. Storage is per-app under /data/data/<package>/. Inter-app communication happens through Intents — structured messages routed by the OS.

Hardware root of trust

Secure Enclave — a separate ARM CPU with its own OS (sepOS). Holds keys for Touch ID, Face ID, Apple Pay, FileVault. Even iOS itself cannot extract keys from the Secure Enclave; it can only ask the Enclave to perform crypto operations.

Trusted Execution Environment (TEE) on most devices, plus Google's Titan M security chip on Pixels. Same goal: keys that the main OS cannot extract. Vendor-specific: Samsung Knox, Qualcomm QSEE, etc.

Permission model

Per-permission prompts at first use. Apps must declare entitlements in their bundle; the user is prompted the first time the app tries to use camera, microphone, contacts, location. Granular sub-permissions ("share approximate location," "share photos selected").

Permissions declared in AndroidManifest.xml. Since Android 6, runtime prompts for dangerous permissions. Sub-permissions roughly parallel iOS (precise/approximate location, photo picker, etc.). Background-execution restrictions tightened in every recent Android release.

Update model

Apple ships updates directly to every supported device. Five-year-old iPhones get current iOS. ~95% of active iOS devices run a recent major version within a few months of release.

Google ships AOSP updates monthly; vendors and carriers gate distribution. Pixel devices update immediately. Other vendors delay by months. Some devices never receive security updates past their first or second year. Long-tail fragmentation is the major Android security challenge.

App distribution

iOS — walled garden

The only path to most users is the App Store. Apple reviews every submission. Side-loading exists narrowly: Apple Enterprise certificates (revocable, expensive), TestFlight (capped at 10,000 testers), AltStore-style sideloading via developer accounts.

The trade-off: Apple is a chokepoint. Malicious apps that pass review get distributed to billions; apps that displease Apple don't get distributed at all. The EU's Digital Markets Act has begun forcing limited third-party app stores on iOS; the security implications are still settling.

Android — plural ecosystem

Google Play is the primary store; Samsung Galaxy Store, Amazon Appstore, F-Droid, and direct APK downloads are all viable. Google Play Protect scans installed apps for known malware across the entire ecosystem (not just Play Store apps), giving partial coverage even for sideloaded apps.

The trade-off: more vectors for malware, balanced by genuine user choice and the ability to distribute software (open-source apps, regional apps, internal enterprise apps) without depending on Google's gatekeeping. Most large malware campaigns target sideloaded Android apps.

What this buys you (and doesn't)

What both platforms buy: apps cannot freely read other apps' data, modify the system, or persist outside their sandbox. Most desktop malware patterns simply don't work on mobile.
What both miss: apps you grant permission to do what they ask. A flashlight app with "camera access" is still a camera-capable app. The sandbox doesn't read the user's intent.
Where iOS excels: attack surface uniformity, rapid OS updates, hardware-backed credentials by default.
Where Android excels: openness (auditability of AOSP, alternative app stores, work profiles for BYOD), user choice, hardware diversity.
What you cannot rely on either to fix: social engineering, phishing that targets the mobile browser, MFA-fatigue prompts, malicious enterprise profiles that the user was tricked into installing.

The advanced persistent mobile threat. NSO Pegasus, Predator, and Intellexa represent the high end of mobile attacks — zero-click exploits delivered via iMessage or WhatsApp that fully compromise a target's phone. Both iOS Lockdown Mode (2022) and Android Advanced Protection (2024) are responses: hardened modes that disable attack surfaces (preview rendering, attachment auto-fetch, complex font parsing) in exchange for slightly worse usability. For high-risk individuals (journalists, dissidents, executives at sanctioned companies), turning these on is a real defense.

The jailbreak / root question

Both platforms have communities that bypass the OS's protections — jailbreak on iOS, root on Android. The motivations range from legitimate (researchers, modders) to malicious (sideload arbitrary apps, hide trackers). For enterprise security, the relevant question is: are jailbroken / rooted devices accessing my corporate apps?

iOS jailbreak detection — check for sandbox escape (writable /), presence of Cydia/Sileo, suspicious environment variables, fork() succeeding when it shouldn't.
Android root detection — check for su binary, Magisk artifacts, build tags, SafetyNet/Play Integrity attestation failures.
The catch — both detection sets are routinely bypassed by motivated attackers. Use hardware-backed attestation (DeviceCheck on iOS, Play Integrity on Android) as the primary signal; library-based detection as a secondary.

The point

iOS and Android both implement sandboxing, code signing, runtime permissions, and hardware-backed crypto — the four pillars of modern mobile security. The differences are in degree (Apple's stricter code signing, Android's more open app distribution) and in operational reality (iOS update uniformity vs Android fragmentation).

For most threat models, both platforms are dramatically more secure than the desktops they replaced. The remaining mobile risk is largely application-layer (the next page) and social (phishing into the mobile browser, MFA fatigue, malicious profiles). The platform itself rarely loses; the app or the human does.

References

Formatted in APA 7.

Apple. (n.d.). Apple Platform Security. https://support.apple.com/guide/security/welcome/web
Google. (n.d.). Android security model. Android Open Source Project. https://source.android.com/docs/security/overview
National Institute of Standards and Technology. (2023). Guidelines for managing the security of mobile devices in the enterprise (NIST Special Publication No. 800-124, Rev. 2). https://doi.org/10.6028/NIST.SP.800-124r2