Build és publikálás a mobilfejlesztésben: mi ez, milyen formátumok és hogyan működik

Build formátumok: APK, AAB, IPA

APK vs AAB

APK (Android Package Kit) — a mobilalkalmazások Androidon történő építésének és publikálásának hagyományos formátuma. Az APK tartalmazza az alkalmazás teljes kódját, erőforrásait és manifestjét. AAB (Android App Bundle) — a Google által 2018-ban bevezetett formátum, amely 2021 augusztusa óta kötelező az új alkalmazások számára. Az AAB nem telepíthető közvetlenül — a Google Play dinamikusan generál optimalizált APK-t minden eszközhöz az AAB-ből.

Az AAB előnyei: a letöltési méret átlagosan 15%-kal kisebb (csak a szükséges erőforrások szállításával: megfelelő képernyősűrűség, nyelvek, CPU-architektúrák). Az AAB támogatja a moduláris szállítást is — modulokat tölthet be igény szerint (Play Feature Delivery) vagy késleltetve (Play On-Demand). A fejlesztők számára az AAB kötelező; a Google Play-en kívüli terjesztéshez (sideloading, piacterek) — csak APK.

IPA

IPA (iOS App Store Package) — az iOS telepíthető fájl, amely egy ZIP-archívum aláírt alkalmazással. Az IPA tartalmaz egy Payload/ mappát a .app bundle-lel, Provisioning Profile-t és aláírást. Az IPA csak macOS-en építhető az Xcode-on keresztül, amely létrehoz egy archívumot (.xcarchive) és exportálja az IPA-t. Az App Store-on keresztüli terjesztéshez az IPA-t Apple Distribution Certificate-tel írják alá; Ad Hoc vagy Enterprise esetén — a megfelelő tanúsítványokkal.

Fordítás és optimalizálás: JIT, AOT, ART, Bitcode

JIT vs AOT

JIT (Just-In-Time) — a kód fordítása az alkalmazás végrehajtása közben, amely befolyásolja a build és publikálás sebességét. Az Android 5.0 (Lollipop) verzióig Dalvik VM-et használtak JIT fordítással. Minden alkalmazásindításkor a DEX bájtkód «menet közben» gépi kódra konvertálódott. Hátrány: lassulás az első indításkor és többlet energiafogyasztás. AOT (Ahead-Of-Time) — a kód fordítása az alkalmazás indítása előtt, a telepítés során. Az Android 7.0 (Nougat) verziótól kezdve az ART (Android Runtime) teljesen lefordítja az alkalmazást a telepítés során.

ART (Android Runtime) — a futásidejű környezet, amely az Android 5.0-ban váltotta fel a Dalvik-ot. Az ART hibrid megközelítést használ: AOT fordítás telepítéskor + JIT a gyakran végrehajtott metódusokhoz. Ez egyesíti az AOT sebességét (gyors indítás) a JIT rugalmasságával (adaptív optimalizálás). Eredmény: az Android-alkalmazások teljesítménye 20-30%-kal nőtt a Dalvik-hoz képest. A fejlesztők számára az ART-ra való áttérés átlátható — a kód nem igényel változtatásokat.

Bitcode és App Thinning

Bitcode — a kód köztes reprezentációja (IR), amelyet az Apple használ az IPA újrafordításához különböző processzorarchitektúrákra. A Bitcode opcionális: iOS-alkalmazásoknál alapértelmezés szerint engedélyezett, watchOS és tvOS esetén kötelező. Az Apple új processzorok megjelenésekor a fejlesztő részvétele nélkül újrafordíthatja a Bitcode-ot. App Thinning — az Apple technológiája, amely magában foglalja a Slicing-et (csak a szükséges erőforrások szállítása az eszközhöz) és az On-Demand Resources-t (erőforrások betöltése igény szerint). Az App Thinning 30-50%-kal csökkenti az App Store-ból való letöltés méretét.

DEX — bájtkód formátum Androidhoz, amelyet az ART/Dalvik hajt végre. A Kotlin/Java forráskód class fájlokba fordul, majd dx vagy d8 (egy modern és gyorsabb eszköz) segítségével DEX-be. Multidex — mechanizmus azon alkalmazások számára, amelyek túllépik a 65 536 metódus korlátját egyetlen DEX-fájlban. Modern projektekben a multidex automatikusan engedélyeződik, ha targetSdkVersion >= 21.

Kódaláírás: Code Signing, Keystore, Provisioning Profile

Android: Keystore

Keystore — egy fájl, amely a privát kulcsot és tanúsítványt tartalmazza az Android-alkalmazás build közbeni aláírásához. A Keystore a keytool (-genkey parancs) vagy az Android Studio segítségével hozható létre. Fontos: a Keystore nem veszíthető el — nélküle nem tudja frissíteni az alkalmazást a Google Play-en. Aláírási paraméterek: keyAlias, keyPassword, storePassword és storeFile. Formátum: JKS (Java KeyStore) vagy PEPK (Play Encrypted Private Key) AAB esetén.

App Bundle ID (Android) — az alkalmazás egyedi azonosítója csomagjelölésben (com.example.app). Version Code — egész szám a belső verziószámozáshoz (minden új build növeli). Version Name — a felhasználónak megjelenített karakterlánc (1.2.3). Ezeket a paramétereket a build.gradle-ben állítják be alkalmazásszinten.

iOS: Apple Certificate és Provisioning Profile

Apple Certificate — digitális tanúsítvány, amely igazolja a fejlesztő személyazonosságát. Típusok: Development (hibakereséshez), Distribution (App Store-hoz), Ad Hoc (korlátozott terjesztéshez). A tanúsítványok az Apple Developer Account-ban jönnek létre, és a Keychain-be töltődnek le. Provisioning Profile — egy fájl, amely összekapcsolja a tanúsítványt, az App ID-t (Bundle Identifier) és az engedélyezett eszközök listáját. Provisioning Profile nélkül az alkalmazás nem fog futni egy eszközön.

Bundle ID (iOS) — az alkalmazás egyedi azonosítója (com.example.app). Build Number — a build száma, minden builddel növekszik. Marketing Version — a felhasználónak megjelenített verzió. Verziókezelés: iOS esetén a paraméterek az Info.plist-ben és a Project Settings-ben állíthatók be; Android esetén — a build.gradle-ben. Az IT Sectr-nél a verziófrissítéseket a Fastlane segítségével automatizáljuk — ez kiküszöböli az emberi hibákat a kiadás során.

Publikálási folyamat az áruházakban

Google Play Console

Google Play Console — egy eszköz Android-alkalmazások publikálásához. Folyamat: fejlesztői fiók regisztrációja ($25 egyszeri), alkalmazás létrehozása, metaadatok kitöltése (név, leírás, képernyőképek, kategória), AAB feltöltése, árak és terjesztés konfigurálása, felülvizsgálat. A Google automatikusan (vírusok, irányelveknek való megfelelés) és egyes kategóriák esetén manuálisan ellenőrzi az alkalmazást. A felülvizsgálat néhány órától 2-3 napig tart.

App Store Connect

App Store Connect — az Apple platformja iOS-alkalmazások publikálásához. Folyamat: Apple fejlesztői fiók ($99/év), alkalmazás létrehozása az App Store Connect-ben, IPA előkészítése Xcode-ban (Archive → Distribute App → App Store Connect), feltöltés Transporter vagy Xcode segítségével, metaadatok kitöltése, felülvizsgálatra küldés. App Review — az Apple manuális felülvizsgálata 24 órától 7 napig tarthat. Az elutasítás tipikus okai: nem működő gombok, hiányos tartalom, engedélykérés magyarázat nélkül.

Bétatesztelés: TestFlight, Closed/Open Beta

TestFlight (iOS)

TestFlight — az Apple hivatalos eszköze iOS-alkalmazások bétateszteléséhez. A TestFlight támogatja az Internal Testing (legfeljebb 100 tesztelő e-mailben, felülvizsgálat nélkül) és az External Testing (legfeljebb 10 000 tesztelő, Apple felülvizsgálattal) lehetőséget. A build-ek 90 napig érhetők el, ezután új build-et kell feltölteni. A TestFlight automatikusan frissíti az alkalmazást a tesztelőknél, amikor új build-et töltenek fel.

Internal / Closed / Open Beta (Android)

Internal Testing (Android) — legfeljebb 100 tesztelő, Google felülvizsgálat nélkül, a build azonnal elérhető. Closed Beta — legfeljebb 1000 tesztelő e-mailben vagy Google Groups segítségével, felülvizsgálat nélkül. Open Beta — korlátlan tesztelő nyilvános linken keresztül, Google felülvizsgálattal. Staged Rollout — a frissítést kapó felhasználók százalékának fokozatos növelése (5% → 20% → 50% → 100%). Ez a legbiztonságosabb kiadási módszer.

App Thinning (iOS) — a letöltött IPA méretének automatikus csökkentése: Slicing (csak az eszközhöz szükséges erőforrások), Bitcode (processzoroptimalizálás), On-Demand Resources (letöltés igény szerint). Az IT Sectr-nél a TestFlight-ot használjuk iOS bétatesztekhez és az Internal Testing-et Androidhoz — ez lehetővé teszi a problémák felismerését a tömeges kiadás előtt.