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.
Yes. IPA inspector, IPA analyzer and IPA file checker are three names for the same job: reading what an .ipa declares without installing it. This page opens the archive in your browser and shows the bundle ID, version and build, minimum iOS version, device families, architectures and the embedded provisioning profile, plus a static security scan and a file explorer.
Yes. It reads an .ipa in your browser without installing it and shows what the build declares: bundle ID, version and build, minimum iOS, device families, privacy permissions and URL schemes from the decoded Info.plist, architectures from the Mach-O header, and a summary of the embedded provisioning profile with its type, team, expiry and device count (the count, not the UDIDs). The Explorer tab is the viewer: it lists every file in the bundle, opens text files such as JSON and XML plists as text, and shows the first 16 KB of any file in hex.
Not to disk. The inspector reads the metadata and lets you look at files in the page, and you can copy what the Explorer tab is showing, but there is no button that saves a file out of the archive. To extract files, use the fact that an .ipa is an ordinary zip: rename it to .zip, or run unzip on it, and the whole Payload/YourApp.app bundle lands on your machine. Neither route decrypts an App Store app. Apple encrypts the executable of apps it distributes with FairPlay; the archive itself is not encrypted, so the metadata still reads, but the compiled code does not. The Binary panel under Security Analysis reports whether the executable is encrypted.
Open it here first. The inspector reads the app's declared privacy permissions, App Transport Security settings, Mach-O binary protections and any hardcoded secrets it can find, all in your browser, so you can see what the build asks for and how it is built before it touches a device. Treat it as triage rather than proof: a clean report lowers the odds of a nasty surprise but does not guarantee the app is benign.
Part of: Online IPA Installer
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 | Device builds are arm64 (arm64e for some system code). A simulator build can be x86_64 or, from an Apple Silicon Mac, arm64 as well, so the slice alone does not tell them apart: CFBundleSupportedPlatforms in Info.plist reads iPhoneSimulator for 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. The bundle identifier is one click to copy, and the build number sits next to the version string at the top of the report.
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 works as a plain IPA viewer: the complete file tree, with text files such as JSON and XML plists readable in place and the first 16 KB of any file shown in hex. It shows files rather than exporting them. To pull files out, unzip the .ipa on your own machine.
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.
