Release dalam pengembangan mobile: dasar-dasar, pembangunan, dan publikasi aplikasi

Apa itu build Release

Release — adalah konfigurasi build di mana semua optimasi kompiler diterapkan, informasi debug dihapus, sumber daya dikompresi, dan kode yang dapat dieksekusi diobfusaksi untuk melindungi kekayaan intelektual. Tujuan Release adalah mendapatkan file biner yang secepat dan sekompak mungkin, siap untuk didistribusikan melalui saluran resmi.

Berbeda dengan Debug, build Release tidak memiliki titik masuk untuk debugger, asersi dinonaktifkan, dan pencatatan diminimalkan. Ini bukan hanya mengubah bendera — ini adalah pipeline build yang berbeda dengan sertifikat, provisioning profile, dan pengaturan pengemasan yang berbeda. Build Release membutuhkan lebih banyak waktu karena kompiler melakukan lintasan optimasi tambahan.

Untuk iOS build Release ditandatangani dengan sertifikat Apple Distribution dan melalui verifikasi di App Store Connect. Untuk Android build Release ditandatangani dengan Upload Key dan dapat diunggah ke Google Play Console. Kedua platform memerlukan penandatanganan digital: aplikasi yang dibangun tanpanya tidak akan terinstal di perangkat pengguna.

Release dan Debug: perbandingan konfigurasi

Perbedaan antara Debug dan Release terlihat di semua tingkatan: dari bendera kompiler hingga ukuran akhir .apk atau .ipa. Memahami perbedaan ini sangat penting untuk pipeline CI/CD dan menemukan regresi yang hanya muncul di build Release.

Bendera kompiler

Di Release kompiler mengaktifkan optimasi berdasarkan ukuran (-Os untuk LLVM) atau kecepatan (-O2). Ini berarti penempatan fungsi inline, penghapusan kode mati, pengaturan ulang instruksi, dan optimasi loop yang agresif. Di Debug semua tahap ini dilewati, yang membuat kode lebih lambat tetapi mempertahankan kesesuaian penuh antara baris kode sumber dan instruksi mesin.

Obfuscation dan minifikasi

ProGuard/R8 (Android) mengganti nama kelas, metode, dan bidang menjadi nama pendek (a, b, c), yang mempersulit rekayasa balik dan mengurangi ukuran file DEX. Di iOS fungsionalitas yang setara disediakan oleh Strip Symbols dan Swift Symbolication. Penting untuk mengonfigurasi aturan keep untuk kelas yang digunakan melalui reflection atau di tata letak XML, jika tidak aplikasi akan crash dengan ClassNotFoundException saat startup.

Ukuran build

Build Release jauh lebih ringkas daripada Debug. Rasio tipikal: versi Debug memakan 40–80 MB, Release — 15–30 MB. Perbedaan ini disebabkan oleh penghapusan simbol debug (DWARF), kompresi sumber daya (aapt2), dan obfuscation DEX. Bagi pengguna, ukuran aplikasi adalah faktor penting dalam konversi instalasi, oleh karena itu optimasi ukuran di Release adalah praktik wajib.

Proses build Release di Android

Gradle menyediakan tugas bawaan untuk membangun versi Release: assembleRelease, bundleRelease (untuk AAB) dan signingReport. Konfigurasi build.gradle yang benar di tingkat modul adalah dasar dari build CI/CD yang stabil. Mari kita lihat langkah-langkah kunci pada contoh proyek tipikal.

Konfigurasi build.gradle

Di buildTypes konfigurasi release ditentukan: minification diaktifkan, shrinkResources dan aturan proguard diatur. Blok signingConfig harus merujuk ke storeFile, storePassword, keyAlias dan keyPassword — parameter ini tidak boleh disimpan di VCS. Untuk CI/CD gunakan variabel lingkungan atau Keystore Provisioning Plugin.

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

Membangun AAB dan APK

Android App Bundle (AAB) — format yang direkomendasikan untuk publikasi di Google Play. AAB tidak berisi satu APK, tetapi satu set sumber daya modular dari mana Google Play secara dinamis menghasilkan APK yang dioptimalkan untuk perangkat tertentu. Perintah ./gradlew bundleRelease membangun AAB, dan ./gradlew assembleRelease — APK universal untuk pengujian sebelum diunggah.

Penandatanganan dan verifikasi

APK/AAB yang ditandatangani diverifikasi melalui apksigner verify. Google Play Console secara otomatis memeriksa tanda tangan saat diunggah. Mulai Android 9 (API 28), Google memerlukan skema penandatanganan v2 atau v3. Untuk Wear OS dan Android TV tambahan diperlukan v3.1 dengan menentukan rotating key.

Proses build Release di iOS

Xcode membangun versi Release dalam konfigurasi Archive — ini bukan hanya build, tetapi pipeline lengkap: kompilasi dengan optimasi, pengemasan ke .xcarchive, penandatanganan dengan sertifikat Distribution dan ekspor ke .ipa. Proses dimulai melalui Product → Archive atau perintah xcodebuild.

Konfigurasi skema build

Di Edit Scheme → Run → Build Configuration pilih Release untuk pengujian akhir. Untuk mengirim ke App Store Connect gunakan Archive dari menu Product. Xcode membuat .xcarchive yang berisi file biner, dSYM, dan Resource-bundle. Dari arsip diekspor .ipa untuk distribusi Ad Hoc, Development, atau App Store.

App Store Connect dan TestFlight

TestFlight menerima build Release yang ditandatangani dengan sertifikat App Store Distribution. Sebelum dikirim ke App Store, build menjalani validasi otomatis di Xcode: kesesuaian sertifikat, keberadaan ikon semua ukuran, kebenaran Info.plist, dan tidak adanya arsitektur emulator di file biner diperiksa.

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

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

Bitcode dan App Thinning

App Thinning — teknologi Apple untuk mengurangi ukuran aplikasi yang diunduh. Saat diunggah ke App Store, Apple mengkompilasi ulang file biner untuk perangkat spesifik pengguna, menghapus arsitektur yang tidak digunakan. Bitcode (representasi perantara LLVM) diaktifkan di build Release jika proyek menggunakan iOS 14+ dan Xcode 12+.

Kesalahan umum saat mempersiapkan Release

Kesalahan konfigurasi build Release dibagi menjadi tiga kategori: masalah kompilasi, masalah penandatanganan, dan kesalahan logis yang muncul hanya setelah optimasi. Mari kita lihat skenario paling umum yang dihadapi pengembang saat beralih dari Debug ke Release.

ClassNotFoundException setelah obfuscation

Kesalahan paling umum di Android — crash saat startup setelah mengaktifkan minifyEnabled. Penyebab: R8 mengganti nama kelas yang digunakan melalui reflection (misalnya, Gson serialization, Retrofit @Body dengan data class). Solusi — tambahkan aturan -keep untuk semua kelas yang berpartisipasi dalam serialisasi dan periksa aturan proguard sebelum build.

Ketiadaan dSYM untuk symbolication

Di iOS pengembang sering lupa menyimpan file dSYM setelah Archive. Tanpa dSYM, log crash dari App Store Connect datang dalam bentuk alamat heksadesimal, bukan nama fungsi yang dapat dibaca. Solusi — konfigurasikan CI/CD untuk mengarsipkan dSYM bersama .ipa dan mengunggahnya ke App Store Connect.

Masalah dengan provisioning profile

Sertifikat Distribution kedaluwarsa atau App ID salah di provisioning profile — alasan penolakan build oleh App Store Connect. Sertifikat berlaku 1 tahun (Apple) atau 3 tahun (Google), dan perpanjangannya harus dimasukkan ke dalam kalender rilis. Pemeriksaan status sertifikat sebelum setiap build Release adalah langkah wajib dalam pipeline CI/CD.

Ketidakcocokan versi SDK dan deployment target

Masalah umum saat beralih dari Debug ke Release — penggunaan API yang tidak tersedia di versi target sistem operasi. Di Debug build diuji pada simulator dengan versi terbaru, di mana semua API baru tersedia. Di Release aplikasi diinstal di perangkat pengguna dengan versi OS yang berbeda, dan pemanggilan API yang tidak tersedia menyebabkan crash saat startup. Gunakan @available (Swift) atau compileSdkVersion + minSdkVersion (Android) untuk menentukan versi minimum secara eksplisit.

Lokalisasi yang hilang dan sumber daya untuk konfigurasi berbeda

Di build Debug, sumber daya sering dimuat dari direktori sumber tanpa memeriksa konfigurasi. Di Release, Gradle dan Xcode menerapkan pemfilteran sumber daya: jika string atau drawable tidak ditemukan di lokalisasi target, aplikasi akan crash atau menampilkan placeholder. Ini sangat kritis untuk Android: tidak adanya terjemahan di values-XX menyebabkan ClassCastException saat parsing XML. Periksa semua lokalisasi sebelum build Release dengan lint dan xcodebuild -showBuildSettings. Untuk mendeteksi masalah seperti itu, gunakan TestFlight dan Internal Testing track sebelum rilis publik — mereka berjalan di perangkat nyata dengan pengaturan bahasa yang berbeda.