iOS vulnerability check: scanning, hardening, and remediation

    iOS gets a reputation for being inherently secure, but real production IPAs ship with leaked secrets, weak App Transport Security exceptions, broken Keychain access control, unsafe URL scheme handlers, and a long tail of subtler bugs. Apple's sandbox protects users from your worst behaviour — it doesn't protect your app, your users' data, or your backend from a determined attacker holding a copy of your IPA.

    This cluster covers the iOS-specific checks PTKD runs against your build and what each finding actually means. Use the lead sections below for the iOS threat model, then drill into the specific guide for whatever PTKD flagged in your last scan.

    2 guides in this cluster

    What Apple guarantees, and what it doesn't

    Apple's baseline gives you four big things automatically: a hardware-backed app sandbox, mandatory code signing, App Transport Security defaults, and a curated distribution channel. None of those four protects you from:

    • Reverse engineering of your IPA.Anyone with Frida or class-dump can read your bundle and pull out hardcoded strings, API endpoints, and the names of your private methods.
    • Jailbroken devices.The sandbox depends on kernel integrity. On a jailbroken device, the attacker can read your Keychain entries, hook your functions, and bypass biometric prompts.
    • Misconfigured Keychain access groups.Default access control allows reading from any device state. If you don't set kSecAttrAccessible explicitly to a backup-restricted value, your secrets sync via iCloud Backup.
    • ATS exceptions you forgot to remove."NSAllowsArbitraryLoads" ships in 11% of real production iOS apps and is the iOS equivalent of disabling TLS verification globally.

    Treat Apple's defaults as the starting line, not the finish line. Every meaningful iOS security control is opt-in.

    The five iOS must-dos before App Store submission

    1. Audit your Info.plist for ATS exceptions.Remove every NSAllowsArbitraryLoads / per-domain exception you can. Apple reviewers will ask why each remaining exception exists — be ready with an answer.
    2. Set explicit Keychain accessibility.Use kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly or stricter for tokens you don't want syncing via iCloud Backup.
    3. Disable backup for sensitive Documents files.Mark files with NSURLIsExcludedFromBackupKey so they don't replicate to iCloud Backup or transfer to a new device.
    4. Add jailbreak detection — but don't hard-block.Score risk, degrade features, or step up auth. Hard blocks cost you legitimate users and don't stop determined attackers anyway.
    5. Strip release symbols and disable swizzling debug logs.Build with DEBUG_INFORMATION_FORMAT = dwarf-with-dsym, separate the dSYM, and strip symbols from the shipped binary.

    How PTKD scans an IPA

    Upload your .ipa (the same file you would upload to App Store Connect) and PTKD runs three passes: static analysis against the Mach-O binary and bundled resources, App Transport Security audit against Info.plist, and SDK fingerprinting against a CVE feed including iOS- specific advisories.

    The report maps to OWASP MASVS controls, flags Apple review-blocking patterns (private API usage, missing privacy keys, deprecated entitlements), and gives copy- paste Swift / Objective-C snippets for each finding. No source code is required; the scanner works from the shipped binary.

    Where to start

    If you only have time for a few pages from this cluster, these are the most-asked guides.

    1. 01
      best iOS app security testing tools 2025 | PTKD

      Honest field guide to the iOS scanners — paid, free, and what each one actually catches.

    2. 02
      ios ipa malware scanner | PTKD

      How an IPA malware scan actually works, and why static-only tools miss runtime issues.

    All guides in this cluster

    Frequently asked questions

    Does Apple's App Review catch security bugs?
    Apple's review catches policy violations, private API usage, and obvious malware patterns. It does not catch weak crypto, leaked secrets, broken authorisation, or business-logic flaws. Don't treat App Review as a security scan — it isn't one. PTKD's scanner runs the checks Apple doesn't.
    Is the iOS Keychain actually secure?
    Yes, with two caveats. First, accessibility flags matter — defaults sync via iCloud Backup. Second, kSecAccessControl is required to gate decryption behind biometric auth; without it, Keychain entries decrypt as soon as the device is unlocked. Use kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly + SecAccessControl with userPresence for the tightest configuration.
    Do I need certificate pinning on iOS if ATS is enabled?
    ATS enforces TLS hygiene but doesn't pin certificates. If an attacker installs a custom root CA on the device — easy on jailbroken devices, possible on managed corporate fleets — ATS still trusts the connection. Pinning closes that gap for high-value APIs.
    Will jailbreak detection block all jailbroken users?
    Reliable detection blocks naive jailbreaks (Cydia present, Substrate hooks visible) but not modern stealth jailbreaks (Dopamine with Ellekit). Score risk: combine detection with attestation, behavioural signals, and server-side checks. Hard blocks are easy to bypass and frustrate legitimate users.
    What's the difference between TestFlight and App Store security checks?
    TestFlight builds bypass App Review's full check; they only get a lightweight pre-review. Issues that would block App Store approval often slip through TestFlight. Run a PTKD scan before TestFlight submission and again before App Store submission so you fix issues early instead of getting rejected late.