A mobile security test plan written for one operating system will under-test the other, because Android and iOS do not share the primitives a security test checks. The clearest evidence is structural: the OWASP Mobile Application Security Testing Guide (MASTG) ships a separate Android test and a separate iOS test for the same Mobile Application Security Verification Standard (MASVS) requirement, precisely because that requirement resolves to a different mechanism on each platform. Secure local storage, network defaults, anti-tampering and the inter-app surface differ in kind rather than degree. This is the platform-difference slice of the broader complete guide to mobile app testing; here is what actually changes when you move a test from Android to iOS, and why disciplined teams run two passes rather than one.
Why can't one mobile test plan cover both Android and iOS?
Because OWASP splits the same security requirement into two different tests, one per platform. For local storage, the Android test checks data held in "SharedPreferences, databases, Internal Storage, External Storage, etc." (OWASP MASTG, Android), while the iOS test for the same goal checks "NSUserDefaults, databases, KeyChain, Internal Storage, External Storage, etc." (OWASP MASTG, iOS). The requirement is identical; the things you inspect are not. A single cross-platform pass tends to test the intersection of the two platforms and quietly skip each one's signature surface, which is how a real weakness on one operating system survives a clean test run.
How does secure local storage differ: Keychain versus Keystore?
Both platforms keep key material off the app process, but iOS adds a layer Android has no direct equivalent of. On Android, stronger compliance routes through the Keystore: it "lets you store cryptographic keys in a container to make them more difficult to extract," with "key material never enters the application process" (Android Developers), and the MASTG notes that L2 storage compliance requires "cryptographic keys securely managed in the Android KeyStore" (OWASP MASTG). On iOS, small secrets belong in the Keychain, which "provides a secure way to store these items" (Apple Platform Security). The difference a tester must catch is the per-file Data Protection class: with NSFileProtectionComplete, "shortly after the user locks a device... the decrypted class key is discarded," whereas the default class for third-party data, NSFileProtectionCompleteUntilFirstUserAuthentication, leaves "the decrypted class key... not removed from memory when the device is locked" (Apple Platform Security). An iOS storage test must assert the right protection class; the Android test has no clean counterpart to that check.
How do network, TLS and certificate pinning testing differ?
Different files, different mechanisms, and different blind spots. Android configures network trust declaratively: since "Android 7.0 (API level 24), Android apps can customize their network security settings using the so-called Network Security Configuration feature" (OWASP MASTG), and that same Network Security Config "is the preferred and recommended way to implement certificate pinning in Android," with the caveat that "for communication from native code, NSC does not apply" (OWASP MASTG). iOS instead enforces App Transport Security from Info.plist: "starting with iOS 9, Apple introduced App Transport Security (ATS)... to always use HTTPS," requiring "TLS version 1.2 or greater" (OWASP MASTG). ATS has its own gap a tester must probe: it "only applies to the URL Loading System... It does not apply to apps that use lower-level APIs (like BSD Sockets)" (OWASP MASTG).
| Dimension | Android | iOS | Why testing differs |
|---|---|---|---|
| Secure local storage | Keystore-backed encryption of internal storage; key material "never enters the application process" | Keychain for small secrets, plus per-file Data Protection classes tied to passcode and lock state | iOS test must also assert the correct Data Protection class (the default is the weaker "until first user authentication"); no clean Android equivalent |
| Network and TLS defaults | Network Security Config (XML), Android 7.0+; cleartext blocked by default for Android 9+ | App Transport Security in Info.plist, iOS 9+; HTTPS with TLS 1.2 minimum |
Different config file and mechanism; ATS does not cover lower-level APIs, so an iOS tester checks beyond it |
| Certificate pinning | Preferentially declared in the Network Security Config; does not apply to native code | Handled in server-trust evaluation under ATS | Pinning lives in different places with different gaps on each platform |
| Anti-tampering | Root detection: su, process and package checks |
Jailbreak detection: file checks and a sandbox-escape write test | Different signals to detect and bypass; both "not very effective by itself" |
| Inter-app surface | Components exposed via android:exported and intents |
Sandbox limits IPC to a small set of sanctioned channels | Android has a broad component and intent surface that has no iOS counterpart |
| Distribution | Multiple app stores and sideloading | App Store is the only official distribution path; code signing gates execution | Android testing must assume untrusted install and tamper paths; iOS adds a review gate |
How does anti-tampering testing differ: root detection versus jailbreak detection?
Same idea, different mechanics, and the same honest caveat on both sides. On Android, "the goal of root detection is to make running the app on a rooted device a bit more difficult," and "like most other defenses, root detection is not very effective by itself, but implementing multiple root checks that are scattered throughout the app can improve the effectiveness" (OWASP MASTG). On iOS, "jailbreak detection mechanisms are added... to make running the app on a jailbroken device more difficult," and again it "is not very effective by itself, but scattering checks throughout the app's source code can improve the effectiveness" (OWASP MASTG). The detection signals are platform-specific: Android testing looks for su and process checks, while one iOS jailbreak check writes "to a location that's outside the application's sandbox... If the file is created successfully, the app can assume that the device has been jailbroken" (OWASP MASTG). A tester verifying these has to know which signals belong to which platform.
How does the inter-app attack surface differ: exported components versus the iOS sandbox?
This is the widest gap, and it is the one a cross-platform plan misses most often. Android exposes app components to other apps through the android:exported attribute: "if true, any app can access the activity and launch it by its exact class name," with consequences that include "other apps inappropriately accessing internal components" and "code execution in the context of the vulnerable application" (Android Developers). Android also carries deep-link collision risk, where "any arbitrary application can declare control over the exact same deep link belonging to another application" (OWASP MASTG). iOS has almost none of this surface: "iOS does not provide a general-purpose mechanism for third-party apps to communicate directly" (OWASP MASTG), and "compared to Android's extensive Binder IPC facilities, iOS offers very few IPC (Inter Process Communication) options, minimizing the potential attack surface" (OWASP MASTG). So an Android plan must enumerate every exported component and intent filter, while an iOS plan spends that effort on the small set of sanctioned channels such as custom URL schemes, where Apple's own guidance is that they "offer a potential attack vector into your app, so make sure to validate all URL parameters" (OWASP MASTG).
How does app distribution change what you test: sideloading versus App Store review?
The install path is part of the threat model, and the two platforms hand you different ones. Android "supports several app stores and sideloading," so a tester cannot assume a single vetted install path and must treat untrusted-source and on-device tampering scenarios as in scope (OWASP MASTG). iOS is the opposite: "Apple's App Store is the only official application distribution platform," and "you won't be able to run any code on an iOS device that hasn't been jailbroken unless Apple explicitly allows it" (OWASP MASTG). The App Store review even ties into the network test: since "January 1, 2017, Apple App Store review requires justification" for ATS exceptions (OWASP MASTG). Tools matter here too, but that is the subject of our companion guide to the open-source mobile security toolchain rather than this piece.
The verdict: test the platforms separately, against their own MASTG chapters
A single cross-platform pass is convenient and structurally incomplete. It tests what Android and iOS have in common and skips what makes each one distinct: the Data Protection class on iOS, the over-exported component on Android, the ATS exception that lower-level networking slips past, the deep-link collision that has no iOS analogue. The MASTG is built around this reality, with its own Android and iOS chapters for the same requirements, and the disciplined approach mirrors it: run an Android pass and an iOS pass, each mapped to its platform-specific tests, rather than one sweep that averages the two. That two-pass, per-platform design is the basis of Vervali's mobile application testing service, because the weaknesses that get apps breached tend to live in exactly the platform-specific places a generic plan never looks.
Sources
- OWASP MASTG, Testing Local Storage for Sensitive Data, Android (MASTG-TEST-0001). https://mas.owasp.org/MASTG/tests/android/MASVS-STORAGE/MASTG-TEST-0001/
- OWASP MASTG, Testing Local Data Storage, iOS (MASTG-TEST-0052). https://mas.owasp.org/MASTG/tests/ios/MASVS-STORAGE/MASTG-TEST-0052/
- Android Developers, Android Keystore system. https://developer.android.com/privacy-and-security/keystore
- Apple Platform Security, Keychain data protection. https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/web
- Apple Platform Security, Data Protection classes. https://support.apple.com/guide/security/data-protection-classes-secb010e978a/web
- OWASP MASTG, Android Network Security Configuration (MASTG-KNOW-0014). https://mas.owasp.org/MASTG/knowledge/android/MASVS-NETWORK/MASTG-KNOW-0014/
- OWASP MASTG, Certificate Pinning, Android (MASTG-KNOW-0015). https://mas.owasp.org/MASTG/knowledge/android/MASVS-NETWORK/MASTG-KNOW-0015/
- OWASP MASTG, iOS App Transport Security (MASTG-KNOW-0071). https://mas.owasp.org/MASTG/knowledge/ios/MASVS-NETWORK/MASTG-KNOW-0071/
- OWASP MASTG, Root Detection, Android (MASTG-KNOW-0027). https://mas.owasp.org/MASTG/knowledge/android/MASVS-RESILIENCE/MASTG-KNOW-0027/
- OWASP MASTG, Jailbreak Detection, iOS (MASTG-KNOW-0084). https://mas.owasp.org/MASTG/knowledge/ios/MASVS-RESILIENCE/MASTG-KNOW-0084/
- Android Developers, Safeguard exported components (android:exported). https://developer.android.com/privacy-and-security/risks/android-exported
- OWASP MASTG, Deep Links, Android (MASTG-KNOW-0019). https://mas.owasp.org/MASTG/knowledge/android/MASVS-PLATFORM/MASTG-KNOW-0019/
- OWASP MASTG, iOS IPC (MASTG-KNOW-0078). https://mas.owasp.org/MASTG/knowledge/ios/MASVS-PLATFORM/MASTG-KNOW-0078/
- OWASP MASTG, Custom URL Schemes, iOS (MASTG-KNOW-0079). https://mas.owasp.org/MASTG/knowledge/ios/MASVS-PLATFORM/MASTG-KNOW-0079/
- OWASP MASTG, iOS Platform Overview (sandbox, sideloading, code signing). https://mas.owasp.org/MASTG/0x06a-Platform-Overview/
Email Us
Call Us
