Bygg och publicering inom mobil utveckling: vad det är, vilka format och hur det fungerar

Byggformat: APK, AAB, IPA

APK vs AAB

APK (Android Package Kit) — det traditionella formatet för att bygga och publicera mobila applikationer på Android. APK innehåller all kod, resurser och manifest för applikationen. AAB (Android App Bundle) — ett format som introducerades av Google 2018 och blev obligatoriskt för nya applikationer från och med augusti 2021. AAB installeras inte direkt — Google Play genererar dynamiskt en optimerad APK för varje enhet från AAB.

Fördelar med AAB: nedladdningsstorleken är i genomsnitt 15 % mindre (genom att endast leverera nödvändiga resurser: korrekta skärmdensiteter, språk, CPU-arkitekturer). AAB stöder också modulär leverans — du kan ladda moduler på begäran (Play Feature Delivery) eller fördröjt (Play On-Demand). För utvecklare är AAB obligatoriskt; för distribution utanför Google Play (sideloading, marknadsplatser) — endast APK.

IPA

IPA (iOS App Store Package) — den iOS-installerbara filen, som är ett ZIP-arkiv med en signerad applikation. IPA innehåller en Payload/-mapp med .app-paketet, Provisioning Profile och signatur. IPA byggs endast på macOS via Xcode, som skapar ett arkiv (.xcarchive) och exporterar IPA. För distribution via App Store signeras IPA med ett Apple Distribution Certificate; för Ad Hoc eller Enterprise — med motsvarande certifikat.

Kompilering och optimering: JIT, AOT, ART, Bitcode

JIT vs AOT

JIT (Just-In-Time) — kompilering av kod under applikationens körning, vilket påverkar bygg- och publiceringshastigheten. På Android upp till version 5.0 (Lollipop) användes Dalvik VM med JIT-kompilering. Vid varje applikationsstart konverterades DEX-bytekod till maskinkod «i farten». Nackdel: försening vid första start och extra energiförbrukning. AOT (Ahead-Of-Time) — kompilering av kod före applikationsstart, under installation. Från och med Android 7.0 (Nougat) kompilerar ART (Android Runtime) applikationen fullständigt under installationen.

ART (Android Runtime) — körningsmiljön som ersatte Dalvik i Android 5.0. ART använder en hybridmetod: AOT-kompilering vid installation + JIT för ofta körda metoder. Detta kombinerar AOT:s hastighet (snabb start) med JIT:s flexibilitet (adaptiv optimering). Resultat: prestandan för Android-applikationer ökade med 20–30 % jämfört med Dalvik. För utvecklare är övergången till ART transparent — koden kräver inga ändringar.

Bitcode och App Thinning

Bitcode — en mellanliggande representation av kod (IR) som Apple använder för att kompilera om IPA för olika processorarkitekturer. Bitcode är valfritt: för iOS-applikationer är det aktiverat som standard, för watchOS och tvOS är det obligatoriskt. Apple kan kompilera om Bitcode när nya processorer släpps utan utvecklarens medverkan. App Thinning — Apples teknik som inkluderar Slicing (leverans av endast nödvändiga resurser för enheten) och On-Demand Resources (ladda resurser på begäran). App Thinning minskar nedladdningsstorleken från App Store med 30–50 %.

DEX — bytecode-format för Android, som körs av ART/Dalvik. Källkod i Kotlin/Java kompileras till class-filer, sedan till DEX via dx eller d8 (ett modernt och snabbare verktyg). Multidex — en mekanism för applikationer som överskrider gränsen på 65 536 metoder i en enda DEX-fil. I moderna projekt aktiveras multidex automatiskt om targetSdkVersion >= 21.

Kodsignering: Code Signing, Keystore, Provisioning Profile

Android: Keystore

Keystore — en fil som innehåller den privata nyckeln och certifikatet för att signera en Android-applikation under bygget. Keystore skapas via keytool (kommandot -genkey) eller Android Studio. Viktigt: Keystore får inte förloras — utan det kan du inte uppdatera applikationen på Google Play. Signeringsparametrar: keyAlias, keyPassword, storePassword och storeFile. Format: JKS (Java KeyStore) eller PEPK (Play Encrypted Private Key) för AAB.

App Bundle ID (Android) — den unika identifieraren för applikationen i paketnotation (com.example.app). Version Code — ett heltal för intern versionsnumrering (varje ny build ökar det). Version Name — en sträng som visas för användaren (1.2.3). Dessa parametrar ställs in i build.gradle på appnivå.

iOS: Apple Certificate och Provisioning Profile

Apple Certificate — ett digitalt certifikat som verifierar utvecklarens identitet. Typer: Development (för felsökning), Distribution (för App Store), Ad Hoc (för begränsad distribution). Certifikat skapas i Apple Developer Account och laddas ner till Keychain. Provisioning Profile — en fil som kopplar samman certifikatet, App ID (Bundle Identifier) och en lista över tillåtna enheter. Utan Provisioning Profile kommer applikationen inte att köras på en enhet.

Bundle ID (iOS) — den unika identifieraren för applikationen (com.example.app). Build Number — buildnumret, ökar med varje build. Marketing Version — versionen som visas för användaren. Versionshantering: för iOS ställs parametrarna in i Info.plist och Project Settings; för Android — i build.gradle. På IT Sectr automatiserar vi versionsuppdateringar via Fastlane — detta eliminerar mänskliga fel vid lansering.

Publiceringsprocess i butiker

Google Play Console

Google Play Console — ett verktyg för att publicera Android-applikationer. Process: registrering av utvecklarkonto ($25 engångsavgift), skapa applikation, fylla i metadata (namn, beskrivning, skärmbilder, kategori), ladda upp AAB, konfigurera priser och distribution, granskning. Google kontrollerar applikationen automatiskt (virus, policyefterlevnad) och manuellt för vissa kategorier. Granskningen tar från några timmar till 2–3 dagar.

App Store Connect

App Store Connect — Apples plattform för att publicera iOS-applikationer. Process: Apple-utvecklarkonto ($99/år), skapa applikation i App Store Connect, förbereda IPA i Xcode (Archive → Distribute App → App Store Connect), ladda upp via Transporter eller Xcode, fylla i metadata, skicka in för granskning. App Review — Apples manuella granskning kan ta från 24 timmar till 7 dagar. Typiska avslagsorsaker: knappar som inte fungerar, ofullständigt innehåll, begäran om behörighet utan förklaring.

Betatestning: TestFlight, Closed/Open Beta

TestFlight (iOS)

TestFlight — Apples officiella verktyg för betatestning av iOS-applikationer. TestFlight stöder Internal Testing (upp till 100 testare via e-post, utan granskning) och External Testing (upp till 10 000 testare, med Apple-granskning). Byggen är tillgängliga i 90 dagar, varefter ett nytt bygge måste laddas upp. TestFlight uppdaterar automatiskt applikationen hos testarna när ett nytt bygge laddas upp.

Internal / Closed / Open Beta (Android)

Internal Testing (Android) — upp till 100 testare, utan Google-granskning, bygget är omedelbart tillgängligt. Closed Beta — upp till 1000 testare via e-post eller Google Groups, utan granskning. Open Beta — obegränsat antal testare via en offentlig länk, med Google-granskning. Staged Rollout — gradvis ökning av andelen användare som får uppdateringen (5 % → 20 % → 50 % → 100 %). Detta är den säkraste lanseringsmetoden.

App Thinning (iOS) — automatisk minskning av storleken på nedladdad IPA: Slicing (endast nödvändiga resurser för enheten), Bitcode (processoroptimering), On-Demand Resources (nedladdning på begäran). På IT Sectr använder vi TestFlight för iOS-betatestning och Internal Testing för Android — detta gör att vi kan fånga problem före en masslansering.