iOS und Android — nativ oder plattformübergreifend, je nach Geschäftsentscheidung
Native iOS-(Swift-) und Android-(Kotlin-)Entwicklung sowie plattformübergreifende React-Native-Entwicklung. Build und Deployment über Fastlane + CI/CD, vollständige Unterstützung bei der Veröffentlichung im App Store und bei Google Play. Backend-Integration über REST oder GraphQL.
Geschäftskontext
Probleme, die wir lösen
Typische Situationen, in denen sich ein Gespräch mit uns lohnt. Wenn mehr als eine davon zutrifft, können wir wahrscheinlich helfen.
- P01
Web-Apps sind auf Mobilgeräten unhandlich
Kunden möchten die App auf dem Smartphone nutzen, aber die Web-UI ist nicht touch-optimiert. Kein Push, kein Offline-Modus, keine Präsenz im App Store. Native oder plattformübergreifende mobile Entwicklung liefert die passende UX.
- P02
Native Entwicklung ist für beide Plattformen teuer und langsam
Swift für iOS, Kotlin für Android — zwei Codebasen, zwei Teams, zwei Release-Zyklen. Plattformübergreifendes React Native ermöglicht 60–80 % gemeinsam genutzten Code, mit nativen Modulen bei Bedarf.
- P03
Plattformübergreifende Lösungen stoßen an Grenzen
React Native oder Flutter versprechen überall denselben Code. Erweiterte Funktionen (In-App-Käufe, Share-Erweiterung, Widgets) benötigen weiterhin plattformspezifische Integration. Wir wissen, wann sich der Rückgriff auf Native lohnt.
- P04
Die Bereitstellung im App Store und Play Store ist komplex
Apple Developer Program, Code-Signing, App Store Connect, Screenshot-Erstellung je Größe, Review-Prozess. Ohne Vorbereitung gehen leicht 2–3 Wochen verloren. Fastlane + dokumentierte Einreichungs-Checkliste.
Leistungen
Was wir liefern
Konkrete Ergebnisse, keine abstrakten Fähigkeiten. Dokumentation und Übergabe sind bei jeder Lieferung inbegriffen.
Plattformübergreifende React-Native-Apps
Expo oder bare React Native, TypeScript, React Navigation, Redux Toolkit oder Zustand. Native Modulintegration bei Bedarf (Kamera, NFC, Bluetooth). OTA-Updates über Expo EAS Update.
- React Native
- Expo
- TypeScript
- EAS
Natives iOS (Swift)
SwiftUI oder UIKit, Combine-Framework, Swift Concurrency, Xcode 16+. In-App-Käufe, Push, Widget-Erweiterung, Share-Erweiterung. TestFlight-Beta-Verteilung.
- Swift
- SwiftUI
- Xcode
- TestFlight
Natives Android (Kotlin)
Jetpack Compose, Kotlin Coroutines, Hilt DI, Android Studio. Material-3-Design. Google Play Internal Testing für Beta.
- Kotlin
- Jetpack Compose
- Hilt
Backend-Integration über REST/GraphQL
API-First-Entwicklung: Backend und Frontend arbeiten parallel anhand eines OpenAPI- oder GraphQL-Schemas. Authentifizierung (JWT, OAuth), Datei-Upload, Push (FCM oder APNs).
- REST
- GraphQL
- Firebase
- JWT
CI/CD, Store-Einreichung und Rollout
Fastlane-Pipeline für Build und Deployment, GitHub-Actions-Trigger. Automatisierte Screenshot-Erstellung je Größe. Einreichungs-Checkliste, Umgang mit Review-Feedback. Stufenweiser Rollout mit Crash-Analytics.
- Fastlane
- GitHub Actions
- Stufenweiser Rollout
Ergebnis
Was Sie am Ende erhalten
Der Go-Live ist nicht das Ende, sondern eine Übergabe. Sie erhalten jedes der folgenden Artefakte, und Ihr Team kann mit allen davon arbeiten.
- D01
iOS- und Android-Build-Artefakte
Signierte IPA- und AAB-Dateien, bereit für den Upload zu App Store Connect und Play Console. Test- und Produktions-Builds klar getrennt.
- D02
TestFlight- und Internal-Testing-Setup
Einladungsablauf für Beta-Tester, Build-Namenskonvention, Vorlage für Release Notes. Ihr QA-Team kann eigenständig testen.
- D03
Crashlytics und Analytics
Firebase Crashlytics oder Sentry, Event-Logging für zentrale Nutzerflüsse, Basis-Dashboard für die Retention.
- D04
App-Store- und Play-Store-Metadaten
Titel, Beschreibung, Screenshots je Größe, Videovorschau (falls nötig), Werbetext. Lokalisierung mindestens in HU + EN.
- D05
Code-Signing-Zertifikate und -Profile
Team-Setup im Apple Developer Program, Play-Store-Schlüsselgenerierung, dokumentierte Zertifikatsablage und -rotation.
- D06
Build-Pipeline (Fastlane + CI)
Automatisierter Build, Versionserhöhung, Signierung, Store-Upload. PR-Merge bis Beta in 1–2 Stunden.
- D07
Release-Runbook + Crash-Protokoll
Schrittweises Release-Verfahren, Rollback-Pfad (Google Play angehaltenes Release, beschleunigtes Apple-Review).
Prozess
Wie wir arbeiten
Sechs Schritte von der Discovery bis zum Support. Die fachspezifischen Inhalte werden je Projekttyp angepasst.
- 01
Analyse
Plattformstrategie, Funktionsumfang, App-Store-/Play-Store-Anforderungen, Monetarisierungsmodell.
- 02
Design
User Flow, natives oder React-Native-UI, Figma-Prototyp, plattformspezifisches Design-System.
- 03
Entwicklung
Swift / Kotlin / React Native, CI/CD-Pipeline (Fastlane), Beta-Build (TestFlight / Internal Testing).
- 04
Test
Unit-Tests (XCTest / JUnit), UI-Test, manuelles QA, Feedback der Beta-Nutzer, Crash-Analytics.
- 05
Launch
Einreichung bei App Store und Google Play, Screenshots und Metadaten, Review-Management, schrittweiser Rollout.
- 06
Support
Crash-Analytics, Verfolgung von OS-Updates, Veröffentlichung neuer Funktionen, Store-Bewertungsmanagement.
Architektur
Typische Architektur
Typische native oder hybride Mobile-Architektur: Thin Client, gemeinsames API-Gateway, entkoppelte Backend-Services.
Client
Gateway
Backend
Daten
Die native oder plattformübergreifende mobile App enthält die nutzerseitige Logik (UI, Zustand, lokaler Cache). Die eigentliche Geschäftslogik liegt im Backend; die App stellt dar und reagiert auf Nutzeraktionen.
Das mobile API-Gateway (oft gemeinsam mit der Web-API genutzt) übernimmt Authentifizierung, Rate Limiting und Push-Anbindung. Die Backend-Services (Auth, Zahlung, Inhalte) sind unabhängig und austauschbar.
Stack
Stack und Tools
Bewährte, dokumentierte Werkzeuge. Wenn das Projekt es rechtfertigt, weichen wir davon ab — aber wir erklären immer, warum.
Plattformübergreifend
- React Native
- Expo
- TypeScript
Native iOS / Android
- Swift
- Kotlin
Backend und Integration
- GraphQL
- Firebase
- Node.js
- REST API
DevOps und Deployment
- Fastlane
- Docker
Integrationen
Integrationen und Schnittstellen
Typische Mobile-App-Integrationen für Push, Zahlung, Analytics und Authentifizierung.
- Firebase
- OneSignal
- Stripe Mobile
- Apple Pay
- Google Pay
- Sentry
- Crashlytics
- Mixpanel
- RevenueCat
- Auth0
- Branch
- Adjust
Zeitplan
Typischer Projektzeitplan in Wochen
Ein einfaches plattformübergreifendes MVP: 8–10 Wochen. Nativ für beide Plattformen mit MVP: 12–16 Wochen. Komplexe Apps mit Zahlung + Offline + Push: 16–24 Wochen.
- W1-2
Discovery
Plattformstrategie (nativ/plattformübergreifend), Funktionsumfang, Monetarisierungsmodell, Store-Anforderungen.
- W3-5
Design
Nutzerfluss, Figma-Prototyp, plattformspezifische UI-Muster, Design-System je Plattform.
- W6-12
Umsetzung
Sprint-basierte Entwicklung, zweiwöchentliche TestFlight-/Internal-Testing-Releases, Code-Review.
- W13-14
QA + Beta
Geräteübergreifende Tests, Beta-Nutzerfeedback, Bereinigung der Crash-Analytics.
- W15-16
Launch
Store-Einreichung, Review-Prozess, stufenweiser Rollout, Monitoring nach dem Launch.
Grenzen
Was wir nicht machen
Es ist ehrlicher, das von Anfang an klarzustellen. Bestimmte Arbeiten übernehmen wir bewusst nicht — entweder entspricht es nicht unserem Profil, oder wir könnten es nicht in der Qualität liefern, für die wir unseren Namen einsetzen würden.
Spieleentwicklung ist nicht unser Profil
Unity- oder Unreal-basierte Spiele erfordern spezialisiertes Team-Know-how. Unsere Stärke liegt bei Business-Apps (Produktivität, E-Commerce, Gesundheitswesen).
AR/VR ist nicht unsere Kernkompetenz
ARKit-, ARCore- oder VR-Headset-Projekte sind eine andere Spezialisierung. Wir können als Partner unterstützen, übernehmen aber nicht die volle Verantwortung.
Wir arbeiten nicht mit Hybrid-Frameworks (Ionic, Cordova)
Unsere Erfahrung im Jahr 2026 zeigt, dass die UX schwächer ist als bei React Native oder Native. Wir setzen auf React Native oder Native.
Reines White-Label-Rebranding ist nichts für uns
Wenn es sich um eine fertige App handelt und nur Logo und Farben geändert werden, sind dedizierte White-Label-Plattformen günstiger.
Erste Woche
Was Sie in den ersten 5 Arbeitstagen erwarten können
In der ersten Woche geht es um die Plattformentscheidung und die Store-Reife.
- 01
Montag
Kickoff + Plattform-Workshop
Matrix Nativ vs. plattformübergreifend, Monetarisierung, Zielgruppe, Erfolgskennzahl.
- 02
Dienstag
Funktionsumfang
MoSCoW-Priorisierung, MVP-Umfang, Roadmap-Ausblick nach dem Launch.
- 03
Mittwoch
Design-Audit
Markenmaterial, mobile Besonderheiten des Design-Systems, Anforderungen an die Barrierefreiheit.
- 04
Donnerstag
Store- und Abrechnungs-Audit
Apple-Developer- und Google-Play-Konten, Stripe-/Apple-Pay-/Google-Pay-Setup, IAP-Plan.
- 05
Freitag
Roadmap-Präsentation
Sprintplan, Meilensteine, Release-Strategie, Entscheidungspunkte.
Preise
Preismodelle
Drei Zusammenarbeitsmodelle. Jedes erhält nach der Discovery-Phase einen präzisen Umfang — konkrete Zahlen folgen, sobald wir das Projekt gesehen haben.
Fester Umfang
MVP-Umfang zum Festpreis, fester Termin. Neue Funktionen durchlaufen einen Change Request. Klares Scope-Dokument vor der Freigabe.
Ideal, wenn
MVPs, B2C-Apps mit einfachem Funktionsumfang, dedizierte Geschäftsfälle.
Time & Material
Sprint-basierte Iteration. Kontinuierliche Entwicklung entlang einer Roadmap, bei der die nächsten 3–6 Sprints regelmäßig aktualisiert werden.
Ideal, wenn
Produktartige Entwicklung, bei der sich der Umfang mit dem Nutzerfeedback weiterentwickelt.
Retainer
Monatliche feste Kapazität für die Wartung nach dem Launch: Crash-Fixes, Nachverfolgung von OS-Updates, kleinere Feature-Arbeiten, Verwaltung der Store-Bewertungen.
Ideal, wenn
Wartung produktiver mobiler Apps, kleinere Feature-Iterationen, Nachverfolgung von OS-Versionen.
FAQ
Häufig gestellte Fragen
Nächster Schritt
Sprechen wir über Ihr Projekt
Konkreter Umfang, transparente Preise, dokumentierte Lieferung. Das erste 30-minütige Gespräch ist kostenlos, und nach einer NDA teilen wir konkrete Zahlen.