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

Three file extensions, three completely different contracts: what’s inside the archive, which store will take it, what key signs it, and what happens when that key is lost. Most developers learn the differences the expensive way — a bounced upload the night of a planned release.

This is the 2026 version of the answer, and 2026 specifics matter: since April 28, App Store Connect only accepts builds made with Xcode 26 and the iOS 26 SDK; Google Play’s target API floor steps up to 36 on August 31; and Amazon’s Appstore for Android — long the default “second Android store” — shut down for non-Fire devices in August 2025. Guides written even a year ago now point at closed doors.

Jump to the decision tree if you just need today’s answer; read the upload and signing sections if you’re wiring CI. Once the binary question is settled, the pre-flight checklist covers everything else that bounces submissions.

Quick-answer decision table

What is an IPA?

An iOS App Package: a ZIP archive wrapping your compiled .app bundle together with the provisioning profile, the code signature, and — since May 2024 — the PrivacyInfo.xcprivacymanifest if you touch any required-reason API. Apple’s distribution model ties every IPA to a Developer Program identity, which is why nothing else accepts the format.

The 2026 build requirement. Since April 28, 2026, App Store Connect refuses uploads built with anything older than Xcode 26 and the iOS 26 SDK. Your deployment target can still reach back years; the toolchain cannot. If CI pins an old Xcode image, this is the wall it hits.

Building one: Product → Archive in Xcode with Any iOS Device selected, then Distribute App from the Organizer. CI pipelines use xcodebuild -exportArchivewith an export-options plist and authenticate uploads with an App Store Connect API key — the same key fastlane’s pilot and deliver ride on.

One newer wrinkle:in the EU, the same IPA can also ship through alternative marketplaces or your own website under the DMA rules — it passes Apple notarization rather than full App Review, but it’s still a signed IPA from the same pipeline.

What is an APK?

An Android Package: DEX bytecode, compiled resources, the manifest, and a signature in one ZIP that any Android device can install directly. It remains the universal install format — just no longer the universal publishing format.

Where APKs still matter in 2026:

• Sideloading and device testing: adb install -r your.apk.
• Samsung Galaxy Store, Huawei AppGallery, F-Droid.
• Amazon’s ecosystem — but only Fire TV and Fire tablets now. The Amazon Appstore for general Android devices closed on August 20, 2025, taking the most popular non-Play distribution channel with it.
• Enterprise/MDM distribution outside any store.

Building and signing: ./gradlew assembleRelease with a signingConfigs block pointed at your keystore; verify with apksigner verify. The keystore never goes in git — its management story is the signing section below.

What is an AAB?

An Android App Bundle is not installable. It is a publishing container: your code and resources organized by module and configuration (ABI, screen density, language), from which Google Play generates a minimal APK per device at install time. Typical result: downloads 15–20% smaller than a universal APK, with optional feature modules and asset packs for anything bigger.

The enforcement timeline that shapes Android releases:

• August 2021: new Play apps must be AAB.
• November 2025: apps targeting Android 15+ must ship 16 KB-page-aligned native libraries.
• Now: new apps and updates must target API 35.
• August 31, 2026: the floor rises to API 36 (Android 16) — which also makes edge-to-edge rendering non-optional.

Building one: ./gradlew bundleRelease, output in app/build/outputs/bundle/release/. You sign it with your upload key; what devices receive is signed by the app signing keyGoogle holds under Play App Signing — the distinction that the signing section unpacks, because it’s the most-misunderstood part of Android publishing.

Which format to use — decision tree

Use IPA if

• You’re shipping to the App Store or TestFlight — the only iOS path.
• You’re distributing via Apple Business/School Manager or EU alternative channels — same artifact, different review and entitlements.

Use AAB if

• You’re shipping anything new to Google Play — there is no choice to make.
• You’re updating a pre-2021 Play app and want smaller installs and Play App Signing’s recovery story — opt in and switch.

Use APK if

• You’re putting a build on a specific device right now (ADB, a tester’s phone, a demo unit).
• You’re distributing through Samsung, Huawei, F-Droid, Fire devices, or your own MDM.
• You’re updating a Play app grandfathered from before August 2021 — allowed, but the AAB migration is one Gradle task away.

How to upload each format in 2026

IPA → App Store Connect

• Xcode Organizer — archive, validate, distribute. The default for solo developers.
• Transporter— Apple’s drag-and-drop upload app, useful when the archive comes from a build machine.
• App Store Connect API — the CI path. An API key from Users and Access → Integrations drives fastlane’s pilot/deliver or your own scripts; no Apple ID 2FA in the pipeline.
• Push My App direct submission — the Pre-Flight Scanner checks the binary first, then submits to App Store Connect from the dashboard.

APK → everywhere else

• Samsung Seller Portal, Huawei AppGallery Connect, and F-Droid’s inclusion process each take a signed APK through their consoles.
• Fire devices go through the Amazon Developer Console — Android-phone targeting is gone, Fire TV and tablets remain.
• Direct: adb install, an MDM, or a download link with install-unknown-apps friction you should expect.

AAB → Google Play

• Play Console: Release → track → Create new release, upload, notes, roll out — remembering new personal accounts face the closed-testing gate covered in the beta testing guide.
• CI: the Play Developer API via fastlane supply or gradle-play-publisher, authenticated with a service-account JSON.
• Push My App: the same scanner validates signing, 16 KB alignment, target SDK, and debug flags, then submits to your chosen track.

Common upload errors and their fixes

Every one of these — plus the seventy-odd non-binary ways a submission dies — lives in the rejection reasons index, and the mechanical ones are exactly what the Pre-Flight Scanner automates.

Signing, upload keys, and Play App Signing

iOS: recoverable by design

One distribution certificate, one provisioning profile, both tied to your Developer Program account. Lose the private key and you revoke, regenerate, and re-archive — users never notice, because Apple controls the distribution signing chain. The operational risk on iOS is expiry breaking CI, not loss breaking users.

Android: two keys, one of them precious

• The upload key — yours. Signs everything you send to Play. Compromised or lost, Google can verify you and register a replacement.
• The app signing key — signs what devices install. Under Play App Signing (default since 2020, mandatory for new apps) Google escrows it. Self-managed and lost, your app is over: no update can ever reach existing installs, and the only path is a new package name starting from zero.

The practical rules: enroll in Play App Signing without agonizing (the recovery asymmetry settles the debate), keep the upload keystore in a password manager plus an encrypted offline backup, and store passwords separately from the files. Key hygiene is boring right up until it’s the whole company.

Frequently asked questions