Budowanie i publikacja w rozwoju mobilnym: co to jest, jakie formaty i jak działa

Formaty kompilacji: APK, AAB, IPA

APK vs AAB

APK (Android Package Kit) — tradycyjny format kompilacji i publikacji aplikacji mobilnych na Androida. APK zawiera cały kod, zasoby i manifest aplikacji. AAB (Android App Bundle) — format wprowadzony przez Google w 2018 roku i obowiązkowy dla nowych aplikacji od sierpnia 2021 roku. AAB nie jest instalowany bezpośrednio — Google Play dynamicznie generuje zoptymalizowany APK dla każdego urządzenia z AAB.

Zalety AAB: rozmiar pobierania jest średnio o 15% mniejszy (poprzez dostarczanie tylko potrzebnych zasobów: prawidłowe gęstości ekranu, języki, architektury CPU). AAB obsługuje również dostarczanie modułowe — możesz ładować moduły na żądanie (Play Feature Delivery) lub z opóźnieniem (Play On-Demand). Dla deweloperów AAB jest obowiązkowy; do dystrybucji poza Google Play (sideloading, marketplace) — tylko APK.

IPA

IPA (iOS App Store Package) — instalowalny plik iOS, będący archiwum ZIP zawierającym podpisaną aplikację. IPA zawiera folder Payload/ z bundlem .app, Provisioning Profile i podpis. IPA jest kompilowany tylko na macOS przez Xcode, który tworzy archiwum (.xcarchive) i eksportuje IPA. Do dystrybucji przez App Store IPA jest podpisywany Apple Distribution Certificate; do Ad Hoc lub Enterprise — odpowiednimi certyfikatami.

Kompilacja i optymalizacja: JIT, AOT, ART, Bitcode

JIT vs AOT

JIT (Just-In-Time) — kompilacja kodu podczas wykonywania aplikacji, wpływająca na szybkość kompilacji i publikacji. Na Androidzie do wersji 5.0 (Lollipop) używano Dalvik VM z kompilacją JIT. Przy każdym uruchomieniu aplikacji bajtkod DEX był konwertowany na kod maszynowy «w locie». Wada: spowolnienie przy pierwszym uruchomieniu i dodatkowe zużycie energii. AOT (Ahead-Of-Time) — kompilacja kodu przed uruchomieniem aplikacji, podczas instalacji. Począwszy od Androida 7.0 (Nougat), ART (Android Runtime) kompiluje aplikację w całości podczas instalacji.

ART (Android Runtime) — środowisko uruchomieniowe, które zastąpiło Dalvik w Androidzie 5.0. ART stosuje hybrydowe podejście: kompilacja AOT podczas instalacji + JIT dla często wykonywanych metod. Łączy to szybkość AOT (szybki start) z elastycznością JIT (adaptacyjna optymalizacja). Wynik: wydajność aplikacji Android wzrosła o 20–30% w porównaniu z Dalvik. Dla deweloperów przejście na ART jest przejrzyste — kod nie wymaga zmian.

Bitcode i App Thinning

Bitcode — pośrednia reprezentacja kodu (IR), której Apple używa do ponownej kompilacji IPA dla różnych architektur procesorów. Bitcode jest opcjonalny: dla aplikacji iOS jest domyślnie włączony, dla watchOS i tvOS jest obowiązkowy. Apple może ponownie skompilować Bitcode przy wydaniu nowych procesorów bez udziału dewelopera. App Thinning — technologia Apple obejmująca Slicing (dostarczanie tylko zasobów potrzebnych dla urządzenia) i On-Demand Resources (ładowanie zasobów na żądanie). App Thinning zmniejsza rozmiar pobierania z App Store o 30–50%.

DEX — format bajtkodu dla Androida, wykonywany przez ART/Dalvik. Kod źródłowy Kotlin/Java jest kompilowany do plików class, następnie do DEX przez dx lub d8 (nowoczesne i szybsze narzędzie). Multidex — mechanizm dla aplikacji przekraczających limit 65 536 metod w jednym pliku DEX. W nowoczesnych projektach multidex jest włączany automatycznie, jeśli targetSdkVersion >= 21.

Podpisywanie kodu: Code Signing, Keystore, Provisioning Profile

Android: Keystore

Keystore — plik zawierający klucz prywatny i certyfikat do podpisywania aplikacji Android podczas kompilacji. Keystore jest tworzony przez keytool (polecenie -genkey) lub Android Studio. Ważne: Keystore nie może zostać utracony — bez niego nie można zaktualizować aplikacji w Google Play. Parametry podpisywania: keyAlias, keyPassword, storePassword i storeFile. Format: JKS (Java KeyStore) lub PEPK (Play Encrypted Private Key) dla AAB.

App Bundle ID (Android) — unikalny identyfikator aplikacji w notacji pakietu (com.example.app). Version Code — liczba całkowita do wewnętrznego numerowania wersji (każda nowa kompilacja go zwiększa). Version Name — ciąg wyświetlany użytkownikowi (1.2.3). Te parametry są ustawiane w build.gradle na poziomie aplikacji.

iOS: Apple Certificate i Provisioning Profile

Apple Certificate — certyfikat cyfrowy potwierdzający tożsamość dewelopera. Typy: Development (do debugowania), Distribution (dla App Store), Ad Hoc (do ograniczonej dystrybucji). Certyfikaty są tworzone w Apple Developer Account i pobierane do Keychain. Provisioning Profile — plik łączący certyfikat, App ID (Bundle Identifier) i listę dozwolonych urządzeń. Bez Provisioning Profile aplikacja nie uruchomi się na urządzeniu.

Bundle ID (iOS) — unikalny identyfikator aplikacji (com.example.app). Build Number — numer kompilacji, zwiększany z każdym buildem. Marketing Version — wersja wyświetlana użytkownikowi. Zarządzanie wersjami: dla iOS parametry są ustawiane w Info.plist i Project Settings; dla Androida — w build.gradle. W IT Sectr automatyzujemy aktualizacje wersji przez Fastlane — eliminuje to błędy ludzkie podczas wydania.

Proces publikacji w sklepach

Google Play Console

Google Play Console — narzędzie do publikowania aplikacji Android. Proces: rejestracja konta dewelopera ($25 jednorazowo), utworzenie aplikacji, wypełnienie metadanych (nazwa, opis, zrzuty ekranu, kategoria), przesłanie AAB, konfiguracja cen i dystrybucji, recenzja. Google sprawdza aplikację automatycznie (wirusy, zgodność z politykami) i ręcznie dla niektórych kategorii. Recenzja trwa od kilku godzin do 2–3 dni.

App Store Connect

App Store Connect — platforma Apple do publikowania aplikacji iOS. Proces: konto dewelopera Apple ($99/rok), utworzenie aplikacji w App Store Connect, przygotowanie IPA w Xcode (Archive → Distribute App → App Store Connect), przesłanie przez Transporter lub Xcode, wypełnienie metadanych, wysłanie do recenzji. App Review — ręczna recenzja Apple może zająć od 24 godzin do 7 dni. Typowe przyczyny odrzucenia: nie działające przyciski, niekompletna treść, prośba o uprawnienia bez wyjaśnienia.

Testy beta: TestFlight, Closed/Open Beta

TestFlight (iOS)

TestFlight — oficjalne narzędzie Apple do testów beta aplikacji iOS. TestFlight obsługuje Internal Testing (do 100 testerów przez e-mail, bez recenzji) i External Testing (do 10 000 testerów, z recenzją Apple). Kompilacje są dostępne przez 90 dni, po czym należy przesłać nową kompilację. TestFlight automatycznie aktualizuje aplikację u testerów po przesłaniu nowej kompilacji.

Internal / Closed / Open Beta (Android)

Internal Testing (Android) — do 100 testerów, bez recenzji Google, kompilacja dostępna natychmiast. Closed Beta — do 1000 testerów przez e-mail lub Google Groups, bez recenzji. Open Beta — nieograniczona liczba testerów przez publiczny link, z recenzją Google. Staged Rollout — stopniowe zwiększanie odsetka użytkowników otrzymujących aktualizację (5% → 20% → 50% → 100%). To najbezpieczniejsza metoda wydania.

App Thinning (iOS) — automatyczne zmniejszanie rozmiaru pobieranego IPA: Slicing (tylko potrzebne zasoby dla urządzenia), Bitcode (optymalizacja procesora), On-Demand Resources (pobieranie na żądanie). W IT Sectr używamy TestFlight do testów beta iOS i Internal Testing dla Androida — pozwala to wykryć problemy przed masowym wydaniem.