Leistung - Mobile
App, die sich
wirklich anfühlt.
Eine eigene Mobile-App lohnt sich, wenn sie ein konkretes Problem löst. Wir bauen native Apps für iOS und Android: Swift und SwiftUI für Apple, Kotlin und Jetpack Compose für Android. Mit eigenem Backend wo nötig, sauberem App-Store-Submit und laufender Pflege als festem Bestandteil.
Swift und SwiftUIKotlin und Jetpack ComposeBackend-APIApp-Store-SubmissionPush-NotificationsDSGVO-konformDeep-LinkingWartung und UpdatesSwift und SwiftUIKotlin und Jetpack ComposeBackend-APIApp-Store-SubmissionPush-NotificationsDSGVO-konformDeep-LinkingWartung und Updates
Mobile-Apps mit
echtem Fundament.
Wir entwickeln native - mit Swift für iOS und Kotlin für Android. Das ist mehr Aufwand als Cross-Platform, aber die Nutzererfahrung ist spürbar besser: schnellere Animationen, weniger Abstürze, saubere Integration ins Betriebssystem. Cross-Platform hat seine Berechtigung - native bleibt für uns die erste Empfehlung, wenn das Budget es trägt.
01 Native iOS (Swift + SwiftUI) - Human Interface Guidelines konform, plattform-native Gestik, Widgets und App-Clips möglich
02 Native Android (Kotlin + Jetpack Compose) - Material You konform, Back-Stack-Verwaltung, Adaptive Layouts für Tablet und Foldable
03 Backend-API für die App - REST oder GraphQL, Auth (JWT, OAuth), Datenhaltung in PostgreSQL oder Firebase, EU-Hosting
04 Push-Notifications und Deep-Linking - DSGVO-konformes Opt-In, zielgruppenspezifische Segmentierung, Universal Links und App Links
05 App-Store und Google-Play-Submission - Screenshots, Store-Listing-Texte, Privacy-Policy-URL, Age-Rating, vollständige Einreichung
06 Wartung und Updates - SDK-Anpassungen nach OS-Majors, Compliance- Updates, Crash-Monitoring, monatliches Wartungspaket
Native vs. Cross-Platform: warum wir Native bevorzugen
Die Entscheidung zwischen Native und Cross-Platform ist eine technische Abwägung. Wer sie an den Anforderungen ausrichtet, kommt meistens bei Native an - wenn das Projekt es erlaubt.
Bessere UX durch Plattform-Compliance
iOS und Android haben jeweils eigene Design-Systeme: Apples Human Interface Guidelines und Googles Material Design. Diese Systeme definieren nicht nur Farben und Formen, sondern Verhalten - wie eine App auf einen Wisch reagiert, wie Transitions aussehen, wie Navigation strukturiert ist. Nutzer auf iOS erwarten andere Gesten und andere Hierarchien als Nutzer auf Android. Das klingt wie ein Detail, fühlt sich aber als Fremdkörper an, wenn es nicht stimmt.
Native Apps können diese Systeme vollständig abbilden, weil sie direkt mit den Plattform-APIs kommunizieren. Keine Abstraktionsschicht, keine Übersetzungsschicht. Das ist der Unterschied zwischen einer App, die sich anfühlt wie eine App, und einer, die sich anfühlt wie eine Webseite im App-Rahmen.
Performance ohne JS-Bridge-Overhead
Cross-Platform-Frameworks wie React Native verwenden eine JavaScript-Bridge, um zwischen dem JS-Code und den nativen Plattform-APIs zu kommunizieren. Das funktioniert gut für Standardfälle. Bei komplexen Animationen, Kamera-Zugriff, intensiver Sensordatenverarbeitung oder sehr schnellen UI-Transitions ist diese Bridge jedoch ein Flaschenhals. Der Nutzer sieht keine Bridge, er sieht ein Ruckeln.
Flutter löst das teilweise durch sein eigenes Render-System (Skia), führt dafür aber andere Eigenheiten ein: die App rendert komplett selbst, was eine hohe Kontrolle ergibt, aber auch bedeutet, dass plattformspezifische Eigenheiten bewusst nachgebaut werden müssen. Bei nativer Entwicklung entsteht dieses Problem nicht - der Code spricht direkt mit dem System.
Wann Cross-Platform trotzdem Sinn macht
Es gibt Fälle, in denen Cross-Platform die richtige Entscheidung ist:
- Bei Prototypen, die vor allem der Ideen-Validierung dienen, spart ein geteilter Codebase Zeit und Geld.
- Bei sehr standardisierten Apps - Infoseiten, einfache Formulare, schlichte Datenpräsentation ohne komplexe Interaktion - ist der native Mehrwert gering.
- Wenn ein kleines internes Team die App langfristig selbst warten muss und die Kapazität für zwei native Codebasen fehlt, kann Flutter mit einer einzigen Codebase sinnvoll sein.
Wir treffen diese Entscheidung im Discovery-Gespräch und legen sie schriftlich begründet vor.
App-Entwicklung Reduktion bis zum
Reduktion bis zum
Wesentlichen.
Apps, die täglich genutzt werden, wirken einfach - das ist das Ergebnis konsequenten Weglassens. Drei exzellente Funktionen schlagen zwölf mittelmäßige.
Was vor der App-Entwicklung geklärt sein muss
Eine App ist der sichtbare Teil eines Systems, das mehrere Fragen beantwortet haben muss, bevor der erste Screen designed wird. Wer das überspringt, zahlt es später - in Nachträgen, in Architektur-Umbauten oder im schlimmsten Fall in einer App, die nicht abgenommen wird, weil sie gegen App-Store-Regeln verstößt.
Backend-Strategie
Was passiert mit den Daten, die die App produziert oder konsumiert? Braucht es einen eigenen Server mit einer eigenen Datenbank, oder reicht ein Headless-CMS wie Contentful oder Directus? Ist Firebase eine Option, oder widerspricht das der DSGVO-Anforderung des Auftraggebers (Firebase läuft auf Google-Infrastruktur, meist in den USA)? Braucht es Echtzeit-Daten, die über WebSockets geliefert werden, oder genügen reguläre REST-Calls? Wo ein eigenes Backend nötig ist, greift unsere individuelle Anwendungsentwicklung.
Wir klären diese Fragen im Discovery-Schritt und dimensionieren das Backend entsprechend. Overpowered für eine Simple-App ist Geldverschwendung, unterdimensioniert für eine wachsende App ist ein Umbau in 18 Monaten.
User-Account-Modell
Muss der Nutzer einen Account haben? Wenn ja, wie meldet er sich an: E-Mail und Passwort, Google-Login, Apple-Login? Gibt es einen Gast-Modus? Hier lauert eine Apple-spezifische Pflicht: Wer in einer iOS-App Social-Login-Optionen wie Google oder Facebook anbietet, muss auch "Sign in with Apple" implementieren. Das ist keine Empfehlung, das ist Pflicht. Fehlt es, wird die App abgelehnt.
Datenschutz und DSGVO
Beide App-Stores verlangen seit einigen Jahren detaillierte Privacy-Labels: welche Daten werden erhoben, werden sie mit Dritten geteilt, werden sie zu Tracking-Zwecken genutzt? Apple hat zusätzlich ein Privacy-Manifest eingeführt, das Frameworks deklarieren muss, die auf bestimmte System-APIs zugreifen. Wer das ignoriert, bekommt einen App-Review-Reject. Wir bereiten diese Angaben vollständig vor, damit es beim ersten Submit klappt.
Monetarisierung
Ist die App kostenlos und verdient woanders Geld - durch einen Dienst, den sie verlängert? Gibt es ein Pro-Abonnement? Werden digitale Güter oder Inhalte innerhalb der App verkauft? Letzteres ist der heikleste Fall auf iOS: Apple verlangt bei Digital-Goods, die in der App konsumiert werden, zwingend In-App-Purchases über das eigene IAP-System - Stripe oder direkter Kreditkartenverkauf sind für diesen Fall nicht erlaubt. Das hat wirtschaftliche Konsequenzen (Apple und Google nehmen eine Provision), die wir transparent kommunizieren.
App-Store-Approval: die unsichtbare Hürde.
Viele Auftraggeber unterschaetzen den Review-Prozess. Eine fertig entwickelte App ist noch keine App, die im Store steht. Der Weg dorthin hat Stolperfallen, die wir kennen - und die wir vorbereiten.
Apple-Review
Apples App-Review-Team prüft jede eingereichte App manuell. Das dauert in der Regel ein bis drei Werktage, kann aber länger gehen. Gängige Ablehnungsgründe: fehlender Privacy-Manifest (Pflicht seit 2024 für alle Frameworks, die auf bestimmte APIs zugreifen), fehlende "Sign in with Apple"-Option wenn andere OAuth-Anbieter integriert sind, App-Tracking-Transparency-Dialog der nicht korrekt implementiert ist, fehlendes oder unvollständiges Datenschutzlabel, oder eine App, die in der Beschreibung Funktionen verspricht, die nicht funktionieren. Wir prüfen alle diese Punkte vor dem Submit.
Google-Play-Review
Google ist meist etwas schneller und etwas weniger streng, hat aber eigene Anforderungen: Das Target-API-Level muss regelmäßig angehoben werden - Apps, die ein veraltetes Android-API-Level targeten, werden aus dem Store entfernt. Die Data-Safety-Form muss vollständig ausgefüllt sein und mit dem tatsächlichen Verhalten der App übereinstimmen. Unstimmigkeiten werden gelegentlich durch automatische Prüfungen entdeckt und führen zur Suspension.
Was wir vorbereiten
- Screenshots im korrekten Format für alle erforderlichen Geräteklassen
- Store-Listing-Texte auf Deutsch (und Englisch auf Anfrage)
- Privacy-Policy-URL
- Age-Rating-Fragebogen
- Kategorie-Auswahl und Sub-Kategorien
Die gängigen Ablehnungsgründe sind dokumentiert - wir bereiten alles so vor, dass der erste Submit der einzige sein muss.
Von der Idee bis
zum Store.
Vier klar abgegrenzte Phasen. Sie sehen den Stand jederzeit, von der Beauftragung bis zum App-Store-Launch.
01.
Discovery und Konzept.
01
Erst verstehen,
dann bauen.
Wir klären gemeinsam, was die App können muss - und welche Funktionen für das erste Release warten dürfen. Viele App-Ideen sind für ein erstes Release zu groß. Der MVP, der schnell lauffähig ist und den Kern des Problems löst, ist fast immer kleiner als die ursprüngliche Idee. Wir helfen dabei, ihn herauszuarbeiten: User-Flows kartieren, technische Constraints benennen, Backend-Bedarf einschätzen, Plattform-Priorität setzen.
Use-Cases werden konkret beschrieben - statt "der Nutzer kann alles sehen" heißt es "der eingeloggte Nutzer sieht seine letzten zehn Buchungen in umgekehrter chronologischer Reihenfolge". Diese Präzision kostet im Discovery-Schritt Stunden, spart später Tage an Missverständnissen. Technische Constraints - Offline-Fähigkeit, Kamera-Zugriff, Standortdaten, Hintergrundprozesse - werden frühzeitig bewertet, weil sie Architektur-Entscheidungen beeinflussen.
Sie erhalten ein schriftliches Konzept mit Funktionsumfang, vorgeschlagener Architektur (native oder begründet cross-platform), Backend-Strategie, Datenschutz-Hinweisen und einer realistischen Einschätzung von Aufwand und Zeitrahmen. Erst wenn Konzept und Umfang verabschiedet sind, beginnt die eigentliche Entwicklung.
02.
Prototyp und Design.
02
Klickbar,
bevor Code läuft.
Vor der ersten Zeile produktivem Code entsteht ein klickbarer Prototyp in Figma. Er schützt vor teuren Missverständnissen. Was sich auf dem Papier gut anhört, fühlt sich im Klick-Prototyp manchmal anders an - das ist der richtige Moment, es zu ändern, lange vor sechs Wochen Entwicklung.
Das Interface-Design folgt den Human Interface Guidelines (iOS) und den Material Design Guidelines (Android). Abweichungen sind möglich und manchmal sinnvoll - aber sie brauchen eine Begründung. Eine App, die sich auf iOS wie Android anfühlt, oder umgekehrt, verwirrt Nutzer, auch wenn sie das nicht benennen können. Für komplexe Animationen und Micro-Interactions nutzen wir Lottie, was spätere Entwicklung direkt aus dem Design-Export beschleunigt.
Prototyp-Feedback ist der günstigste Moment für Korrekturen. Wir machen einen strukturierten User-Test-Durchlauf und halten Architektur- Entscheidungen fest, die aus dem Design folgen: Navigationsstruktur, Tab-Bar vs. Drawer, Modal-Verwendung, Onboarding-Flow. Diese Entscheidungen stehen danach fest und schaffen Klarheit für den Bau-Schritt.
03.
Bau und TestFlight/Beta.
03
Echte Builds,
echte Tests.
Wir entwickeln iOS und Android parallel oder sequenziell, je nach Budget und Markt-Priorität. Builds werden laufend über TestFlight (iOS) und Google Play Internal Testing (Android) ausgeliefert - Sie können jederzeit auf Ihrem eigenen Gerät testen, ohne auf einen finalen Release warten zu müssen. Sprint-Modell: jede Woche gibt es etwas Neues zu sehen.
Backend-API und Datenmodell werden parallel aufgebaut, wenn die App eine eigene Datenhaltung braucht. Push-Notifications werden von Anfang an als Teil der Architektur eingebunden. Crash-Reporting (Firebase Crashlytics oder Sentry) wird vom ersten Beta-Build an aktiv, damit wir Probleme erkennen, bevor sie Store-Reviewer sehen.
Jede Iteration schließt mit einem Review-Gespräch ab. Was noch fehlt, was angepasst wird, was bewusst für Version 2 zurückgestellt wird - das klären wir gemeinsam. Jeder Zurückstellungsentscheid wird schriftlich festgehalten, damit nichts verloren geht. Beta-Tester können ab diesem Schritt aktiv eingebunden werden: TestFlight-Links für bis zu 10.000 Tester, internes Feedback-System.
04.
Submission und Wartung.
04
Store-Submit,
ohne Rückfragen.
Die Einreichung im Apple App Store und bei Google Play übernehmen wir vollständig: Screenshots in allen erforderlichen Formaten, Store-Listing- Texte, Metadaten, Datenschutzangaben, Age-Rating, Data-Safety-Form, Privacy-Manifest. Der Review-Prozess bei Apple ist in der Regel der aufwendigere - die gängigen Ablehnungsgründe sind dokumentiert, und wir bereiten die App entsprechend vor.
Nach dem Launch richten wir Crash-Reporting und Update-Prozess ein, damit spätere Versionen reibungslos eingereicht werden können. Monatliche Wartung ist Pflicht: Apple und Google erhöhen jährlich das Mindest-Target-API-Level und führen neue Pflicht- Anforderungen ein. Eine App ohne Wartung verfällt mit der Zeit.
Ob Sie danach eine laufende Wartung bei uns beauftragen oder intern fortführen wollen: wir übergeben sauber dokumentierten Code und ein vollständiges Architecture-Decision-Record-Dokument, das jeder Entwickler nachvollziehen kann. Der Wechsel zu einem anderen Entwickler ist jederzeit möglich.
Bevor wir starten.
Native, React Native oder Flutter - was empfehlen Sie?
Unsere erste Empfehlung ist Native: Swift für iOS, Kotlin für Android. Begründung: native Apps fühlen sich besser an, laufen stabiler und integrieren sich sauber in das Betriebssystem - keine JS-Bridge, kein eigenes Render-System. React Native ist für Prototypen und standardisierte Apps eine vernünftige Wahl, hat aber Performance-Grenzen bei komplexen Animationen und Sensor-Zugriff. Flutter gibt hohe Kontrolle, rendert aber komplett selbst - plattformspezifisches Verhalten muss manuell nachgebaut werden. Wir empfehlen ohne Eigeninteresse und legen die Entscheidung schriftlich begründet vor.
iOS und Android gleichzeitig oder erst eine Plattform?
Das hängt von Ihrer Zielgruppe ab. In Deutschland liegt die Android- Marktdurchdringung bei rund 70 Prozent, in Österreich und der Schweiz ähnlich. Wenn Ihre Zielgruppe das widerspiegelt, fangen Sie mit Android an. Bei B2B-Kontexten und kaufkräftigeren Zielgruppen ist iOS oft stärker vertreten. Oft reicht ein OS für den Start vollständig aus, um echtes Nutzerfeedback zu sammeln. Bei nativer Entwicklung sind die Codebasen getrennt - der zweite OS lässt sich sauber nachziehen. Wir helfen bei der Priorisierung im Konzept-Schritt.
Wer reicht die App im Store ein?
Wir - vollständig. Sie benötigen einen Apple Developer Account (99 USD pro Jahr) und ein Google Play Developer-Konto (25 USD Einmalgebühr). Der Account kann bei Ihnen oder - auf Wunsch - bei uns liegen; letzteres macht Sinn wenn Sie keinen eigenen Entwickler haben und alles in einer Hand behalten wollen. Alles andere - Screenshots, Texte, Kategorien, Datenschutz-Angaben, Age-Rating, den eigentlichen Submit-Prozess, die Kommunikation mit dem Review-Team - übernehmen wir. Apple-Review dauert in der Regel ein bis drei Werktage, Google ist meist schneller.
Was kostet eine App?
Das hängt von Umfang, Plattformanzahl, Backend-Komplexität und dem Wartungsmodell danach ab. Eine einfache Informations-App ohne eigene Datenhaltung ist ein anderes Projekt als eine App mit Nutzerverwaltung, Echtzeit-Synchronisation, Offline-Fähigkeit und Abo-Modell. Wir nennen keinen Pauschalpreis ohne Konzept. Nach dem Discovery-Gespräch bekommen Sie eine konkrete Einschätzung mit Umfang und Aufwand - als schriftliches Angebot, bevor Sie sich festlegen.
Können Sie laufende Updates und Wartung übernehmen?
Ja, und wir empfehlen es stark. Apple und Google erhöhen jährlich das Mindest-Target-API-Level - Apps, die nicht mitziehen, werden aus dem Store entfernt oder laufen auf neuen Geräten nicht mehr korrekt. Dazu kommen neue Pflicht-Anforderungen, Datenschutz-Updates und gelegentliche Breaking Changes in System-APIs. Unser Wartungspaket umfasst proaktives Monitoring, SDK-Updates, Compliance-Checks und einen monatlichen Build-Zyklus. Wer intern warten möchte, bekommt von uns sauber dokumentierten Code und eine Übergabe-Session.
Was passiert wenn Apple oder Google die Anforderungen ändern?
OS-Majors kommen jedes Jahr im Herbst: iOS und Android gleichzeitig. Oft gibt es Breaking Changes in APIs oder neue Pflichtanforderungen für den Store. Im Wartungsmodell klären wir das proaktiv in der Vorbereitungsphase - nicht reaktiv nachdem die App im Store gesperrt wurde. Wenn Sie selbst warten: wir liefern die Codebase so aus, dass ein erfahrener Entwickler die jährlichen Updates eigenständig einpflegen kann. Unsere Dokumentation macht klar, was wo konfiguriert ist.
Wer hostet das Backend?
Wir setzen auf EU-Hosting - in der Regel Hetzner (Frankfurt) oder AWS Frankfurt, je nach Anforderungen. DSGVO-Konformität ist Voraussetzung, nicht Option. Firebase ist eine valide Backend-Wahl für bestimmte Fälle - läuft aber auf Google-Infrastruktur, meist in den USA, was datenschutzrechtlich genau abgeklärt werden muss. Wir deklarieren transparent, wo Daten gespeichert werden, und helfen bei der Datenschutzerklärung.
Kann ich In-App-Purchases für digitale Güter nutzen?
Ja, aber mit einer wichtigen Einschränkung: Apple und Google verlangen für digitale Güter und Inhalte, die in der App konsumiert werden, den Einsatz ihres eigenen In-App-Purchase-Systems. Direkter Kreditkartenverkauf über Stripe oder ähnliche Anbieter ist für diesen Fall nicht erlaubt und führt zum App-Reject. Die Provision liegt bei 15-30 Prozent je nach Abo-Laufzeit. Das ist eine wirtschaftliche Größe, die früh in die Kalkulation einfließt. Wir besprechen das im Discovery-Schritt.
Brauchen Push-Notifications eine DSGVO-Einwilligung?
Ja. Push-Notifications erfordern auf beiden Plattformen eine explizite Opt-In-Abfrage des Nutzers - Android seit Version 13 auch systemseitig erzwungen. Wir bauen den Notification-Opt-In-Flow DSGVO-konform auf: erklärende Vorankündigungsmeldung bevor der System-Dialog erscheint, saubere Ablehnung ohne Nagging, Opt-Out jederzeit in den App-Einstellungen erreichbar. Das schreibt sich in wenigen Sätzen, hat aber Auswirkungen auf die Adoption-Rate - wer den Dialog schlecht erklärt, bekommt viele Ablehnungen.
Wie lange dauert ein App-Projekt?
Ein MVP mit einer Plattform, klarem Umfang und vorbereiteten Inhalten läuft in drei bis vier Monaten. Eine App für beide Plattformen mit eigenem Backend und komplexerem Funktionsumfang braucht sechs bis zwölf Monate. Der häufigste Zeitfresser sind unklare Anforderungen und spät geliefertes Feedback, deutlich öfter als die Entwicklung selbst. Discovery-Qualität am Anfang ist der beste Hebel für Termintreue.
Was wenn ich keinen eigenen Apple Developer Account anlegen will?
Sie können Apps auch über unseren Developer Account einreichen lassen, solange Sie kein eigenes Label aufbauen wollen. Langfristig empfehlen wir aber den eigenen Account - er gibt Ihnen volle Kontrolle über Ihre App, Ihre Store-Listing-Seite und Ihre Nutzerdaten. Wir helfen beim Aufsetzen und führen dann in Ihrem Namen ein.