Release inom mobilutveckling: grunder, bygge och publicering av appar

Vad är en Release-build

Release — är en byggkonfiguration där alla kompilatoroptimeringar tillämpas, debug-information tas bort, resurser komprimeras och körbar kod obfuskeras för att skydda immateriella rättigheter. Målet med Release är att få en så snabb och kompakt binär fil som möjligt, redo för distribution via officiella kanaler.

Till skillnad från Debug innehåller en Release-build inga ingångspunkter för debugger, påståenden är inaktiverade och loggning är minimerad. Detta är inte bara att växla en flagga — det är en annan bygg-pipeline med andra certifikat, provisioning profiles och paketeringsinställningar. En Release-build tar längre tid eftersom kompilatorn utför extra optimeringsomgångar.

För iOS signeras en Release-build med ett Apple Distribution-certifikat och genomgår verifiering i App Store Connect. För Android signeras en Release-build med en Upload Key och kan laddas upp till Google Play Console. Båda plattformarna kräver digital signering: en app som byggs utan den installeras inte på användarens enhet.

Release och Debug: jämförelse av konfigurationer

Skillnaden mellan Debug och Release visar sig på alla nivåer: från kompilatorflaggor till den slutliga storleken på .apk eller .ipa. Att förstå dessa skillnader är avgörande för CI/CD-pipelinen och för att hitta regressioner som bara uppträder i Release-builden.

Kompilatorflaggor

I Release aktiverar kompilatorn optimering baserat på storlek (-Os för LLVM) eller hastighet (-O2). Detta innebär inbäddning av inline-funktioner, borttagning av död kod, omordning av instruktioner och aggressiv optimering av loopar. I Debug hoppas alla dessa steg över, vilket gör koden långsammare men bevarar fullständig överensstämmelse mellan källkodsrader och maskininstruktioner.

Obfuskering och minifiering

ProGuard/R8 (Android) döper om klasser, metoder och fält till korta namn (a, b, c), vilket försvårar reverse engineering och minskar DEX-filstorleken. På iOS tillhandahålls motsvarande funktionalitet av Strip Symbols och Swift Symbolication. Det är viktigt att konfigurera keep-regler för klasser som används via reflektion eller i XML-layout, annars kraschar appen med ClassNotFoundException vid start.

Byggstorlek

En Release-build är betydligt mer kompakt än Debug. Typiskt förhållande: Debug-versionen tar 40–80 MB, Release — 15–30 MB. Skillnaden beror på borttagning av debug-symboler (DWARF), resurskomprimering (aapt2) och DEX-obfuskering. För användare är appstorleken en viktig faktor för installationskonvertering, därför är storleksoptimering i Release en obligatorisk praxis.

Release-byggprocessen på Android

Gradle tillhandahåller inbyggda uppgifter för att bygga Release-versionen: assembleRelease, bundleRelease (för AAB) och signingReport. Korrekt konfiguration av build.gradle på modulnivå är grunden för en stabil CI/CD-build. Låt oss titta på de viktigaste stegen med exemplet av ett typiskt projekt.

Konfigurera build.gradle

I buildTypes anges release-konfigurationen: minifiering aktiveras, shrinkResources och proguard-regler ställs in. signingConfig-blocket måste referera till storeFile, storePassword, keyAlias och keyPassword — dessa parametrar bör inte lagras i VCS. För CI/CD, använd miljövariabler eller Keystore Provisioning Plugin.

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

Bygga AAB och APK

Android App Bundle (AAB) — det rekommenderade formatet för publicering i Google Play. AAB innehåller inte en enda APK, utan en modulär uppsättning resurser från vilken Google Play dynamiskt genererar en optimerad APK för en specifik enhet. Kommandot ./gradlew bundleRelease bygger en AAB, och ./gradlew assembleRelease — en universell APK för testning före uppladdning.

Signering och verifiering

Signerad APK/AAB verifieras via apksigner verify. Google Play Console kontrollerar automatiskt signaturen vid uppladdning. Från och med Android 9 (API 28) kräver Google signeringsschema v2 eller v3. För Wear OS och Android TV krävs dessutom v3.1 med angivande av rotating key.

Release-byggprocessen på iOS

Xcode bygger Release-versionen i Archive-konfigurationen — detta är inte bara en build, utan en fullständig pipeline: kompilering med optimering, paketering till .xcarchive, signering med Distribution-certifikat och export till .ipa. Processen startas via Product → Archive eller kommandot xcodebuild.

Konfigurera byggschema

I Edit Scheme → Run → Build Configuration väljer du Release för slutlig testning. För att skicka till App Store Connect, använd Archive i Product-menyn. Xcode skapar en .xcarchive som innehåller den binära filen, dSYM och resursbuntar. Från arkivet exporteras en .ipa för Ad Hoc-, Development- eller App Store-distribution.

App Store Connect och TestFlight

TestFlight accepterar Release-builds signerade med App Store Distribution-certifikat. Innan sändning till App Store genomgår bygget automatisk validering i Xcode: certifikatöverensstämmelse, förekomst av ikoner i alla storlekar, korrekthet av Info.plist och frånvaro av emulatorarkitekturer i den binära filen kontrolleras.

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

# Exportera .ipa för App Store
xcodebuild -exportArchive \
  -archivePath "build/MyApp.xcarchive" \
  -exportPath "build/" \
  -exportOptionsPlist "export.plist"

Bitcode och App Thinning

App Thinning — Apples teknik för att minska storleken på den nedladdade appen. Vid uppladdning till App Store omkompilerar Apple den binära filen för användarens specifika enhet och tar bort oanvända arkitekturer. Bitcode (LLVM:s mellanrepresentation) aktiveras i Release-builden om projektet använder iOS 14+ och Xcode 12+.

Vanliga misstag vid förberedelse av Release

Konfigurationsfel för Release-builden delas in i tre kategorier: kompileringsproblem, signeringsproblem och logiska fel som uppträder först efter optimering. Låt oss titta på de vanligaste scenarierna som utvecklare stöter på vid övergången från Debug till Release.

ClassNotFoundException efter obfuskering

Det vanligaste felet på Android — krasch vid start efter aktivering av minifyEnabled. Orsak: R8 döpte om en klass som används via reflektion (t.ex. Gson serialization, Retrofit @Body med data class). Lösning — lägg till en -keep-regel för alla klasser som deltar i serialisering och kontrollera proguard-reglerna före bygget.

Saknad dSYM för symbolication

På iOS glömmer utvecklare ofta att spara dSYM-filer efter Archive. Utan dSYM kommer kraschloggar från App Store Connect som hexadecimala adresser istället för läsbara funktionsnamn. Lösning — konfigurera CI/CD att arkivera dSYM tillsammans med .ipa och ladda upp dem till App Store Connect.

Problem med provisioning profile

Utgånget Distribution-certifikat eller felaktigt App ID i provisioning profile — orsak till att bygget avvisas av App Store Connect. Certifikat är giltiga i 1 år (Apple) eller 3 år (Google), och deras förnyelse måste planeras i releas kalendern. Kontroll av certifikatstatus före varje Release-build är ett obligatoriskt steg i CI/CD-pipelinen.

Inkompatibilitet mellan SDK-versioner och deployment target

Vanligt problem vid övergång från Debug till Release — användning av API:er som inte är tillgängliga på målversionen av operativsystemet. I Debug testas bygget på en simulator med den senaste versionen, där alla nya API:er är tillgängliga. I Release installeras appen på användarenheter med olika OS-versioner, och anrop av ett otillgängligt API leder till en krasch vid start. Använd @available (Swift) eller compileSdkVersion + minSdkVersion (Android) för att explicit ange minimiversionen.

Saknade lokaliseringar och resurser för olika konfigurationer

I Debug-builden laddas resurser ofta från källkataloger utan konfigurationskontroll. I Release tillämpar Gradle och Xcode resursfiltrering: om en sträng eller drawable inte hittas i mållokaliseringen, kraschar appen eller visar en platshållare. Detta är särskilt kritiskt för Android: saknad översättning i values-XX leder till ClassCastException vid tolkning av XML. Kontrollera alla lokaliseringar före Release-builden med lint och xcodebuild -showBuildSettings. För att upptäcka sådana problem, använd TestFlight och Internal Testing track före den offentliga releasen — de körs på riktiga enheter med olika språkinställningar.