Native App: Schlüsselkonzepte, native iOS- und Android-Entwicklung

Was ist eine Native App

Native App — eine mobile Anwendung, die speziell für eine Plattform mit ihrer nativen Programmiersprache und Tools entwickelt wurde. Für iOS ist dies Swift oder Objective-C mit Xcode, für Android Kotlin oder Java mit Android Studio. Der Code wird direkt in den Maschinencode der Plattform kompiliert (über LLVM für iOS, ART für Android), was maximale Ausführungsgeschwindigkeit gewährleistet.

Native App-Architektur umfasst drei Schichten. Präsentationsschicht — UI-Komponenten (UIKit/SwiftUI auf iOS, Jetpack Compose/Android Views auf Android). Domänenschicht — Geschäftslogik mit Use Cases und Repository-Schnittstellen. Datenschicht — Datenquellen: Netzwerk (URLSession/Alamofire auf iOS, Retrofit/OkHttp auf Android), Datenbank (CoreData/SwiftData, Room), Dateisystem. Jede Schicht verwendet native SDKs — zum Beispiel kann eine iOS-App CoreLocation für Geolokalisierung, CoreBluetooth für BLE, AVFoundation für Kamera, Metal für 3D-Grafiken aufrufen. Android bietet ähnliche Alternativen: FusedLocationProvider für Geo, BluetoothAdapter für BLE, CameraX für Kamera, OpenGL ES/Vulkan für Grafiken.

Lebenszyklus einer nativen App unterscheidet sich je nach Plattform. iOS verwendet ein strenges Modell mit AppDelegate und SceneDelegate: Die App durchläuft die Zustände notRunning → foregroundInactive → foregroundActive → background → suspended. Android verwendet ein flexibleres Modell mit Activity und Fragment: onCreate → onStart → onResume → onPause → onStop → onDestroy, zudem können Prozesse bei Speichermangel vom System beendet werden. Der Entwickler muss die Zustandsspeicherung (iOS: State Restoration, Android: onSaveInstanceState) korrekt handhaben, um eine nahtlose Benutzererfahrung zu gewährleisten.

iOS-Entwicklung: Swift und Xcode

iOS-Entwicklung erfolgt ausschließlich auf macOS in der Xcode-Umgebung — Apples integrierte Entwicklungsumgebung mit Code-Editor, Interface Builder, iOS-Simulator und Profiling-Tools (Instruments). Die Hauptsprache ist Swift, die Apple 2014 eingeführt hat. Swift kombiniert Typsicherheit mit C-naher Leistung und unterstützt OOP-, funktionale und protokollorientierte Programmierparadigmen.

Wichtige iOS-Frameworks:

• UIKit — das Haupt-Framework für den Aufbau von Schnittstellen mit imperativem Ansatz (UIViewController, UIView, Auto Layout)
• SwiftUI — ein deklaratives Framework (iOS 13+) mit @State, @Binding, @ObservedObject für reaktive UI-Updates
• Combine — ein reaktives Programmier-Framework mit Publisher/Subscriber zur Verarbeitung asynchroner Ereignisse
• CoreData / SwiftData — Frameworks für persistente Datenspeicherung mit Objektgraph und SQLite im Hintergrund
• URLSession — ein nativer HTTP-Client mit HTTP/2-Unterstützung, Caching und Hintergrund-Downloads
• ARKit, CoreML, Vision — Frameworks für AR, maschinelles Lernen und Computer Vision auf dem Gerät

Xcode-Tools umfassen: Interface Builder für visuelles UI-Design, Asset Catalog für Ressourcenverwaltung, Swift Package Manager für Abhängigkeiten, Test Navigator für Unit- und UI-Tests (XCTest), Organizer für die Veröffentlichung im App Store. Instruments ermöglicht Profiling von CPU, Speicher, Netzwerk, Grafik und Energieverbrauch. Für CI/CD werden Xcode Cloud oder Drittanbieterdienste (GitHub Actions, Bitrise, Fastlane) verwendet.

Android-Entwicklung: Kotlin und Android Studio

Android-Entwicklung erfolgt in Android Studio — einer IDE basierend auf IntelliJ IDEA von Google. Die Hauptsprache ist Kotlin, die 2017 zur bevorzugten Wahl wurde. Kotlin ist vollständig mit Java kompatibel, bietet aber eine präzisere Syntax, Null-Sicherheit durch den Elvis-Operator, Coroutinen für Asynchronität und Erweiterungsfunktionen. Android Studio umfasst einen Layout-Editor für visuelles Design, einen Android-Emulator mit Google Play Services, APK Analyzer und Profiler.

Wichtige Android-Komponenten:

• Jetpack Compose — ein deklaratives UI-Framework (Android 5+) mit @Composable-Funktionen und reaktivem Zustand über mutableStateOf
• Android Views — ein klassisches imperatives System mit XML-Layouts, Activity, Fragment, RecyclerView
• Room — eine ORM-Bibliothek für SQLite mit Kompilierungszeit-Überprüfung und Flow-Unterstützung
• Retrofit + OkHttp — ein Standard-Stack für HTTP-Anfragen mit Interceptoren, Caching und Coroutine-Unterstützung
• Hilt / Dagger — Dependency-Injection-Frameworks basierend auf JSR-330
• WorkManager — eine API für verzögerte und Hintergrundaufgaben mit Ausführungsgarantie auch nach Neustart

Android-Architekturmuster: Google empfiehlt MVVM mit einer Repository-Schicht. ViewModel speichert Zustand (StateFlow), Repository abstrahiert Datenquellen, Use Cases kapseln Geschäftslogik. Navigation Component verwaltet Bildschirmübergänge über einen Navigationsgraphen. Zum Testen werden JUnit, MockK, Compose UI Test und Espresso verwendet.

Codebeispiel: Swift für iOS

Betrachten wir die Erstellung einer einfachen iOS-App in SwiftUI — eine Aufgabenliste mit Datenspeicherung über SwiftData. Die App demonstriert wichtige native iOS-Entwicklungsmuster: deklarative UI, reaktive Updates, Datenverwaltung.

import SwiftUI
import SwiftData

// 1. Datenmodell mit SwiftData
@Model
final class TaskItem {
    var title: String
    var isCompleted: Bool
    var createdAt: Date

    init(title: String) {
        self.title = title
        self.isCompleted = false
        self.createdAt = Date()
    }
}

// 2. ViewModel mit Geschäftslogik
@Observable
final class TaskViewModel {
    var tasks: [TaskItem] = []

    func addTask(title: String, context: ModelContext) {
        let task = TaskItem(title: title)
        context.insert(task)
        tasks.append(task)
    }

    func toggleTask(task: TaskItem) {
        task.isCompleted.toggle()
    }
}

// 3. Hauptbildschirm der App
struct ContentView: View {
    @Environment(\.modelContext) private var context
    @State private var viewModel = TaskViewModel()
    @State private var newTaskTitle = ""
    @Query private var tasks: [TaskItem]

    var body: some View {
        NavigationStack {
            List {
                Section(header: Text("Neue Aufgabe")) {
                    HStack {
                        TextField("Namen eingeben", text: $newTaskTitle)
                        Button("Hinzufügen") {
                            addTask()
                        }
                        .disabled(newTaskTitle.isEmpty)
                    }
                }
                Section(header: Text("Aufgabenliste")) {
                    ForEach(tasks) { task in
                        HStack {
                            Image(systemName: task.isCompleted ? "checkmark.circle.fill" : "circle")
                                .onTapGesture { viewModel.toggleTask(task: task) }
                            Text(task.title)
                                .strikethrough(task.isCompleted)
                            Spacer()
                            Text(task.createdAt, style: .date)
                                .font(.caption)
                                .foregroundColor(.secondary)
                        }
                    }
                    .onDelete { indexSet in
                        for index in indexSet {
                            context.delete(tasks[index])
                        }
                    }
                }
            }
            .navigationTitle("Meine Aufgaben")
        }
    }

    private func addTask() {
        guard !newTaskTitle.isEmpty else { return }
        viewModel.addTask(title: newTaskTitle, context: context)
        newTaskTitle = ""
    }
}

Wichtige Muster im Code: @Model — ein SwiftData-Makro zur automatischen Erstellung von persistentem Speicher; @Observable — ein Observable-Makro für reaktive UI-Updates; @Query — ein Property Wrapper zum automatischen Laden von Daten aus SwiftData. Die App verwendet die MVVM-Architektur mit einem ViewModel, das die Geschäftslogik verwaltet, und einer SwiftUI-View zur Anzeige. SwiftData speichert Daten automatisch bei Modelländerungen — der Entwickler muss keine SQL-Abfragen schreiben.

Codebeispiel: Kotlin für Android

Eine ähnliche Android-App in Kotlin mit Jetpack Compose und Room. Zeigt die Unterschiede in Architektur und Ansätzen zwischen den Plattformen.

// 1. Entity Room — Datenmodell
@Entity(tableName = "tasks")
data class TaskEntity(
    @PrimaryKey(autoGenerate = true) val id: Int = 0,
    val title: String,
    val isCompleted: Boolean = false,
    val createdAt: Long = System.currentTimeMillis()
)

// 2. DAO — Datenbankabfragen
@Dao
interface TaskDao {
    @Query("SELECT * FROM tasks ORDER BY createdAt DESC")
    fun getAllTasks(): Flow<List<TaskEntity>>

    @Insert
    suspend fun insertTask(task: TaskEntity)

    @Delete
    suspend fun deleteTask(task: TaskEntity)
}

// 3. ViewModel mit Geschäftslogik
class TaskViewModel(private val dao: TaskDao) : ViewModel() {
    val tasks: StateFlow<List<TaskEntity>> = dao
        .getAllTasks()
        .stateIn(viewModelScope, SharingStarted.WhileSubscribed(5000), emptyList())

    fun addTask(title: String) {
        viewModelScope.launch {
            dao.insertTask(TaskEntity(title = title))
        }
    }

    fun toggleTask(task: TaskEntity) {
        viewModelScope.launch {
            dao.insertTask(task.copy(isCompleted = !task.isCompleted))
        }
    }
}

// 4. Compose UI
@Composable
fun TaskScreen(viewModel: TaskViewModel = viewModel()) {
    val tasks by viewModel.tasks.collectAsState()
    var newTitle by remember { mutableStateOf("") }

    Column(modifier = Modifier.padding(16.dp)) {
        Text("Meine Aufgaben", style = MaterialTheme.typography.headlineMedium)

        Row(
            modifier = Modifier.fillMaxWidth().padding(vertical = 8.dp)
        ) {
            OutlinedTextField(
                value = newTitle,
                onValueChange = { newTitle = it },
                label = { Text("Neue Aufgabe") },
                modifier = Modifier.weight(1f)
            )
            Button(
                onClick = { viewModel.addTask(newTitle); newTitle = "" },
                enabled = newTitle.isNotBlank()
            ) {
                Text("Hinzufügen")
            }
        }

        LazyColumn {
            items(tasks, key = { it.id }) { task ->
                Row(
                    modifier = Modifier
                        .fillMaxWidth()
                        .clickable { viewModel.toggleTask(task) }
                        .padding(vertical = 4.dp),
                    verticalAlignment = Alignment.CenterVertically
                ) {
                    Checkbox(checked = task.isCompleted, onCheckedChange = { viewModel.toggleTask(task) })
                    Text(
                        text = task.title,
                        textDecoration = if (task.isCompleted) TextDecoration.LineThrough else TextDecoration.None
                    )
                }
            }
        }
    }
}

Hauptunterschiede zu iOS: Room verwendet @Entity-, @Dao- und @Query-Annotationen für die Arbeit mit SQLite; ViewModel verwaltet den Lebenszyklus über viewModelScope mit Coroutinen; StateFlow bietet reaktive Compose-UI-Updates über collectAsState. Auf Android werden Daten über Flow übertragen — ähnlich wie Combine Publisher, aber mit Abbruch bei Bildschirmwechsel über viewModelScope.

Vor- und Nachteile von Native App

Vorteile nativer Apps gegenüber plattformübergreifenden Lösungen umfassen mehrere Schlüsselaspekte. Leistung: direkter GPU-Zugriff über Metal (iOS) und Vulkan (Android) liefert 60 fps bei komplexen Animationen. API-Zugriff: neue iOS- und Android-Funktionen sind am Veröffentlichungstag verfügbar, ohne auf Framework-Unterstützung warten zu müssen. Benutzererfahrung: native UI-Komponenten (NavigationStack, TabView, Sheet auf iOS; Scaffold, NavigationBar, BottomSheet auf Android) bieten vertrautes Verhalten. Energieeffizienz: nativer Code verbraucht 15–25 % weniger Akku bei Hintergrundaufgaben.

Nachteile nativer Apps: Die Entwicklungskosten sind aufgrund der Notwendigkeit von zwei separaten Teams 1,5–2 Mal höher. Die Markteinführungszeit verlängert sich: zwei parallele Entwicklungen erfordern Koordination und verdoppeln das Testvolumen. Wartung: Updates müssen gleichzeitig für beide Plattformen veröffentlicht werden, was CI/CD erschwert. Für einfache Apps (Kataloge, Feeds, Formulare) können plattformübergreifende Lösungen wirtschaftlicher und schneller sein.

Wann Native App wählen: Spiele und Anwendungen mit intensiver Grafik (Metal, Vulkan, ARKit, ARCore); Apps mit tiefer OS-Integration (Bluetooth LE, NFC, CoreBluetooth, HealthKit, Google Fit); Finanz-, Medizin- und Unternehmens-Apps mit Sicherheits- und Zertifizierungsanforderungen; Projekte, bei denen jede Millisekunde Latenz kritisch ist (Handel, Streaming, Videoanrufe). Für MVPs, Startups und einfache Apps kann plattformübergreifende Entwicklung eine rationalere Wahl sein.