Release in Mobile Development: Basics, Build and Publishing Apps

What Is a Release Build

Release — is a build configuration in which all compiler optimizations are applied, debugging information is removed, resources are compressed, and the executable code is obfuscated to protect intellectual property. The goal of Release is to obtain the fastest and most compact binary file ready for distribution through official channels.

In contrast to Debug, a Release build does not contain entry points for the debugger, assertions are disabled, and logging is minimized. This is not just a flag switch — it is a different build pipeline with different certificates, provisioning profiles, and packaging settings. A Release build takes longer because the compiler performs additional optimization passes.

For iOS, the Release build is signed with an Apple Distribution certificate and undergoes review in App Store Connect. For Android, the Release build is signed with an Upload Key and can be uploaded to Google Play Console. Both platforms require digital signing: an app built without it will not install on a user's device.

Release vs Debug: Configuration Comparison

The difference between Debug and Release manifests at all levels: from compiler flags to the final size of the .apk or .ipa. Understanding these differences is critical for the CI/CD pipeline and for finding regressions that only appear in Release builds.

Compiler Flags

In Release, the compiler enables optimization for size (-Os for LLVM) or speed (-O2). This means inlining functions, dead code removal, instruction reordering, and aggressive loop optimization. In Debug, all these stages are skipped, making the code slower but preserving full correspondence between source lines and machine instructions.

Obfuscation and Minification

ProGuard/R8 (Android) rename classes, methods, and fields to short names (a, b, c), which complicates reverse engineering and reduces DEX file size. On iOS, equivalent functionality is provided by Strip Symbols and Swift Symbolication. It is important to configure keep rules for classes that are used via reflection or in XML layouts, otherwise the app will crash with ClassNotFoundException at startup.

Build Size

Release builds are significantly more compact than Debug builds. Typical ratio: a Debug version takes 40–80 MB, Release — 15–30 MB. The difference is due to the removal of debug symbols (DWARF), resource compression (aapt2), and DEX obfuscation. For users, app size is an important conversion factor for installs, so size optimization in Release is a mandatory practice.

Release Build Process on Android

Gradle provides built-in tasks for building a Release version: assembleRelease, bundleRelease (for AAB), and signingReport. Proper configuration of build.gradle at the module level is the foundation of a stable CI/CD build. Let's walk through the key stages using a typical project as an example.

build.gradle Configuration

In the buildTypes block, the release configuration is specified: minification is enabled, shrinkResources is turned on, and proguard rules are set. The signingConfig block must reference storeFile, storePassword, keyAlias, and keyPassword — these parameters must not be stored in VCS. For CI/CD, use environment variables or the Keystore Provisioning Plugin.

android {
    buildTypes {
        release {
            minifyEnabled true
            shrinkResources true
            proguardFiles getDefaultProguardFile(
                "proguard-android-optimize.txt"
            ), "proguard-rules.pro"
            signingConfig signingConfigs.release
        }
    }
}

Building AAB and APK

Android App Bundle (AAB) is the recommended format for publishing to Google Play. An AAB contains not a single APK but a modular set of resources, from which Google Play dynamically generates an optimized APK for a specific device. The command ./gradlew bundleRelease builds an AAB, while ./gradlew assembleRelease builds a universal APK for testing before upload.

Signing and Verification

A signed APK/AAB is verified via apksigner verify. Google Play Console automatically checks the signature upon upload. Starting from Android 9 (API 28), Google requires v2 or v3 signing schemes. For Wear OS and Android TV, v3.1 with a rotating key is additionally required.

Release Build Process on iOS

Xcode builds the Release version in Archive configuration — this is not just a build but a full pipeline: compilation with optimization, packaging into .xcarchive, signing with a Distribution certificate, and exporting to .ipa. The process is initiated via Product → Archive or the xcodebuild command.

Build Scheme Configuration

In Edit Scheme → Run → Build Configuration, select Release for final testing. To submit to App Store Connect, use Archive from the Product menu. Xcode creates an .xcarchive containing the binary file, dSYM, and resource bundles. From the archive, .ipa is exported for Ad Hoc, Development, or App Store distribution.

App Store Connect and TestFlight

TestFlight accepts Release builds signed with an App Store Distribution certificate. Before submission to the App Store, the build undergoes automatic validation in Xcode: certificate compliance is checked, icons of all sizes are verified, Info.plist correctness is confirmed, and simulator architectures are checked for absence in the binary file.

# Building Release via xcodebuild
xcodebuild archive \
  -project MyApp.xcodeproj \
  -scheme "MyApp" \
  -configuration "Release" \
  -archivePath "build/MyApp.xcarchive"

# Exporting .ipa for App Store
xcodebuild -exportArchive \
  -archivePath "build/MyApp.xcarchive" \
  -exportPath "build/" \
  -exportOptionsPlist "export.plist"

Bitcode and App Thinning

App Thinning is Apple's technology for reducing the size of the downloaded app. When uploading to the App Store, Apple recompiles the binary file for the specific user device, removing unused architectures. Bitcode (LLVM intermediate representation) is included in Release builds if the project uses iOS 14+ and Xcode 12+.

Common Mistakes When Preparing a Release

Release build configuration errors fall into three categories: compilation issues, signing issues, and logical errors that only appear after optimization. Let's look at the most common scenarios developers face when transitioning from Debug to Release.

ClassNotFoundException After Obfuscation

The most common error on Android — a crash at startup after enabling minifyEnabled. The cause: R8 renamed a class used via reflection (e.g., Gson serialization, Retrofit @Body with data class). The solution is to add a -keep rule for all classes involved in serialization and check proguard rules before building.

Missing dSYM for Symbolication

On iOS, developers often forget to save dSYM files after Archive. Without dSYM, crash logs from App Store Connect arrive as hexadecimal addresses rather than readable function names. The solution is to configure CI/CD to archive dSYM along with .ipa and upload them to App Store Connect.

Provisioning Profile Issues

An expired Distribution certificate or incorrect App ID in the provisioning profile is the reason App Store Connect rejects the build. Certificates are valid for 1 year (Apple) or 3 years (Google), and their renewal should be factored into the release calendar. Checking certificate status before every Release build is a mandatory step in the CI/CD pipeline.

SDK Version and Deployment Target Incompatibility

A common issue when transitioning from Debug to Release — using APIs unavailable on the target OS version. In Debug, the build is tested on a simulator with the latest version, where all new APIs are available. In Release, the app is installed on user devices with different OS versions, and calling an unavailable API leads to a crash at startup. Use @available (Swift) or compileSdkVersion + minSdkVersion (Android) to explicitly specify the minimum version.

Missing Localization and Resources for Different Configurations

In Debug builds, resources are often loaded from source directories without configuration verification. In Release, Gradle and Xcode apply resource filtering: if a string or drawable is not found in the target locale, the app either crashes or shows a placeholder. This is especially critical for Android: missing translation in values-XX leads to ClassCastException when parsing XML. Check all locales before a Release build using lint and xcodebuild -showBuildSettings. To detect such issues, use TestFlight and Internal Testing tracks before public release — they run on real devices with different language settings.