Discovery & Anforderungsklarung
Stakeholder-Interviews, Nutzerflow-Validierung, Input/Output-Vertrag der Kalorien-Engine, Backend-Lueckenanalyse, DSGVO-Compliance-Mapping, Apple- und Google-Review-Richtlinienanalyse.
Fallstudie · HealthTech · Ernaehrung
BasilDoc — Flutter-Ernaehrungs- und Mahlzeitenplanungs-App
Wie wir eine plattformuebergreifende Ernaehrungs-App entwickelt haben — bereit fuer App Store und Google Play, mit einer Flutter-Codebasis, einer Kalorien- und Makronaehrstoff-Engine, einem woechentlichen Mahlzeitenplaner und In-App-Kauf-Integration, die serverseitiger Quittungsvalidierung fuer Nutzer in Deutschland, Oesterreich, der Schweiz und der gesamten EU standhalt.
Die Aufgabe — mobile Erweiterung eines rein web-basierten Diaetdienstes
Das BasilDoc-Produktteam betrieb einen etablierten webbasierten Diaetdienst und wollte eine mobile Erweiterung fuer iOS und Android. Backend und ein teilweises Design-System waren bereits vorhanden, doch fehlte dem Team interne Mobile-Kompetenz, ein vollstaendiges Lastenheft und eine klare Anforderung: Der In-App-Kauf musste zuverlaessig ueber Apple StoreKit und Google Play Billing funktionieren — fuer Nutzer in Deutschland, Oesterreich, der Schweiz und der gesamten EU, wo Store-Regeln und Steuerbehandlung sich auf Codepfad-Ebene unterscheiden. Wir entwickelten den Mobile-Client in Flutter mit Dart, um beide Plattformen aus einer einzigen Codebasis zu bedienen. Da das Lastenheft unvollstaendig war, fuehrten wir Stakeholder-Interviews durch, um reale Nutzerflows zu klaeren — Zielauswahl, Kalorienberechnung, Rezeptnutzung, Wochenplanung — und die Erkenntnisse fueherten zu Backend- und Design-Anpassungen noch vor der ersten Produktionszeile. Ein kombinierter Scrum/Kanban-Rhythmus absorbierte Anforderungsaenderungen ohne Geschwindigkeitsverlust. Die In-App-Kauf-Integration wurde als eigenstaendiger Workstream mit serverseitiger Quittungsvalidierung gegen beide Store-Endpunkte behandelt. Das Ergebnis ist eine DSGVO-konforme HealthTech-App fuer den DACH- und EU-Markt, die als Referenzprojekt in unserer Mobile-App-Entwicklung steht.
Projektuebersicht
Flutter / Dart plattformuebergreifend
Material 3 + Cupertino Parität
Kalorien- + Makronaehrstoff-Engine
Woechentlicher Mahlzeitenplaner
Rezeptbibliothek mit Video
In-App-Kauf in beiden Stores
Serverseitige Quittungsvalidierung
DSGVO-konform · EU-Store-bereit
Kennzahlen auf einen Blick
Eine Momentaufnahme dessen, was das BasilDoc-Projekt ueber eine Flutter-Codebasis, die Kalorien-Engine und die In-App-Kauf-Integration im ersten Produktionszyklus geliefert hat.
1gemeinsame Dart-Codebasis fuer iOS und Android mit plattformoptimierten Widgets
2Store-Billing-Pipelines synchron verbunden — Apple StoreKit und Google Play Billing
0erfundene Nutzerzahlen in dieser Fallstudie — jede Kennzahl beschreibt den technischen Umfang
~50%Reduktion von Build-, QA- und Release-Zyklen gegenueber zwei parallelen nativen Teams
7 TageUmfang des woechentlichen Mahlzeitenplaners — Ziel, Makros, Rezept-Austausch
14–22 Wo.typisches Lieferfenster fuer ein vergleichbares Flutter-HealthTech-MVP in beiden Stores
Warum Flutter + Dart statt React Native, nativem iOS + Android und Ionic
Die Stack-Entscheidung praegt jeden anderen Architekturentscheid in einem plattformuebergreifenden HealthTech-Projekt. Wir waehlten Flutter mit Dart gegenueber React Native, parallelen nativen iOS- und Android-Teams und Ionic / Capacitor, weil die Abwaegungen genau zu einem Ernaehrungsprodukt passen, bei dem pixelgenaue Darstellung auf beiden Plattformen eine Anforderung ist. Flutter rendert ueber eine eigene Skia-basierte Pipeline statt ueber betriebssystemeigene Primitive — ein Mahlzeitenplan-Raster verhalt sich auf iPhone und Pixel identisch, ohne plattformspezifisches Layout-Drift. Material 3 deckt Android ab, Cupertino-Widgets decken iOS ab — beide aus derselben Dart-Quelle.
React Native schied aus, weil Bridge-Overhead und Render-Pipeline-Unterschiede genau dort plattformspezifische Abweichungen erzeugen, wo eine HealthTech-UI sie sich nicht leisten kann — die Kalorienangaben, die Makro-Balken, das Mahlzeitenraster muessen auf beiden Plattformen pixelgenau landen. Parallele native iOS- und Android-Teams haetten Build-, QA- und Release-Zyklen verdoppelt, ohne dass der Funktionsumfang tiefe plattformspezifische Integrationen erfordert. Ionic / Capacitors WebView-basiertes Rendering verliert die Gestenfluessigkeit, die eine HealthTech-Consumer-App benoetigt.
| Dimension | Flutter (BasilDoc) | React Native | Nativ iOS + Android / Ionic |
|---|---|---|---|
| Rendering-Modell | Skia-basiert; pixelgenaue Darstellung plattformuebergreifend | OS-native Primitive ueber JS-Bridge | Nativ: direkt; Ionic: WebView |
| Anzahl Codebasen | Eine Dart-Codebasis fuer beide Stores | Eine JS/TS-Codebasis mit Plattform-Branches | Nativ: zwei Codebasen; Ionic: eine Web-Codebasis |
| UI-Konsistenz | Material 3 + Cupertino — identisch auf iOS und Android | Plattformstandard — Drift an Layoutkanten | Nativ: vollstaendige Paritaetsarbeit; Ionic: Web-Look |
| Build- / Release-Rhythmus | Eine CI-Matrix baut beide Stores | Eine Matrix; native Module verlangsamen | Nativ: zwei Matrizen; Ionic: Web + Wrapper |
| IAP-Integrationstiefe | Erstanbieter StoreKit + Play Billing Plugins | Community-Plugins; Qualitaet variiert | Nativ: tiefste Integration; Ionic: WebView-Einschraenkungen |
| Gestenfluessigkeit | Hoch — Skia kontrolliert das Frame | Variabel — Bridge kann Frames verlieren | Nativ: beste; Ionic: WebView-Deckel |
| Ausgereiftes Plugin-Oekosystem | Stark bei Consumer-Oberflaechen — Zahlungen, Medien, Push | Stark, aber heterogene Qualitaet | Nativ: volle Plattform; Ionic: Cordova-Legacy |
Plattformreferenzen: Apple StoreKit Dokumentation, Google Play Billing Referenz, Material 3.
iOS-Build — Cupertino-Widgets, Kalorien-Engine und der Empfehlungsalgorithmus
Die iOS-Oberflaeche nutzt Cupertino-Widgets, damit sich BasilDoc fuer iPhone-Nutzer wie eine native App anfuehlt — Navigationsrhythmus, modale Sheets und Picker-Verhalten entsprechen genau dem, was ein iOS-Nutzer in Deutschland, Oesterreich oder der Schweiz erwartet. Die Kalorien- und Makronaehrstoff-Engine liegt im gemeinsamen Dart-Layer: Ein zielbasierter Selektor errechnet ein taegliches Kalorienziel und eine Makroaufteilung (Eiweiss, Kohlenhydrate, Fett), das Empfehlungssystem schlaegt Programme vor, die zum Nutzerprofil passen, und die Rezeptbibliothek rendert mit einem Video-Anleitungsplayer, der iOS-Hintergrundaudio-Regeln beachtet, sodass Nutzer beim Kochen weiter zuschauen koennen.
Die gesamte iOS-Oberflaeche — Onboarding, Zielauswahl, Kalorien-Engine, Rezeptbibliothek, Mahlzeitenplaner — wird vom gleichen Dart-Code gesteuert wie Android, wobei plattformbewusste Widgets die visuelle Schicht zur Renderzeit aufloesen. Der In-App-Kauf-Pfad ist ueber das Erstanbieter-Apple-StoreKit-Plugin verdrahtet, mit Quittungsvalidierungsaufrufen an denselben Server-Endpunkt, den auch Android nutzt. Die kombinierte Oberflaeche wird als Teil unserer Mobile-App-Entwicklung geliefert, mit einem strikten No-Platform-Drift-CI-Gate, das iOS und Android bei jedem Release synchron haelt.
Android-Build — Material 3, Mahlzeitenplaner und Play Billing
Die Android-Oberflaeche nutzt Material 3 aus derselben Dart-Quelle, wobei plattformbewusste Widgets Navigation, Dialoge und Bewegung in Android-native Rhythmen aufloesen. Das Herzstuck ist der woechentliche Mahlzeitenplaner: Nutzer waehlen ein Programm, die Kalorien-Engine errechnet Tagesziel und Makroaufteilung, und der Planer fuellt sieben Tage aus der Rezeptbibliothek mit austauschbaren Slots — ein Nutzer kann das Dienstagsfruehstueck ersetzen, ohne den Rest der Woche neu zu planen. Der Einkaufslisten-Export fasst die ausgewaehlte Woche in eine teilbare Liste zusammen. Push-Erinnerungen fuer Mahlzeiten werden ueber Firebase Cloud Messaging eingebunden, standardmaessig als Opt-in, um die Anforderungen der DSGVO fuer Nutzer in der EU vollstaendig zu erfuellen.
Der In-App-Kauf-Pfad unter Android laeuft ueber Google Play Billing mit demselben serverseitigen Validator wie der iOS-Pfad. Der einzelne Berechtigungseintrag steuert den Feature-Zugang fuer Diaetprogramme, Rezepte und Mahlzeitenhistorie — ein Nutzer, der auf Android abonniert und dann zu iOS wechselt, stellt den Zugang problemlos wieder her, da das Entitlement serverseitig gespeichert ist, nicht store-seitig. Hintergrundworker bearbeiten nicht dringende Operationen — Rezeptbibliothek-Sync, Push-Benachrichtigungsplanung, Zertifikatsrotation — mit Backoff-Semantiken, die Akku-Schonmodi auf Android 10 bis Android 14 bei Samsung, Xiaomi, OnePlus und Pixel respektieren.
Architektur, Datenschutz und die Berechtigungsbruecke
BasilDocs Datenschutzhaltung war eine Architekturentscheidung, bevor sie ein Marketingversprechen wurde. Die App erfasst ausschliesslich die personenbezogenen Daten, die die Kalorien-Engine benoetigt — Ziel, Altersgruppe, Zielgewicht, Ernaehrungseinschraenkungen — und speichert sie unter einer anonymisierten Nutzer-ID, die bewusst von der Zahlungsidentitaet getrennt ist. Apples und Googles Verifizierungsendpunkte verwahren die Quittungen; der serverseitige Validator normalisiert die Antwort und schreibt einen einzigen Berechtigungseintrag, der auf die anonyme ID geschluessel ist. Die Store-Seite sieht das Diaetprofil des Nutzers nie, und die Ernaehrungs-Seite sieht die Apple ID oder das Google-Konto nie.
Regionsbewusste Consent-Flows sind auf Client-Ebene integriert: Nutzer in der EU und im EWR erhalten einen DSGVO-konformen granularen Einwilligungsbildschirm mit getrennten Toggles fuer optionale Produktanalysen gemaess Art. 7 DSGVO; Nutzer in den USA erhalten den entsprechenden CCPA-Hinweis im gleichen Flow. Die Datenschutzhaltung ist so konzipiert, dass eine kuenftige unabhaengige Datenschutzpruefung eine Dokumentationsaufgabe ist, keine architektonische Nachruestung — ein wichtiger Vorteil fuer DACH-Unternehmen, die nach Art. 25 DSGVO (Datenschutz durch Technikgestaltung) auditiert werden.
Compliance-Status: DSGVO-konform · ISO 27001-bereit · SOC 2 Type II in Vorbereitung · HIPAA-faehig · CCPA-bestaetigt.
Projektmethodik
Ein Fuenf-Phasen-Projekt, das BasilDoc von einem unvollstaendigen Lastenheft und einem rein webbasierten Diaetdienst zu einer produktionsreifen iOS- und Android-App mit In-App-Kauf-Integration gefuehrt hat.
Stack & Architektur
Flutter Shared Layer, Material 3 + Cupertino-Strategie, Kalorien- und Makronaehrstoff-Engine, Datenmodell des Mahlzeitenplaners, IAP-Berechtigungsschema, Skeleton des serverseitigen Quittungsvalidators.
Plattform-Builds
Zielbasierte Diaetauswahl, Rezeptbibliothek mit Video-Anleitungsplayer, woechentlicher Mahlzeitenplaner, Einkaufslisten-Export, Push-Erinnerungen, In-App-Kauf fuer beide Stores.
Haertung & Review-Vorbereitung
Haertung der serverseitigen Quittungsvalidierung, DSGVO-konforme Datenschutzerklaerung, regionsbewusste Consent-Flows, App Store HealthTech-Offenlegung, Google Play Datenschutzpruefungsvorbereitung.
Launch & Telemetrie
App Store + Google Play Einreichung fuer EU-Storefronts, Rollout der kostenpflichtigen Stufe, Push-Erinnerungs-Cohort-Optimierung, Opt-in-Analysen fuer Zielabschlussrate.
Anonymes Billing, Abonnementstatus und die Berechtigungsbruecke
BasilDocs Monetarisierungsschicht wurde so entwickelt, dass Zahlungsidentitaet und Ernaehrungsprofil nachweislich getrennt bleiben — denn eine HealthTech-Datenschutzhaltung bricht zusammen, sobald eine einzige Datenbank eine StoreKit-Transaktion mit einer Zielauswahl verknuepft. Abonnements werden ueber Apple StoreKit auf iOS und Google Play Billing auf Android verkauft, wobei die serverseitige Quittungsvalidierung den Verifizierungsendpunkt jedes Stores ansteuert und einen Berechtigungseintrag schreibt, der auf einen anonymisierten, rotierten Bezeichner geschluesselt ist — niemals auf Apple ID, Google-Konto oder E-Mail-Adresse. Innerhalb der Kalorien-Engine und des Mahlzeitenplaners ist ausschliesslich ein kurzlebiger Bearer-Token sichtbar, der auf die Berechtigung abbildet und aggressiv ablaeuft. Zugang zu Diaetprogrammen, Rezeptbibliotheks-Freischaltungen, Video-Player-Gating und woechentliche Mahlzeitenhistorie lesen alle vom selben Berechtigungseintrag — ein einzelnes Abonnement loest plattformubergreifend sauber auf, ueber Neuinstallationen, Geraetwechsel und den kuenftigen Web-Account-Uebergang hinweg. Das gesamte Subsystem wurde mit Erweiterbarkeit im Blick entwickelt: Das Hinzufuegen eines Familienplans, eines Multi-Geraete-Entitlements oder einer Coach-und-Klient-Stufe mit gekoppelten Profilen ist eine Konfigurationsaenderung am Berechtigungsdienst, kein Code-Release. Dieselbe Haltung schafft Raum fuer zukuenftige KI/ML- & Data-Engineering-Funktionen — personalisierte Empfehlungen auf Basis anonymisierter Kohorten, nicht verknuepft mit der Zahlungsidentitaet.
Launch im DACH-Raum und auf dem EU-Markt
BasilDoc wurde fuer Apple App Store und Google Play Storefronts entwickelt, die in Deutschland, Oesterreich, der Schweiz und der gesamten Europaeischen Union aktiv sind. Eine einzige Codebasis bedient alle EU-Regionen ohne plattformspezifische Verzweigung. Consent-Flows sind regionsbewusst auf Client-Ebene implementiert: Nutzer in der EU und im EWR erhalten einen DSGVO-konformen granularen Einwilligungsbildschirm mit getrennten Toggles fuer optionale Produktanalysen gemaess Art. 7 und 13 DSGVO; fuer US-Nutzer wird ein CCPA-konformer Hinweis angezeigt. Die Datenverwaltungspraxis ist mit der DSGVO fuer europaeische Nutzer abgestimmt. Da die anonymisierte Nutzer-ID Ernaehrungsdaten von der Zahlungsidentitaet isoliert, reduziert sich regionale Compliance auf transparente Offenlegung statt auf jurisdiktionsspezifische Datentrennung.
Die In-App-Kauf-Pipelines wurden gegen Apples Sandbox und Googles Lizenztestkanal in beiden Regionen parallel getestet, und das App Store Altersrating sowie das Google Play Inhalts-Rating wurden fuer den HealthTech-Funktionsumfang kalibriert. Die Datenschutzerklaerung wurde so verfasst, dass sie exakt die oben beschriebene Architektur dokumentiert, unter Bezugnahme auf DSGVO-Verpflichtungen gemaess Art. 5, 13, 17 und 25. Das Entwicklungsteam arbeitet nach mitteleuropaeischer Zeit (MEZ) und bietet taeglich vier Stunden Echtzeituberlappung mit dem US-Ostbetrieb (9–13 Uhr ET) fuer Stand-ups, Store-Review-Koordination und Incident-Response.
Tech-Stack und Roadmap
Flutter
Dart
iOS
Android
Material 3
Cupertino widgets
Apple StoreKit
Google Play Billing
REST API
Figma
SQLite cache
Push notifications
Image pipeline
Video instruction player
Makro-Rechner
Kalorien-Engine
Zielbasiertes Empfehlungssystem
Mahlzeitenplaner
Die aktive Roadmap fuer die massgeschneiderte Softwareentwicklung von BasilDoc umfasst einen Wearable-Daten-Ingestionspfad fuer Apple Health und Google Fit, einen Offline-First-Rezeptcache fuer reiseschwache Konnektivitaet, eine Coach-und-Klient-Paarstufe fuer Ernaehrungsberater in Deutschland, Oesterreich und der Schweiz sowie einen Desktop-Companion, der die Flutter-Geschaftslogik ueber Flutter Desktop teilt. Ein DACH-fokussierter Wachstumsfunnel ist mit regionsspezifischen Rezeptbibliotheken geplant, und das Berechtigungs-Subsystem unterstuetzt bereits die Multi-Seat-Zuweisung, die eine kuenftige B2B-Ernaehrungsstufe benoetigen wird.
Planen Sie eine HealthTech-App fuer den DACH-Markt? Sprechen Sie mit uns.
Wenn Sie eine plattformuebergreifende Ernaehrungs- oder HealthTech-App planen, bei der In-App-Kauf-Integration und DSGVO-konforme Datenschutzhaltung einer Apple- und Google-Pruefung standhalten muessen, haben wir diesen Stack vollstaendig ausgeliefert und koennen den Entwicklungszeitplan erheblich verkuerzen. Das Entwicklungsteam ist Teil der YuSMP Group. Wir arbeiten zum Festpreis fuer klar definierte MVPs und in dedizierten Entwicklungsteams fuer laufende Lieferung, mit einem MEZ-Arbeitstag und einer garantierten US-Ostbetrieb-Ueberlappung (9–13 Uhr ET) fuer Stand-ups, Demos und Incident-Response.
Haeufig gestellte Fragen
Was kostet die Entwicklung einer Diaet- und Ernaehrungs-App wie BasilDoc?
Ein plattformuebergreifendes Diaet-MVP fuer iOS und Android mit Flutter, einer Kalorien- und Makronaehrstoff-Engine, einer Rezeptbibliothek und In-App-Kauf-Integration kostet typischerweise 80.000 bis 190.000 EUR. Mit zielbasiertem Empfehlungssystem, woechentlichem Mahlzeitenplaner, Einkaufslisten-Export, Video-Player und Push-Erinnerungen steigt der Umfang auf 220.000 bis 470.000 EUR. Die groessten Kostentreiber sind die Praezision der Kalorien-Engine, die serverseitige Quittungsvalidierung fuer beide Stores und der DSGVO-konforme Consent-Flow fuer den EU-Markt.
Warum Flutter statt React Native oder nativen iOS- und Android-Apps fuer eine HealthTech-App?
Flutter liefert eine einzige Dart-Codebasis fuer iOS und Android mit pixelgenauem Material 3 und Cupertino-Widgets — ideal fuer ein HealthTech-Produkt fuer den DACH-Raum, bei dem plattformpraezise Darstellung eine Anforderung ist. Im Vergleich zu React Native ist die Render-Pipeline stabiler und der Bridge-Overhead geringer. Gegenueber zwei parallelen nativen Teams reduziert eine gemeinsame Codebasis Build-, QA- und Release-Zyklen um rund 50 Prozent — entscheidend fuer kosteneffiziente Softwareentwicklung in Deutschland.
Wie wird der In-App-Kauf ueber Apple StoreKit und Google Play Billing umgesetzt?
Der In-App-Kauf ist ein eigenstaendiger Arbeitsbereich. Der iOS-Client integriert Apple StoreKit, der Android-Client Google Play Billing. Beide Pfade senden Quittungen an einen einzigen serverseitigen Validator, der die Verifizierungsendpunkte beider Stores aufruft, die Antwort normalisiert und einen Berechtigungseintrag pro Nutzer schreibt. Dieser Eintrag steuert den Feature-Zugang fuer Diaetprogramme, Mahlzeitenplaene und Rezepte. Serverseitige Validierung ist Pflicht — rein clientseitige Quittungspruefungen sind trivial angreifbar und gefaehrden die gesamte Abonnementhaltung.
Wie wird DSGVO-Konformitaet fuer eine Ernaehrungs-App im DACH-Raum sichergestellt?
Die App erfasst ausschliesslich die personenbezogenen Daten, die die Kalorien-Engine benoetigt — Ziel, Altersgruppe, Zielgewicht, Ernaehrungseinschraenkungen — und speichert sie unter einer anonymisierten Nutzer-ID, die nicht mit der Zahlungsidentitaet verknuepft ist. Regionsbewusste Consent-Flows zeigen Nutzern in der EU und dem EWR einen DSGVO-konformen granularen Einwilligungsbildschirm. Push-Erinnerungen sind standardmaessig Opt-in, und die Datenschutzerklaerung dokumentiert jeden Datenpfad gemaess Art. 5 und 13 DSGVO.
Wie lange dauert die Entwicklung einer Flutter-HealthTech-App fuer iOS und Android?
Ein fokussiertes MVP mit zielbasierter Diaetauswahl, Kalorien-Engine, Rezeptbibliothek, Mahlzeitenplaner und In-App-Kauf benoetigt typischerweise 14 bis 22 Wochen. Video-Player, Einkaufslisten-Export, personalisierte Empfehlungen und Push-Erinnerungen erfordern zusaetzliche 6 bis 10 Wochen. Fuer Store-Einreichung und Review-Abstimmung — inklusive Apple HealthTech-Offenlegung, Google Play Datenschutzpruefung und DSGVO-konformer Datenschutzerklaerung — sollten 3 bis 5 Wochen eingeplant werden.
Verwandte Fallstudien
Weitere HealthTech- und Consumer-Mobile-Projekte
Unilab
Patienten-App fuer ein staedteuebergreifendes Labornetzwerk — Terminbuchung, Befunde, Push-Benachrichtigungen, Buchhaltungsintegration.
Fallstudie ansehen →
SuperStep
Einzelhandels-Berater-App fuer Boutique-Inventar in mehreren Filialen — ElasticSearch-Suche, 1C-Integration.
Fallstudie ansehen →
Malish
Lokale Marktplatz-App fuer eine stationaere Kinderbedarf-Kette — flexibler Katalog, Online-Bestandssynchronisation.
Fallstudie ansehen →Verwandte Leistungen
MVP-Entwicklung
Investor-ready MVP in 12 Wochen fuer 60–120k EUR. Senior PM, Designer, Entwickler, QA.
Mehr erfahren →
Mobile-App-Entwicklung
Native iOS-, Android- und plattformuebergreifende Apps mit store-ready Release-Pipelines.
Mehr erfahren →
SaaS-Entwicklung
Mandantenfahige SaaS-Plattformen mit SSO, Billing und regionsgebundener Datenhaltung. SOC 2 in Vorbereitung.
Mehr erfahren →Aehnliches Projekt planen
Discovery Call buchenAngebot anfordern
Teilen Sie uns einige Details mit, und ein Senior-Consultant antwortet innerhalb eines Werktages.