Build and Deployment in Mobile Development: What It Is, What Formats, and How It Works

Build Formats: APK, AAB, IPA

APK vs AAB

APK (Android Package Kit) — the traditional format for building and publishing mobile applications on Android. APK contains the entire code, resources, and manifest of the application. AAB (Android App Bundle) — a format introduced by Google in 2018 and made mandatory for new applications as of August 2021. AAB is not installed directly — Google Play dynamically generates an optimized APK for each device from AAB.

Advantages of AAB: download size is on average 15% smaller (by delivering only the necessary resources: correct screen densities, languages, CPU architectures). AAB also supports modular delivery — you can load modules on demand (Play Feature Delivery) or deferred (Play On-Demand). For developers, AAB is mandatory; for distribution outside Google Play (sideloading, marketplaces) — only APK.

IPA

IPA (iOS App Store Package) — the iOS installable file, which is a ZIP archive containing a signed application. IPA contains a Payload/ folder with the .app bundle, Provisioning Profile, and signature. IPA is built only on macOS via Xcode, which creates an archive (.xcarchive) and exports IPA. For distribution through the App Store, IPA is signed with an Apple Distribution Certificate; for Ad Hoc or Enterprise — with corresponding certificates.

Compilation and Optimization: JIT, AOT, ART, Bitcode

JIT vs AOT

JIT (Just-In-Time) — compilation of code during application execution, affecting build and deployment speed. On Android up to version 5.0 (Lollipop), Dalvik VM with JIT compilation was used. On each application launch, DEX bytecode was converted to machine code "on the fly". Drawback: slowdown on first launch and additional power consumption. AOT (Ahead-Of-Time) — compilation of code before application launch, during installation. Starting with Android 7.0 (Nougat), ART (Android Runtime) compiles the application fully during installation.

ART (Android Runtime) — the runtime environment that replaced Dalvik in Android 5.0. ART uses a hybrid approach: AOT compilation during installation + JIT for frequently executed methods. This combines AOT speed (fast startup) with JIT flexibility (adaptive optimization). Result: Android application performance increased by 20–30% compared to Dalvik. For developers, the transition to ART is transparent — code requires no changes.

Bitcode and App Thinning

Bitcode — an intermediate representation of code (IR) that Apple uses to recompile IPA for different processor architectures. Bitcode is optional: for iOS applications it is enabled by default, for watchOS and tvOS it is mandatory. Apple can recompile Bitcode when new processors are released without developer involvement. App Thinning — Apple's technology that includes Slicing (delivering only the resources needed for the device) and On-Demand Resources (loading resources on demand). App Thinning reduces the download size from the App Store by 30–50%.

DEX — bytecode format for Android, executed by ART/Dalvik. Kotlin/Java source code is compiled into class files, then into DEX via dx or d8 (a modern and faster tool). Multidex — a mechanism for applications that exceed the 65,536 method limit in a single DEX file. In modern projects, multidex is enabled automatically if targetSdkVersion >= 21.

Code Signing: Code Signing, Keystore, Provisioning Profile

Android: Keystore

Keystore — a file containing the private key and certificate for signing an Android application during build. Keystore is created via keytool (the -genkey command) or Android Studio. Important: Keystore cannot be lost — without it you cannot update the application on Google Play. Signing parameters: keyAlias, keyPassword, storePassword, and storeFile. Format: JKS (Java KeyStore) or PEPK (Play Encrypted Private Key) for AAB.

App Bundle ID (Android) — the unique application identifier in package notation (com.example.app). Version Code — an integer for internal version numbering (each new build increments it). Version Name — a string displayed to the user (1.2.3). These parameters are set in the app-level build.gradle.

iOS: Apple Certificate and Provisioning Profile

Apple Certificate — a digital certificate that verifies the developer's identity. Types: Development (for debugging), Distribution (for App Store), Ad Hoc (for limited distribution). Certificates are created in Apple Developer Account and downloaded to Keychain. Provisioning Profile — a file that links the certificate, App ID (Bundle Identifier), and a list of allowed devices. Without a Provisioning Profile, the application will not run on a device.

Bundle ID (iOS) — the unique application identifier (com.example.app). Build Number — the build version, incremented with each build. Marketing Version — the version shown to the user. Version management: for iOS, parameters are set in Info.plist and Project Settings; for Android — in build.gradle. At IT Sectr, we automate version updates via Fastlane — this eliminates human errors during release.

Publishing Process in Stores

Google Play Console

Google Play Console — a tool for publishing Android applications. Process: register a developer account ($25 one-time), create an application, fill in metadata (name, description, screenshots, category), upload AAB, configure pricing and distribution, review. Google checks the application automatically (for viruses, policy violations) and manually for some categories. Review takes from a few hours to 2–3 days.

App Store Connect

App Store Connect — Apple's platform for publishing iOS applications. Process: Apple Developer account ($99/year), create an application in App Store Connect, prepare IPA in Xcode (Archive → Distribute App → App Store Connect), upload via Transporter or Xcode, fill in metadata, submit for review. App Review — Apple's manual review can take from 24 hours to 7 days. Typical reasons for rejection: non-working buttons, incomplete content, permission requests without explanation.

Beta Testing: TestFlight, Closed/Open Beta

TestFlight (iOS)

TestFlight — Apple's official tool for beta testing iOS applications. TestFlight supports Internal Testing (up to 100 testers by email, no review) and External Testing (up to 10,000 testers, with Apple review). Builds are available for 90 days, after which a new build must be uploaded. TestFlight automatically updates the application for testers when a new build is uploaded.

Internal / Closed / Open Beta (Android)

Internal Testing (Android) — up to 100 testers, no Google review, build is available immediately. Closed Beta — up to 1000 testers by email or Google Groups, no review. Open Beta — unlimited testers via a public link, with Google review. Staged Rollout — gradual increase in the percentage of users receiving the update (5% → 20% → 50% → 100%). This is the safest release method.

App Thinning (iOS) — automatic reduction of the downloaded IPA size: Slicing (only necessary resources for the device), Bitcode (processor optimization), On-Demand Resources (download on demand). At IT Sectr, we use TestFlight for iOS beta testing and Internal Testing for Android — this allows us to catch issues before a mass release.