IPA: What It Is, File Structure and How It Works

What Is IPA and What Is It Used For

IPA (iOS App Store Package) is a package format for distributing applications on the Apple platform. Like APK, IPA is technically a ZIP archive, but with its own structure dictated by iOS security and signing requirements.

History of the Format

The IPA format appeared alongside iPhone OS 2.0 in 2008 and the App Store. It was based on the .app bundle format from macOS, packaged in ZIP to reduce size during transmission. Since then, the IPA structure has not undergone major changes — only signing schemes and metadata have evolved.

Use Cases

App Store — the primary channel. Ad-hoc distribution — for testing on a limited number of devices (up to 100). Enterprise distribution — for corporate apps without publishing to the store. Developers also use IPA for testing on real devices via Xcode.

IPA File Structure from the Inside

The internal structure of an IPA is a ZIP archive containing a Payload folder with the .app bundle and metadata.

The .app Bundle

Inside the Payload folder is the app bundle with the .app extension. This is not a file but a directory that iOS recognizes as an application. Inside: the executable Mach-O file (name matches the bundle name), Info.plist, resources, images, and localized strings.

Mach-O Executable File

Source code in Swift or Objective-C is compiled into machine code in the Mach-O (Mach Object) format. The file contains __TEXT (code), __DATA (data), and __LINKEDIT (linker metadata) segments. Modern IPAs contain only the 64-bit arm64 architecture.

IPA Build Process via Xcode

Xcode automates the IPA build: from compiling source code to creating a signed archive ready for upload to App Store Connect.

Build Schemes

Debug — for development, no optimizations. Release — for publishing, with compiler optimizations. Each scheme defines compilation flags, code signing, and entitlements. Xcode creates an Archive via Product → Archive.

// Info.plist — basic application metadata
<key>CFBundleName</key>
<string>MyApp</string>
<key>CFBundleIdentifier</key>
<string>com.example.myapp</string>
<key>CFBundleVersion</key>
<string>1</string>
<key>CFBundleShortVersionString</key>
<string>1.0.0</string>

Build Architecture

Xcode compiles each .swift or .m file into an object file (.o), then links them into a single Mach-O binary. Resources (images, XIB, storyboard) are processed separately: storyboards are compiled into the binary .storyboardc format, images are optimized into Asset Catalog (.car).

IPA Signing and Provisioning Profile

Signing is the most complex aspect of an IPA. Apple requires a digital signature for any app running on a real device. The system verifies the developer certificate, entitlements, and Provisioning Profile compliance.

Signing Components

Certificate (Development or Distribution) — certifies the developer's identity. Provisioning Profile — links the certificate, bundle ID, and list of allowed devices (for ad-hoc). Entitlements — app permissions (push notifications, iCloud, App Groups).

Signing Process

Xcode signs each library and framework inside the .app bundle, then signs the bundle itself. The final IPA is signed at the ZIP archive level. Apple verifies all signing levels during installation. iOS will not launch the app if even one component has an invalid signature.

// Signature verification via Security framework
import Security

func checkSignature() -> Bool {
    let url = Bundle.main.bundleURL
    var staticCode: SecStaticCode?

    guard SecStaticCodeCreateWithPath(
        url as CFURL,
        [], &staticCode
    ) == errSecSuccess else {
        return false
    }
    return true
}

Publishing IPA to App Store Connect

App Store Connect is Apple's platform for managing app publishing. Uploading an IPA is done via Xcode Organizer, Transporter, or the command line using xcrun altool.

Upload Process

After creating an archive, Xcode offers Distribute App with a choice of method: App Store Connect, Ad-hoc, Enterprise, or Development. Selecting App Store Connect, the developer specifies the team and confirms the upload. Xcode verifies the signature, sends the IPA to Apple's servers, and returns the processing status.

Command Line

For CI/CD, xcrun altool or the newer notarytool is used. Apple requires notarization for macOS apps; for iOS this step is optional but recommended. xcodebuild -exportArchive creates a signed IPA ready for upload.

Apple checks each IPA for malicious code, private APIs, and compliance with App Store Review Guidelines. The review process takes from 1 hour to 2 days.

App Thinning: Optimizing IPA for Devices

When uploading an IPA to App Store Connect, Apple applies App Thinning — a technology that optimizes the binary for specific devices. Slicing removes resources for unsupported resolutions and architectures. On-Demand Resources allows loading parts of the app (game levels, videos) only on user request. Bitcode is an intermediate representation that Apple can recompile for new architectures without developer involvement.

App Store also checks IPA compliance with Sandbox requirements: the app must not access other apps' data, the file system outside its container, or hardware features without explicit user permission.

Testing IPA via TestFlight

TestFlight is Apple's official service for beta testing apps. The developer uploads the IPA to App Store Connect and invites testers via email or a public link.

Internal and External Testing

Internal Testing — up to 100 members from the developer's team. No Apple review required. External Testing — up to 10,000 testers, requires Beta App Review. TestFlight automatically distributes builds to testers and collects analytics.

TestFlight Limitations

A build is available for testing for 90 days after upload. TestFlight supports up to 100 active builds simultaneously. Each tester can install up to 30 apps at once. Crashlytics integrates with TestFlight to collect crash reports and non-fatal errors.

IPA and Continuous Integration

Building an IPA in a CI environment requires a macOS runner. GitHub Actions, GitLab CI, and Bitrise provide macOS environments for iOS builds. The Fastlane lane `build_app` automates the entire cycle: archiving, signing, exporting IPA, and uploading to TestFlight. For managing certificates and profiles, Match — a Fastlane tool — stores signatures in an encrypted Git repository.

Common IPA Issues

Developers encounter a number of characteristic errors when building and signing IPAs. Most are related to incorrect certificate and profile configuration.

Signing Error: No matching provisioning profile found

Xcode cannot find a Provisioning Profile matching the bundle ID and certificate. Solution — download current profiles in Xcode Accounts → Download Manual Profiles or use Automatic Signing.

ITMS-90125: The binary is invalid

This error occurs when uploading an IPA with an invalid architecture. Modern IPAs should contain only arm64. Including i386 or x86_64 in the binary causes rejection. Solution — check architectures in Build Settings and exclude simulator architectures.

Invalid Bundle Structure: The bundle is missing the required .app bundle

The IPA does not contain the correct Payload/App.app structure. Apple expects a precise hierarchy. Solution — verify that the archive includes a Payload folder with one .app bundle, not a flat list of files.

Distributing IPA without App Store

For enterprise distribution, the Enterprise Apple Developer Program is used ($299/year). The IPA is signed with an Enterprise certificate and can be installed on any company device without quantity limits. Ad-hoc distribution is limited to 100 devices per developer account ($99/year). MDM (Mobile Device Management) systems such as Jamf and Microsoft Intune support mass installation of Enterprise IPAs.