Drop an .ipa to read its bundle ID, version, frameworks, and provisioning — plus a full security analysis. Entirely in your browser.
Parsed with JSZip in your browser. Nothing is uploaded, logged, or stored on a server.
Bundle ID, version, frameworks and provisioning, plus a one-click security analysis tab.
Findings, hardcoded secrets, Mach-O binary protections, and a full privacy-permission audit.
Drop the .ipa on the inspector above and it is parsed in your browser. You get the bundle identifier, version and build, minimum iOS version, device families, architectures, frameworks and the embedded provisioning profile without installing the app or owning a Mac. An .ipa is also an ordinary zip archive, so renaming it to .zip and unarchiving it gives you the Payload/YourApp.app bundle to browse by hand.
A Payload/ folder containing exactly one .app bundle — the directory iOS installs on the device. Inside it are the compiled Mach-O executable, a binary Info.plist holding the app's metadata, Assets.car with the compiled images and icons, a Frameworks/ folder for embedded frameworks and dylibs, _CodeSignature/ with a hash for every resource, and embedded.mobileprovision, the provisioning profile the build was signed with.
No. The archive is unpacked and parsed in the page with JavaScript, so the file never leaves your machine and nothing is logged or stored. That also means you can inspect a build under NDA without it touching anyone's server. The practical ceiling is 250 MB per file, which is where in-browser parsing stops being comfortable.
All three live in the Info.plist inside the .app bundle, which Xcode writes as a binary plist, so a text editor shows mostly gibberish. The inspector decodes it and reports CFBundleIdentifier as the bundle ID, CFBundleShortVersionString with CFBundleVersion as the version and build number, and MinimumOSVersion as the oldest iOS release the build will run on.
Usually because that device is not in the provisioning profile the build was signed with. Ad Hoc and Development profiles only install on devices whose UDIDs are listed in the profile, so check the profile's device count and expiry date, then check the minimum iOS version against the tester's phone. Adding a device means registering its UDID in the Apple Developer portal and rebuilding. Re-signing the existing .ipa is not required if you can build again.
The inspector summarises the embedded profile: its type (Development, Ad Hoc, Enterprise or App Store), the team it belongs to, the expiry date with days remaining, how many devices it covers and how many entitlements it grants. For the full UDID list and the complete entitlement dictionary, take embedded.mobileprovision out of the bundle and open it in BetaDrop's provisioning profile decoder.
Yes. The Security Analysis tab runs a static pass in your browser: App Transport Security configuration, potential hardcoded secrets in bundled plists and text resources, Mach-O binary protections (PIE, ARC, stack canary, 64-bit, FairPlay encryption) and an audit of every privacy permission the app declares. It is fast triage, not a replacement for a full security review. A clean report is not a guarantee, and a flag is not always exploitable.
An .ipa is a zip archive with a fixed shape: a Payload/ folder holding exactly one .app bundle, which is the directory iOS installs on the device. Rename the file to .zip and any unarchiver will open it. The inspector above does the same thing in the page and then reads the parts that matter, so you do not have to dig through the bundle by hand, or own a Mac to look inside a build at all.
Inside Payload/YourApp.app there are six things worth knowing about:
CFBundleExecutable. Its header records which CPU architectures the build contains and which hardening features the compiler applied.Info.plist is the bundle's metadata dictionary: identifier, version, minimum iOS version, device families, permission strings, URL schemes. Xcode writes it as a binary plist, which is why opening it in a text editor shows mostly gibberish.Assets.car is the compiled asset catalogue holding icons and images, and usually one of the two largest files in the bundle.Frameworks/ holds embedded .framework bundles and .dylib files: your own dynamic frameworks, third-party SDKs, and on older deployment targets a copy of the Swift runtime._CodeSignature/CodeResources is a manifest of hashes covering every resource in the bundle. Edit one file after signing and its hash no longer matches, so iOS refuses the install.embedded.mobileprovision is the provisioning profile the build was signed with, wrapped in a signed container. This is the file that decides which devices may install the app.One thing that surprises people: a build you exported yourself is not encrypted. FairPlay encryption is applied when Apple distributes an app through the App Store, not by Xcode. Your own ad-hoc export is a readable zip, which is why a browser can take it apart, and why anyone you send the file to can do the same. Treat an .ipa as legible to whoever holds it.
Dropping a build in unpacks the archive, decodes the binary Info.plist, reads the Mach-O header of the executable and summarises the embedded profile. Here is what each headline field is for.
| Field | Read from | Why it matters |
|---|---|---|
| Bundle identifier | CFBundleIdentifier in Info.plist | Has to match the App ID on the profile that signed the build. It is also the app's identity on the device: a second build sharing the identifier replaces the first rather than installing beside it. |
| Version and build | CFBundleShortVersionString, CFBundleVersion | The version is what testers quote in bug reports; the build number is what actually distinguishes the four different binaries you all call “1.4”. |
| Minimum iOS version | MinimumOSVersion | A device running an older iOS than this cannot install the build. First thing to check when one tester in five reports a failure and the rest are fine. |
| Device families | UIDeviceFamily | Which hardware the build targets: iPhone, iPad, Apple TV, Apple Watch, Mac Catalyst or Vision Pro. |
| Architectures | Mach-O header of the executable | arm64 and arm64e are device slices. An x86_64-only binary is almost always a simulator build, which will never install on a phone no matter what you do to the profile. |
| Provisioning profile | embedded.mobileprovision | Type (Development, Ad Hoc, Enterprise or App Store), team, expiry date and how many devices it covers. This is what decides whether a given tester can install at all. |
| Entitlements | Entitlements dictionary in the profile | The capabilities the signature grants: push notifications, app groups, keychain sharing, associated domains. The inspector counts them; the profile decoder lists them. |
| Privacy permissions | NS…UsageDescription keys in Info.plist | Every permission the app can ask for, with the sentence the user is shown. iOS terminates an app that requests a permission whose usage string is missing. |
| URL schemes | CFBundleURLTypes | The deep-link entry points any other app on the device can invoke. Worth reading on a build you did not compile yourself. |
| Size by directory | Zip entry table | Where the megabytes went (asset catalogue, embedded frameworks or the binary), plus install size against compressed download size. |
The two fields most people need in a hurry are the bundle identifier and the build number: the first because it has to match the App ID on the signing profile, the second because “1.4” means nothing once four builds of 1.4 exist. Both are one click to copy.
The most common reason a perfectly good .ipa refuses to install is that the tester's device is not in the provisioning profile. Ad Hoc and Development profiles carry a list of UDIDs, one per registered device. At install time iOS compares the device's UDID against that list, and if it is missing the install fails with a message that never names the real cause.
The other profile shapes behave differently, which is why the inspector labels which of the four it found. An Enterprise (In-House) profile provisions all devices and carries no list at all: that is what makes enterprise builds install anywhere, and why Apple restricts the programme to internal employee distribution. An App Store profile has no device list either, because the store re-signs the app on the way out. A Development profile lists devices too, but is meant for the machines your team debugs on.
Two things on the profile card are worth checking every time. The device count tells you how far the build can reach: Apple caps ad-hoc registrations at 100 devices per product type per membership year, and slots only free up at renewal. The expiry date tells you how long the build stays usable: when a profile expires, copies already installed stop launching, not just new installs.
The inspector reports the profile type, team, expiry with days remaining, and how many devices and entitlements it covers. To read the actual UDID list or the full entitlement dictionary, take embedded.mobileprovision out of the bundle and open it in the provisioning profile decoder, which lists and copies every device. To collect a tester's UDID in the first place, send them the UDID checker; it takes a couple of taps on their phone.
Most people open an .ipa because something has already gone wrong. These are the usual cases and where to look.
Beyond the metadata, the Security Analysis tab runs a static pass over the bundle: App Transport Security configuration, potential hardcoded secrets in bundled plists and text resources, Mach-O protections (PIE, ARC, stack canary, 64-bit, FairPlay encryption) and an audit of every privacy permission the app declares. It is triage rather than a penetration test (a clean report is not a guarantee and a flag is not always exploitable), but it catches the obvious problems, an API key committed into a bundled JSON file being the most common of them.
The inspector does not upload your build. The archive is unpacked and parsed in the page with JavaScript, so the file stays on your machine: you can inspect a client's build under NDA without it touching anyone's server, and there is no account to create. The practical limit is 250 MB per file, which is where in-browser parsing stops being comfortable. If the summary does not cover what you need, the Explorer tab browses the complete file tree with text and hex viewers.
The next step is usually getting it onto a tester's phone. BetaDrop turns a signed .ipa into an over-the-air install link and QR code: it generates the itms-services manifest iOS needs, so the tester installs straight from Safari with no App Store review and no tester account. If you are unsure whether your build is signed the right way for that, can you sign an IPA online? covers when re-signing is genuinely needed and when rebuilding is the shorter road. For the Android half of the same job, the APK inspector reads the binary AndroidManifest.xml the same way: package name, SDK levels, permissions, components and native ABIs.
