Come creare un’app nel 2026: la guida in nove passi

La prima domanda non è “come creare un’app?” ma “mi serve un’app?”. Un sito web funziona già sul telefono, si aggiorna senza passare da nessuno store e non paga quote annuali. Un’app ha senso quando il prodotto ha bisogno di ciò che solo un’app può fare: notifiche push, uso offline, fotocamera e sensori, widget, orologio, acquisti dentro lo store — oppure quando gli utenti la aprono da un’icona più volte al giorno e non da un link ogni tanto.

Il test rapido: i tuoi utenti arrivano cliccando un link o aprendo un’icona? Se la risposta è “link”, forse ti serve un sito fatto bene e questa guida ti ha appena fatto risparmiare mesi. Se è “icona”, continua. Il confronto completo tra app nativa e sito web, con i casi in cui vince l’uno o l’altro, è nella nostra guida in inglese.

Non “iPhone o Android?” in astratto, ma: dove sono i primi cento utenti che conosci per nome? Se la tua cerchia usa iPhone, parti da iOS; se vendi a un pubblico dove domina Android, parti da lì. Partire da una piattaforma sola è una scelta seria, non una rinuncia: la prima versione va cambiata quaranta volte, e cambiarla su due piattaforme costa il doppio proprio quando impari di più.

La buona notizia del 2026 è che questa decisione non è più definitiva. Con la strada giusta (passo 3), la seconda piattaforma arriva dallo stesso progetto invece che da una riscrittura — e allora la domanda “quale per prima?” torna a essere solo una questione di dove stanno i tuoi utenti.

Qualunque cosa ti raccontino le pubblicità, i modi per creare un’app nel 2026 sono quattro. Si differenziano per tre cose: quanto paghi, a chi appartiene il codice alla fine, e quanto è “vera” l’app — Swift e Kotlin nativi che si comportano come il telefono, oppure un sito web dentro un guscio.

Strada 1 — Farla fare: agenzia o freelance. Tu descrivi, un team costruisce. Giusto se hai budget, poco tempo e un progetto complesso con un orizzonte lungo. Il rischio: ogni modifica dopo la consegna costa di nuovo, e sei legato ai tempi di qualcun altro. Un prezzo medio serio non esiste — dipende dal progetto — e chi te ne dà uno su un blog se lo sta inventando.

Strada 2 — App builder. Blocchi già pronti che configuri in un editor visuale. Velocissimo per i casi standard — menu di un ristorante, prenotazioni, area soci. Il limite: il tetto è quello dei blocchi, l’affitto mensile non finisce mai, e il codice quasi mai è tuo. Controlla sempre in quale piano il builder pubblica davvero negli store e non solo un sito web “installabile”: Apple e Google respingono con regolarità i gusci sottili intorno a un sito.

Strada 3 — Programmare tu: Swift o Kotlin. La curva più ripida e la proprietà più completa. Xcode e Android Studio sono gratuiti, la documentazione di Apple e Google è ottima, e nel 2026 impari con un agente AI accanto che ti fa andare più veloce. Giusto se vuoi diventare sviluppatore, non solo avere un’app: mesi prima della prima versione utile.

Strada 4 — Un agente AI scrive codice nativo vero. La strada nuova: descrivi l’app in italiano normale, e un agente scrive Swift e SwiftUI per iPhone e Kotlin con Jetpack Compose per Android, compila, corregge i propri errori e ti mostra il risultato. È ciò che oggi si chiama vibe coding, e la differenza tra una demo e un prodotto sta nella struttura che lo strumento impone: in Modaal — il nostro — per ogni funzionalità l’agente scrive prima un piano che approvi, e solo dopo il codice; il progetto Xcode è sul tuo Mac dal primo build, e la seconda piattaforma nasce dallo stesso progetto. Come funziona concretamente, passo per passo, è in creare app con AI. Il limite onesto: serve un Mac, e i casi speciali complessi vogliono ancora la revisione di uno sviluppatore.

Se ti stai chiedendo “ma senza saper programmare?”: le strade 2 e 4 sono per te, e la differenza tra le due è cosa resta alla fine — blocchi dentro una piattaforma, oppure codice nativo tuo.

Questo passo va fatto ora, non la settimana del lancio, perché ha tempi suoi che nessuno strumento accorcia. Per pubblicare su iPhone serve l’Apple Developer Program: 99 dollari all’anno, un Apple Account con autenticazione a due fattori e — attenzione — il tuo nome legale esatto, non un soprannome né il nome dell’azienda nel campo del nome. Se l’account è per una società, Apple chiede un numero D-U-N-S, e ottenerlo richiede giorni lavorativi che non si possono saltare.

Per Android serve un account Google Play Console: 25 dollari una tantum. Le cifre restano in dollari perché è così che le incassano gli store; il conto completo di cosa costa un’app — account, strumenti, costi ricorrenti, ogni numero verificabile — è nella nostra guida ai costi.

Un dettaglio che vale oro se scegli la strada 1: l’account sviluppatore deve essere intestato a te, non all’agenzia. Chi possiede l’account possiede la scheda nello store, le recensioni e gli utenti.

Il passo che quasi tutti saltano, e quello che decide più di ogni altro. Una pagina, non un documento: cosa fa l’app, per chi, e tre scenari nella forma “l’utente fa X, vede Y” — più una riga su cosa la prima versione lascia fuori di proposito. Se non riesci a scriverla, il problema non è lo strumento: non sai ancora cosa stai costruendo, e nessuna delle quattro strade può saperlo al posto tuo.

Questa pagina è la stessa su tutte le strade, cambia solo il nome: per l’agenzia è il capitolato, per l’app builder è la scelta del modello, per chi programma è il progetto, per l’agente AI è il prompt. Ed è anche il primo posto dove pensare alle quattro parti che ha ogni app — le schermate, i dati, il backend se serve, e le regole degli store — perché tre scenari scritti bene le fanno emergere da sole.

Un consiglio pratico che vale doppio con la strada 4: scrivi gli scenari come li spiegheresti a uno sviluppatore molto letterale e molto veloce. “Sbagliato” non insegna niente; “il pulsante va in basso, dove arriva il pollice” lo sistema al primo colpo.

Un’app non è un sito rimpicciolito. Il pollice arriva in basso, non in alto; una schermata fa una cosa, non cinque; i testi si leggono in movimento, con una mano sola, sotto il sole. Prima di costruire, disegna le tre schermate degli scenari — anche a mano, anche su carta — e chiediti per ognuna: qual è l’unica cosa che l’utente deve fare qui?

Se costruisci nativo (strade 3 e 4), lascia che il telefono faccia il suo lavoro: i componenti di iOS e di Android sanno già come si comporta una lista, un pulsante, un foglio che scorre dal basso. Un’app che li usa sembra “giusta” senza che tu sappia spiegare perché; un’app che li reinventa sembra un sito, anche quando non lo è.

Qualunque strada tu abbia scelto, l’obiettivo della prima settimana è uno solo: l’app sul tuo telefono, con i tre scenari che funzionano davvero. Non belli — funzionanti. Il simulatore è educato; il pollice è onesto, e ti dirà in dieci secondi cose che un mese di progettazione non ti avrebbe detto.

Con la strada 4 la prima settimana ha un ritmo preciso: descrivi, l’agente propone un piano, lo correggi e lo approvi, l’agente costruisce, tu provi sul telefono e dici cosa cambia. Costruire è iterare — la stessa schermata sistemata quaranta volte in un pomeriggio — e uno strumento che fa pagare ogni tentativo fa pagare esattamente quei pomeriggi. Il piano gratuito di Modaal è un progetto con prompt illimitati su una piattaforma; Pro costa 9 € al mese con pagamento annuale e aggiunge la seconda piattaforma e la distribuzione su TestFlight e App Store — i dettagli sono sulla pagina prezzi. Una regola vale per qualsiasi strumento: prima di iniziare, leggi in quale piano puoi pubblicare e portarti via il codice.

La tentazione classica è partire dal backend: database, login, sincronizzazione. La regola migliore è l’opposta: la prima versione usa dati finti realistici e non ha login finché uno dei tre scenari non lo richiede. Un’app che funziona sul telefono con dati finti ti insegna più di un backend perfetto senza app.

Quando arriva il momento, i backend gestiti — Supabase, Firebase e simili — coprono account, dati e sincronizzazione senza che tu gestisca un server, e hanno librerie ufficiali per Swift e Kotlin. Se hai fatto un prototipo web con uno strumento come Lovable e stai passando a un’app vera, questo è il punto in cui scopri che il backend sopravvive al trasloco: quello che si ricostruisce è la parte davanti, non i dati.

Gli amici sono gentili; gli sconosciuti sono utili. Su iPhone lo strumento è TestFlight, il servizio beta di Apple: carichi una build, inviti tester con un link e vedi crash e feedback prima del pubblico. Su Android il percorso equivalente passa dai canali di test della Play Console. Cinque sconosciuti che usano i tre scenari senza il tuo aiuto valgono più di cinquanta amici che dicono “bello”.

Poi la revisione. Apple scrive che il 90 per cento delle app inviate viene esaminato in meno di 24 ore — altri tempi non li citiamo perché Apple non li pubblica. Quando una prima richiesta viene respinta, di solito è per completezza — un account di prova che non funziona, informazioni mancanti nella scheda, una funzione che si blocca durante la revisione — non per l’idea. La procedura passo per passo, con i limiti delle schermate e dei testi, è nella nostra guida alla pubblicazione (in inglese).

E infine la cosa che nessuna guida dice abbastanza forte: il lancio è la linea di partenza. Il giorno in cui l’app è nello store comincia il lavoro vero — leggere le recensioni, sistemare, pubblicare aggiornamenti. È per questo che a chi appartiene il codice, e quanto costa ogni iterazione, contano più di qualunque confronto di funzionalità fatto al passo 3.