Free tool · no iTunes · no Xcode · file deleted after

IPA Analyzer
Decode any iOS build.

Drop an .ipa file to inspect its Info.plist — bundle identifier, version, minimum iOS, device family, embedded frameworks, and signing team. Same data Xcode would show you, without installing Xcode.

File is unzipped to a temporary directory and deleted immediately after analysis.

What you'll see

  • Identity — bundle display name, bundle ID, version, build, icon
  • Compatibility — minimum iOS, target SDK, supported device families (iPhone / iPad / Apple TV / Watch)
  • Build environment — Xcode build, platform name, SDK version
  • Frameworks & plugins — every embedded .framework and app extension (Pods, Flutter, React Native, etc.)
  • Signing — provisioning profile team name, expiration, and the registered device count from embedded.mobileprovision
IPA 101

What's inside an IPA file?

An IPA (iOS App Archive) is a ZIP archive containing an iOS app bundle. Renaming an .ipa to .zip and unzipping it reveals a Payload/ directory with the actual .app bundle inside.

Inside every IPA

  • Payload/<Name>.app/Info.plist — the app's identity card: bundle ID, version, supported devices, capabilities, URL schemes, declared privacy strings. This analyzer decodes it.
  • Payload/<Name>.app/<Name> — the Mach-O binary (compiled Swift/Objective-C).
  • Payload/<Name>.app/Frameworks/ — every embedded framework (CocoaPods, SPM, Flutter engine, etc).
  • Payload/<Name>.app/PlugIns/ — app extensions (Share, Widget, Watch, Siri).
  • Payload/<Name>.app/embedded.mobileprovision — the signed provisioning profile that says this build is allowed to run on these devices, signed by this team.
  • Payload/<Name>.app/_CodeSignature/ — Apple's code signature manifest, mapping every file to a SHA-256 hash so iOS can detect tampering.

Why analyze an IPA?

  • Pre-flight check before sharing. Confirm version, bundle ID, and provisioning team match before you send the build to testers.
  • Validate the signing team. The embedded.mobileprovision tells you which Apple Developer team signed the build and when the profile expires — useful if a tester reports "the app won't open".
  • Audit dependencies. See every embedded framework. Catches mistakes like accidentally shipping a debug-only logging framework into the release build.
  • Investigate compatibility. Inspect UIDeviceFamily and MinimumOSVersion to confirm the build will run on the testers' devices.

Common Info.plist keys, decoded

  • CFBundleIdentifier — the reverse-DNS bundle ID (e.g. com.yourcompany.yourapp). Must match the App ID on Apple Developer Portal.
  • CFBundleShortVersionString — the user-visible version (1.2.0). Shown in the App Store and in Settings.
  • CFBundleVersion — the build number (e.g. 123). Internal counter, must increase with each upload to App Store Connect.
  • MinimumOSVersion — the oldest iOS version this build supports.
  • UIDeviceFamily[1] iPhone only, [2] iPad only, [1, 2] universal.
  • DTXcodeBuild / DTSDKName — the Xcode build number and iOS SDK version the binary was compiled against.

Ship the IPA to your testers.

OTA install link, QR code, install analytics — all in one tap. The same parser that powers this analyzer runs the moment you upload.