Construirea și publicarea în dezvoltarea mobilă: ce este, ce formate și cum funcționează

Formate de construire: APK, AAB, IPA

APK vs AAB

APK (Android Package Kit) — formatul tradițional de construire și publicare a aplicațiilor mobile pe Android. APK conține tot codul, resursele și manifestul aplicației. AAB (Android App Bundle) — un format introdus de Google în 2018 și devenit obligatoriu pentru aplicațiile noi din august 2021. AAB nu se instalează direct — Google Play generează dinamic un APK optimizat pentru fiecare dispozitiv din AAB.

Avantajele AAB: dimensiunea descărcării este în medie cu 15% mai mică (prin livrarea doar a resurselor necesare: densități corecte ale ecranului, limbi, arhitecturi CPU). AAB suportă și livrarea modulară — puteți încărca module la cerere (Play Feature Delivery) sau amânat (Play On-Demand). Pentru dezvoltatori, AAB este obligatoriu; pentru distribuirea în afara Google Play (sideloading, piețe) — doar APK.

IPA

IPA (iOS App Store Package) — fișierul instalabil iOS, care este o arhivă ZIP care conține o aplicație semnată. IPA conține un folder Payload/ cu pachetul .app, Provisioning Profile și semnătura. IPA este construit doar pe macOS prin Xcode, care creează o arhivă (.xcarchive) și exportă IPA. Pentru distribuirea prin App Store, IPA este semnat cu un Apple Distribution Certificate; pentru Ad Hoc sau Enterprise — cu certificatele corespunzătoare.

Compilare și optimizare: JIT, AOT, ART, Bitcode

JIT vs AOT

JIT (Just-In-Time) — compilarea codului în timpul execuției aplicației, care afectează viteza de construire și publicare. Pe Android până la versiunea 5.0 (Lollipop) se folosea Dalvik VM cu compilare JIT. La fiecare pornire a aplicației, bytecode-ul DEX era convertit în cod mașină «pe loc». Dezavantaj: încetinire la prima pornire și consum suplimentar de energie. AOT (Ahead-Of-Time) — compilarea codului înainte de pornirea aplicației, în timpul instalării. Începând cu Android 7.0 (Nougat), ART (Android Runtime) compilează complet aplicația în timpul instalării.

ART (Android Runtime) — mediul de execuție care a înlocuit Dalvik în Android 5.0. ART folosește o abordare hibridă: compilare AOT la instalare + JIT pentru metodele frecvent executate. Aceasta combină viteza AOT (pornire rapidă) cu flexibilitatea JIT (optimizare adaptivă). Rezultat: performanța aplicațiilor Android a crescut cu 20-30% față de Dalvik. Pentru dezvoltatori, tranziția la ART este transparentă — codul nu necesită modificări.

Bitcode și App Thinning

Bitcode — o reprezentare intermediară a codului (IR) pe care Apple o folosește pentru recompilarea IPA pentru diferite arhitecturi de procesoare. Bitcode este opțional: pentru aplicațiile iOS este activat implicit, pentru watchOS și tvOS este obligatoriu. Apple poate recompila Bitcode la lansarea noilor procesoare fără implicarea dezvoltatorului. App Thinning — tehnologia Apple care include Slicing (livrarea doar a resurselor necesare dispozitivului) și On-Demand Resources (încărcarea resurselor la cerere). App Thinning reduce dimensiunea descărcării din App Store cu 30-50%.

DEX — format bytecode pentru Android, executat de ART/Dalvik. Codul sursă Kotlin/Java este compilat în fișiere class, apoi în DEX prin dx sau d8 (un instrument modern și mai rapid). Multidex — un mecanism pentru aplicațiile care depășesc limita de 65.536 de metode într-un singur fișier DEX. În proiectele moderne, multidex este activat automat dacă targetSdkVersion >= 21.

Semnarea codului: Code Signing, Keystore, Provisioning Profile

Android: Keystore

Keystore — un fișier care conține cheia privată și certificatul pentru semnarea unei aplicații Android în timpul construcției. Keystore este creat prin keytool (comanda -genkey) sau Android Studio. Important: Keystore nu poate fi pierdut — fără el nu puteți actualiza aplicația pe Google Play. Parametri de semnare: keyAlias, keyPassword, storePassword și storeFile. Format: JKS (Java KeyStore) sau PEPK (Play Encrypted Private Key) pentru AAB.

App Bundle ID (Android) — identificatorul unic al aplicației în notație de pachet (com.example.app). Version Code — un număr întreg pentru numerotarea internă a versiunilor (fiecare construcție nouă îl incrementează). Version Name — un șir afișat utilizatorului (1.2.3). Acești parametri sunt setați în build.gradle la nivelul aplicației.

iOS: Apple Certificate și Provisioning Profile

Apple Certificate — un certificat digital care verifică identitatea dezvoltatorului. Tipuri: Development (pentru depanare), Distribution (pentru App Store), Ad Hoc (pentru distribuire limitată). Certificatele sunt create în Apple Developer Account și descărcate în Keychain. Provisioning Profile — un fișier care leagă certificatul, App ID (Bundle Identifier) și o listă de dispozitive permise. Fără Provisioning Profile, aplicația nu va rula pe un dispozitiv.

Bundle ID (iOS) — identificatorul unic al aplicației (com.example.app). Build Number — numărul de construcție, incrementat la fiecare build. Marketing Version — versiunea afișată utilizatorului. Gestionarea versiunilor: pentru iOS, parametrii sunt setați în Info.plist și Project Settings; pentru Android — în build.gradle. La IT Sectr, automatizăm actualizările de versiune prin Fastlane — aceasta elimină erorile umane în timpul lansării.

Procesul de publicare în magazine

Google Play Console

Google Play Console — un instrument pentru publicarea aplicațiilor Android. Proces: înregistrarea unui cont de dezvoltator ($25 unic), crearea aplicației, completarea metadatelor (nume, descriere, capturi de ecran, categorie), încărcarea AAB, configurarea prețurilor și distribuției, revizuire. Google verifică aplicația automat (virusuri, conformitate cu politicile) și manual pentru unele categorii. Revizuirea durează de la câteva ore până la 2-3 zile.

App Store Connect

App Store Connect — platforma Apple pentru publicarea aplicațiilor iOS. Proces: cont de dezvoltator Apple ($99/an), crearea aplicației în App Store Connect, pregătirea IPA în Xcode (Archive → Distribute App → App Store Connect), încărcarea prin Transporter sau Xcode, completarea metadatelor, trimiterea pentru revizuire. App Review — revizuirea manuală a Apple poate dura de la 24 de ore până la 7 zile. Motive tipice de respingere: butoane nefuncționale, conținut incomplet, cerere de permisiuni fără explicație.

Testare beta: TestFlight, Closed/Open Beta

TestFlight (iOS)

TestFlight — instrumentul oficial Apple pentru testarea beta a aplicațiilor iOS. TestFlight suportă Internal Testing (până la 100 de testeri prin e-mail, fără revizuire) și External Testing (până la 10.000 de testeri, cu revizuire Apple). Construcțiile sunt disponibile 90 de zile, după care trebuie încărcată o nouă construcție. TestFlight actualizează automat aplicația la testeri la încărcarea unei noi construcții.

Internal / Closed / Open Beta (Android)

Internal Testing (Android) — până la 100 de testeri, fără revizuire Google, construcția disponibilă imediat. Closed Beta — până la 1000 de testeri prin e-mail sau Google Groups, fără revizuire. Open Beta — testeri nelimitați printr-un link public, cu revizuire Google. Staged Rollout — creșterea treptată a procentului de utilizatori care primesc actualizarea (5% → 20% → 50% → 100%). Aceasta este cea mai sigură metodă de lansare.

App Thinning (iOS) — reducerea automată a dimensiunii IPA descărcat: Slicing (doar resursele necesare dispozitivului), Bitcode (optimizarea procesorului), On-Demand Resources (descărcare la cerere). La IT Sectr, folosim TestFlight pentru testarea beta iOS și Internal Testing pentru Android — aceasta ne permite să depistăm problemele înainte de o lansare în masă.