Case study · HealthTech · Nutrition
Come abbiamo consegnato un'app di nutrizione consumer cross-platform — pronta per App Store e Google Play, con un unico codebase Flutter, un motore calorie e macro, un costruttore di piani pasto settimanali e un'infrastruttura In-App Purchase che regge alla validazione delle ricevute per il pubblico negli Stati Uniti e nell'Unione Europea fin dal primo giorno.
Il team di prodotto BasilDoc gestiva un servizio di dieta web consolidato e voleva una controparte mobile su iOS e Android. Il backend e un sistema di design parziale erano già in essere, ma il team non aveva capacità mobile interna, aveva una specifica incompleta e un requisito imprescindibile che l'In-App Purchase funzionasse correttamente tra Apple StoreKit e Google Play Billing — per il pubblico negli Stati Uniti e nell'Unione Europea dove le regole degli store e la gestione fiscale differiscono in modi che contano a livello di codepath. Abbiamo realizzato il client mobile in Flutter con Dart per consegnare entrambe le piattaforme da un unico codebase. Poiché la specifica era esile, abbiamo condotto interviste con gli stakeholder per chiarire i flussi utente reali — selezione degli obiettivi, calcolo delle calorie, consumo delle ricette, pianificazione settimanale — e le risposte hanno guidato aggiustamenti al backend e al design definiti prima che venisse scritto qualsiasi codice di produzione. Una cadenza combinata Scrum/Kanban ha assorbito i cambi di scope senza perdere velocità, e l'infrastruttura In-App Purchase è stata trattata come un flusso di lavoro autonomo con validazione delle ricevute lato server sugli endpoint di verifica di Apple e Google. Il risultato finale è un'app HealthTech consumer pronta per gli store USA e UE, posizionata come build di punta nella nostra practice di sviluppo app mobile.
Una panoramica di ciò che la build BasilDoc ha consegnato su un unico codebase Flutter, il motore calorico e l'infrastruttura In-App Purchase durante il suo primo ciclo di produzione.
La scelta dello stack domina ogni altra decisione architetturale in una build HealthTech cross-platform. Abbiamo scelto Flutter con Dart rispetto a React Native, iOS e Android nativi in parallelo e Ionic / Capacitor perché i compromessi si allineano perfettamente con un prodotto di nutrizione consumer dove la parità di pixel tra piattaforme è una funzionalità. Flutter esegue il rendering attraverso la propria pipeline basata su Skia invece di delegare gli alberi di widget alle primitive native del sistema operativo, il che significa che una griglia di piani pasto si comporta in modo identico su iPhone e Pixel senza drift di layout per piattaforma. Material 3 copre Android e i widget Cupertino coprono iOS, entrambi dalla stessa sorgente Dart.
React Native è stato escluso perché l'overhead del bridge e le differenze nella pipeline di rendering aggiungono drift per piattaforma esattamente dove una UI HealthTech non può permetterselo — i numeri del motore calorico, le barre dei macro, la griglia dei piani pasto devono tutti atterrare sullo stesso pixel su entrambe le piattaforme. iOS e Android nativi in parallelo avrebbero raddoppiato i cicli di build, QA e rilascio per un set di funzionalità che non richiede integrazioni profonde specifiche per piattaforma. Il rendering basato su WebView di Ionic / Capacitor perde la fluidità gestuale di cui un'app HealthTech consumer ha bisogno.
| Dimensione | Flutter (BasilDoc) | React Native | iOS + Android nativi / Ionic |
|---|---|---|---|
| Modello di rendering | Basato su Skia; parità di pixel tra piattaforme | Primitive native del SO tramite bridge JS | Nativo: diretto; Ionic: WebView |
| Numero di codebase | Un unico codebase Dart per entrambi gli store | Un unico codebase JS/TS con rami per piattaforma | Nativo: due codebase; Ionic: un codebase web |
| Coerenza UI | Material 3 + Cupertino — identica su iOS e Android | Predefinito per piattaforma — drift sui bordi del layout | Nativo: lavoro di piena parità; Ionic: aspetto web |
| Cadenza build / rilascio | Singola matrice CI che fa la build di entrambi gli store | Matrice singola; i moduli nativi rallentano | Nativo: due matrici; Ionic: web + wrapper |
| Profondità integrazione IAP | Plugin first-party StoreKit + Play Billing | Plugin della community; qualità variabile | Nativo: massima profondità; Ionic: restrizioni WebView |
| Fluidità gestuale | Alta — Skia gestisce il frame | Variabile — il bridge può far perdere frame | Nativo: massima; Ionic: limite del WebView |
| Ecosistema plugin maturo | Solido sulle superfici consumer — pagamenti, media, push | Solido, ma qualità eterogenea | Nativo: piattaforma completa; Ionic: eredità Cordova |
Platform references: Apple StoreKit documentation, Google Play Billing reference, Material 3.
La superficie iOS utilizza widget Cupertino affinché l'esperienza BasilDoc risulti nativa per un utente iPhone — il ritmo di navigazione, i fogli modali, il comportamento del picker corrispondono tutti a ciò che un pubblico iOS negli USA o nell'UE si aspetta di serie. Il motore calorico e dei macro risiede nello strato condiviso Dart: un selettore basato sugli obiettivi risolve un target calorico giornaliero e una ripartizione dei macro (proteine, carboidrati, grassi), il motore di raccomandazione basato sugli obiettivi propone programmi che corrispondono al profilo dell'utente, e la libreria ricette viene renderizzata con un player video con istruzioni che rispetta le regole audio in background di iOS affinché un utente possa continuare a cucinare mentre un passaggio viene riprodotto.
L'intera superficie iOS — onboarding, selezione degli obiettivi, motore calorico, libreria ricette, costruttore di piani pasto — è guidata dallo stesso codice Dart che guida Android, con widget consapevoli della piattaforma che risolvono il livello visivo al momento del rendering. Il percorso In-App Purchase è cablato tramite il plugin Apple StoreKit first-party, con chiamate di validazione ricevute inviate allo stesso endpoint server che usa Android. La superficie combinata viene consegnata come parte della nostra practice di sviluppo app mobile, con un gate CI rigoroso anti-drift di piattaforma che mantiene iOS e Android sincronizzati ad ogni rilascio.
La superficie Android utilizza Material 3 dalla stessa sorgente Dart, con widget consapevoli della piattaforma che risolvono navigazione, dialoghi e animazioni ai ritmi nativi di Android. Il costruttore di piani pasto settimanali è il pezzo centrale: gli utenti scelgono un programma, il motore calorico risolve un target giornaliero e una ripartizione dei macro, e il costruttore popola sette giorni dalla libreria ricette con slot facilmente sostituibili così un utente può cambiare la colazione del martedì senza ricostruire il resto della settimana. L'esportazione della lista della spesa raggruppa la settimana selezionata in un'unica lista condivisibile, e i promemoria push per i pasti sono cablati tramite Firebase Cloud Messaging su Android con un default opt-in per restare in regola con il GDPR per gli utenti nell'Unione Europea.
Il percorso In-App Purchase su Android passa attraverso Google Play Billing con lo stesso validatore lato server che usa il percorso iOS. Il singolo record di entitlement controlla l'accesso alle funzionalità tra programmi dietetici, accesso alle ricette e cronologia dei piani pasto — il che significa che un utente che si abbona su Android e poi passa a un iPhone ripristina l'accesso correttamente perché l'entitlement è lato server, non lato store. I worker in background gestiscono le operazioni non urgenti — sincronizzazione della libreria ricette, pianificazione delle notifiche push, rotazione dei certificati — con semantiche di backoff che rispettano gli stati di risparmio energetico su Android 10 fino ad Android 14 sui dispositivi Samsung, Xiaomi, OnePlus e Pixel.
La postura sulla privacy di BasilDoc era una decisione architetturale prima di essere una dichiarazione di marketing. L'app raccoglie solo i dati personali di cui il motore calorico ha bisogno — obiettivo, fascia d'età, peso target, restrizioni alimentari — e li conserva sotto un ID utente opaco deliberatamente separato dall'identità di pagamento. Gli endpoint di verifica di Apple e Google conservano le ricevute; il validatore lato server normalizza la risposta e scrive un unico record di entitlement indicizzato dall'ID opaco. Il lato store non vede mai il profilo alimentare dell'utente, e il lato alimentare non vede mai l'Apple ID o l'account Google dell'utente.
I flussi di consenso consapevoli della regione sono cablati al livello client: gli utenti nell'UE e nello SEE ricevono una schermata di consenso granulare in stile GDPR con toggle separati per eventuali analisi di prodotto facoltative; gli utenti in California ricevono un'informativa in stile CCPA «Non vendere né condividere le mie informazioni personali» nello stesso flusso. La postura è costruita per allinearsi agli obblighi GDPR per gli utenti nell'Unione Europea e agli obblighi CCPA / CPRA per gli utenti in California e negli Stati Uniti — e per rendere una futura revisione della privacy indipendente un esercizio di documentazione piuttosto che un retrofit architetturale.
Postura di conformità: allineata GDPR · pronta ISO 27001 · SOC 2 Tipo II in corso · compatibile HIPAA · CCPA riconosciuta.
Una build in cinque fasi che ha portato BasilDoc da una specifica esile e un servizio di dieta solo web a un'app iOS e Android in produzione con infrastruttura In-App Purchase.
Interviste agli stakeholder, validazione dei flussi utente, contratto input/output del motore calorico, analisi delle lacune del backend, mappatura postura GDPR + CCPA, revisione delle policy di revisione Apple e Google.
Strato condiviso Flutter, strategia Material 3 + Cupertino, motore calorie e macro, modello dati del costruttore di piani pasto, schema entitlement IAP, struttura del validatore di ricevute lato server.
Selezione della dieta basata sugli obiettivi, libreria ricette con player video con istruzioni, costruttore di piani pasto settimanali, esportazione lista della spesa, promemoria push, In-App Purchase su entrambi gli store.
Hardening della validazione ricevute lato server, redazione della privacy policy, flussi di consenso consapevoli della regione, informativa HealthTech per App Store, preparazione alla revisione dati sensibili di Google Play.
Sottomissione su App Store + Google Play per gli store USA e UE, rollout del livello a pagamento, calibrazione coorte promemoria push, analisi opt-in per il tasso di completamento degli obiettivi.
Il livello di monetizzazione di BasilDoc è stato costruito per mantenere provabilmente separati l'identità di pagamento e il profilo alimentare, perché la postura sulla privacy di un'app HealthTech si sgretola nel momento in cui un singolo database unisce una transazione StoreKit a una selezione di obiettivi. Gli abbonamenti vengono venduti tramite Apple StoreKit su iOS e Google Play Billing su Android, con validazione delle ricevute lato server che accede all'endpoint di verifica di ogni store e scrive un unico record di entitlement indicizzato da un identificatore opaco e ruotato — mai dall'Apple ID, dall'account Google o dall'indirizzo e-mail. All'interno del motore calorico e del costruttore di piani pasto, l'unica cosa visibile è un bearer token di breve durata che mappa sull'entitlement e scade in modo aggressivo. L'accesso ai programmi dietetici, lo sblocco della libreria ricette, il gating del player video con istruzioni e la cronologia dei piani pasto settimanali leggono tutti dallo stesso record di entitlement, così un singolo abbonamento si risolve correttamente attraverso reinstallazioni, cambi di dispositivo e il futuro passaggio a un account web. L'intero sottosistema è stato costruito pensando all'estensibilità: aggiungere un piano famiglia, un entitlement multi-dispositivo o un livello coach-e-cliente con profili abbinati è una modifica di configurazione al servizio di entitlement, non un rilascio di codice. La stessa postura lascia spazio a future funzionalità di AI/ML & ingegneria dei dati — raccomandazioni personalizzate calibrate su coorti anonimizzate, non unite all'identità di pagamento.
BasilDoc è stata realizzata per gli store Apple App Store e Google Play attivi negli Stati Uniti e nell'Unione Europea. La build in lingua inglese serve gli utenti in California, New York, Texas, Florida e Washington negli USA, e gli utenti nei Paesi Bassi, Germania, Francia, Irlanda e Svezia nell'UE, senza un codebase separato per regione. I flussi di consenso sono consapevoli della regione al livello client: gli utenti nell'UE e nello SEE ricevono una schermata di consenso granulare in stile GDPR con toggle separati per eventuali analisi di prodotto facoltative; gli utenti in California ricevono un'informativa in stile CCPA «Non vendere né condividere le mie informazioni personali» nello stesso flusso. Le pratiche di gestione dei dati sono allineate al GDPR per gli utenti europei e al mosaico delle leggi sulla privacy degli stati USA — CCPA / CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) e Oregon CPA. Poiché l'ID utente opaco isola i dati alimentari dall'identità di pagamento, la conformità regionale si riduce a una divulgazione onesta piuttosto che a una segregazione dei dati per giurisdizione.
Le pipeline In-App Purchase sono state testate contro la sandbox di Apple e il canale di test delle licenze di Google Play in entrambe le regioni in parallelo, e la classificazione per età dell'App Store più il rating dei contenuti di Google Play sono stati calibrati per il set di funzionalità HealthTech. La privacy policy è stata redatta per documentare esattamente l'architettura di cui sopra, citando direttamente gli obblighi GDPR e gli obblighi CCPA della California. Il team di ingegneria dietro la build si trova nel fuso CET e gestisce una giornata lavorativa CET con sovrapposizione con la costa est degli USA (9:00–13:00 ET) per stand-up, coreografia della revisione negli store e risposta agli incidenti — il fuso orario che consente a un team di prodotto negli USA e a un team di ingegneria nell'UE di condividere quattro ore di sovrapposizione in diretta ogni giorno.
La roadmap attiva di sviluppo software su misura per BasilDoc include un percorso di ingestione dei dati da wearable per Apple Health e Google Fit, una cache di ricette offline-first per i viaggi a bassa connettività, un livello abbinato coach-e-cliente per i nutrizionisti negli USA e nell'UE, e un'app desktop companion che condivide la logica di business Flutter tramite Flutter Desktop. Sono pianificati un funnel di crescita focalizzato sugli USA e uno focalizzato sull'UE con librerie di ricette specifiche per regione, e il sottosistema di entitlement supporta già l'assegnazione multi-posto di cui un futuro livello B2B per la nutrizione avrà bisogno.
Se state pianificando un'app di dieta, nutrizione o HealthTech cross-platform dove l'infrastruttura In-App Purchase e la postura sulla privacy devono superare la revisione di Apple e Google per il pubblico negli USA e nell'UE, abbiamo consegnato questo stack dall'inizio alla fine e possiamo comprimere significativamente i tempi di sviluppo. Il team di ingegneria dietro di essa fa parte di YuSMP Group. Lavoriamo a prezzo fisso per MVP ben definiti e con team dedicati per la consegna continuativa, con una giornata lavorativa CET e una finestra garantita di sovrapposizione con la costa est degli USA (9:00–13:00 ET) per stand-up, demo e risposta agli incidenti.
Un MVP cross-platform di dieta e pianificazione dei pasti che copre iOS e Android tramite Flutter, un motore calorie e macro, una libreria di ricette e l'infrastruttura In-App Purchase ha un costo tipico di 90.000–210.000 €. L'aggiunta di un motore di raccomandazione basato sugli obiettivi, costruttore di piani pasto settimanali, esportazione lista della spesa, player video con istruzioni e promemoria push porta un prodotto completo a 250.000–520.000 €. I principali fattori di costo sono la precisione del motore calorico, la validazione delle ricevute In-App Purchase su due store e il flusso di consenso GDPR e CCPA calibrato per gli store USA e UE.
Flutter consegna un unico codebase Dart a iOS e Android con widget Material 3 e Cupertino pixel-accurate, il che si adatta a un prodotto HealthTech consumer dove la parità tra piattaforme è una funzionalità, non un caso. Rispetto a React Native, la pipeline di rendering è più prevedibile e l'overhead del bridge è inferiore. Rispetto a iOS e Android nativi in parallelo, un unico codebase riduce di circa la metà i cicli di build, QA e rilascio per un set di funzionalità che non richiede integrazioni profonde specifiche per piattaforma.
L'In-App Purchase è un flusso di lavoro autonomo. Il client iOS integra Apple StoreKit, il client Android integra Google Play Billing, e entrambi i percorsi client inviano le ricevute a un unico validatore lato server che accede agli endpoint di verifica di Apple e Google, normalizza la risposta e scrive un unico record di entitlement per utente. Quel record controlla l'accesso alle funzionalità tra programmi dietetici, piani pasto e ricette. La validazione lato server è obbligatoria — i controlli delle ricevute solo lato client sono aggirati banalmente e compromettono l'intera postura dell'abbonamento.
L'app raccoglie solo i dati personali necessari per far funzionare il motore calorico — obiettivo, fascia d'età, peso target, restrizioni alimentari — e li conserva sotto un ID utente opaco non associato all'identità di pagamento. I flussi di consenso consapevoli della regione presentano una schermata di consenso granulare in stile GDPR agli utenti nell'UE e nello SEE e un'informativa in stile CCPA agli utenti in California. I promemoria push sono opt-in per impostazione predefinita in entrambe le regioni, e la privacy policy documenta ogni percorso di dati usato dal motore calorico e dal costruttore di piani pasto.
Un MVP focalizzato con selezione della dieta basata sugli obiettivi, un motore calorie e macro, una libreria di ricette, costruttore di piani pasto settimanali e In-App Purchase su entrambi gli store richiede tipicamente 14–22 settimane. L'aggiunta di un player video con istruzioni, esportazione lista della spesa, raccomandazioni personalizzate e promemoria push per i pasti aggiunge 6–10 settimane. Il passaggio di sottomissione agli store e coreografia della revisione — informativa HealthTech di Apple, revisione dei dati sensibili di Google Play e una privacy policy che copra i flussi di consenso USA e UE — dovrebbe essere preventivato con 3–5 settimane di lavoro dedicato.
Related cases
App per i pazienti di una rete di laboratori multi-città — prenotazione appuntamenti, risultati, notifiche push, integrazione contabilità.
Vedi il caso →
App per consulenti retail per l'inventario delle boutique tra i punti vendita — ricerca ElasticSearch, integrazione 1C.
Vedi il caso →
App mobile marketplace locale per una catena offline di prodotti per bambini — catalogo flessibile, sincronizzazione stock online.
Vedi il caso →
MVP pronto per gli investitori consegnato in 12 settimane per 60-120k EUR. PM senior, designer, ingegneri, QA.
Scopri di più →
App iOS native, Android e cross-platform con pipeline di rilascio pronte per gli store.
Scopri di più →
Piattaforme SaaS multi-tenant con SSO, fatturazione, residenza dati ancorata alla regione. SOC 2 in corso.
Scopri di più →Condividete alcuni dettagli e un consulente senior risponderà entro un giorno lavorativo.