Progettiamo e sviluppiamo app mobile, dall’idea alla pubblicazione
Sviluppiamo applicazioni per iOS e Android con React Native e Flutter, oppure in nativo quando il progetto lo richiede. Seguiamo il lavoro dalla definizione delle schermate fino alla pubblicazione sugli store e agli aggiornamenti successivi. DietApp, disponibile su Google Play, è nata così.
Prima di commissionare lo sviluppo di un’app mobile
Chi cerca uno studio a cui affidare un’app arriva quasi sempre con la stessa domanda: quanto costa. È la domanda giusta, posta troppo presto. Il costo dipende da quante schermate servono, da quali sistemi esterni vanno collegati, dal fatto che dietro l’app ci sia o meno un server con account e dati, dalla presenza di pagamenti o abbonamenti. Senza quelle informazioni qualsiasi cifra è un numero buttato lì.
Il secondo ostacolo è il linguaggio. I preventivi arrivano pieni di sigle, chi commissiona non ha modo di capire cosa sta comprando e finisce per scegliere il prezzo più basso. Poi scopre che la pubblicazione sugli store non era compresa, che il backend è una voce a parte, che gli aggiornamenti si pagano a ore.
In Melarise lavoriamo senza passaggi di consegne: chi scrive il preventivo è la stessa persona che scrive il codice e che risponde quando qualcosa non funziona. Questo riduce i passaggi e rende più semplice dire in anticipo cosa è incluso e cosa no. Quando una richiesta è fuori dalla nostra portata, o quando il budget non regge il perimetro richiesto, lo diciamo prima di firmare.
Cosa comprende il servizio di sviluppo app mobile
Un progetto di sviluppo applicazioni iOS e Android non si esaurisce nella scrittura del codice. Queste sono le attività che seguiamo, esplicitate una per una così da poterle discutere e, se serve, ridurre.
Analisi e definizione delle schermate
Trasformiamo la richiesta iniziale in un elenco di schermate e di azioni possibili in ciascuna. È il documento su cui si basa la stima: se una schermata esce dalla lista, esce anche dal preventivo, e viceversa.
Progettazione dell’interfaccia
Disegniamo la navigazione, gli stati vuoti, i messaggi di errore e i casi limite, rispettando le convenzioni di iOS e Android invece di forzare lo stesso identico aspetto sulle due piattaforme.
Sviluppo dell’applicazione
Scrittura del codice con React Native o Flutter, oppure in nativo quando il progetto lo richiede. Consegniamo build installabili durante il lavoro, non solo alla fine.
Backend, autenticazione e dati
Registrazione e accesso, database, sincronizzazione, notifiche. Usiamo Firebase e Google Cloud, che permettono di partire con costi proporzionati al traffico reale invece di pagare server fermi.
Pubblicazione su App Store e Google Play
Preparazione delle schede, screenshot, informativa privacy, dichiarazioni sui dati raccolti, gestione delle richieste di chiarimento in fase di revisione. Firmiamo le build e seguiamo il rilascio fino all’approvazione.
Aggiornamenti e manutenzione
Correzioni, adeguamento alle nuove versioni dei sistemi operativi e alle nuove regole degli store, nuove funzioni. Concordiamo prima se questa parte è a chiamata o continuativa.
Nativo o cross-platform: quando scegliere React Native o Flutter
Non esiste una tecnologia migliore in assoluto. Nativo significa due basi di codice separate, Swift per iOS e Kotlin per Android: massimo controllo, doppio lavoro. Cross-platform con React Native o Flutter significa una sola base di codice per entrambe le piattaforme, con parti specifiche scritte dove servono davvero. Per gran parte delle app di gestione, prenotazione, contenuti e account il cross-platform copre il fabbisogno senza differenze percepibili dall’utente. Questi sono i criteri che usiamo per decidere insieme al committente.
Quante piattaforme servono davvero
Se l’app parte su una sola piattaforma e l’altra arriverà forse, il nativo torna competitivo. Se servono entrambe fin dal primo giorno, una base di codice condivisa riduce tempi e costi di manutenzione.
Quanto l’app dipende dall’hardware
Uso intensivo della fotocamera in tempo reale, realtà aumentata, grafica 3D, elaborazione audio o Bluetooth a basso livello spingono verso il nativo. Liste, moduli, mappe, chat e pagamenti no.
Chi manterrà il codice dopo la consegna
Se il committente ha o avrà un team interno, la tecnologia va scelta in base a cosa quel team sa mantenere, non a cosa preferiamo noi.
Vincolo di tempo e di budget
Cross-platform significa una sola correzione quando emerge un difetto, invece di due. Su progetti con budget definito questo pesa più delle prestazioni di picco.
Aspettative sull’interfaccia
Flutter disegna i propri componenti e garantisce un aspetto identico ovunque. React Native si appoggia ai componenti di sistema e risulta più aderente alle abitudini di ciascuna piattaforma. È una scelta che riguarda il posizionamento quanto la tecnica.
Come si svolge un progetto di sviluppo app
Ogni fase si chiude con qualcosa di consegnato e verificabile. Se il progetto si ferma, si ferma con in mano il materiale prodotto fino a quel punto.
Fase 1: Definizione
Uno o due incontri per capire chi userà l’app, cosa deve poter fare e cosa resta fuori dalla prima versione. Consegna: elenco delle schermate, requisiti tecnici, scelta della tecnologia motivata e stima economica con perimetro esplicito.
Fase 2: Progettazione dell’interfaccia
Disegniamo le schermate principali e i percorsi di navigazione, compresi errori e stati vuoti. Consegna: un prototipo navigabile che si può provare sul telefono prima che venga scritta una riga di codice.
Fase 3: Sviluppo a cicli brevi
Lavoriamo per blocchi funzionali, a partire da quelli che reggono il resto: accesso, dati, schermata principale. Consegna: build installabili a ogni ciclo, così le correzioni di rotta arrivano durante il lavoro e non alla fine.
Fase 4: Test e preparazione al rilascio
Prove su dispositivi reali, verifica dei permessi richiesti, controllo dei consumi e dei tempi di caricamento. Consegna: schede per App Store e Google Play, informativa privacy, dichiarazioni sulla raccolta dati, build firmate.
Fase 5: Pubblicazione e vita dopo il rilascio
Invio agli store, risposta alle eventuali richieste dei revisori, monitoraggio dei primi giorni. Consegna: app disponibile al pubblico, accessi agli account di pubblicazione, repository del codice e piano degli aggiornamenti.
DietApp: un’app pubblicata davvero su Google Play
Il modo più onesto per mostrare come lavoriamo è indicare un’app che si può scaricare e usare. DietApp (si apre in una nuova scheda) è un prodotto proprietario di Melarise: pubblicata su Google Play il 26 settembre 2025, aggiornata a luglio 2026, ha superato i 500 download. Genera piani alimentari personalizzati a partire da età, peso, altezza, livello di attività, obiettivo e alimenti da escludere, e ricalcola il piano quando peso o obiettivo cambiano.
Dentro c’è quasi tutto quello che ricorre nei progetti dei clienti: un ricettario con oltre 400 ricette italiane con valori nutrizionali già calcolati, un assistente in chat che stima calorie e macronutrienti dalla foto di un piatto, il tracciamento del peso con grafici di andamento e un modello freemium con abbonamento Premium a 6,99 euro al mese o 34,99 euro all’anno, gestito tramite Google Play e RevenueCat. La parte meno visibile è quella costata più tempo: trattandosi di dati sanitari, l’app li gestisce come categoria particolare ai sensi dell’articolo 9 del GDPR, con consenso esplicito, e dichiara apertamente di non essere un dispositivo medico né una consulenza nutrizionale.
È un caso utile anche per i limiti che porta con sé. DietApp oggi esiste solo per Android; la versione iOS è annunciata senza data. Averlo scritto sul sito invece di lasciarlo intendere è una scelta precisa, la stessa che applichiamo ai progetti su commissione. Il percorso è raccontato per esteso nella scheda del progetto e l’app si consulta su diet-app.it (si apre in una nuova scheda).
App nativa, cross-platform e web app progressiva a confronto
Prima di scegliere la tecnologia conviene guardare le tre strade possibili sugli aspetti che incidono davvero su costo e risultato.
| Aspetto | App nativa | Cross-platform | Web app progressiva (PWA) |
|---|---|---|---|
| Base di codice | Una per iOS e una per Android | Una sola, con parti specifiche dove serve | Una sola, condivisa con il sito |
| Prestazioni | Le migliori possibili sulla piattaforma | Vicine al nativo per la maggior parte delle app | Legate al browser, adeguate per contenuti, mappe e moduli |
| Accesso alle funzioni del dispositivo | Completo, disponibile appena esce una novità di sistema | Ampio, tramite librerie ponte, con qualche ritardo sulle novità | Limitato, con vincoli marcati su iOS per notifiche e sensori |
| Distribuzione | App Store e Google Play | App Store e Google Play | Dal browser, con aggiunta alla schermata iniziale |
| Aggiornamenti | Nuova versione sottoposta a revisione dello store | Nuova versione sottoposta a revisione dello store | Immediati, senza revisione |
| Tempi e costi | I più alti: due sviluppi paralleli | Intermedi | I più contenuti |
| Quando ha senso | Grafica 3D, sensori, elaborazione in tempo reale | Gestionali, prenotazioni, marketplace, app con account | Estensione mobile di una piattaforma web già esistente |
Sviluppo app in Italia: come si lavora a distanza
Lavoriamo da remoto con committenti in tutta Italia. Lo sviluppo di un’app si svolge quasi interamente a distanza: prototipi condivisi, build installabili sul telefono del cliente, chiamate periodiche di allineamento. Gli strumenti restano gli stessi ovunque si trovi il committente: repository del codice, ambiente di prova, tracciamento delle attività aperte. La distanza geografica incide poco, la chiarezza degli accordi incide molto.
Quello che pesa sul risultato è il ritmo degli scambi: un interlocutore unico per tutta la durata del progetto, aggiornamenti a scadenze concordate, build che si provano sul telefono invece di descrizioni a parole. Quando una decisione tocca il perimetro, la mettiamo per iscritto insieme al suo effetto su tempi e costi, prima di procedere. Chi vuole capire prima come ragioniamo può leggere chi siamo e sfogliare gli altri progetti.
Domande frequenti sullo sviluppo di applicazioni iOS e Android
Le domande che riceviamo più spesso da chi sta valutando se creare un’app, con le risposte che daremmo al telefono.
Quanto costa sviluppare un’app mobile?
Non diamo cifre a scatola chiusa, perché sarebbero inventate. Il costo dipende da cinque fattori: il numero di schermate, la presenza di un backend con account e dati, le integrazioni con sistemi esterni come pagamenti o gestionali già in uso, il numero di piattaforme di destinazione e il livello di personalizzazione grafica. Un’app che consulta contenuti e uno strumento che gestisce prenotazioni e incassi stanno su ordini di grandezza diversi. Dopo l’incontro di definizione ricevi una stima scritta legata a un elenco preciso di schermate. Operiamo in regime forfettario, quindi le fatture non applicano IVA.
Quanto tempo serve per creare un’app?
Il calendario dipende dal perimetro concordato e da due variabili che non controlliamo del tutto: la velocità con cui arrivano contenuti e decisioni dal committente, e i tempi di revisione degli store, che valutano ogni versione prima di pubblicarla. In fase di stima indichiamo una data per la prima build installabile e una per l’invio agli store, e le aggiorniamo se il perimetro cambia. Una prima versione ridotta pubblicata presto batte quasi sempre una versione completa pubblicata tardi.
Chi si occupa della pubblicazione sugli store?
Ce ne occupiamo noi, dalla preparazione delle schede alla risposta ai revisori. Gli account sviluppatore Apple e Google, però, vanno intestati al committente: sono suoi, come il nome dell’app e la sua posizione nel negozio. Se non esistono ancora, ti guidiamo nell’apertura passo per passo, senza inserire noi i tuoi dati di pagamento o le tue credenziali.
Di chi è il codice dell’app?
Del committente. Alla consegna ricevi il repository completo, le chiavi di firma, gli accessi ai servizi cloud e la documentazione necessaria a permettere a un altro sviluppatore di riprendere il lavoro. Non usiamo formule che leghino il cliente allo studio per necessità tecnica: se qualcuno resta, deve restare perché il lavoro funziona.
Cosa serve dopo la pubblicazione?
Il lavoro su un’app continua dopo la pubblicazione. Apple e Google aggiornano i sistemi operativi ogni anno e periodicamente cambiano le regole su privacy, permessi e versioni minime supportate: senza adeguamenti, dopo qualche tempo l’app viene rimossa o smette di funzionare su parte dei dispositivi. Servono poi correzioni sui difetti che emergono con l’uso reale e piccole modifiche suggerite dalle recensioni. Concordiamo in anticipo se preferisci interventi a chiamata o un accordo continuativo.
