IPA vs APK vs AAB: Which File to Upload and How (2026)

IPA vs APK vs AAB is the one decision every mobile app developer has to make without fully understanding what they’re choosing. Each file is a different archive, with a different structure, accepted by a different set of stores, built with a different command, and signed with a different key. Get it wrong and your upload bounces; get it right once and your CI pipeline runs clean for years.

This is the 2026 reference for all three. It covers what each format actually is, which store accepts which, how to build and upload each one with current tooling, and the signing wrinkles most other posts skip. If you only need the answer for your specific release, jump to the decision tree below. If you’re switching platforms or setting up a CI pipeline, read the upload-procedure section in full.

One note upfront. Apple’s rules around IPA submission changed with Xcode 16, and Google’s rules around AAB submission tightened again in August 2025 (target API 35) and November 2025 (16 KB memory page alignment). Some published guides still reference older requirements. The advice here is current as of April 2026 for both stores, and it pairs with our full ASO playbook for indie developers once your binary is ready to ship.

Quick-answer decision table

Ctrl-F this section if you only need the one-line answer.

What is an IPA?

IPA stands for iOS App Package. It is a ZIP archive containing the compiled .appbundle plus the provisioning profile, code signature, and metadata the App Store needs to distribute your build. Only the iOS App Store accepts IPAs — there is no cross-platform equivalent because Apple’s distribution model requires cryptographic signing tied to a specific Developer Program account.

What is inside an IPA:

• The compiled .app bundle (Mach-O executable, Info.plist, asset catalog, embedded frameworks).
• The provisioning profile (.mobileprovision).
• The code signature.
• PrivacyInfo.xcprivacy — required since May 2024 for apps that touch any required-reason API.

How to build one. Open your project in Xcode, pick Any iOS Device as the run destination, and choose Product → Archive. Xcode compiles, signs, and packages the app into an .xcarchive. From Organizer, choose Distribute App → App Store Connect and Xcode hands you a signed .ipa ready to upload.

How to sign one. You need an active Apple Developer Program membership, a Distribution Certificate, and a Provisioning Profile that matches your bundle identifier. Xcode automatic signing handles most of this. For CI, generate an App Store Connect API key and use xcodebuild -exportArchive with an export-options plist.

What is an APK?

APK stands for Android Package. It is a ZIP archive containing your compiled Android app — DEX (Dalvik Executable) bytecode, compiled resources, the AndroidManifest, assets, and the code signature. Every Android device can install an APK directly without any store involvement.

The 2021 enforcement. Google Play stopped accepting APKs for new apps in August 2021 and for updates to apps created after that date. Apps that existed on Play before August 2021 can still ship APK updates, but every new listing must be an AAB.

Where APKs still matter:

• Amazon Appstore (AAB is in beta but APK is the standard path).
• Samsung Galaxy Store, Huawei AppGallery, F-Droid.
• Sideloading via ADB: adb install your.apk.
• Internal distribution via MDM or QR-code install pages.
• Testing builds you send to a single beta tester outside a store flow.

How to build one. Command line: ./gradlew assembleRelease. Android Studio: Build → Generate Signed Bundle / APK → APK. Output lives in app/build/outputs/apk/release/.

How to sign one. Generate an upload keystore (keytool -genkey), configure Gradle signing (signingConfigs in your build.gradle.kts), build, and verify with apksigner verify. The upload keystore is yours to keep — never commit it to git.

What is an AAB?

AAB stands for Android App Bundle. Google introduced the format in 2018 as a superset of the APK. Instead of packaging one install-ready file, you package your app as a bundle of code and resources organised by module and configuration (screen density, ABI, language). When a user installs your app from Google Play, Play slices the bundle into a device-specific APK containing only the code, resources, and native libraries that phone actually needs. Play-delivered apps are typically 15–20% smaller than the equivalent universal APK.

Enforcement timeline:

• August 2021. New apps on Google Play must be AAB.
• August 2022. Updates to apps created on or after August 2021 must be AAB.
• August 2025. New apps must target API level 35.
• November 2025. Apps targeting Android 15+ must support 16 KB memory page size in their native libraries.

What is inside an AAB: a base module (always required), optional feature modules for on-demand and conditional delivery, optional asset packs for large assets like game levels, a bundleconfig.json that specifies how Play should split the bundle, and signing information tied to your upload key.

How to build one. Command line: ./gradlew bundleRelease. Android Studio: Build → Generate Signed Bundle / APK → Android App Bundle. Output is an .aab in app/build/outputs/bundle/release/.

How to sign one. Use your upload key — the same keystore you would use for an APK. With Play App Signing (the default since 2020), Google holds the app signing key that the final device-installed APKs are signed with, and you hold only the upload key. More on that distinction in the signing section below — it is the most-misunderstood part of AAB submission.

Which format to use — decision tree

If you are only releasing to one store, the answer is obvious. The confusion happens when you ship to multiple channels or migrate between them. The rules, ordered from most-common to least:

Use IPA if

• You are releasing to the Apple App Store — the only store that accepts iOS binaries.
• You are distributing through Apple Business Manager or Apple School Manager — same format, different entitlements.
• You are building Ad Hoc or Enterprise distributions for internal use.

Use AAB if

• You are shipping a new app to Google Play. Required since August 2021.
• You are updating an app on Google Play whose first upload was on or after August 2021. Required since August 2022.
• You want Google Play to slice per-device APKs automatically to cut install size.

Use APK if

• You are sideloading a build onto a device via ADB for testing.
• You are distributing to Amazon Appstore, Samsung Galaxy Store, Huawei AppGallery, F-Droid, or any Android store where AAB is not the primary format.
• You are shipping an enterprise-distributed internal Android app outside any store.
• You are updating a Google Play app whose first upload was before August 2021 — APK is still permitted, though AAB is strongly recommended.

How to upload each format in 2026

Three formats, three upload procedures, each with at least one CI-friendly option.

IPA → App Store Connect

• Transporter (easiest). Download the Transporter app from the Mac App Store, drag and drop your .ipa, sign in with your Apple ID, click Deliver.
• Xcode Organizer. Window → Organizer → Archives → Distribute App. Xcode uploads the archive, validates signing, and lands the build in App Store Connect within a few minutes.
• App Store Connect API for CI. Generate an API key in App Store Connect under Users and Access → Keys, then use xcrun altool --upload-app or the fastlane deliver / pilot actions in your pipeline.
• Push My App direct submission. Pass the binary through the Pre-Flight Scanner, then submit directly to App Store Connect from the dashboard. No Transporter, no Xcode, no API-key juggling.

APK → non-Play stores

• Amazon Appstore: Amazon Developer Console → Add New App → Binary File.
• Samsung Galaxy Store: Seller Portal → New App → Binary.
• Huawei AppGallery: AppGallery Connect → Version Management → Software Package.
• ADB sideload: adb install -r your.apk.

AAB → Google Play

• Play Console manually: Release → [track] → Create new release → Upload .aab. Write release notes, review, roll out.
• CI/CD: Google Play Developer API with fastlane supply or gradle-play-publisher. Both take a service account JSON and ship straight from CI.
• Push My App direct submission. The same Pre-Flight Scanner runs against the .aab — signing, 16 KB alignment, target SDK, debuggable flag — then submits to the Play track of your choice.

Common upload errors and their fixes

Every error above is in the full App Store rejection reasons index with the cited guideline and a longer-form fix. Most of them are detectable before upload — the Pre-Flight Scanner inspects your binary, your signing, and your privacy manifest against every item in that index.

Signing, upload keys, and Play App Signing

Signing is where developers lose days. One-page summary:

iOS

One Distribution Certificate and one Provisioning Profile per app. The certificate is tied to your Apple Developer Program account. If you lose the private key, you can revoke the cert and generate a new one without any user-facing impact — Apple re-signs apps during distribution. Xcode automatic signing matches certs to bundle identifiers for you.

Android — upload key vs app signing key

This is the confusion point.

• The upload key is the keystore you generate and hold. You use it to sign every .aab or .apk you upload to Play.
• The app signing key is what the final device-installed app is signed with. If you enrolled in Play App Signing (the default since 2020), Google holds this key. If you opted out, you hold both.

Why this matters. If your upload key is compromised, Play lets you rotate to a new one — because the app signing key Google holds remains unchanged and users see no break in the signing chain. If you did not enrol in Play App Signing and you lose your app signing key, you cannot publish updates to your existing users at all — you have to ship a new app under a new package name.

Back up every keystore. Store upload keys in a password manager and an encrypted offline backup. Store the passwords separately from the keystore files.

Frequently asked questions