Native iOS/Android-Entwicklung
Volle Plattform-Power. Keine Kompromisse.
Swift und Kotlin — volle Geraeteleistung, natives UX, Zugriff auf alle Plattform-APIs.
Warum native Entwicklung¶
Cross-Platform-Frameworks sparen Zeit am Anfang. Native Entwicklung spart Probleme in Produktion.
Wenn Sie Bluetooth Low Energy-Kommunikation mit einem Scanner in der Hand eines Lagerarbeiters brauchen, Background Location Tracking fuer Fahrer oder eine Custom-Kamera-Pipeline fuer OCR in der Produktionslinie — Cross-Platform-Abstraktionen verlangsamen Sie mehr als sie sparen. Jeder Wrapper fuegt Latenz hinzu, schraenkt den Zugriff auf Plattform-APIs ein und erschwert das Debugging.
Swift (iOS) und Kotlin (Android) bieten vollen, uneingeschraenkten Zugriff auf alles, was die Plattform bietet. ARKit/ARCore fuer Augmented Reality, Core ML/ML Kit fuer On-Device-Inferenz, HealthKit/Health Connect fuer Gesundheitsdaten, CallKit fuer VoIP, WidgetKit fuer Home-Screen-Widgets. Kein Warten darauf, dass Framework-Autoren den Wrapper fertig schreiben.
Performance ohne Kompromisse¶
Nativer Code laeuft direkt auf der Hardware. Keine JavaScript Bridge, kein Dart VM-Overhead. Fuer die meisten CRUD-Apps macht das keinen Unterschied. Fuer Echtzeit-Kameraverarbeitung, komplexe Animationen oder schwere Berechnungen ist es ein Abgrund:
- Frame Rate: Stabile 60 fps (120 fps auf ProMotion-Geraeten) auch bei komplexen Animationen
- Memory Footprint: Direkte Kontrolle ueber Allokationen, ARC/GC-Optimierung pro Plattform
- Startzeit: Cold Start unter 1,5s, Warm Start unter 500ms
- Batterie: Optimierte Hintergrundverarbeitung, kein unnoetigiger Bridging-Overhead
Architektur fuer Enterprise¶
Eine Enterprise-Mobile-App ist keine Todo-Liste. Es ist ein System, das Jahre funktionieren muss, Entwickler-Fluktuation ueberstehen, Dutzende Bildschirme und Hunderte Business-Regeln bewaeltigen muss. Architektur entscheidet.
Clean Architecture + MVVM¶
Wir trennen Verantwortlichkeiten in Schichten, die sich unabhaengig aendern:
Domain Layer — reine Business-Logik, Use Cases. Weiss nichts ueber UI, Datenbanken, Netzwerk. Testbar mit Unit-Tests ohne jegliche Abhaengigkeiten. ProcessOrderUseCase, ValidateDeliveryUseCase — jeder Use Case macht eine Sache.
Data Layer — Repository Pattern. Abstraktion ueber Datenquellen (API, lokale DB, Cache). Das Repository entscheidet, woher Daten kommen: Cache? Netzwerk? Beides? Business-Logik weiss es nicht und muss es nicht.
Presentation Layer — ViewModels fuer State Management. SwiftUI auf iOS, Jetpack Compose auf Android. Unidirektionaler Datenfluss — State fliesst in eine Richtung, keine Race Conditions, vorhersagbares Verhalten.
Dependency Injection: Hilt/Koin auf Android, Swinject auf iOS. Jede Abhaengigkeit ist injizierbar und mockbar. Testbar auf jeder Schicht — Unit-Tests fuer Logik, Integrationstests fuer Data Layer, UI-Tests fuer Flows.
Kotlin Multiplatform (KMP)¶
Wo es Sinn macht, Code zu teilen, teilen wir. KMP-Modul fuer:
- Networking: Ktor Client, Serialisierung, API-Modelle
- Business Rules: Validierung, Berechnungen, Transformationen
- Caching: SQLDelight fuer lokale Datenbank
- State Management: Shared ViewModels mit expect/actual fuer plattformspezifisches Verhalten
UI bleibt rein nativ — SwiftUI und Jetpack Compose. Ergebnis: 40-60% geteilter Code, 100% natives UX. Keine Kompromisse beim Benutzererlebnis.
Design System¶
Jede Enterprise-App braucht ein Design System. Nicht weil es trendy ist — weil ohne es das UI nach einem Jahr inkonsistent ist und neue Bildschirme 3x laenger dauern.
Figma → Code Pipeline¶
Design Tokens (Farben, Abstaende, Typografie, Schatten) in Figma definiert, in Code exportiert. Markenfarbe aendern = an einer Stelle aendern, Verbreitung ueber die gesamte App. Wiederverwendbare Komponenten: CoreButton, CoreCard, CoreListItem — konsistentes Verhalten und Erscheinungsbild.
Barrierefreiheit von Anfang an¶
VoiceOver (iOS) und TalkBack (Android) sind keine Nachgedanken. Semantische Labels, Focus Management, Dynamic Type Support. Kontrastverhaeltnisse gemaess WCAG 2.1 AA. Barrierefreiheit ist nicht nur fuer Sehbehinderte — es ist qualitative UI fuer alle.
Wann nativ, wann Cross-Platform¶
Wir entscheiden basierend auf Anforderungen, nicht Ideologie:
| Kriterium | Nativ (Swift/Kotlin) | Cross-Platform (RN/Flutter) |
|---|---|---|
| Hardware-Zugriff (BLE, NFC, Kamera) | ✅ Voll, ohne Wrapper | ⚠️ Ueber Bridge, Einschraenkungen |
| Performance (Animationen, Echtzeit) | ✅ Maximum | ⚠️ Ausreichend fuer die meisten |
| Time-to-Market | ⚠️ Laenger (2 Codebases) | ✅ Kuerzer (1 Codebase) |
| Langfristige Wartung | ✅ Stabil, Plattform-Updates | ⚠️ Framework-Abhaengigkeit |
| Budget | ⚠️ Hoeher | ✅ Niedriger |
Unsere Empfehlung: Fuer operative Apps mit Hardware-Anforderungen, Offline-Modus und langem Lebenszyklus waehlen wir nativ. Fuer MVPs, interne Tools und Content-getriebene Apps erwaegen wir Cross-Platform.
Technologie-Stack¶
iOS: Swift, SwiftUI, UIKit, Combine, async/await, Core Data, SwiftData, Keychain, XCTest, Swift Testing, Xcode Cloud.
Android: Kotlin, Jetpack Compose, Coroutines/Flow, Room, Hilt, DataStore, Espresso, JUnit5, Gradle.
Shared: Kotlin Multiplatform, Ktor, SQLDelight, kotlinx.serialization, Turbine.
CI/CD: Fastlane, GitHub Actions, Bitrise, Firebase App Distribution, TestFlight.
Häufig gestellte Fragen
MVP in 6-8 Wochen. Vollstaendige App mit Offline-Modus, Integration und CI/CD: 3-6 Monate. Abhaengig vom Umfang — ein Discovery-Workshop hilft, Umfang und Zeitplan zu klaeren.
Swift (iOS), Kotlin (Android) fuer native Entwicklung. React Native/Flutter fuer Cross-Platform. Wir waehlen basierend auf Anforderungen, nicht auf Ideologie.