Thunkable Review 2026: Fast Prototypes, Frequent Crashes

Ti guiderò passo dopo passo attraverso ciò che è successo, dall’assistere all’AI che genera 1.000 righe di codice in tre minuti fino a quando non sono comparsi errori di runtime prima ancora di poter testare la schermata di login. Vedrai cosa Thunkable fa brillantemente, dove invece va in crisi totale, e se vale davvero il budget di token per il tuo caso d’uso specifico.

Cos’è Thunkable?

Thunkable è un builder di app mobili no-code che utilizza l’AI per generare applicazioni native iOS e Android a partire da prompt testuali.

A differenza delle piattaforme no-code tradizionali basate su blocchi drag-and-drop, l’AI builder di Thunkable genera codice reale, completo di file JavaScript, strutture dei componenti e stili.

Puoi osservare l’AI “pensare” ai tuoi requisiti, scomponendo il tuo prompt in struttura dell’app, stile di design, funzionalità principali e modelli di dati prima di scrivere il codice. Questa trasparenza lo distingue dai builder AI a scatola nera che nascondono i dettagli tecnici.

Quali problemi risolve?

• Velocità rispetto a partire da zero: costruire un’app multi-schermata con autenticazione, form e gestione dei dati che richiederebbe giorni in sviluppo tradizionale avviene in minuti
• UI mobile professionale senza competenze di design: l’AI capisce i pattern di design mobile e genera app che sembrano native, non semplici siti web mobili
• Flessibilità per utenti tecnici: a differenza degli strumenti pure no-code, hai accesso al codice React Native sottostante, quindi gli sviluppatori possono personalizzare oltre ciò che l’AI genera

Come si posiziona: Mentre piattaforme come Bubble si concentrano sulle web app con editor visuali, e Flutterflow punta a sviluppatori che vogliono codice Flutter, Thunkable colma il divario. È abbastanza veloce per i founder non tecnici per prototipare e offre accesso al codice per chi vuole il controllo.

A chi è rivolto Thunkable?

Thunkable funziona meglio per creator con propensione tecnica che vogliono prototipi di app mobili rapidi e non temono di risolvere problemi o dare un’occhiata al codice quando qualcosa si rompe. Funziona inoltre al meglio per:

• Fondatori di startup che validano idee mobile-first: se stai costruendo un marketplace, un sistema di prenotazione o un portale di servizi e hai bisogno di un prototipo funzionale iOS/Android da mostrare a investitori o early user, Thunkable ti porta dall’idea a un’app testabile in poche ore.
• Sviluppatori Python che esplorano lo sviluppo mobile: comprendi la logica di backend e le API, ma imparare Swift o Kotlin sembra eccessivo per un MVP. Thunkable genera codice React Native leggibile e modificabile, permettendoti di prototipare rapidamente interfacce mobili mentre concentri le tue competenze di backend sulle integrazioni API.
• Proprietari di piccole imprese che costruiscono strumenti interni: puoi descrivere il tuo workflow in linguaggio semplice, ottenere un prototipo funzionante e distribuirlo come web app o app mobile nativa senza assumere un team di sviluppo.

Non ideale per: utenti non tecnici in attesa di esperienze zero-code, zero-error. L’AI spesso genera codice con bug, e correggere gli errori di runtime richiede o bruciare token su tentativi di “Fix with AI” o modificare tu stesso il JavaScript.

Pro e Contro di Thunkable

Prova Thunkable gratis e guarda l’AI trasformare il tuo concetto di app mobile in codice funzionante in meno di 5 minuti. Niente Swift, niente Kotlin, solo tu e una casella di testo.

Funzionalità di Thunkable

• L’AI genera codice React Native dai prompt
• App multi-schermata con navigazione inferiore
• Autenticazione utente e gestione dei ruoli
• Costruttore di form con dropdown e validazione
• Controllo versione per ogni iterazione del codice
• Pubblica su iOS, Android o web
• Integrazioni: Airtable, Firebase, Google Sheets, Xano
• Download di file APK/AAB per il deployment

La mia esperienza pratica con Thunkable

Questo è il mio resoconto completo della creazione di un Portale di Richieste di Servizio con Thunkable. Volevo un sistema completo con login utente, una dashboard e un database funzionante. Ecco esattamente come è andata, ogni clic e ogni frustrazione inclusi.

1. Per iniziare: registrazione e prime impressioni

Sono atterrato sulla homepage di Thunkable, e la prima cosa che ho visto è stato un enorme invito all’azione minimalista: “Turn Your Idea into An App.”

Proprio al centro dello schermo c’era una grande casella di testo bianca. Sotto di essa, erano presenti quattro categorie suggerite per aiutarti a iniziare:

• Pianificazione eventi
• Gestione dell’inventario
• Viaggi
• Meditazione

Però non volevo un template; volevo vedere se l’AI fosse in grado di gestire una richiesta complessa e multilivello.

Ma prima ancora di poter digitare una parola, ho voluto creare un account. Ho cliccato sul pulsante “Sign up” nell’angolo in alto a destra.

È comparsa una finestra bianca e pulita che offriva tre modalità di registrazione:

• Continua con Google
• Continua con Apple
• Registrati con email

Ho inserito il mio indirizzo email e ho premuto il pulsante blu “Sign up with email”. Thunkable non usa password in questa fase iniziale.

Usano invece un sistema basato su “magic link”. Ho dovuto uscire dal sito, aprire la mia email in una nuova scheda e trovare il messaggio da “The Thunkable Team”. Ho dovuto cliccare su “Confirm”. Alla fine sono stato reindirizzato alla dashboard di Thunkable.

La prima cosa che ho notato una volta loggato è stata che l’interfaccia era incredibilmente vuota. Non c’era nessun pop-up “Welcome! Let’s take a tour”, nessun video tutorial e nessun chatbot fastidioso che mi salutava.

Questo è ciò a cui ho pensato:

La registrazione è stata veloce, ma non sono un fan dei magic link perché ti costringono a passare da una scheda all’altra. Tuttavia, l’interfaccia è bellissima. Non è intasata di mille pulsanti o barre laterali; c’è solo quella grande casella di prompt che ti fissa, il che rende l’intero processo molto accessibile per chi non sa da dove iniziare.

2. Il mio primo prompt e limiti di caratteri

Sono tornato alla schermata principale del prompt per inserire i dettagli del mio progetto. Volevo costruire un “Service Request Portal” per i proprietari di casa.

Non era una richiesta semplice; volevo un workflow completo. Ho passato qualche minuto a redigere un prompt molto specifico per vedere se l’AI avrebbe seguito esattamente le mie istruzioni.

Ho incluso anche una struttura dati dettagliata per due tabelle: una “Services Table” e una “Users Table”. Ho perfino definito i ruoli di “Customer” e “Admin”.

Ciò che mi ha sorpreso è stato che la casella di testo era molto ampia. Ho incollato tutto il mio prompt dettagliato, quasi 300 parole, e non mi ha interrotto.

Non ho visto né un contatore di caratteri né alcun avviso di “lunghezza massima”. Ha semplicemente accettato il testo e ha atteso il mio comando. Quando sono stato soddisfatto del prompt, ho cliccato il pulsante rosso “Generate App” in fondo alla casella.

La mia opinione sul processo di prompting:

Questa parte è stata fluida. È sembrato molto naturale, quasi come scrivere un brief per un freelancer. Ho apprezzato poter essere estremamente specifico su colonne dati e opzioni dei dropdown senza che lo strumento si confondesse.

Rispetto ad altri builder che offrono solo una piccola casella di testo di una riga, l’ampia area di Thunkable ti incoraggia davvero ad essere dettagliato. Ti fa sentire in controllo del design già dal primissimo istante.

3. Osservare l’AI in azione: la fase di “pensiero”

Appena ho dato il via, lo schermo si è oscurato e un messaggio di stato è apparso: “Analyzing your request.”

Questa è stata la parte più interessante di tutta l’esperienza. Invece di un generico spinner di caricamento, Thunkable mi ha mostrato un log in tempo reale del “processo di pensiero” dell’AI.

Ho visto l’AI scomporre il mio prompt in quattro categorie distinte:

• Struttura dell’app: ha scelto un layout “Bottom Navigation” con tre schermate principali: Home, New Request e Profile.
• Stile di design: ha registrato la mia richiesta per un “Primary blue color” e un’estetica “Professional”. Ha inoltre annotato “Clean, modern interface” come obiettivo.
• Funzionalità principali: ha elencato i componenti che intendeva realizzare, inclusi il sistema di Login/Register, il Service Request Form e la Dashboard con filtro per stato.
• Struttura dati: ha confermato che avrebbe creato due tabelle: users e service_requests. Ha persino elencato le colonne che stava creando, come id, service_type e status.

Dopo l’analisi, lo schermo è passato a un vero e proprio editor di codice. Ho visto l’AI digitare letteralmente codice React Native.

Ho visto i file venire creati nella barra laterale sinistra. File come App.js, theme.js e HomeScreen.js sono apparsi uno dopo l’altro. Ho potuto vedere la logica venire scritta: funzioni come handleSubmit, fetchRequests e toggleStatus.

L’intero processo, dal clic su “Generate” all’avere un’app “finished”, ha richiesto quasi esattamente tre minuti. Una piccola notifica è apparsa in basso: “Your app has been generated!” e un pulsante blu “Preview” è comparso.

Questo è ciò a cui ho pensato:

Vedere il “processo di pensiero” dell’AI è stato incredibile. Mi ha dato la possibilità di verificare se avesse effettivamente compreso la mia richiesta prima ancora di iniziare a scrivere il codice.

È un po’ strano trovarsi in uno strumento “no-code” a fissare 1.000 righe di JavaScript, ma è davvero fantastico se vuoi capire come lavora la tua app “sotto il cofano”. Togliere il mistero dalla “scatola nera” dell’AI fa la differenza.

4. Primo sguardo: revisione dell’app generata

Quando la build è terminata, ho premuto quel pulsante “Preview”. Sul lato destro dello schermo è apparso un emulatore di telefono.

La mia prima impressione è stata che l’app sembrava molto pulita e “native”. Non assomigliava a un sito web mobile; sembrava un’app reale che troveresti sull’App Store.

Ecco un riepilogo di ciò che ho visto:

• La dashboard: La prima schermata era la lista delle “Service Requests”. Aveva un bel header e una barra di toggle in alto con quattro tab: All, Pending, In Progress e Completed.
• La palette colori: Ha seguito perfettamente le mie istruzioni. I pulsanti erano di un blu profondo e professionale, e lo sfondo era di un grigio tenue che faceva risaltare le schede bianche.
• La navigazione: In fondo allo schermo c’era un menu chiaro con tre icone: “Requests”, “New Request” e “Profile”.
• L’aspetto: Puntava decisamente a uno stile “professional”. I font erano nitidi, il padding tra gli elementi era uniforme e utilizzava pattern UI mobili standard che risultavano molto familiari.

Tuttavia, la dashboard era vuota. Non ha generato alcun “dummy data” per mostrarmi come sarebbe apparsa una richiesta nella lista, il che rendeva un po’ difficile valutare l’aspetto finale senza aggiungere manualmente dei dati.

La mia opinione sul primo sguardo:

Il design era esattamente quello che avevo chiesto: professionale e blu. Non ha cercato di essere troppo “fancy”, cosa che ho apprezzato per un portale di servizi. Sono rimasto colpito da come gestiva tab e navigazione; era molto fluido.

Il mio unico piccolo appunto è che avrei voluto che generasse qualche richiesta di servizio finta così lo schermo non fosse così vuoto all’inizio. Avrebbe rafforzato il fattore “wow”.

5. Quando sono comparsi gli errori: il ciclo di troubleshooting

La luna di miele è finita nel momento in cui ho cercato effettivamente di interagire con l’app. Ho cliccato sulla tab “New Request” per vedere il form, e invece del form è comparsa una casella viola acceso sull’emulatore. Diceva:

Runtime Error: Your app encountered an error while running. Cannot read properties of null (reading ‘id’) at Line 433, Column 50. Error location: the ‘HomeScreen’ screen.

Non avevo nemmeno toccato il codice e l’app stava già crashando. Tuttavia, Thunkable sembra aspettarselo.

All’interno della casella di errore c’era un grosso pulsante “Fix with AI”. L’ho cliccato e l’AI è tornata in modalità “Thinking”. Ha impiegato circa 45 secondi per “re-analizzare” il codice e poi ha aggiornato la preview.

Il crash iniziale era sparito e sono finalmente riuscito a vedere il form “New Service Request”. Era esattamente come l’avevo descritto:

• Un dropdown per “Service Type” con opzioni Plumbing, Electrical, ecc.
• Una grande area di testo per la descrizione.
• Un date picker per la data preferita.
• Un dropdown “Urgency Level”.

Ma poi, ho provato a cliccare sull’icona “Profile” per vedere le informazioni utente, ed è comparso un secondo errore:
Runtime Error: Cannot read properties of null (reading ‘name’) at Line 949, Column 42.

Questo è ciò a cui ho pensato:

Questa parte è stata frustrante. L’AI è una grande designer, ma un coder pieno di bug. Sembrava avere difficoltà con la logica di “authentication”. Cercava di recuperare il name o l’ID di un utente prima ancora che avessi effettuato il login o creato un account, causando il crash dell’intera app.

Il pulsante “Fix with AI” è potente, ma doverlo usare tre volte solo per vedere tre schermate diverse è stato un po’ deludente. Mi ha fatto pensare che l’app non fosse ancora del tutto “ready for prime time”.

6. Crediti e limiti di token: il costo della costruzione

Mentre premevo quel pulsante “Fix with AI”, ho iniziato a chiedermi quanto mi stesse costando. Ho cliccato sulle impostazioni del mio account e ho trovato una sezione “Tokens”.

Sul “Free Plan” ho visto di aver ricevuto 1,2k token. Ogni volta che l’AI genera una nuova app o prova a correggere una porzione di codice, attinge da questo limite.

Ho notato che dopo la build iniziale e i miei due “fix”, il conteggio dei token era sceso di circa 250.

Questo significa che se hai un’app complessa che richiede molto troubleshooting, potresti bruciare facilmente i token gratuiti in un solo pomeriggio.

La mia opinione sui limiti di credito:

È un sistema equo, ma aggiunge un po’ di stress al processo di creazione. Ogni volta che cliccavo su “Fix with AI”, avevo la sensazione di spendere soldi. Sarebbe meglio se le correzioni AI non contassero ai fini del tuo limite, specialmente quando gli errori sono causati dal codice generato dall’AI stessa.

7. Personalizzazione del design: no-code vs. high-code

Volevo verificare se potevo cambiare il design senza usare l’AI. Ho cliccato sulla tab “Edit”, aspettandomi un editor drag-and-drop simile alla piattaforma standard di Thunkable. Invece, mi è stato mostrato solo il codice.

Per queste app generate dall’AI, “personalizzazione” significa modificare il codice React Native.

• Modificare i colori: ho dovuto aprire un file chiamato theme.js e cambiare codici esadecimali come #0000FF con altri valori.
• Spostare i pulsanti: ho dovuto regolare le impostazioni del “Flexbox” nel codice simile al CSS.
• Aggiungere componenti: se volevo aggiungere un nuovo pulsante, dovevo digitare manualmente nel codice.

Non esiste ancora un “Design Panel” con slider o selettori di colore per queste build AI. O usi l’AI per apportare modifiche o scrivi codice.

Questo è ciò a cui ho pensato:

È stata una grande sorpresa. Mi aspettavo che l’AI generasse un’app basata su blocchi che potessi modificare visivamente.

Dandomi il codice grezzo, Thunkable sta praticamente dicendo che questo strumento è pensato per sviluppatori che vogliono un vantaggio iniziale, non per principianti assoluti che non vogliono mai vedere una riga di codice. Rende lo strumento molto potente, ma lo rende anche molto più difficile da usare per i non tecnici.

8. Configurazione di dati e backend: dove sono i miei dati?

Ho deciso di analizzare come venivano gestiti i dati. Quando ho controllato il codice, ho trovato questa riga in cima:

const storageStrategy = ‘all-local’;

E scavando più a fondo, ho visto che l’app utilizzava qualcosa chiamato useQuery e useMutation da ‘platform-hooks’:

const { useQuery, useMutation } = require(‘platform-hooks’);

All’inizio è stato confuso. Le service request venivano memorizzate usando questi hook, ma non riuscivo a capire dove stessero realmente andando i dati. Rimanevano sul telefono? Venivano inviate a un database cloud?

Ecco cosa ho scoperto:

La strategia ‘all-local’ significa che i dati vengono memorizzati localmente sul dispositivo, ma non in un database vero e proprio e permanente. È sostanzialmente un setup locale basato su localStorage che sembra utilizzare un database (con query e mutation), ma in realtà gestisce i dati nel browser o nella memoria temporanea del telefono.

Il buono: il codice è già strutturato per funzionare con un database. Il pattern useQuery e useMutation è esattamente quello che useresti con un vero backend.

Il cattivo: non è realmente collegato ad Airtable, Firebase, Google Sheets o a nessun database cloud. Se un proprietario invia una richiesta, un idraulico o un admin non ha modo di vederla perché è salvata solo sul dispositivo del proprietario. I dati spariscono se cancelli l’app o cambi dispositivo.

Cosa è successo quando ho chiesto “How do I connect a database?”

Non ero sicuro di come collegarmi a un database reale, quindi ho digitato questa domanda nella chat box dove avevo inserito il prompt originale. Speravo che l’AI mi spiegasse il processo o proponesse di configurare un’integrazione.

Invece è successo qualcosa di strano. I log di “Thinking” dell’AI (che potevo vedere mentre processava) mostravano qualcosa di interessante:

“L’utente sta chiedendo ‘How do I connect a database?’ Questo non è una richiesta di modifica del codice, ma piuttosto una domanda… Tuttavia, in base alle mie istruzioni, devo restituire solo codice aggiornato e completo.”

L’AI era programmata per fornire solo codice, non spiegazioni. Quindi invece di rispondere alla mia domanda, ha interpretato la richiesta come un comando di modifica dell’app. Ha impiegato 13,6 secondi a “pensare” e poi ha rigenerato il codice.

Ma ecco il colpo di scena: il codice che mi ha restituito era quasi identico a quello che avevo già. Si era limitato a riorganizzare un po’ la struttura interna (creando un ServiceRequestContext per condividere i dati tra le schermate) mantenendo però la stessa strategia di storage ‘all-local’.

Non mi ha collegato a un database cloud. Non ha proposto di connettersi ad Airtable. Si è limitato a darmi una versione leggermente rifattorizzata dello stesso setup di storage locale.

Perfino il log di Thinking dell’AI riconosceva questa limitazione:

“La risposta appropriata sarebbe spiegare che: 1. La strategia corrente è ‘local’ (nessun database) 2. Per usare un database devono migrare alla strategia ‘all-local’ (che usa platform-hooks con useQuery/useMutation) 3. La strategia ‘all-supabase’ (database cloud con auth) arriverà in una release futura. Tuttavia, ho l’istruzione di restituire SOLO codice, niente altro.”

In sostanza: l’AI sapeva cosa stavo chiedendo, ma non poteva spiegare nulla. Poteva solo fornirmi codice.

E poiché l’integrazione con database cloud non era ancora pienamente disponibile (la strategia “all-supabase” sarebbe arrivata in una release futura), si è limitata allo storage locale.

La mia opinione sul backend:

Il builder AI adotta per default un approccio local-first, che va bene per demo ma non per app multi-utente in produzione. Ciò che mi ha frustrato è che:

1. l’AI non mi ha chiesto in anticipo dove volessi memorizzare i dati (Airtable? Firebase? Google Sheets?).
2. l’AI non poteva spiegare le sue scelte quando ho chiesto direttamente. È programmata per restituire solo codice, non per conversare sulle decisioni architetturali.
3. il codice sembra pronto per un database (con useQuery e useMutation), ma in realtà è solo un wrapper sofisticato su localStorage.

Secondo la documentazione di Thunkable, potrei teoricamente cambiare la storageStrategy da ‘all-local’ a qualcosa come ‘all-supabase’ (che userebbe un vero database cloud con autenticazione), ma i log di thinking dell’AI suggeriscono che questa feature arriverà in una release futura, il che significa che il builder AI non ha ancora pieno accesso alle strategie di database cloud.

La vera domanda: è questa una limitazione dell’AI, o avrei dovuto essere più specifico nel prompt? Se avessi detto fin dall’inizio “Build a service portal that stores requests in Airtable”, l’AI l’avrebbe gestito? Sospetto che la risposta sia forse, ma l’AI avrebbe dovuto chiedermi quale database desiderassi invece di defaultare allo storage locale senza spiegazioni.

9. Integrazioni disponibili: collegare i puntini

Anche se l’AI non le ha create per me, ho controllato la piattaforma per vedere quali integrazioni fossero disponibili se volessi aggiungerle manualmente.

Ho scoperto che potrei collegare l’app a:

• Airtable: per un database cloud più potente con interfaccia in stile foglio di calcolo. Perfetto per gestire le richieste di servizio in un modo accessibile sia agli sviluppatori sia agli admin non tecnici.
• Firebase: per una vera autenticazione utente e sincronizzazione dei dati tra dispositivi. Questo risolverebbe subito il problema dei dati che vivono solo su un telefono.
• Google Sheets: per un semplice tracciamento dei dati accessibile ai non tecnici. Immagina un property manager che apre un Google Sheet per vedere tutte le richieste di servizio in arrivo, senza codice.
• Xano: per un backend scalabile senza gestire server. Ideale per app che devono crescere senza dover preoccuparsi dell’infrastruttura.
• Backendless: per database visuali e funzionalità di gestione utenti. Un’altra opzione di backend no-code.
• Cloudinary: per gestire le immagini. Pensa a foto di un tubo rotto che i proprietari potrebbero caricare con la loro richiesta di servizio.
• Webflow: per la sincronizzazione con un CMS di sito web. Se hai un sito di property management creato in Webflow, potresti teoricamente sincronizzare le richieste di servizio tra sito e app.
• RevenueCat: per acquisti in-app e abbonamenti, se volessi monetizzare l’app.

Gli strumenti ci sono tutti. La domanda è: perché l’AI non li ha usati?

Qui entra in gioco un dettaglio interessante. Sono tornato a rivedere il processo di thinking dell’AI quando ho chiesto “How do I connect a database?”

L’AI era a conoscenza di queste integrazioni. Ha menzionato esplicitamente che:

“Per utilizzare un database, devono migrare alla strategia ‘all-local’ (che usa platform-hooks con useQuery/useMutation). La strategia ‘all-supabase’ (database cloud con auth) arriverà in una future release.”

Da ciò deduco alcune cose:

1. Le integrazioni esistono, ma il builder AI ha accesso limitato a esse. Thunkable supporta chiaramente Airtable, Firebase, Google Sheets e altro, ma il builder AI sembra limitato a poche “storage strategy” predefinite come ‘all-local’ (storage device) e ‘all-supabase’ (database cloud, in arrivo).
2. L’AI non ha un’interfaccia conversazionale per la configurazione. Non potevo semplicemente scrivere “Connect this to my Airtable” e lasciare che l’AI facesse il lavoro. Avrei dovuto configurare manualmente l’integrazione seguendo la documentazione di Thunkable.
3. L’AI è ottimizzata per la velocità, non per la personalizzazione. Ha scelto l’opzione più veloce e semplice (storage locale) invece di fare domande di follow-up come “Dove vuoi memorizzare i dati?” o “Quanti utenti avrà quest’app?”

Ciò a cui ho pensato:

Il potenziale c’è eccome, ed è più robusto di quanto avessi inizialmente riconosciuto. La mia frustrazione non è verso le capacità di Thunkable: la piattaforma ha chiaramente tutte le integrazioni. La mia frustrazione è che il builder AI non abbia offerto proattivamente queste opzioni durante la fase di prompt.

Avrei voluto che l’AI mi chiedesse qualcosa come:

“Vedo che stai costruendo un portale di servizio. Dove vorresti memorizzare le richieste di servizio?

• Local Storage (veloce, offline-friendly, ma i dati restano su un solo dispositivo)
• Airtable (database cloud con interfaccia a foglio di calcolo)
• Firebase (database in tempo reale con autenticazione utente)
• Google Sheets (tracciamento dei dati semplice e condivisibile)

“
Quella domanda mi avrebbe risparmiato il lavoro di costruire qualcosa che sembra un’app multi-utente ma funziona come un prototipo single-user.

10. Controllo versione: la massima sicurezza

Una funzionalità che mi ha davvero colpito è stato lo strumento “Version History”. Cliccando una piccola icona a forma di orologio nella barra superiore si è aperta una sidebar con l’elenco di ogni singola versione dell’app creata dall’AI.

Ho visto una timeline:

1. Service Request Portal with User Authentication (quella che è crashata)
2. “Fix null reference error” (la prima correzione)
3. Connect database to application

Potevo cliccare su ognuna di queste versioni per visualizzare il codice o addirittura “Restore” l’app a quel preciso momento.

È stato incredibilmente utile quando un tentativo di “Fix with AI” peggiorava l’app o introduceva un nuovo crash.

La mia opinione sul controllo versione:

È il miglior controllo versione che abbia visto in qualsiasi tool no-code o AI. Ti dà un vero senso di sicurezza. Non temi di sperimentare o di permettere all’AI tentativi di correzioni rischiose perché sai che puoi tornare indietro nel tempo con un solo clic. Rende il processo caotico dello sviluppo con AI molto più professionale e controllato.

11. Pubblicazione e deploy: andare live

Quando ho ritenuto che l’app fosse in uno stato sufficientemente buono, ho dato un’occhiata alle opzioni di “Publish”. Nell’angolo in alto a destra c’è un grosso pulsante “Publish”.

Cliccandolo si apre un menu con tre scelte principali:

• Publish iOS: avvia il processo di invio della tua app all’Apple App Store. Richiede un account Apple Developer.
• Publish Android: crea un file APK o AAB per il Google Play Store.
• Publish Web App: questa è stata la più interessante. Ti fornisce un URL così le persone possono usare la tua app in un browser mobile senza scaricare nulla.

C’era anche un pulsante “Download” che mi permetteva di richiedere una copia locale dei file di build Android o iOS. Questo è un grande vantaggio perché significa che non sei “bloccato” sulla piattaforma Thunkable per sempre. Possiedi davvero l’output.

La mia opinione sulla pubblicazione:

Il flusso di pubblicazione è molto diretto. Non nascondono l’opzione “web app” dietro un enorme paywall, cosa che ho apprezzato. Il fatto di poter ottenere i file di build raw per Android e iOS fa sembrare questo uno strumento professionale anziché un semplice giocattolo per hobbisti. È una conclusione molto fluida al processo di creazione.

Riepilogo finale dell’esperienza

Dopo aver passato qualche ora con lo strumento, avevo un prototipo funzionante di un Portale di Richieste di Servizio. Aveva una schermata di login, un form di richiesta funzionante e una dashboard che filtrava i lavori per stato.

La mia valutazione finale:

L’AI builder di Thunkable è un punto di partenza potente per chiunque voglia creare un’app mobile rapidamente. È fantastico per visualizzare un’idea e realizzare la struttura UI in minuti anziché giorni.

Tuttavia, non è una “bacchetta magica”. Ti imbatterai in errori, dovrai spendere token per correggerli e potresti dover guardare del codice se vuoi connettere un database reale.

Rispetto ad altri strumenti, Thunkable sembra più un ambiente di sviluppo professionale. Ti mostra il codice e ti fornisce gli strumenti per aggiustarlo. Se sei un creator con propensione tecnica che vuole un vantaggio enorme sul prossimo progetto, questa è una tecnologia davvero impressionante.

Se stai cercando un’app perfetta in un clic senza alcuno sforzo, potresti trovare gli errori di runtime un po’ opprimenti. In generale, è un enorme passo avanti per il mondo no-code.

Piani e prezzi di Thunkable

Thunkable offre quattro livelli di prezzo strutturati attorno ai limiti di token AI, privacy dei progetti e capacità di pubblicazione.

Tutti i piani includono il generatore di codice AI. La differenza è quante risorse puoi creare e dove puoi distribuire.

Costi nascosti da conoscere

Avrai bisogno di account Apple Developer (99$/anno) e Google Play (25$ una tantum) per pubblicare le app. Thunkable non lo menziona in anticipo, ma non puoi distribuire sugli store senza di essi.

I token AI scadono mensilmente sui piani a pagamento (si rinnovano al ciclo di fatturazione). Se sei sul piano Accelerator e usi 3.000 dei tuoi 20.000 token, il mese successivo riavrai 20.000 token. I token non utilizzati non si accumulano.

Importante: se la tua sottoscrizione scade, le app pubblicate diventano inaccessibili agli utenti finali. Non è come WordPress, dove il tuo sito resta online dopo la cancellazione. Le tue app restano offline finché non rinnovi.

La mia raccomandazione

Inizia con il piano Accelerator (19$/mese) se prendi sul serio la fase di costruzione. I 2.000 token del piano Free finiscono troppo in fretta durante il debugging, e serve almeno un progetto privato per qualsiasi attività business.

Puoi costruire l’app in Thunkable e poi connetterla manualmente al tuo backend Django usando il codice React Native generato. Basta modificare gli endpoint API nei file di codice.

Alternative a Thunkable

La generazione di codice AI-powered di Thunkable lo pone come uno strumento di prototipazione rapida, ma se il tuo obiettivo è un UI mobile pixel-perfect con controllo completo del codice, FlutterFlow offre un’alternativa interessante.

Scegli Thunkable se sei: un founder non tecnico che vuole validare un’idea di app mobile. Sei a tuo agio con bug occasionali e cerchi il percorso più rapido dal concept al prototipo funzionante.

Scegli FlutterFlow se sei: uno sviluppatore che esplora lo sviluppo mobile e desidera codice leggibile ed esportabile. Comprendi i concetti di programmazione e vuoi un controllo granulare su UI, animazioni e logica di backend.

Verdetto finale su Thunkable

L’AI builder di Thunkable consegna esattamente ciò che promette: app mobili funzionanti in minuti a partire da prompt in inglese semplice.

Vedere l’AI scomporre i tuoi requisiti e generare codice React Native è davvero impressionante, e il sistema di controllo versione significa che puoi sperimentare senza paura.

Ma ecco la realtà: passerai più tempo a correggere bug generati dall’AI che a costruire funzionalità. Gli errori di runtime compaiono costantemente, bruciando il tuo budget di token con tentativi di “Fix with AI” che spesso introducono nuovi problemi.

Ma se ti aspetti app rifinite e pronte per la produzione senza mai toccare codice, rimarrai deluso.

Thunkable

4.3

0 user reviews

€ 16,49 /mo

Prezzo iniziale

Rating based on expert review

• Intuitività
  0.0
• Supporto
  0.0
• Funzioni
  0.0
• Affidabilità
  0.0
• Prezzo
  0.0