Build und Deployment in der mobilen Entwicklung: was es ist, welche Formate und wie es funktioniert

Build-Formate: APK, AAB, IPA

APK vs AAB

APK (Android Package Kit) — das traditionelle Format zum Erstellen und Veröffentlichen von mobilen Apps unter Android. APK enthält den gesamten Code, die Ressourcen und das Manifest der App. AAB (Android App Bundle) — ein von Google 2018 eingeführtes Format, das ab August 2021 für neue Apps obligatorisch wurde. AAB wird nicht direkt installiert — Google Play generiert dynamisch eine optimierte APK für jedes Gerät aus dem AAB.

Vorteile von AAB: Die Download-Größe ist durchschnittlich 15% kleiner (durch die Auslieferung nur der benötigten Ressourcen: richtige Bildschirmdichten, Sprachen, CPU-Architekturen). AAB unterstützt auch modulare Auslieferung — Sie können Module bei Bedarf (Play Feature Delivery) oder verzögert (Play On-Demand) laden. Für Entwickler ist AAB obligatorisch; für die Verteilung außerhalb von Google Play (Sideloading, Marktplätze) — nur APK.

IPA

IPA (iOS App Store Package) — die iOS-Installationsdatei, ein ZIP-Archiv mit einer signierten App. IPA enthält einen Payload/-Ordner mit dem .app-Bundle, Provisioning Profile und Signatur. IPA wird nur unter macOS über Xcode erstellt, das ein Archiv (.xcarchive) erstellt und IPA exportiert. Für die Verteilung über den App Store wird IPA mit einem Apple Distribution Certificate signiert; für Ad Hoc oder Enterprise — mit entsprechenden Zertifikaten.

Kompilierung und Optimierung: JIT, AOT, ART, Bitcode

JIT vs AOT

JIT (Just-In-Time) — Kompilierung von Code während der App-Ausführung, die die Build- und Veröffentlichungsgeschwindigkeit beeinflusst. Unter Android bis Version 5.0 (Lollipop) wurde Dalvik VM mit JIT-Kompilierung verwendet. Bei jedem App-Start wurde DEX-Bytecode «on the fly» in Maschinencode umgewandelt. Nachteil: Verlangsamung beim ersten Start und zusätzlicher Energieverbrauch. AOT (Ahead-Of-Time) — Kompilierung von Code vor dem App-Start, während der Installation. Ab Android 7.0 (Nougat) kompiliert ART (Android Runtime) die App vollständig während der Installation.

ART (Android Runtime) — die Laufzeitumgebung, die Dalvik in Android 5.0 ablöste. ART verwendet einen hybriden Ansatz: AOT-Kompilierung bei der Installation + JIT für häufig ausgeführte Methoden. Dies kombiniert die Geschwindigkeit von AOT (schneller Start) mit der Flexibilität von JIT (adaptive Optimierung). Ergebnis: Die Leistung von Android-Apps stieg um 20–30% im Vergleich zu Dalvik. Für Entwickler ist der Wechsel zu ART transparent — der Code muss nicht geändert werden.

Bitcode und App Thinning

Bitcode — eine Zwischendarstellung von Code (IR), die Apple verwendet, um IPA für verschiedene Prozessorarchitekturen neu zu kompilieren. Bitcode ist optional: Für iOS-Apps ist es standardmäßig aktiviert, für watchOS und tvOS ist es obligatorisch. Apple kann Bitcode bei neuen Prozessoren ohne Beteiligung des Entwicklers neu kompilieren. App Thinning — Apples Technologie, die Slicing (Auslieferung nur der benötigten Ressourcen für das Gerät) und On-Demand Resources (Laden von Ressourcen bei Bedarf) umfasst. App Thinning reduziert die Download-Größe aus dem App Store um 30–50%.

DEX — Bytecode-Format für Android, ausgeführt von ART/Dalvik. Kotlin/Java-Quellcode wird in Class-Dateien kompiliert, dann über dx oder d8 (ein modernes und schnelleres Tool) in DEX. Multidex — ein Mechanismus für Apps, die das Limit von 65.536 Methoden in einer einzelnen DEX-Datei überschreiten. In modernen Projekten wird Multidex automatisch aktiviert, wenn targetSdkVersion >= 21.

Code Signing: Code Signing, Keystore, Provisioning Profile

Android: Keystore

Keystore — eine Datei mit dem privaten Schlüssel und dem Zertifikat zum Signieren einer Android-App während des Builds. Keystore wird über keytool (der Befehl -genkey) oder Android Studio erstellt. Wichtig: Keystore darf nicht verloren gehen — ohne ihn können Sie die App bei Google Play nicht aktualisieren. Signierungsparameter: keyAlias, keyPassword, storePassword und storeFile. Format: JKS (Java KeyStore) oder PEPK (Play Encrypted Private Key) für AAB.

App Bundle ID (Android) — die eindeutige App-Kennung in Paketnotation (com.example.app). Version Code — eine ganze Zahl für die interne Versionsnummerierung (jeder neue Build erhöht sie). Version Name — eine Zeichenfolge, die dem Benutzer angezeigt wird (1.2.3). Diese Parameter werden in der build.gradle auf App-Ebene festgelegt.

iOS: Apple Certificate und Provisioning Profile

Apple Certificate — ein digitales Zertifikat, das die Identität des Entwicklers bestätigt. Typen: Development (zum Debuggen), Distribution (für den App Store), Ad Hoc (für eingeschränkte Verteilung). Zertifikate werden im Apple Developer Account erstellt und in den Keychain heruntergeladen. Provisioning Profile — eine Datei, die das Zertifikat, die App ID (Bundle Identifier) und eine Liste erlaubter Geräte verknüpft. Ohne Provisioning Profile wird die App auf einem Gerät nicht ausgeführt.

Bundle ID (iOS) — die eindeutige App-Kennung (com.example.app). Build Number — die Build-Nummer, die mit jedem Build erhöht wird. Marketing Version — die dem Benutzer angezeigte Version. Versionsverwaltung: Für iOS werden die Parameter in Info.plist und Project Settings festgelegt; für Android — in build.gradle. Bei IT Sectr automatisieren wir Versionsupdates über Fastlane — dies eliminiert menschliche Fehler bei der Veröffentlichung.

Veröffentlichungsprozess in den Stores

Google Play Console

Google Play Console — ein Tool zum Veröffentlichen von Android-Apps. Prozess: Entwicklerkonto registrieren ($25 einmalig), App erstellen, Metadaten ausfüllen (Name, Beschreibung, Screenshots, Kategorie), AAB hochladen, Preise und Vertrieb konfigurieren, Überprüfung. Google überprüft die App automatisch (Viren, Richtlinienkonformität) und manuell für einige Kategorien. Die Überprüfung dauert zwischen einigen Stunden und 2–3 Tagen.

App Store Connect

App Store Connect — Apples Plattform zum Veröffentlichen von iOS-Apps. Prozess: Apple-Entwicklerkonto ($99/Jahr), App in App Store Connect erstellen, IPA in Xcode vorbereiten (Archive → Distribute App → App Store Connect), über Transporter oder Xcode hochladen, Metadaten ausfüllen, zur Überprüfung einreichen. App Review — Apples manuelle Überprüfung kann 24 Stunden bis 7 Tage dauern. Typische Ablehnungsgründe: nicht funktionierende Schaltflächen, unvollständiger Inhalt, Berechtigungsanfragen ohne Erklärung.

Beta-Tests: TestFlight, Closed/Open Beta

TestFlight (iOS)

TestFlight — Apples offizielles Tool für Beta-Tests von iOS-Apps. TestFlight unterstützt Internal Testing (bis zu 100 Tester per E-Mail, ohne Überprüfung) und External Testing (bis zu 10.000 Tester, mit Apple-Überprüfung). Builds sind 90 Tage lang verfügbar, danach muss ein neuer Build hochgeladen werden. TestFlight aktualisiert die App bei Testern automatisch, wenn ein neuer Build hochgeladen wird.

Internal / Closed / Open Beta (Android)

Internal Testing (Android) — bis zu 100 Tester, ohne Google-Überprüfung, Build sofort verfügbar. Closed Beta — bis zu 1000 Tester per E-Mail oder Google Groups, ohne Überprüfung. Open Beta — unbegrenzte Tester über einen öffentlichen Link, mit Google-Überprüfung. Staged Rollout — schrittweise Erhöhung des Prozentsatzes der Benutzer, die das Update erhalten (5% → 20% → 50% → 100%). Dies ist die sicherste Veröffentlichungsmethode.

App Thinning (iOS) — automatische Reduzierung der heruntergeladenen IPA-Größe: Slicing (nur benötigte Ressourcen für das Gerät), Bitcode (Prozessoroptimierung), On-Demand Resources (Download bei Bedarf). Bei IT Sectr verwenden wir TestFlight für iOS-Beta-Tests und Internal Testing für Android — so können wir Probleme vor einer Massenveröffentlichung erkennen.