An IPA (iOS App Store Package) file is the signed application archive used to distribute and install apps on iPhone, iPad and other Apple devices. In mobile distribution it plays the role that the APK plays for Android: it packages the compiled app bundle, its resources and its code signature into one file with the .ipa extension, which is technically a ZIP archive with a defined internal layout.
Most users never see an IPA, because the App Store and TestFlight handle download and installation. For developers and release engineers, however, the IPA is the unit that is built, signed, uploaded, reviewed and installed, and most distribution problems on iOS trace back to how it was signed and provisioned.
What an IPA file contains
Inside an IPA, a top-level Payload folder holds the `.app` bundle, a directory that contains the compiled executable, the Info.plist metadata file, compiled storyboards and asset catalogs, embedded frameworks and app extensions such as widgets. The _CodeSignature folder and the embedded provisioning profile tie the bundle to a developer identity and to a distribution method.
The table describes the most important parts of the archive.
| Element | Location in the archive | Purpose |
|---|---|---|
| App executable | Payload/AppName.app | Compiled ARM64 machine code |
| Info.plist | Inside the app bundle | Bundle ID, version, capabilities, permissions text |
| Embedded provisioning profile | embedded.mobileprovision | Which devices and services the app may use |
| Code signature | _CodeSignature folder | Proves integrity and developer identity |
| Frameworks and extensions | Frameworks and PlugIns folders | Shared code, widgets, share extensions |
| Resources | Asset catalogs, localizations | Images, strings, fonts and data |
An IPA uploaded to the App Store contains compiled, architecture-specific code and is processed by Apple after upload. Apple then applies app thinning, delivering to each device only the resources and code variants it needs, so the download size a user sees is usually smaller than the uploaded IPA.
How an IPA is built and signed
An IPA is produced from an Xcode archive through an export step that selects a distribution method and applies the matching certificate and provisioning profile. The process can run in Xcode or in automation with xcodebuild and CI services.
- Archive the app in release configuration, producing an
.xcarchivewith debug symbols. - Choose the distribution method, such as App Store Connect, ad hoc, enterprise or development.
- Sign with the matching certificate and embed the provisioning profile for that method.
- Export the IPA and, for store distribution, upload it to App Store Connect.
- Keep the dSYM files so crash reports can be symbolicated later.
Signing is strict because iOS refuses to run code that is not properly signed. The bundle identifier, entitlements, certificate and provisioning profile must all match; a single mismatch, such as an expired certificate or a push notification entitlement missing from the profile, produces an installation or upload failure.
Distribution methods for IPA files
The same app can be exported as different IPAs, one for each distribution channel. The method decides who can install the app and whether Apple reviews it.
| Method | Who can install | Apple review | Typical use |
|---|---|---|---|
| App Store | Public users in chosen regions | Full app review | Commercial release |
| TestFlight | Up to 10,000 external testers | Beta review for external testers | Beta testing |
| Ad hoc | Up to 100 registered devices per type | None | Small test groups, demos |
| Enterprise | Employees of one organization | None, strict program rules | Internal company apps |
| Custom apps | Specific organizations via business stores | App review | B2B distribution |
| Alternative marketplaces | Users in permitted regions | Notarization | Distribution outside the App Store |
TestFlight builds expire after 90 days, and ad hoc and enterprise IPAs stop working when their provisioning profile or certificate expires or is revoked. Teams that rely on these channels must plan re-signing before deadlines.
IPA compared with Android package formats
IPA is often compared with the two Android formats, APK and AAB. The main conceptual difference is that the IPA is both the upload and the installable format, while Android separates the publishing format from what devices install.
| Aspect | IPA | APK | AAB |
|---|---|---|---|
| Platform | iOS and iPadOS | Android | Android |
| Directly installable | Yes, with valid signing | Yes | No, store generates APKs |
| Signing control | Apple-issued certificates | Developer key | Play App Signing key |
| Device optimization | App thinning after upload | Universal or split APKs | Split APKs per device |
| Sideloading freedom | Very limited | Broad with user consent | Not applicable |
The practical consequence is that Apple controls the trust chain for every IPA. An Android developer can sign an APK with a self-generated key and share it directly, whereas an IPA installs only when an Apple-issued certificate and a valid provisioning profile authorize it for the device and distribution method. This stricter model limits casual sideloading and much mass-market malware, but it also makes certificate and profile management a routine part of iOS release work rather than an occasional chore.
Common problems with IPA files
Nearly all IPA issues are signing, provisioning or metadata errors, and they are found either at upload or when a tester tries to install the app.
- Unable to install on a test device because its UDID is missing from the ad hoc profile.
- Upload rejected because the build number was already used for that version.
- Missing purpose strings in Info.plist for camera, location or contacts, which causes rejection.
- Entitlement mismatch between the app and its profile, breaking push, iCloud or App Groups.
- Lost dSYM files, leaving production crash reports unreadable.
Teams reduce these failures with automated signing management, unique build numbers generated by CI and an archive of every shipped IPA together with its symbols, so any release can be reproduced and investigated later.
Stripped to the essentials
An IPA is the installation file of an iPhone or iPad app. It is a sealed package that holds the app and everything it needs to run.
The package carries a digital seal from Apple and the developer. If the seal is missing or broken, the device refuses to open it. Ordinary users never handle these files directly, because the App Store does it for them, but developers create and upload one for every release.
Where it is applied
A mobile team at a logistics company prepares a new version of its driver app. The CI pipeline archives the app, exports two IPAs: one signed for App Store Connect and one ad hoc build for 40 registered test phones used by warehouse staff. The ad hoc build lets supervisors check scanning workflows on site without waiting for any review.
After a week of testing, the team uploads the store IPA, distributes it to 300 external drivers through TestFlight, and finally submits it for App Store review. Because the pipeline stores each IPA with its dSYM files, a crash reported two weeks later is symbolicated immediately and traced to a single line of code.