iOS Penetration Testing in 2026: Workflow, Tools, and Setup

Last updated: August 2026. Written by Josh Hutcheson, OnlineCourseing editor. Every tool below was checked against its own source repository and against the OWASP MASTG tool registry before publication — nine tools from our previous version did not survive that check. See our review methodology.

QUICK VERDICT

iOS runs on 31.6% of the world’s mobile devices as of July 2026, against Android’s 68.36%, according to StatCounter. That minority share is misleading as a measure of how much iOS testing work exists: the platform is heavily over-represented in banking, healthcare and enterprise deployments, which is exactly where paid assessment work lives.

It is also the harder of the two platforms to test, and the reason is structural rather than incidental. Apple encrypts App Store binaries, sandboxes every app, enforces code signing at load time and does not permit arbitrary sideloading. Each of those is a deliberate barrier, and each one has to be worked around before a test can begin at all — which is why an iOS engagement spends a disproportionate share of its time on environment setup compared with the equivalent Android job.

This guide is organised the way an actual assessment runs: the legal groundwork, the standard you test against, building a device you can work on, and then the five phases of the test itself with the current tooling for each. At the end there is a section most guides in this space leave out — the tools we removed, and the evidence that retired them.

What iOS penetration testing actually involves

iOS penetration testing is the authorised security assessment of an iPhone or iPad application, covering how it stores data on the device, how it communicates over the network, how it uses the platform’s own security features, and how well it resists being reverse-engineered or tampered with. It is an application security discipline first and a device-hacking discipline second — the target is nearly always somebody’s app, not somebody’s phone.

That distinction matters because it determines what you are looking for. A great deal of the actual findings in an iOS report are unglamorous: an authentication token written to a plist file in plain text, a database left unencrypted in the app’s Documents directory, a Keychain item stored with an accessibility class that survives a device lock, a debug endpoint left enabled in a production build, certificate pinning implemented in a way that a one-line Frida script defeats. None of that requires an exotic exploit. It requires systematic coverage.

The other half of the work is resilience testing — whether the app detects a jailbroken device, whether it notices a debugger attached, whether its anti-tampering checks can be neutralised. For a banking or payments app this is often the section the client cares most about, and it is the section where the runtime instrumentation tools below do all the heavy lifting.

Why iOS is harder to test than Android

Four platform decisions account for most of the difficulty, and understanding them explains why the toolchain looks the way it does.

1. App Store binaries are encrypted. Apple applies FairPlay encryption to apps distributed through the store, so the copy sitting on a device cannot be disassembled directly. You have to recover a decrypted copy from memory while the app is running — which is what Frida-ios-dump exists to do — or get an unencrypted build from the client.
2. Code signing is enforced at load time. Any binary you want to run has to carry a valid signature. That is why signing and sideloading tools such as Sideloadly and ios-app-signer are part of a standard iOS kit and have no real Android equivalent.
3. The sandbox is strict and there is no adb. Android gives you a first-party debug bridge with a shell. iOS gives you nothing comparable, so a large part of the ecosystem — libimobiledevice, iproxy, usbmuxd, ios-deploy — exists purely to reimplement the device communication Apple does not expose.
4. Objective-C and Swift runtimes behave differently. Objective-C’s dynamic message dispatch makes method hooking straightforward, which is why so much iOS tooling is built around it. Swift compiles to something much closer to a static native binary, with mangled symbol names, so a Swift-heavy app is measurably harder to instrument than an Objective-C one of the same age. Tools like swift-demangle exist specifically to claw back some of that readability.

There is a fifth practical constraint that is not a platform decision but affects every engagement: you need a macOS host for parts of the workflow. Xcode, its command line tools, class-dump and codesign are macOS-only. Much of the rest runs anywhere, but a test planned entirely on Linux will hit walls.

Before you start: authorisation is the whole game

Every technique on this page is lawful when you have written permission covering the specific application, and a criminal matter when you do not. In the United States that line is drawn by the Computer Fraud and Abuse Act; in the United Kingdom by the Computer Misuse Act 1990; most other jurisdictions have a close equivalent. The technical act is identical either way — the authorisation is the only thing that separates a paid assessment from an offence.

For iOS specifically there are three scoping questions worth settling in writing before any tooling is installed, because each of them has caught testers out:

• Whose device is it? Jailbreaking voids the warranty and, on a corporate-issued handset, may breach the device policy your client’s own IT team enforces. Test on a dedicated research device you own, or on a virtualised one.
• Whose backend is it? An app’s traffic terminates on servers that may belong to a third party — a payments processor, an analytics vendor, a mapping API. Authorisation from the app owner does not extend to those endpoints. Agree what is in scope at the network layer, not just the app layer.
• Whose data is it? A production build talking to production infrastructure means real user records. Insist on a test environment and test accounts, or get explicit written sign-off on handling live data.

SCOPE NOTE

The standard to test against: OWASP MASVS and MASTG

The single biggest difference between a professional iOS assessment and an ad-hoc poke around an app is that the professional one is measured against a published standard. For mobile that standard is the OWASP Mobile Application Security Verification Standard (MASVS), which defines what must be verified, paired with the Mobile Application Security Testing Guide (MASTG), which documents how to verify it.

MASVS organises the mobile attack surface into eight control groups. Working through them in order is the simplest way to guarantee a report has no blind spots:

• MASVS-STORAGE — secure storage of sensitive data on the device (data at rest).
• MASVS-CRYPTO — cryptographic functionality used to protect sensitive data.
• MASVS-AUTH — authentication and authorisation mechanisms used by the app.
• MASVS-NETWORK — secure communication with remote endpoints (data in transit).
• MASVS-PLATFORM — secure interaction with the platform and other installed apps.
• MASVS-CODE — data-processing best practice and keeping dependencies current.
• MASVS-RESILIENCE — resistance to reverse engineering and tampering.
• MASVS-PRIVACY — controls that protect user privacy.

CURRENT AS OF THIS UPDATE

The MASTG also maintains something more immediately useful for this article: a registry of testing tools, each with its own catalogue entry. We used it as an audit against our own list, and the result is the reason this page changed so much. Of the eleven tools the previous version recommended, exactly two — Frida and Burp Suite — appear in OWASP’s registry. The other nine do not, and when we checked each one individually, that absence turned out to be well-founded every time.

Learn the methodology behind the tools →

Building a device you can actually test on

This is the step that stops most people, and there are three viable routes. They are not equivalent, and the right one depends on what the engagement allows.

Route 1: a jailbroken research device

A jailbreak gives you a root shell, unrestricted filesystem access and the ability to load the Frida server as a system daemon — the fullest capability available and still the default for serious work. The practical constraint is hardware: jailbreaks track specific chip generations and iOS versions, not the latest release. palera1n covers, in the project’s own words, “A8 through A11, T2 devices, on iOS/iPadOS/tvOS 15.0, bridgeOS 5.0 and higher.” In practice this means buying an older iPhone specifically as a test rig rather than expecting your current handset to qualify.

Route 2: a non-jailbroken device with a repackaged app

You can inject the Frida gadget into an app, re-sign it, and install it on a stock device. objection automates the repackaging; Sideloadly handles signing and installation on both macOS and Windows. This works on current iOS versions and is often the only option when the client will not supply a legacy device — but you lose system-wide visibility, and you can only instrument the one app you repackaged.

One caution OWASP flags on its Sideloadly entry and which is worth repeating: signing requires an Apple developer account, and you should not use your personal one for this. Free accounts work, with a seven-day signature lifetime; a paid account gets you a year.

Route 3: virtualised iOS

Corellium runs virtual iOS devices in the cloud, giving root-level access to arbitrary iOS versions without needing a physical jailbreakable handset at all. OWASP catalogues it as a testing tool. It is a commercial product and priced accordingly, which puts it out of reach for individual learners, but for a consultancy that needs to test across many iOS versions it removes the entire hardware-procurement problem in one step.

Phase 1: getting a decrypted copy of the app

Nothing static happens until you have an unencrypted binary. An IPA pulled from the App Store is FairPlay-encrypted, and a disassembler pointed at it returns noise.

Frida-ios-dump is the standard answer. It is a Python script that, as OWASP describes it, “uses Frida’s Memory API to dump the memory of the running app and recreate an IPA file. Because the code is extracted from memory, it is automatically decrypted.” The tool has 3,922 stars on GitHub. OWASP’s own entry also names bagbak as an alternative worth knowing when frida-ios-dump struggles with a particular app.

Two supporting tools belong in this phase. The libimobiledevice suite (8,159 stars) is the cross-platform library that lets a computer talk to an iOS device at all — its iproxy utility forwards a TCP port over USB, which is how you reach the Frida server on the device without going over the network. And ipsw handles firmware images when you need to work with the OS itself rather than an app.

If the client can simply hand you an unencrypted build from their CI pipeline, take it. It is faster, more reliable, and removes an entire class of things that can go wrong mid-engagement. Ask before you start.

Phase 2: static analysis of the binary

With a decrypted IPA in hand, static analysis tells you what the app is made of before you run it.

MobSF — start here

MobSF is the automated first pass. Drop an IPA into its web interface and it returns a one-page overview covering the binary’s compiler protections, the entitlements and URL schemes in the Info.plist, hardcoded strings and secrets, and the ATS network configuration. OWASP’s entry notes that running MobSF on a macOS host produces slightly better class-dump output than running it elsewhere — a small detail that matters if you are choosing where to host it. The project has 21,667 GitHub stars and is actively developed.

MobSF will not find your best finding. What it does is clear the obvious ground in a few minutes so your manual time goes somewhere useful, and it produces a consistent baseline across every app you test.

class-dump and the Objective-C runtime

class-dump extracts Objective-C class, category and protocol declarations from a Mach-O binary — effectively recovering the app’s header files. That output is what tells you which methods exist and are therefore worth hooking in Phase 5. The official release is macOS-only, though OWASP notes an unofficial dockerised version exists for other platforms. The upstream repository (3,586 stars) has not seen a commit since April 2022, which is worth knowing, but the Mach-O format it parses has not changed either, so it still works.

Alongside it sit the Apple-supplied basics: otool and nm for load commands and symbols, codesign for signature and entitlement inspection, and plutil for converting binary property lists into something readable. OWASP catalogues all of them, and they cost nothing to learn because they ship with Xcode’s command line tools.

Disassemblers

For anything deeper than symbol inspection you need a disassembler. Ghidra is free, open source, maintained by the NSA and, at 73,827 GitHub stars, the most widely adopted reverse-engineering framework there is — its decompiler handles ARM64 well enough for most iOS work. radare2 is the command-line alternative, and it matters here for a specific reason covered in the next section. Hopper and IDA Pro are the commercial options; Hopper in particular has a following among iOS specialists for its Objective-C handling.

Phase 3: local data storage and the Keychain

This phase produces more real findings than any other, and it needs the least sophisticated tooling. The question is simple: after using the app normally, what has it left on disk, and is any of it sensitive?

Work through the app’s sandbox container systematically — the Documents and Library directories, NSUserDefaults plists, any Core Data or SQLite databases, cached network responses, and the WebKit cache if the app embeds web views. objection can list and pull these files directly; on a jailbroken device Filza gives you a filesystem browser on the handset itself.

The Keychain gets its own treatment. Keychain-Dumper (1,419 stars) exists, in OWASP’s words, to “check which keychain items are available to an attacker once an iOS device has been jailbroken.” The finding you are usually hunting is not that a credential is in the Keychain — that is correct behaviour — but that it was stored with an over-permissive accessibility attribute, so it remains readable when the device is locked. objection can dump the Keychain too, which is often more convenient mid-session.

Two smaller tools round the phase out: BinaryCookieReader parses the binary cookie files iOS apps leave behind, and iOSbackup reads encrypted iTunes backups, which is a legitimate source of app data when you cannot get onto the device directly.

Phase 4: network interception and pinning bypass

Burp Suite is the standard proxy, and it is one of only two tools from our previous list that survived the OWASP audit. Configure the device to route through Burp, install and explicitly trust the Burp CA certificate in the iOS settings — on iOS, installing a root certificate and trusting it are two separate steps, and missing the second is the most common reason a first-time setup silently fails. Burp Suite Community is free; Professional adds the active scanner and is the paid tier. mitmproxy and HTTP Toolkit are both catalogued by OWASP as alternatives, and mitmproxy in particular scripts well when you need to rewrite traffic programmatically.

Certificate pinning is what you will actually spend the time on. A well-built app rejects your proxy certificate even after it is trusted, and there are three standard ways through:

1. objection’s built-in bypass. OWASP lists “disable SSL pinning for popular methods” as a headline objection feature. It is one command and it works on a large share of apps, so try it first.
2. SSL Kill Switch 3. A jailbreak tweak that disables certificate validation, including pinning, system-wide across iOS and macOS apps. Note the version number: OWASP catalogues SSL Kill Switch 3, not the widely-linked version 2 — the current project describes itself as “next generation SSLKillSwitch with much more support.”
3. A targeted Frida script. When the app implements pinning in a custom way that the generic bypasses miss, you hook the specific validation function yourself. frida-multiple-unpinning is a community script that covers a wide range of implementations before you resort to writing your own.

One caveat that catches people: none of these help if the app does not use the standard networking stack. Flutter apps bundle their own TLS implementation and ignore the system trust store entirely — which is why OWASP catalogues reFlutter and disable-flutter-tls-verification as separate tools. Identify the framework before you start debugging a bypass that was never going to work.

Phase 5: runtime instrumentation

This is where iOS testing becomes genuinely powerful, and where a single tool dominates.

Frida — the foundation

Frida attaches to a running process and lets you inspect and rewrite its behaviour from JavaScript. On iOS it hooks the Objective-C runtime directly: OWASP’s entry describes instantiating Objective-C objects, calling static and non-static class methods, and tracing method calls, with “full access to memory, e.g. to read and/or write any structured data.” With 21,795 GitHub stars and releases shipping continuously, it is the one tool on this page that is genuinely not optional.

The practical uses are immediate: bypass a jailbreak-detection check by making the function return false, read a decryption key out of memory at the moment it is used, log every call to a method to understand a protocol, or change a return value to see how the app handles a state it was never meant to reach. Frida CodeShare hosts community scripts for common cases, so the first move is usually to check whether somebody has already solved your problem.

objection — Frida with the batteries included

objection (9,352 stars) sits on top of Frida and turns the common tasks into REPL commands. OWASP lists its iOS feature set as repackaging applications to include the Frida gadget, disabling SSL pinning for popular methods, accessing application storage to download or upload files, executing custom Frida scripts, dumping the Keychain, and reading plist files. For most testers objection is the day-to-day interface and raw Frida is what you drop to when objection does not cover the case.

Grapefruit, r2frida and Fridump

Grapefruit (1,379 stars, formerly Passionfruit) wraps much of the same capability in a web interface running on localhost:31337 — useful when you want to browse an app’s classes, files and Keychain visually rather than by command. r2frida marries radare2’s disassembler to Frida’s runtime access, so you can disassemble memory in a live process rather than a file on disk; it is the reason radare2 earns a place in the kit even if you prefer Ghidra for static work. Fridump handles bulk memory dumping when you are hunting for secrets that only exist at runtime.

One historical note worth having, because it explains a tool you will see in every older guide. Cycript was the original interactive runtime-exploration console for iOS. OWASP does not catalogue it — it catalogues Frida-cycript, which its entry describes as “a fork of Cycript including a brand new runtime called Mjølner powered by Frida.” The original was absorbed into the Frida ecosystem. If you want Cycript’s syntax, use the fork.

The current iOS penetration testing toolkit

Every tool below appears in the OWASP MASTG tool registry, and every one was confirmed actively maintained at the time of this update. Star counts are from the GitHub API on 30 August 2026.

WHY THERE ARE NO AFFILIATE LINKS ON THIS PAGE

Nine tools we removed, and the evidence that retired them

The previous version of this article recommended eleven tools. Nine of them are gone. We are documenting each removal rather than quietly deleting them, because these same nine still appear in most iOS tool listicles — if you have read one recently, you have probably been pointed at several dead projects.

Two patterns are worth extracting from that table, because they generalise beyond this page. First, a dead project rarely announces itself: iNalyzer and Paraben both return a healthy HTTP 200, because the vendor redirected the old URL to something else. You have to compare the URL you requested with the URL you landed on. Second, a GitHub repository’s “last pushed” date is not its last commit — iRET reports activity in 2024 while its most recent actual commit is from 2014.

Where to practise legally

You cannot learn this on somebody else’s app. Three deliberately vulnerable targets exist for exactly this purpose, and all are free.

• DVIA-v2 (Damn Vulnerable iOS App, 1,112 stars) is the most complete. It covers insecure data storage, jailbreak detection, runtime manipulation, transport layer flaws and binary patching, with each challenge mapped to a technique you will use on real engagements.
• OWASP MAS Crackmes, also known as the UnCrackable Apps, are the reverse-engineering challenges used as worked examples throughout the MASTG itself. Working them alongside the guide is the most efficient way to learn the methodology and the tooling together.
• Myriam (270 stars, still maintained) is the tool our previous version described incorrectly. It is a vulnerable app with security challenges — a target to attack, not an instrument to attack with — and on that correct footing it is a genuinely good beginner exercise.

How to learn iOS penetration testing properly

The tools are the easy part. What separates someone who can run objection from someone who can deliver a defensible report is the methodology underneath — scoping, systematic MASVS coverage, evidence capture, severity rating and writing findings a development team can act on. That is what structured training teaches and what tool tutorials do not.

A realistic order if you are starting from scratch: get comfortable with general penetration testing fundamentals first, because iOS-specific work assumes you already understand web traffic, authentication flows and how to write up a finding. Mobile is a specialisation layered on top of that, not an entry point.

We rank and review the options here: the best penetration testing courses covers the practical, hands-on end including the certifications that carry weight with employers, while our ethical hacking course rankings and broader cyber security courses are the better starting point if you are earlier in the journey.

See our ranked pentesting courses →

For the platform-specific skills that iOS work builds on, the rest of our tooling coverage is the natural next step: mobile app security testing tools for the Android side of the same job, web application penetration testing tools because almost every mobile app has a web backend, and the penetration testing methodology that structures all of it.

Frequently asked questions

Do I need a jailbroken iPhone for iOS penetration testing?

Not always, but it remains the fullest option. A jailbreak gives you a root shell, whole-filesystem access and the ability to run the Frida server as a system daemon. Without one you can still repackage a single app with the Frida gadget using objection and Sideloadly, which works on current iOS versions but limits you to that one app with no system-wide visibility. The third route is a virtualised device through Corellium, which gives full access on arbitrary iOS versions at a commercial price.

What is the single most important iOS pentesting tool to learn first?

Frida, without close competition. It underpins objection, Grapefruit, r2frida, Fridump and frida-ios-dump, so time spent understanding it pays off across the entire toolchain. Learn objection alongside it, since objection turns the most common Frida tasks into single commands and is what you will use day to day.

Is Cydia Impactor still usable in 2026?

No. Cydia Impactor’s own website states that as of late 2019 it can only install IPA files if you hold a paid Apple developer account, and that without one it will not function. Sideloadly and TrollStore have replaced it for sideloading, and OWASP catalogues Sideloadly rather than Impactor.

How do I get past certificate pinning in an iOS app?

Try objection’s built-in bypass first, since it covers the popular pinning implementations in one command. If that fails, SSL Kill Switch 3 disables certificate validation system-wide on a jailbroken device. For custom implementations, hook the specific validation function with a Frida script; the community frida-multiple-unpinning script covers many cases before you need to write your own. Note that Flutter apps bundle their own TLS stack and ignore the system trust store entirely, so they need reFlutter instead.

What standard should an iOS penetration test be measured against?

The OWASP Mobile Application Security Verification Standard (MASVS) defines what to verify across eight control groups covering storage, cryptography, authentication, network, platform interaction, code quality, resilience and privacy. The Mobile Application Security Testing Guide (MASTG) documents how to test each one. Note that MASTG v2.0.0, released on 30 June 2026, removed the MAS Checklist spreadsheet that earlier versions shipped.

Can I do iOS penetration testing without a Mac?

Partly, but you will hit limits. Xcode, its command line tools, class-dump and codesign are macOS-only, and MobSF produces better class-dump output on a macOS host. Frida, objection, MobSF itself, Burp Suite and Sideloadly all run on Windows or Linux, so a great deal of the workflow is portable. For sustained professional work a Mac removes friction you will otherwise keep working around.

Is iOS penetration testing legal?

It is lawful only with written authorisation covering the specific application and scope. Without it, the same actions fall under the Computer Fraud and Abuse Act in the United States, the Computer Misuse Act 1990 in the United Kingdom, or the local equivalent elsewhere. Settle three things in writing before you start: whose device you are testing on, which backend endpoints are in scope given that some belong to third-party vendors, and whether you are permitted to touch live user data.

Related reading: mobile app security testing tools · web application pentesting tools · penetration testing tools · WiFi penetration testing tools · Kali Linux tools · penetration testing methodology · best penetration testing courses · network penetration testing

Compare pentesting courses and certifications →

Related guides

For desktop testing, see our guide to pentest tools for Windows — including which tools run natively and which need WSL2. The Android and cross-platform side is covered in mobile app security testing tools.