Swift iOS penetration testing: What we test in native iOS apps

Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs Comprehensive Security Partner (CSP)

The Apple ecosystem projects an aura of impenetrable security. The hardware is locked down, the App Store review process is famously strict, and the Swift language itself eliminates many common memory corruption vulnerabilities present in C or Objective-C. This creates a false sense of security for many Nigerian fintech founders building native iOS applications.

The reality is that iOS security mechanisms are designed to protect the *user* from malicious apps. They are not designed to protect your *fintech company* from a malicious user. If an attacker downloads your app onto their own jailbroken iPhone, they have absolute control over the runtime environment. They can read the memory, intercept the network traffic, and bypass the client-side biometric checks you thought were uncrackable.

At Simpa Labs, we do not rely on automated source code scanners to tell you if your iOS app is secure. We act as the adversary. We extract the Mach-O binary, we patch the assembly instructions, and we manipulate the Objective-C runtime bridges on a live, jailbroken device. Here is a deep dive into our Swift iOS penetration testing methodology.

What a Swift iOS pentest covers

Our iOS penetration tests are structured around the four attack surfaces that produce real, critical findings in production fintech apps: local data storage, network communication, binary integrity, and API authorization. Every test is conducted manually using advanced dynamic instrumentation techniques.

1. Keychain and local storage analysis

The iOS Keychain is the only acceptable location to store persistent authentication tokens, client certificates, and symmetric encryption keys. However, simply using the Keychain is not enough; the accessibility configuration dictates the actual security boundary.

We verify that your app uses the Keychain with appropriate accessibility flags. The most common critical finding we report is developers using kSecAttrAccessibleAlways or kSecAttrAccessibleAfterFirstUnlock. This means the credentials remain accessible in memory even when the device is locked, and in some cases, can be extracted via iTunes backups. The correct scope for a fintech application's session tokens must always be kSecAttrAccessibleWhenUnlockedThisDeviceOnly, which explicitly prevents the token from migrating to the user's new iPhone via iCloud backup.

Beyond the Keychain, we inspect every data store the app writes to at runtime. Using our proprietary filesystem extraction pipelines, we pull the complete on-device file sandbox immediately after a user logs in and conducts a transaction. We rigorously inspect:

• NSUserDefaults: Frequently used to cache user profile data, tier levels, or onboarding flags. We often find developers accidentally writing complete API JSON responses into NSUserDefaults. If authentication tokens land here, they survive backups and are completely readable without a jailbreak using standard diagnostic tools.
• CoreData and SQLite databases: Checked for unencrypted transaction histories, BVN fragments, or session tokens stored as plaintext rows. If CoreData is used, we verify that the SQLCipher wrapper is implemented correctly and that the encryption key itself is not hardcoded.
• Plist files and caches: HTTP response caches in Library/Caches frequently contain complete API response bodies, including account balances and personal details. By default, iOS URLSession caches GET requests to disk.

2. App Transport Security (ATS) and certificate pinning

App Transport Security (ATS) enforces HTTPS for all network connections by default. We inspect the app's Info.plist for NSAllowsArbitraryLoads exceptions. Developers often add these exceptions to resolve connectivity issues during staging and mistakenly leave them in production builds. Finding this key set to true means the app will make unencrypted HTTP connections and accept any TLS certificate, making interception trivial with a proxy on the same Wi-Fi network.

If ATS is configured correctly, we then test your certificate pinning implementation with real bypass attempts. We inject custom payloads at runtime to hook the URLSession delegate's SSL verification functions. The goal is to confirm that pinning is actually enforced by the operating system, rather than just configured in the code but never called.

Many Nigerian fintech apps configure pinning libraries correctly but fail to call the validation method on *every* network request. If a single endpoint (like the profile picture upload API) fails to enforce pinning, an attacker can intercept that request to steal the Authorization header and replay it against the rest of the API.

3. Binary analysis and entitlements review

We extract the compiled Mach-O binary from the IPA file and run static analysis using military-grade disassemblers. Swift binaries are inherently harder to reverse engineer than Android APKs because they compile directly to ARM64 machine code rather than an intermediate bytecode. However, Swift binaries compiled for release still contain massive amounts of metadata.

The goals of our static analysis are to identify hardcoded secrets (API keys, internal staging endpoints, third-party SDK admin tokens), reconstruct authentication logic flows, and locate debug build artefacts left in production binaries. We map out the exact string offsets and cross-reference them with the functions that call your cryptographic routines.

We also extract the app's entitlements file and audit the declared capabilities. Excessive entitlements (like com.apple.security.network.server on a standard mobile banking app) expose unexpected attack surfaces to the operating system. We rigorously check for keychain access group sharing between apps from the same developer organization. Improper sharing configurations can allow a malicious companion app (or a compromised third-party SDK) to silently read the session credentials from your primary banking app's Keychain partition.

4. Objective-C runtime hooks on Swift apps

Even if an app is written entirely in 100% pure Swift, any code that interacts with UIKit, Foundation, or system frameworks crosses over into the Objective-C runtime territory. This architectural bridging is the Achilles heel of iOS client-side security.

Using advanced dynamic instrumentation frameworks, we hook these Objective-C method dispatch points (the objc_msgSend routine) to intercept data in transit between your Swift business logic and the underlying OS APIs. This is exactly how we validate that local authentication (Face ID or Touch ID) cannot be bypassed.

For example, if your app checks Face ID before allowing a transfer, we hook the LAContext evaluatePolicy result before your app ever reads it. We force the operating system to return a "success" boolean to your Swift code, regardless of whose face was actually scanned.

// Instrumentation payload to intercept LAContext biometric evaluation result
// This forces the iOS biometric subsystem to report a successful Face ID match
var LAContext = ObjC.classes.LAContext;
var evaluatePolicy = LAContext["- evaluatePolicy:localizedReason:reply:"];

Interceptor.attach(evaluatePolicy.implementation, {
  onEnter: function(args) {
    // Swap the reply block to always return success = true
    var replyBlock = args[4];
    // Forces the app to believe biometric succeeded regardless of sensor result
  }
});

5. API authorization and business logic testing

While tearing apart the iOS binary is highly technical, the most valuable and financially devastating findings are almost never found in the binary itself. They are found in the backend APIs the iOS app communicates with. Once we bypass SSL pinning, we extract the full traffic profile through an intercepting proxy. We then systematically replay and manipulate every authenticated request against your backend servers.

We look for Broken Object Level Authorization (BOLA) vulnerabilities, parameter manipulation (such as changing an accountId parameter to access another user's transaction history), and privilege escalation through endpoint chaining. Can a standard user call an endpoint intended only for the iOS admin dashboard?

For Nigerian fintech apps, we specifically test the flows that carry massive regulatory and financial risk: BVN lookup response manipulation, NIP transfer confirmation binding, transaction reference replay attacks, and webhook endpoint validation. A perfectly secure iOS binary communicating with a fundamentally flawed backend API is a guaranteed data breach.

What you get at the end

At the end of the engagement, you receive a written report with a severity-ranked list of all findings, complete reproduction steps for each vulnerability, and prioritized remediation guidance written specifically for your iOS engineering team. We do not provide generic advice; we provide the exact Swift code snippets required to secure your Keychain implementation or fix your URLSession configuration.

We also schedule a findings walkthrough call to ensure nothing is misunderstood. For Nigerian fintechs, the report is structured specifically to satisfy CBN IT audit documentation requirements and provide the necessary proof of security to enterprise partners.

Related reading

Blog: iOS penetration testing · iOS vs Android security comparison · Mobile app pentest checklist

Services: Penetration testing · API security testing