Build dan publikasi dalam pengembangan seluler: apa itu, format apa dan cara kerjanya

Format build: APK, AAB, IPA

APK vs AAB

APK (Android Package Kit) — format tradisional untuk membangun dan mempublikasikan aplikasi seluler di Android. APK berisi seluruh kode, sumber daya, dan manifes aplikasi. AAB (Android App Bundle) — format yang diperkenalkan oleh Google pada tahun 2018 dan menjadi wajib untuk aplikasi baru sejak Agustus 2021. AAB tidak diinstal secara langsung — Google Play secara dinamis menghasilkan APK yang dioptimalkan untuk setiap perangkat dari AAB.

Keunggulan AAB: ukuran unduhan rata-rata 15% lebih kecil (dengan hanya mengirimkan sumber daya yang diperlukan: kerapatan layar yang tepat, bahasa, arsitektur CPU). AAB juga mendukung pengiriman modular — Anda dapat memuat modul sesuai permintaan (Play Feature Delivery) atau ditangguhkan (Play On-Demand). Untuk pengembang, AAB wajib; untuk distribusi di luar Google Play (sideloading, pasar) — hanya APK.

IPA

IPA (iOS App Store Package) — file instalasi iOS, yang merupakan arsip ZIP berisi aplikasi yang ditandatangani. IPA berisi folder Payload/ dengan bundel .app, Provisioning Profile, dan tanda tangan. IPA dibangun hanya di macOS melalui Xcode, yang membuat arsip (.xcarchive) dan mengekspor IPA. Untuk distribusi melalui App Store, IPA ditandatangani dengan Apple Distribution Certificate; untuk Ad Hoc atau Enterprise — dengan sertifikat yang sesuai.

Kompilasi dan optimasi: JIT, AOT, ART, Bitcode

JIT vs AOT

JIT (Just-In-Time) — kompilasi kode selama eksekusi aplikasi, yang memengaruhi kecepatan build dan publikasi. Di Android hingga versi 5.0 (Lollipop), Dalvik VM dengan kompilasi JIT digunakan. Setiap kali aplikasi diluncurkan, bytecode DEX diubah menjadi kode mesin «saat itu juga». Kekurangan: perlambatan pada peluncuran pertama dan konsumsi daya tambahan. AOT (Ahead-Of-Time) — kompilasi kode sebelum peluncuran aplikasi, selama instalasi. Mulai Android 7.0 (Nougat), ART (Android Runtime) mengompilasi aplikasi sepenuhnya selama instalasi.

ART (Android Runtime) — lingkungan runtime yang menggantikan Dalvik di Android 5.0. ART menggunakan pendekatan hibrida: kompilasi AOT saat instalasi + JIT untuk metode yang sering dieksekusi. Ini menggabungkan kecepatan AOT (startup cepat) dengan fleksibilitas JIT (optimasi adaptif). Hasil: kinerja aplikasi Android meningkat 20-30% dibandingkan Dalvik. Bagi pengembang, transisi ke ART transparan — kode tidak memerlukan perubahan.

Bitcode dan App Thinning

Bitcode — representasi antara kode (IR) yang digunakan Apple untuk mengompilasi ulang IPA untuk arsitektur prosesor yang berbeda. Bitcode bersifat opsional: untuk aplikasi iOS diaktifkan secara default, untuk watchOS dan tvOS bersifat wajib. Apple dapat mengompilasi ulang Bitcode saat prosesor baru dirilis tanpa keterlibatan pengembang. App Thinning — teknologi Apple yang mencakup Slicing (mengirimkan hanya sumber daya yang diperlukan untuk perangkat) dan On-Demand Resources (memuat sumber daya sesuai permintaan). App Thinning mengurangi ukuran unduhan dari App Store sebesar 30-50%.

DEX — format bytecode untuk Android, dieksekusi oleh ART/Dalvik. Kode sumber Kotlin/Java dikompilasi menjadi file class, kemudian menjadi DEX melalui dx atau d8 (alat yang lebih modern dan lebih cepat). Multidex — mekanisme untuk aplikasi yang melebihi batas 65.536 metode dalam satu file DEX. Dalam proyek modern, multidex diaktifkan secara otomatis jika targetSdkVersion >= 21.

Penandatanganan kode: Code Signing, Keystore, Provisioning Profile

Android: Keystore

Keystore — file yang berisi kunci privat dan sertifikat untuk menandatangani aplikasi Android selama proses build. Keystore dibuat melalui keytool (perintah -genkey) atau Android Studio. Penting: Keystore tidak boleh hilang — tanpa itu Anda tidak dapat memperbarui aplikasi di Google Play. Parameter penandatanganan: keyAlias, keyPassword, storePassword, dan storeFile. Format: JKS (Java KeyStore) atau PEPK (Play Encrypted Private Key) untuk AAB.

App Bundle ID (Android) — pengidentifikasi unik aplikasi dalam notasi paket (com.example.app). Version Code — bilangan bulat untuk penomoran versi internal (setiap build baru meningkatkannya). Version Name — string yang ditampilkan kepada pengguna (1.2.3). Parameter ini diatur dalam build.gradle tingkat aplikasi.

iOS: Apple Certificate dan Provisioning Profile

Apple Certificate — sertifikat digital yang memverifikasi identitas pengembang. Tipe: Development (untuk debugging), Distribution (untuk App Store), Ad Hoc (untuk distribusi terbatas). Sertifikat dibuat di Apple Developer Account dan diunduh ke Keychain. Provisioning Profile — file yang menghubungkan sertifikat, App ID (Bundle Identifier), dan daftar perangkat yang diizinkan. Tanpa Provisioning Profile, aplikasi tidak akan berjalan di perangkat.

Bundle ID (iOS) — pengidentifikasi unik aplikasi (com.example.app). Build Number — nomor build, meningkat setiap build. Marketing Version — versi yang ditampilkan kepada pengguna. Manajemen versi: untuk iOS, parameter diatur di Info.plist dan Project Settings; untuk Android — di build.gradle. Di IT Sectr, kami mengotomatiskan pembaruan versi melalui Fastlane — ini menghilangkan kesalahan manusia saat rilis.

Proses publikasi di toko

Google Play Console

Google Play Console — alat untuk mempublikasikan aplikasi Android. Proses: pendaftaran akun pengembang ($25 sekali), membuat aplikasi, mengisi metadata (nama, deskripsi, tangkapan layar, kategori), mengunggah AAB, mengonfigurasi harga dan distribusi, peninjauan. Google memeriksa aplikasi secara otomatis (virus, kepatuhan kebijakan) dan secara manual untuk beberapa kategori. Peninjauan memakan waktu dari beberapa jam hingga 2-3 hari.

App Store Connect

App Store Connect — platform Apple untuk mempublikasikan aplikasi iOS. Proses: akun pengembang Apple ($99/tahun), membuat aplikasi di App Store Connect, menyiapkan IPA di Xcode (Archive → Distribute App → App Store Connect), mengunggah melalui Transporter atau Xcode, mengisi metadata, mengirim untuk ditinjau. App Review — peninjauan manual Apple dapat memakan waktu 24 jam hingga 7 hari. Alasan penolakan umum: tombol tidak berfungsi, konten tidak lengkap, permintaan izin tanpa penjelasan.

Pengujian beta: TestFlight, Closed/Open Beta

TestFlight (iOS)

TestFlight — alat resmi Apple untuk pengujian beta aplikasi iOS. TestFlight mendukung Internal Testing (hingga 100 penguji melalui email, tanpa peninjauan) dan External Testing (hingga 10.000 penguji, dengan peninjauan Apple). Build tersedia selama 90 hari, setelah itu build baru harus diunggah. TestFlight secara otomatis memperbarui aplikasi pada perangkat penguji saat build baru diunggah.

Internal / Closed / Open Beta (Android)

Internal Testing (Android) — hingga 100 penguji, tanpa peninjauan Google, build tersedia segera. Closed Beta — hingga 1000 penguji melalui email atau Google Groups, tanpa peninjauan. Open Beta — penguji tidak terbatas melalui tautan publik, dengan peninjauan Google. Staged Rollout — peningkatan bertahap persentase pengguna yang menerima pembaruan (5% → 20% → 50% → 100%). Ini adalah metode rilis paling aman.

App Thinning (iOS) — pengurangan otomatis ukuran IPA yang diunduh: Slicing (hanya sumber daya yang diperlukan untuk perangkat), Bitcode (optimasi prosesor), On-Demand Resources (unduh sesuai permintaan). Di IT Sectr, kami menggunakan TestFlight untuk pengujian beta iOS dan Internal Testing untuk Android — ini memungkinkan kami menangkap masalah sebelum rilis massal.