IPA viewer: look inside an iPhone app
Got an .ipa from a developer, a company, a beta tester or a sideloading site? See what it is without a Mac: its name, version and build, the iOS it needs, every permission prompt it can show you in its own words, when its provisioning profile runs out, which devices it is allowed on, and who signed it.
The file is read by this tab only. It is not uploaded, not installed and not run.
What it shows
- Which app it is. The name on the Home Screen, the bundle ID (such as
com.example.notes, the ID iOS and the App Store know it by), the version (CFBundleShortVersionString) and build number (CFBundleVersion), the minimum iOS, and whether it is made for iPhone, iPad or both. The icon is drawn too, although Xcode stores it as a "crushed" PNG that ordinary image viewers cannot open. - Every permission prompt, in the app's own words. iOS puts the app's own sentence in each "Allow … to access your camera?" prompt, and the app must declare that sentence in its
Info.plistbefore it may ask. Each one is listed with what it unlocks: camera, microphone, photos, location while in use or always, contacts, calendars, Bluetooth, the local network, Face ID, Health, and the App Tracking Transparency prompt. - The provisioning profile (
embedded.mobileprovision): the team, the kind (Development, Ad Hoc, Enterprise or App Store), the expiry date with "expires in N days" or "expired", how many devices it allows, and the entitlements it grants. A sideloaded or test build stops opening the day its profile expires. - Who signed it. The signer certificate from the executable's code signature (for example "Apple Distribution: Company Name (TEAMID)"), its validity dates and chain, the identifier sealed into the signature, and the entitlements signed into the binary, which are what the app actually gets.
- Whether the code is still encrypted. Every app downloaded from the App Store arrives with its code encrypted (the Mach-O
LC_ENCRYPTION_INFOcommand sayscryptid 1). The page says so for each processor slice, so you can tell an App Store download from a developer's build. - What else is inside. URL schemes it opens, other apps it checks for, background modes (location, audio, VoIP…), whether it allows plain HTTP, app extensions such as widgets, keyboards, share sheets and VPNs, embedded frameworks with their versions, the Apple frameworks it links, and every file with its size.
What it cannot do
- It does not install or run the app. Nothing in the file is executed. Installing still needs a Mac, Apple Configurator, or a tool such as AltStore or Sideloadly, and a device the profile allows.
- It cannot decrypt an App Store binary. The FairPlay keys live only on devices signed in with the Apple ID that bought the app. The
Info.plist, profile, icon and file list are not encrypted, so they still read; the code itself does not. - Reading a signature is not a trust check. The certificate is read, not verified against the code or against Apple's roots and revocation lists. A re-signed or tampered app shows whatever certificate it carries. On a Mac,
codesign --verify --deep --verbose=2 App.appchecks it. - It is not a malware scan. Permission prompts and entitlements say what an app may ask for, not what its code does with it.
- No Assets.car, no translations. An icon kept only in the compiled asset catalogue is not drawn, and the prompt texts are the ones in
Info.plist; an app may show translated ones fromxx.lproj/InfoPlist.strings.
Useful to know about .ipa files
- What an .ipa is
- A ZIP archive with one folder,
Payload/, holding the app bundleName.app. Rename a copy to .zip and any unzip tool opens it. Inside the bundle are the executable (a Mach-O file, sometimes a "fat" one with several processor slices),Info.plist, the signature's seal in_CodeSignature/, the resources, and, for anything but an App Store download,embedded.mobileprovision. - Profile kinds
- A Development profile lists test devices and lets a debugger attach (
get-task-allowis true). Ad Hoc also lists devices, up to 100 of each device type per membership year, and is how most test builds are shared. Enterprise (in-house) has no device list and installs on any device that trusts the company; Apple revokes these certificates when they are shared publicly. An App Store profile is only for uploading; Apple re-signs the app it ships to customers. - When it stops working
- Paid-account Development and Ad Hoc profiles last up to a year. Profiles made with a free Apple ID, as AltStore and Sideloadly use, last 7 days, which is why sideloaded apps need refreshing every week. Once the profile has expired, iOS will not launch the app until it is re-signed. The expiry shown here is the profile's
ExpirationDate, compared with your device's clock. - Permission prompts
- Since iOS 10, an app that touches the camera, microphone, photos, contacts or calendars without the matching
NS…UsageDescriptionkey is closed by iOS. So the list here covers the protected data the app can ask for, and the text is what you would read in the prompt. Location has two levels: "While Using" and, asked separately later, "Always". - Encrypted or not
cryptid 1means the code pages are FairPlay-encrypted, which is how every App Store download arrives. A developer, Ad Hoc or Enterprise build hascryptid 0, as does an App Store app that was decrypted on a device. An App Store .ipa withcryptid 1cannot be re-signed into a working sideload, because only the buyer's devices can decrypt its code.