Short answer. A web or API pentest does not cover your iOS app. It covers the backend the app talks to. The iOS build adds attack surface that has no web equivalent: the IPA you distribute to every user, the data the app writes to a device you do not control, and a platform runtime where jailbreak detection, App Transport Security, certificate pinning and URL schemes are the actual controls. iOS and Android are two scopes because they are two builds with different storage models, different platform interfaces and different resilience controls. Testing follows the OWASP Mobile Application Security Verification Standard and Mobile Application Security Testing Guide, and the report evidences ISO 27001:2022 A.8.8 and A.8.29 plus SOC 2 CC7.1.
Cybersecify is a founder-led penetration testing firm in Bengaluru serving AI-first and API-first SaaS startups. This is the buyer-side explanation of what an iOS application pentest covers, what the App Store does and does not require, and when the honest answer is that you do not need one yet. The sample report is public if you want to judge the deliverable before talking to anyone.
The trigger is nearly always external. An enterprise prospect sends a vendor security questionnaire and asks for the most recent penetration test of the mobile application. Or an investor doing technical diligence asks the same thing. You have a report. Its scope section names your web application and your API, and the reviewer reads that section before anything else.
Does a web pentest cover my iOS app
It does not, and the reason is structural rather than a matter of thoroughness.
Your iOS app and your web app usually share a backend. A properly run API pentest covers that shared server side: authentication, authorization logic, business rules, injection surface. That work genuinely transfers, and a good vendor will tell you so rather than reselling it.
Three things do not transfer, because a browser cannot reach them.
The binary is distributed to the attacker. Every user who installs your app receives the application binary. It can be pulled from a device, decrypted, and disassembled. Class structure, embedded strings, hardcoded endpoints, bundled configuration files and any credential a developer assumed was hidden by compilation are all recoverable. Server-side code stays on the server; app code does not.
The app writes to a device you do not control. iOS applications persist data in the Keychain, NSUserDefaults, Core Data and SQLite stores, cache directories and log output. They also leak through two paths that surprise teams: the system pasteboard, which other applications can read, and the background snapshot that iOS captures when an app is suspended so it can render the app switcher. If the screen showing an account balance or a document is captured, that image sits on disk.
The platform runtime is adversarial. The user controls the operating system. That is what turns jailbreak detection, App Transport Security, certificate pinning, URL scheme handling and Universal Links into security controls rather than implementation details, and it is why the OWASP mobile standards carry a resilience control group that has no web counterpart.
This is the same structural argument as API pentest versus web app pentest, applied one layer further out. Different surface, different scope, different test.
Why does iOS need its own scope even if we already tested Android
Because a finding on one platform is usually absent on the other, and the fixes are different code.
Storage. Android has SharedPreferences and the Android Keystore. iOS has the Keychain, where the question that matters is which accessibility class the developer chose. A value written as accessible always behaves very differently on a locked or stolen device from one restricted to this device and reachable only once the device has been unlocked since boot. Alongside that, iOS file Data Protection classes determine whether files at rest are readable while the device is locked. None of these choices have Android equivalents.
Platform interfaces. Android exports activities, services, broadcast receivers and content providers. iOS exposes custom URL schemes, Universal Links and app extensions. Both can be abused, but the bug classes and the tests differ entirely.
Resilience. Android resilience testing means root detection and tamper detection. iOS means jailbreak detection and anti-debugging.
iOS-only leakage paths. The pasteboard and the background snapshot have no Android analogue in the same form, and both produce genuine findings in real engagements.
Cross-platform frameworks narrow the gap without closing it. In React Native or Flutter the business logic is shared, but the secure storage layer, the network configuration, the platform bridge and the packaging are per platform, and that is exactly where mobile findings concentrate.
That is why iOS and Android are quoted as two scopes: the Growth Pentest at INR 1,79,999 over 10 business days, against one scope at INR 74,999 for a single build.
What gets tested in an iOS app pentest
Testing follows the OWASP Mobile Application Security Verification Standard, currently v2.1.0, as the requirements standard, and the OWASP Mobile Application Security Testing Guide, currently v2.0.0, as the methodology. MASVS organises requirements into eight control groups covering storage, cryptography, authentication, network, platform interaction, code quality, resilience and privacy. Every finding carries the control group it violates plus a CWE identifier and a CVSS score, so your engineers can check the OWASP source themselves.
Static analysis of the IPA. Decrypting and disassembling the application binary, recovering the class structure, and reading what shipped inside the package. Strings and bundled resources are swept for hardcoded API keys, private endpoints, test credentials and internal hostnames. The Info.plist is reviewed for App Transport Security exceptions, declared URL schemes, requested permissions and their usage descriptions. Third-party SDKs are inventoried and checked against known vulnerable versions, which matters because an analytics or attribution SDK routinely collects and transmits more than the product team believes.
Keychain and local storage. What the app writes to the device during normal use, and whether any of it should not be there. The Keychain is the specific focus: what is stored in it, and under which accessibility class, because that choice determines whether the value is reachable on a locked or stolen device. Beyond the Keychain, session tokens in NSUserDefaults, personal data in an unencrypted Core Data store, full API responses cached to disk, and authentication material in log output are all common. File Data Protection classes are checked to see whether files at rest are actually protected while the device is locked.
Pasteboard and background snapshot leakage. Two iOS-specific paths worth calling out because they are frequently missed. Sensitive values copied to the general pasteboard are readable by other applications on the device. And when the app is backgrounded, iOS captures a snapshot of the current screen for the app switcher, which is written to disk. If the app does not obscure sensitive screens before suspending, account details or documents end up in an image file.
Cryptography and key handling. Whether platform cryptography is used correctly, whether keys are hardcoded, whether custom or weak algorithms have been introduced, and whether key material can be extracted at runtime.
App Transport Security and certificate pinning. Whether ATS is enforced or whether exceptions have been declared in the Info.plist, and for which domains. ATS exceptions are often added during development to unblock a local server and then shipped, which quietly permits weaker transport for those domains in production. Certificate pinning, where implemented, is then tested the way an attacker tests it, by attempting to defeat it at runtime with an intercepting proxy in place, because pinning that can be disabled by hooking a single function does not stop anyone from reading your API traffic.
Jailbreak detection and resilience. Whether the app detects a jailbroken device and whether the detection survives a determined bypass attempt. How much this matters depends entirely on your product. For payments, banking and anti-fraud it is a real control. For a general business SaaS client it usually is not, and we say so rather than inflating the severity to make the report look busier.
URL schemes, Universal Links and app extensions. Whether a crafted link can reach an authenticated screen, carry an injected parameter, or trigger an action without confirmation, and whether any registered scheme accepts input it should not.
Authentication and authorization on the mobile surface. Token storage and lifetime, refresh handling, and how Face ID or Touch ID is used. The recurring issue is a biometric prompt that gates only the user interface while the underlying session token remains usable, which looks like authentication and is not. Any authorization decision made on the client that belongs on the server is reported as a finding regardless of how the app presents it.
What do the Apple App Store Review Guidelines actually require for security
Less than most buyers assume. This is worth stating precisely, because vendors sometimes imply an App Store gate that does not exist.
Reading the App Store Review Guidelines directly:
- Guideline 1.6 Data Security is the security guideline. It says apps should implement appropriate security measures to ensure proper handling of user information and prevent its unauthorized use, disclosure or access by third parties. It does not mandate specific algorithms, methods or standards.
- Guideline 5.1 Privacy covers data collection and storage, data use and sharing, consent, data minimisation and retention, with subsections for health data, children and location.
- Guideline 2.5 Software Requirements covers using public APIs, supporting the current operating system, keeping the app self-contained rather than downloading code that changes its features, and not shipping harmful code.
None of these require you to hold a penetration test report, and Apple does not issue a security badge in exchange for one. What the pentest gives you is a defensible basis for the data-handling claims you are already making, and it surfaces the gap between what your app actually transmits and stores and what your privacy disclosures say. In our experience that gap is nearly always a bundled third-party SDK that nobody on the product team audited, rather than anything deliberate.
If your driver is a customer questionnaire rather than the App Store, security questionnaire content covers what those reviewers ask for.
What evidence does an iOS pentest give my SOC 2 or ISO 27001 auditor
Auditors want independent testing against a defined scope, with findings, severities, reproduction steps and verified remediation. That is what the report is.
For ISO 27001:2022, it supports A.8.8 management of technical vulnerabilities and A.8.29 security testing in development and acceptance. For SOC 2, it supports CC7.1 Vulnerability Detection, plus CC6.1 Logical Access where mobile authentication and authorization are in scope.
Two limits worth being direct about.
A pentest report does not evidence a secure development lifecycle control. That is demonstrated through process, meaning your design reviews, code review gates and release approvals, not through a test result. Any vendor mapping a test report onto a lifecycle control is stretching, and an experienced auditor will push back.
And Cybersecify is not a certification body. We are not CERT-In empanelled and we are not ourselves SOC 2 or ISO 27001 certified. We produce the evidence and the control mapping. The certificate or attestation is issued by an accredited certification body or a licensed CPA firm. For how the pieces assemble, penetration testing for SOC 2 covers auditor expectations on timing and format, and ISO 27001 controls explained covers Annex A.
Scheduling matters more than most buyers expect: book roughly 8 to 10 weeks before the audit. Testing is 5 or 10 business days. Your remediation is the long pole, and the retest needs to land inside the same evidence period.
How long does an iOS app pentest take and what does it cost
Published on our pricing page rather than quoted case by case:
- Startup Pentest, INR 74,999 plus taxes. One scope, 5 business days. The iOS app alone.
- Growth Pentest, INR 1,79,999 plus taxes. Two scopes, 10 business days. iOS plus Android, or iOS plus the API behind it.
Business days means Monday to Friday, with the weekend as buffer rather than counted testing time. Scopes run sequentially by default. Parallel execution is available on request, depends on tester availability at the time of booking, and is not guaranteed, so a customer deadline should not be built on it.
Both plans include one free retest within one month of the v1.0 report. The retest runs 1 to 3 business days and produces a v2.0 report superseding v1.0, with updated status per finding and fresh proof for each fixed issue. That is what an auditor or an enterprise reviewer will accept, as opposed to an email stating the findings were closed.
Both founders work on every engagement, with Rathnakara GN (OSCP, M.Sc Cyber Security) leading pentest delivery. If you are comparing quotes, pentest cost in India sets out the realistic range and what sits inside each tier, and how to evaluate a pentest vendor covers the questions that separate manual testing from a scanner with a report attached.
What do you need from us before an iOS pentest starts
Access is the part that slips, not the testing. Five things:
- A build we can install on a test device. In practice a TestFlight build, or a signed IPA with a provisioning profile that covers our device identifiers. We provide those identifiers at kickoff, and this is the single most common cause of a delayed start, so it is worth beginning early.
- Test accounts, at least two per role, in separate tenants. Authorization boundaries are tested by crossing them, which needs real accounts on both sides.
- The backend environment, named. Which API the build points at, and whether we are testing staging or production. If staging, we need to know where it differs on authentication, authorization and rate limiting, because a staging copy with authentication stubbed out yields findings that do not transfer to production.
- Any attestation, anti-tamper or fraud tooling, disclosed upfront. We will trip it. Agreeing that in advance is better than your on-call engineer discovering it.
- About 30 minutes with an engineer who knows the app. Enough to walk the flows that matter commercially, rather than the ones easiest to find from the outside.
For general first-engagement scoping, how to scope your first pentest covers the same ground.
When do I not need an iOS app pentest
Three cases where the honest answer is not yet.
The app is a thin web view wrapper. No local storage, no offline mode, no native integrations. Your real risk is in the web application and the API. Test those first and add the mobile scope when the app does something genuinely native.
Nobody has asked and the app handles nothing sensitive. No enterprise customer, no investor, no compliance programme, no regulated data. There is almost certainly higher-value security work available to you this quarter.
The backend has never been tested. Do that first. A server-side authorization flaw is exploitable by anyone with an HTTP client. Most local storage findings need physical access to an unlocked device or malware already on it. Address the wider blast radius first.
The case flips quickly if any of these hold: the app stores data locally for offline use, it handles payments or financial data, it uses Face ID or Touch ID as part of an authentication decision, an enterprise customer or auditor has explicitly asked, or you have anti-fraud requirements that depend on jailbreak detection actually holding.
What to do next
If you already hold a pentest report and want to know whether it covers your iOS build, send us the scope section. We will tell you what it covers and what it does not. No NDA required, no follow-up unless you ask for one.
If you would rather judge the output first, the sample report is public and the methodology page sets out the frameworks and how findings are scored and mapped. To talk it through, book a 30-minute scoping call with the founders.
iOS application pentest | Android application pentest | Pricing | Sample report | Methodology
Cybersecify is a Bengaluru-based founder-led cybersecurity consultancy serving AI-first and API-first SaaS startups. Both founders are on every engagement: Rathnakara GN leads pentest delivery, Ashok Kamat leads consulting and client work.