Claude Code: come creo app mobile senza scrivere una riga di codice

L'AI non ti ruberà il lavoro. Ma qualcuno che sa usare l'AI per costruire app mobile in 15 minuti, forse sì.

Quando ho iniziato a sperimentare con Claude Code per sviluppare applicazioni mobile, la prima domanda che mi sono fatto è stata: fino a che punto posso arrivare senza scrivere codice? La risposta mi ha sorpreso: fino a pubblicare app funzionanti su App Store e Play Store, complete di database, autenticazione utenti e funzionalità AI. In questo articolo ti mostro come ho costruito tre app complete—un habit tracker, un calorie tracker stile Cal.AI, e un timer Pomodoro—usando solo prompts in linguaggio naturale.

Perché Claude Code cambia le regole dello sviluppo mobile

Claude Code non è semplicemente un chatbot che genera codice. È un ambiente di sviluppo integrato che può leggere file, modificare progetti esistenti, eseguire comandi terminal e persino fare debug autonomo. La differenza fondamentale rispetto ad altri strumenti AI è che Claude Code può vedere l'intero contesto del tuo progetto e lavorare su più file contemporaneamente.

Puoi usare Claude Code in tre modi: direttamente nel browser su claude.ai/code, tramite l'app desktop, o integrato in IDE come Visual Studio Code o Cursor. Io preferisco quest'ultima opzione perché mi dà controllo granulare sui file e permette di gestire progetti più complessi. Ma indipendentemente dall'interfaccia che scegli, il "cervello" sottostante è lo stesso.

La vera magia avviene quando combini Claude Code con framework come React Native ed Expo. React Native ti permette di scrivere un'app una volta sola e deployarla su iOS, Android e web. Expo automatizza gran parte del processo di build e testing, eliminando la necessità di configurare Xcode o Android Studio manualmente.

Il framework per progettare app che le persone vogliono usare

Prima di scrivere una singola riga di codice (o prompt), devi rispondere a cinque domande. Questo framework funziona per qualsiasi tipo di app e previene il problema più comune dello sviluppo: costruire qualcosa che nessuno userà.

1. Core function: Qual è l'unica cosa che, se la togliessi, renderebbe la tua app inutile? Per un habit tracker, è la capacità di creare e tracciare abitudini. Per un calorie tracker, è scannerizzare cibo e ottenere stime caloriche. Scegli una sola funzione core. Se ne hai tre, hai tre app diverse.

2. Core loop: Ogni azione dell'utente deve produrre una ricompensa visibile entro 30 secondi. Questo ciclo azione-ricompensa è ciò che rende un'app "sticky". Quando qualcuno completa un'abitudine, l'app deve rispondere con feedback aptico, animazioni, suoni. Non basta salvare il dato in un database—l'utente deve sentire che qualcosa è successo.

3. Accessory features: Aggiungi solo funzionalità che supportano il core loop. Un habit tracker ha bisogno di uno storico, grafici di consistenza, reminder personalizzati. Ma non ha bisogno di integrazione con Spotify o un social network completo. Ogni feature che aggiungi dilui il focus dell'app.

4. Surface area check: Limita l'app a 5-7 schermate massimo. Se un utente non capisce come funziona l'app dopo un utilizzo, hai fallito. La semplicità non è un optional nel mobile: è un requisito. Ho visto troppe app morire perché cercavano di fare tutto invece di fare una cosa benissimo.

5. Retention hook: Devi creare uno stato "incompiuto" che obbliga l'utente a tornare. Challenge di 3 giorni, streak da mantenere, notifiche push intelligenti. Se l'utente apre l'app una volta e poi la dimentica, non hai un'app—hai un foglio di calcolo con interfaccia carina.

Come costruire un'app da zero con Claude Code in meno di un'ora

Il processo di sviluppo che uso è identico per ogni app, indipendentemente dalla complessità. Inizia creando una nuova cartella per il progetto e aprila in Cursor o nel tuo IDE preferito. Apri Claude Code e scrivi: "Voglio costruire un'app mobile con Expo e React Native. Configura il workspace per me."

Claude Code installerà le dipendenze, creerà la struttura delle cartelle, configurerà TypeScript e il routing. In 2-3 minuti hai un progetto funzionante. A quel punto, usa un tool di trascrizione vocale (io uso Aqua) per dettare l'intero brief dell'app seguendo il framework delle 5 domande. Claude tradurrà il tuo brief in un'app funzionante.

Il primo test avviene sempre sul browser locale. Chiedi a Claude: "Avvia un server locale e apri l'app in Chrome." Questo ti permette di vedere l'app in tempo reale, fare modifiche e iterare rapidamente. Puoi simulare un dispositivo mobile direttamente in Chrome DevTools. Quando trovi bug—e li troverai—copia semplicemente l'errore, incollalo in Claude e scrivi "fix". Il 90% delle volte, Claude risolve autonomamente.

Dopo aver verificato che l'app funziona in locale, passa a Expo Go. Scarica l'app Expo Go sul tuo telefono, poi chiedi a Claude: "Avvia un server Expo in un nuovo terminale." Scansiona il QR code che appare e l'app si caricherà direttamente sul tuo dispositivo. Questo è il momento in cui scopri i problemi reali: icone tagliate, testo che scompare, animazioni che laggano. Testa sempre su hardware reale, non su emulatori.

Design: come rendere un'app da prototipo brutto a prodotto pubblicabile

Il design è dove la maggior parte delle app AI fallisce. Claude può costruire funzionalità complesse, ma out-of-the-box i colori sono casuali, i font orribili, il layout caotico. La soluzione? Non chiedere a Claude di "inventare" un design. Mostragli cosa vuoi.

Vai su Dribbble o Behance e cerca app nella tua categoria. Trova 2-3 design che ti piacciono, fai screenshot e caricali in Claude. Scrivi: "Voglio che la mia app assomigli a questa. Stesso schema colori, stessa tipografia, stesso spacing. Non copiare il contenuto, solo lo stile." Claude estrarrà palette, font, border radius, padding e li applicherà alla tua app.

Per il mio calorie tracker, ho usato un approccio ibrido. Ho generato mockup con GPT Image (ora chiamato DALL-E), estratto gli asset visivi (alberi, sfondi, icone), e fatto importare tutto a Claude. Il risultato finale è un'app che sembra disegnata da un designer professionista, ma costruita interamente con prompts.

Una tecnica che funziona particolarmente bene: chiedi a Claude di aprire l'app in Chrome DevTools e fare uno screenshot loop. "Apri ogni pagina dell'app, fai screenshot, identifica incongruenze di design e correggile. Ripeti finché ogni schermata è pixel-perfect." Claude eseguirà questo processo autonomamente, risparmiandoti ore di lavoro manuale.

Database e autenticazione: da locale a cloud in 10 minuti

Fino a questo punto, tutti i dati della tua app sono salvati localmente sul dispositivo. Se disinstalli l'app, perdi tutto. Se vuoi usare l'app su più dispositivi, non funziona. Per rendere l'app realmente utilizzabile, serve un database cloud e un sistema di autenticazione.

Uso Supabase per entrambe le cose perché integra Postgres (database), autenticazione OAuth, storage file e edge functions in un'unica piattaforma. L'alternativa è Firebase di Google, che funziona benissimo ma ti lega a un ecosistema molto opinionato e a un sistema di design che non sempre mi piace.

Configurare Supabase è banale. Vai su supabase.com, crea un progetto, scegli una password per il database e abilita "automatic RLS" (Row Level Security). Questo ultimo step è critico: protegge il tuo database da accessi non autorizzati senza dover scrivere policy di sicurezza manualmente.

Torna su Claude e scrivi: "Voglio aggiungere un database Supabase a questo progetto. Configuralo per me, inclusa autenticazione email/password e caching locale per performance." Claude creerà lo schema del database, implementerà le API calls, aggiungerà le schermate di login/signup e configurerà il sync tra locale e cloud. Ti chiederà la tua API key di Supabase—copiala dal dashboard e incollala.

A questo punto devi testare di nuovo tutto end-to-end. L'aggiunta di un database introduce nuovi punti di failure: latenza di rete, timeout, errori di autenticazione. Testa il flusso completo: signup, login, creazione dati, logout, re-login, verifica che i dati persistano. Se qualcosa non funziona, Claude può debuggare leggendo i log di Supabase direttamente.

Sicurezza: il passo che il 99% degli sviluppatori AI salta (e tu no)

Se pubblichi un'app senza fare un audit di sicurezza, stai giocando alla roulette russa. Un bug di sicurezza può costare migliaia di euro in API abuse, esporre dati sensibili degli utenti, o farti bannare dall'App Store. Non è paranoia—è gestione del rischio.

Ho creato un prompt di sicurezza specifico per app vibecoded che copre le vulnerabilità più comuni: hard-coded secrets, missing server-side validation, database policies aperte, OAuth middleware inconsistente, hallucinated packages. Dopo aver completato l'app, apri una nuova conversazione con Claude (questo è importante—deve analizzare con occhi freschi), incolla il prompt di sicurezza e lascialo eseguire.

Claude scansionerà l'intero codebase e ti restituirà una lista prioritizzata di vulnerabilità: critical, high, medium, low. Per ogni vulnerability, ti dirà dove si trova nel codice, qual è il rischio e come fixarla. Scrivi: "Fixa tutte le vulnerabilities rosse e gialle." Dopo che Claude ha implementato le correzioni, riesegui l'audit. Spesso fixare un problema ne crea un altro—esegui l'audit almeno due volte.

Questo processo non renderà la tua app inviolabile. Ma eliminerà il 80-90% delle vulnerabilità low-hanging-fruit che gli attaccanti sfruttano per primi. È la differenza tra un lucchetto da bicicletta e una porta blindata: non ferma un professionista determinato, ma scoraggia il 99% degli opportunisti.

Pubblicare su App Store: la burocrazia che nessuno ti racconta

Hai un'app funzionante, sicura, bella. Ora arriva la parte più frustrante: convincere Apple e Google a lasciarti pubblicare. Il processo è lungo, burocratico e pieno di requisiti assurdi. Ma è fattibile, anche senza esperienza pregressa.

Per iOS, serve un Apple Developer Account (99€/anno). Per Android, serve un Google Play Console account (25€ una tantum). Iscriviti a entrambi prima di iniziare il processo di submission. Apple impiega 24-48 ore per approvare l'iscrizione, Google è quasi istantaneo.

Prima di poter submittare, devi buildare l'app per produzione. Questo è diverso dal build di sviluppo che hai usato finora. Scrivi a Claude: "Prepara l'app per produzione. Genera app.json, eas.json, configura icon e splash screen." Claude creerà tutti i file necessari. Poi esegui eas build --platform ios nel terminale. Expo builderà l'app sui loro server—il processo richiede 10-15 minuti.

Una volta completato il build, devi creare la landing page dell'app su App Store Connect. Questo richiede screenshot (per iPhone 6.5", iPad Pro, e altre risoluzioni), una descrizione lunga, keywords, privacy policy URL, support URL, rating contenuti. La parte più laboriosa sono gli screenshot—devi catturare l'app in azione su risoluzioni specifiche. Claude può automatizzare questo aprendo l'app in Chrome DevTools e catturando screenshot pixel-perfect.

Il requisito più assurdo: devi hostare una privacy policy e una support page su un dominio web. Non può essere un PDF. Deve essere una pagina HTML accessibile pubblicamente. Ho risolto creando leftclick.ai/caltracker/privacy con Claude—mi ha generato il contenuto completo in 30 secondi seguendo le linee guida Apple. Se non hai un sito web, puoi usare GitHub Pages gratuitamente.

Infine, devi fornire credenziali di test per il reviewer Apple. Crea un account dummy (test@gmail.com, password: Test123!) e inseriscilo nel form. Apple testerà manualmente ogni funzione della tua app—se qualcosa non funziona, la submission viene rifiutata e devi ricominciare. Usa TestFlight per distribuire l'app a 5-10 beta tester prima della submission ufficiale. Meglio scoprire i bug prima che lo faccia il reviewer.

Se tutto va bene, Apple approva l'app in 24-72 ore. Se qualcosa va storto, ti inviano un elenco di problemi da fixare. In genere sono cose banali: testo troppo piccolo, contrasto insufficiente, funzionalità non documentata. Fixa, re-submitta, ripeti. La prima app richiede sempre 2-3 iterazioni. Dalla seconda in poi, conosci già le regole del gioco.

Stiamo vivendo il momento più straordinario della storia dello sviluppo software: un singolo professionista, con gli strumenti giusti, può costruire prodotti che prima richiedevano team di 10 persone e mesi di lavoro. Ma vale la pena chiedersi, con un filo di ironia: fino a quando saremo noi a usare l'AI per creare, e non viceversa?