Release v mobilním vývoji: základy, sestavení a publikace aplikací

Co je Release sestavení

Release — je konfigurace sestavení, ve které jsou aplikovány všechny optimalizace kompilátoru, jsou odstraněny ladící informace, zdroje jsou komprimovány a spustitelný kód je obfuskován pro ochranu duševního vlastnictví. Cílem Release je získat co nejrychlejší a nejkompaktnější binární soubor připravený k distribuci prostřednictvím oficiálních kanálů.

Na rozdíl od Debug neobsahuje Release sestavení vstupní body pro ladicí program, aserce jsou vypnuty a protokolování je minimalizováno. Toto není jen přepnutí příznaku — je to jiné pipeline sestavení s jinými certifikáty, provisioning profile a nastavením balení. Release sestavení vyžaduje více času, protože kompilátor provádí další optimalizační průchody.

Pro iOS je Release sestavení podepsáno certifikátem Apple Distribution a prochází ověřením v App Store Connect. Pro Android je Release sestavení podepsáno klíčem Upload Key a může být nahráno do Google Play Console. Obě platformy vyžadují digitální podpis: aplikace sestavená bez něj se nenainstaluje na zařízení uživatele.

Release a Debug: porovnání konfigurací

Rozdíl mezi Debug a Release se projevuje na všech úrovních: od příznaků kompilátoru až po konečnou velikost .apk nebo .ipa. Porozumění těmto rozdílům je kritické pro pipeline CI/CD a hledání regresí, které se projevují pouze v Release sestavení.

Příznaky kompilátoru

V Release kompilátor zapíná optimalizaci podle velikosti (-Os pro LLVM) nebo rychlosti (-O2). To znamená vkládání inline funkcí, odstraňování mrtvého kódu, přeskupování instrukcí a agresivní optimalizaci cyklů. V Debug jsou všechny tyto fáze vynechány, což kód zpomaluje, ale zachovává plnou shodu mezi řádky zdrojového kódu a strojovými instrukcemi.

Obfuskace a minifikace

ProGuard/R8 (Android) přejmenovávají třídy, metody a pole na krátká jména (a, b, c), což ztěžuje zpětné inženýrství a zmenšuje velikost DEX souboru. Na iOS je ekvivalentní funkcionalita zajištěna Strip Symbols a Swift Symbolication. Je důležité nakonfigurovat pravidla keep pro třídy, které jsou použity prostřednictvím reflexe nebo v XML rozvržení, jinak aplikace spadne s ClassNotFoundException při spuštění.

Velikost sestavení

Release sestavení je výrazně kompaktnější než Debug. Typický poměr: Debug verze zabírá 40–80 MB, Release — 15–30 MB. Rozdíl je způsoben odstraněním ladících symbolů (DWARF), kompresí zdrojů (aapt2) a obfuskací DEX. Pro uživatele je velikost aplikace důležitým faktorem konverze instalací, proto je optimalizace velikosti v Release povinnou praxí.

Proces Release sestavení na Androidu

Gradle poskytuje vestavěné úlohy pro sestavení Release verze: assembleRelease, bundleRelease (pro AAB) a signingReport. Správná konfigurace build.gradle na úrovni modulu je základem stabilního CI/CD sestavení. Podívejme se na klíčové fáze na příkladu typického projektu.

Konfigurace build.gradle

V buildTypes je uvedena konfigurace release: je zapnuta minifikace, shrinkResources a nastavena pravidla proguard. Blok signingConfig musí odkazovat na storeFile, storePassword, keyAlias a keyPassword — tyto parametry by neměly být uloženy ve VCS. Pro CI/CD použijte proměnné prostředí nebo Keystore Provisioning Plugin.

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

Sestavení AAB a APK

Android App Bundle (AAB) — doporučený formát pro publikaci v Google Play. AAB neobsahuje jeden APK, ale modulární sadu zdrojů, ze kterých Google Play dynamicky generuje optimalizovaný APK pro konkrétní zařízení. Příkaz ./gradlew bundleRelease sestaví AAB a ./gradlew assembleRelease — univerzální APK pro testování před nahráním.

Podpis a ověření

Podepsaný APK/AAB je ověřen prostřednictvím apksigner verify. Google Play Console automaticky kontroluje podpis při nahrávání. Od Androidu 9 (API 28) Google vyžaduje schémata podpisu v2 nebo v3. Pro Wear OS a Android TV je navíc vyžadován v3.1 s uvedením rotating key.

Proces Release sestavení na iOS

Xcode sestavuje Release verzi v konfiguraci Archive — není to jen build, ale plné pipeline: kompilace s optimalizací, zabalení do .xcarchive, podpis certifikátem Distribution a export do .ipa. Proces se spouští přes Product → Archive nebo příkazem xcodebuild.

Konfigurace schématu sestavení

V Edit Scheme → Run → Build Configuration vyberte Release pro konečné testování. Pro odeslání do App Store Connect použijte Archive z nabídky Product. Xcode vytvoří .xcarchive obsahující binární soubor, dSYM a Resource-bundle. Z archivu je exportován .ipa pro distribuci Ad Hoc, Development nebo App Store.

App Store Connect a TestFlight

TestFlight přijímá Release sestavení podepsaná certifikátem App Store Distribution. Před odesláním do App Store prochází sestavení automatickou validací v Xcode: kontroluje se shoda certifikátů, přítomnost ikon všech velikostí, správnost Info.plist a absence emulátorových architektur v binárním souboru.

# Sestavení Release přes xcodebuild
xcodebuild archive \
  -project MyApp.xcodeproj \
  -scheme "MyApp" \
  -configuration "Release" \
  -archivePath "build/MyApp.xcarchive"

# Export .ipa pro App Store
xcodebuild -exportArchive \
  -archivePath "build/MyApp.xcarchive" \
  -exportPath "build/" \
  -exportOptionsPlist "export.plist"

Bitcode a App Thinning

App Thinning — technologie Apple pro zmenšení velikosti stahované aplikace. Při nahrávání do App Store Apple překompiluje binární soubor pro konkrétní zařízení uživatele a odstraní nepoužité architektury. Bitcode (mezilehlá reprezentace LLVM) je zapnut v Release sestavení, pokud projekt používá iOS 14+ a Xcode 12+.

Typické chyby při přípravě Release

Chyby konfigurace Release sestavení se dělí do tří kategorií: problémy kompilace, problémy podpisu a logické chyby projevující se až po optimalizaci. Podívejme se na nejčastější scénáře, se kterými se vývojáři setkávají při přechodu z Debug na Release.

ClassNotFoundException po obfuskaci

Nejčastější chyba na Androidu — pád při spuštění po zapnutí minifyEnabled. Příčina: R8 přejmenoval třídu používanou prostřednictvím reflexe (např. Gson serialization, Retrofit @Body s data class). Řešení — přidejte pravidlo -keep pro všechny třídy účastnící se serializace a zkontrolujte pravidla proguard před sestavením.

Chybějící dSYM pro symbolication

Na iOS vývojáři často zapomínají uložit dSYM soubory po Archive. Bez dSYM přicházejí deníky pádů z App Store Connect jako hexadecimální adresy, nikoli čitelná jména funkcí. Řešení — nakonfigurujte CI/CD na archivaci dSYM spolu s .ipa a jejich nahrání do App Store Connect.

Problémy s provisioning profile

Prošlý certifikát Distribution nebo nesprávné App ID v provisioning profile — důvod odmítnutí sestavení App Store Connect. Certifikáty jsou platné 1 rok (Apple) nebo 3 roky (Google) a jejich obnovení je třeba zahrnout do kalendáře vydání. Kontrola stavu certifikátu před každým Release sestavením je povinným krokem v CI/CD pipeline.

Nekompatibilita verzí SDK a deployment target

Častý problém při přechodu z Debug na Release — použití API nedostupných na cílové verzi operačního systému. V Debug je sestavení testováno na simulátoru s nejnovější verzí, kde jsou všechna nová API dostupná. V Release je aplikace instalována na zařízení uživatelů s různými verzemi OS a volání nedostupného API vede k pádu při spuštění. Použijte @available (Swift) nebo compileSdkVersion + minSdkVersion (Android) pro explicitní určení minimální verze.

Chybějící lokalizace a zdroje pro různé konfigurace

V Debug sestavení jsou zdroje často načítány z původních adresářů bez kontroly konfigurace. V Release Gradle a Xcode aplikují filtrování zdrojů: pokud string nebo drawable není nalezen v cílové lokalizaci, aplikace buď spadne, nebo zobrazí placeholder. To je obzvláště kritické pro Android: chybějící překlad v values-XX vede k ClassCastException při parsování XML. Zkontrolujte všechny lokalizace před Release sestavením pomocí lint a xcodebuild -showBuildSettings. Pro odhalení těchto problémů použijte TestFlight a Internal Testing track před veřejným vydáním — běží na skutečných zařízeních s různými jazykovými nastaveními.