Release у мобилном развоју: основе, изградња и објављивање апликација

Шта је Release компилација

Release — то је конфигурација компилације у којој се примењују све оптимизације компајлера, уклањају се информације за отклањање грешака, ресурси се компресују, а извршни код се обфускује ради заштите интелектуалне својине. Циљ Release је добијање најбрже и најкомпактније бинарне датотеке спремне за дистрибуцију преко званичних канала.

За разлику од Debug, Release компилација не садржи улазне тачке за отклањач грешака, асерти су искључени, а евидентирање је сведено на минимум. Ово није само пребацивање заставице — то је другачији pipeline компилације са другачијим сертификатима, provisioning profile и подешавањима паковања. Release компилација захтева више времена јер компајлер обавља додатне пролазе оптимизације.

За iOS Release компилација се потписује Apple Distribution сертификатом и пролази проверу у App Store Connect. За Android Release компилација се потписује Upload Key кључем и може се отпремити у Google Play Console. Обе платформе захтевају дигитални потпис: апликација направљена без њега неће се инсталирати на уређају корисника.

Release и Debug: поређење конфигурација

Разлика између Debug и Release манифестује се на свим нивоима: од заставица компајлера до коначне величине .apk или .ipa. Разумевање ових разлика је критично за CI/CD pipeline и проналажење регресија које се појављују само у Release компилацији.

Заставице компајлера

У Release компајлер укључује оптимизацију по величини (-Os за LLVM) или брзини (-O2). То значи уграђивање inline функција, уклањање мртвог кода, преуређивање инструкција и агресивну оптимизацију петљи. У Debug су све ове фазе прескочене, што чини код споријим, али задржава пуну подударност између линија изворног кода и машинских инструкција.

Обфускација и минификација

ProGuard/R8 (Android) преименују класе, методе и поља у кратка имена (a, b, c), што отежава обрнути инжењеринг и смањује величину DEX датотеке. На iOS еквивалентна функционалност се обезбеђује путем Strip Symbols и Swift Symbolication. Важно је конфигурисати keep правила за класе које се користе путем reflection или у XML распореду, иначе ће апликација пасти са ClassNotFoundException при покретању.

Величина компилације

Release компилација је значајно компактнија од Debug. Типичан однос: Debug верзија заузима 40–80 MB, Release — 15–30 MB. Разлика настаје услед уклањања отклањачких симбола (DWARF), компресије ресурса (aapt2) и обфускације DEX. За кориснике, величина апликације је важан фактор конверзије инсталација, зато је оптимизација величине у Release обавезна пракса.

Процес Release компилације на Android

Gradle пружа уграђене задатке за компилацију Release верзије: assembleRelease, bundleRelease (за AAB) и signingReport. Правилна конфигурација build.gradle на нивоу модула је основа стабилне CI/CD компилације. Размотримо кључне фазе на примеру типичног пројекта.

Конфигурација build.gradle

У buildTypes се наводи конфигурација release: укључује се minification, shrinkResources и постављају proguard правила. Блок signingConfig мора да упућује на storeFile, storePassword, keyAlias и keyPassword — ови параметри не смеју бити ускладиштени у VCS. За CI/CD користите променљиве окружења или Keystore Provisioning Plugin.

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

Компилација AAB и APK

Android App Bundle (AAB) — препоручени формат за објављивање у Google Play. AAB не садржи један APK, већ модуларни скуп ресурса из којег Google Play динамички генерише оптимизовани APK за одређени уређај. Команда ./gradlew bundleRelease гради AAB, а ./gradlew assembleRelease — универзални APK за тестирање пре отпремања.

Потпис и верификација

Потписани APK/AAB се проверава путем apksigner verify. Google Play Console аутоматски проверава потпис при отпремању. Почев од Android 9 (API 28), Google захтева v2 или v3 шеме потписа. За Wear OS и Android TV додатно је потребан v3.1 са навођењем rotating key.

Процес Release компилације на iOS

Xcode гради Release верзију у Archive конфигурацији — то није само build, већ комплетан pipeline: компилација са оптимизацијом, паковање у .xcarchive, потписивање Distribution сертификатом и извоз у .ipa. Процес се покреће преко Product → Archive или командом xcodebuild.

Подешавање шеме компилације

У Edit Scheme → Run → Build Configuration изаберите Release за коначно тестирање. За слање у App Store Connect користите Archive из менија Product. Xcode креира .xcarchive који садржи бинарну датотеку, dSYM и Resource-бандлове. Из архиве се извози .ipa за Ad Hoc, Development или App Store дистрибуцију.

App Store Connect и TestFlight

TestFlight прихвата Release компилације потписане App Store Distribution сертификатом. Пре слања у App Store, компилација пролази аутоматску валидацију у Xcode: проверава се усклађеност сертификата, присуство икона свих величина, исправност Info.plist и одсуство емулаторских архитектура у бинарној датотеци.

# Изградња Release путем xcodebuild
xcodebuild archive \
  -project MyApp.xcodeproj \
  -scheme "MyApp" \
  -configuration "Release" \
  -archivePath "build/MyApp.xcarchive"

# Извоз .ipa за App Store
xcodebuild -exportArchive \
  -archivePath "build/MyApp.xcarchive" \
  -exportPath "build/" \
  -exportOptionsPlist "export.plist"

Bitcode и App Thinning

App Thinning — технологија компаније Apple за смањење величине преузете апликације. При отпремању у App Store, Apple поново компилира бинарну датотеку за одређени уређај корисника, уклањајући неискоришћене архитектуре. Bitcode (посредни приказ LLVM) се укључује у Release компилацији ако пројекат користи iOS 14+ и Xcode 12+.

Типичне грешке при припреми Release

Грешке конфигурације Release компилације деле се у три категорије: проблеми компилације, проблеми потписа и логичке грешке које се појављују тек након оптимизације. Размотримо најчешће сценарије са којима се сусрећу програмери при преласку са Debug на Release.

ClassNotFoundException након обфускације

Најчешћа грешка на Android — пад при покретању након укључивања minifyEnabled. Узрок: R8 је преименовао класу која се користи путем reflection (нпр. Gson serialization, Retrofit @Body са data class). Решење — додајте -keep правило за све класе које учествују у серијализацији и проверите proguard правила пре компилације.

Недостатак dSYM за symbolication

На iOS програмери често забораве да сачувају dSYM датотеке након Archive. Без dSYM, дневници грешака из App Store Connect стижу у облику хексадецималних адреса, а не читљивих имена функција. Решење — конфигуришите CI/CD да архивира dSYM заједно са .ipa и отпреми их у App Store Connect.

Проблеми са provisioning profile

Истекао Distribution сертификат или нетачан App ID у provisioning profile — разлог одбијања компилације од стране App Store Connect. Сертификати важе 1 годину (Apple) или 3 године (Google), а њихово обнављање треба уврстити у календар издавања. Провера статуса сертификата пре сваке Release компилације је обавезан корак у CI/CD pipeline-у.

Неусаглашеност верзија SDK и deployment target

Чест проблем при преласку са Debug на Release — коришћење API-ја недоступних на циљаној верзији оперативног система. У Debug компилација се тестира на симулатору са најновијом верзијом, где су сви нови API-ји доступни. У Release апликација се инсталира на уређаје корисника са различитим верзијама оперативног система, а позив недоступног API-ја доводи до пада при покретању. Користите @available (Swift) или compileSdkVersion + minSdkVersion (Android) за експлицитно навођење минималне верзије.

Недостајуће локализације и ресурси за различите конфигурације

У Debug компилацији ресурси се често учитавају из изворних директоријума без провере конфигурације. У Release Gradle и Xcode примењују филтрирање ресурса: ако се string или drawable не пронађе у циљаној локализацији, апликација или пада или приказује placeholder. Ово је посебно критично за Android: недостатак превода у values-XX доводи до ClassCastException при парсирању XML. Проверите све локализације пре Release компилације помоћу lint и xcodebuild -showBuildSettings. За откривање оваквих проблема користите TestFlight и Internal Testing track пре јавног издања — они се покрећу на стварним уређајима са различитим језичким подешавањима.