Preparing an iOS app for expertise: a practical checklist

iOS is often seen as "secure by itself". Apps run in a sandbox, there is App Store review, code is signed. All true — but a cybersecurity expertise examines your app, not the platform. For the iOS app of our own product (Flutter), the expertise returned two high-severity findings: no protection against dynamic analysis tools and no jailbreak detection. Both fall under M7 — Insufficient Binary Protections in OWASP Mobile Top 10 (2024).

The list below is built on that experience. It is grouped by OWASP MASVS sections, so it is easy to match against findings in an expertise report.

1. Jailbreak and dynamic analysis protection (MASVS-RESILIENCE)

On a jailbroken device, sandbox restrictions weaken: other processes can read the app's files, access the Keychain, and swap out the app's functions at runtime. Tools such as Frida let someone inject code (hook) into the app and change its behaviour even without a jailbreak.

Here the expertise expects the app to:

• detect signs of a jailbreak (suspicious files, writable system directories, stores such as Cydia/Sileo);
• detect an attached debugger;
• detect Frida and other hooking tools;
• detect that the app has been re-signed (tamper);
• respond clearly to a threat: stop running or block important functions.

We closed this with the freeRASP library. The iOS configuration takes the bundle ID and Apple Team ID — if the app is re-signed with another team's certificate, the library notices. When a threat is detected, the user sees a clear blocking screen.

To verify: run the app on a jailbroken test device or with Frida attached and confirm the blocking screen appears. That is exactly how the expertise checks it.

2. App Transport Security (MASVS-NETWORK)

ATS blocks unencrypted HTTP connections on iOS by default. The trouble is that it is very easy to switch off. Info.plist should not contain this:

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <true/>
</dict>

If some external service still uses HTTP, do not disable ATS entirely — add an exception for that domain only (NSExceptionDomains) and document it. Ideally, there are no exceptions at all.

ATS covers the transport layer only. Certificate pinning is added separately. In our Flutter app we loaded only trusted root certificates into a Dart SecurityContext — it works the same way on iOS and Android.

3. Keychain and data storage (MASVS-STORAGE)

Tokens, session keys and personal data should not be kept in UserDefaults or a plain file — those are not encrypted and end up in device backups. The right place is the Keychain.

Within the Keychain, the chosen accessibility level matters too. For data that should not move to another device, use the options ending in ThisDeviceOnly, such as kSecAttrAccessibleWhenUnlockedThisDeviceOnly. In Flutter with flutter_secure_storage:

const storage = FlutterSecureStorage(
  iOptions: IOSOptions(
    accessibility: KeychainAccessibility.first_unlock_this_device,
  ),
);

One more subtlety: on iOS, Keychain items can survive the app being deleted. Add logic to clear old items on first launch.

4. Traces inside the app

The expertise also looks at traces the app leaves while it runs:

• Logs. In a release build, print/NSLog must not output tokens, phone numbers or request bodies.
• Background snapshot. When the app goes to the background, iOS saves a screenshot. On screens with sensitive data, cover the content when moving to the background.
• WebView. If the app has a WebView, clear its cookies and cache on logout. We added this as well.
• Clipboard. Restrict copying from password and code fields.

5. Code protection

Dart code should be built with flutter build ipa --release --obfuscate --split-debug-info=.... Endpoints and keys should not sit in the binary as plain strings. This topic is covered in detail in a separate article.

6. A short note on export compliance

The ITSAppUsesNonExemptEncryption key in Info.plist is App Store Connect's export control question. If the app only uses HTTPS and the system's standard encryption, it is usually set to false; with your own encryption algorithms, extra documentation may be required. This key is not directly part of the cybersecurity expertise, but it is also a question about encryption, and your answers to the two should not contradict each other. For your specific situation, rely on Apple's official documentation.

7. Submitting the IPA

• Clarify in advance which file the expertise expects: which build type, with which signature.
• The submitted IPA must be built with release settings — obfuscation and RASP behave differently in a debug build.
• The expertise asks for checksums of the file (MD5, SHA-1, SHA-256). Take them from the exact file you submit, and do not rebuild it.

Short checklist

1. Jailbreak, debugger, Frida and tamper are detected; there is a response to threats.
2. No NSAllowsArbitraryLoads; ATS exceptions are minimal and documented.
3. Certificate pinning is configured.
4. Sensitive data is in the Keychain at a ThisDeviceOnly level.
5. No sensitive data in logs, background snapshot is covered, WebView is cleared on logout.
6. Dart code is obfuscated.
7. The IPA is a release build, and checksums are taken from that exact file.

Security scan

Want your iOS app checked before submitting it for expertise? Request a security scan. The Claude AI agent and our specialist will go through the points above and tell you which issues to close first.