Migration snapshot
ActivePlatform
a Thunkable
Thunkable launched Thunkable AI on March 31, 2026 (PRNewswire) and shipped v560 in June 2026. CEO Arun Saigal reports publishing attempts jumped 51% after the AI launch. Claims: 5 million creators, apps used by 29 Fortune 100 companies. Pricing was restructured October 2024 (Starter/Professional/Business tiers discontinued; existing users grandfathered). Platform is stable — migration urgency comes from code lock-in, not platform health.
Typical timeline
8–12 weeks
Typical cost
$13K–$25K (agency, fixed)
Why teams leave a Thunkable
Thunkable is a well-run platform — the reason to leave is not instability but absolute code lock-in. Every feature you add today is one more thing to rebuild from scratch when you eventually leave.
Total code lock-in
No source-code export exists (Capterra Dec 2025: 'does not allow you to export raw code'). Leaving Thunkable always means a full rebuild, regardless of how long you stay. Every month of additional features increases the rebuild cost.
Publishing-tier pricing floor
$59/mo Builder tier is required just to have one live app on stores; $79+ to go unlimited. Teams with multiple apps face compounding subscription costs with no codebase equity in return.
Block-logic complexity ceiling
Complex business logic in the block-based editor does not scale — deeply nested conditional logic, complex state machines, and multi-step data flows become unmaintainable. Once you hit this ceiling, the only path forward is a code rewrite.
Native device feature gaps
Deep sensor integrations (BLE, camera customization, background tasks), custom push notification handling, and native module access hit hard platform limits that require writing native code unavailable in Thunkable.
App Store rejection risk
Thunkable apps are documented as flagged under Apple's Design 4.0 (looks like template) and Spam 4.3 (duplicate submissions) rejection patterns. A custom React Native build gives full control over UI differentiation that avoids these flags.
What can you actually take with you?
Thunkable exports nothing: no source code, no screen exports, no logic files. The only assets you control are the data in your external backends (Firebase, Sheets, Airtable) and the screenshots you take yourself.
| Asset | Can you export it? | How | Notes |
|---|---|---|---|
| Data | Partial | If backed by Firebase, Google Sheets, or Airtable, export data directly from those services — you own those accounts and their data. Export from Firebase Console (JSON or CSV), Google Sheets (CSV), or Airtable (CSV/JSON). | Thunkable-native data storage export is not documented. If you stored data only inside Thunkable (not in an external service), that data path is undocumented — verify with Thunkable support before relying on it. |
| Code | No | No source-code export of any kind exists. Block logic, screen structure, and component definitions are locked inside the platform. | Full rebuild required on migration — no code carries over regardless of plan tier. |
| Design/UI | No | Screens are not exportable. Screenshot or screen-record every screen yourself — this becomes your rebuild specification. | No Figma export, no image export of screen layouts. Manual documentation is the only path. |
| Logic/Workflows | No | Block-based logic stays inside the platform and cannot be exported in any form. All logic must be re-implemented as TypeScript functions and hooks. | For complex block trees, use Thunkable's block editor screenshots as the spec for re-implementation. |
| Users & Auth | Partial | If using Firebase Auth, user records (including auth metadata) are in your Firebase project — export or migrate directly. Firebase Auth supports user export via Firebase CLI or Admin SDK. | Thunkable-native user authentication export is not documented. Password hashes for Thunkable-managed auth are not documented for export — plan a forced password reset for those users. |
Swipe the table sideways to see the full breakdown.
Where each piece moves in code
The target stack is React Native (Expo) with your existing Firebase or a new Supabase backend — chosen based on whether your current data source is worth keeping or migrating during the rebuild.
a Thunkable
Thunkable screens (drag-drop)
In code
React Native screen components with React Navigation or Expo Router
Use Thunkable screenshots as the pixel-level spec for each screen component
a Thunkable
Block-based logic
In code
TypeScript functions and React hooks
Translate block trees manually or use an AI assistant with screenshots as input; complex trees take 2–4 hours each
a Thunkable
Built-in variables / app variables
In code
React Context, Zustand store, or React Query cache
Map Thunkable's app-wide and screen-level variables to an appropriate state management layer
a Thunkable
Firebase data source
In code
Firebase SDK in React Native — stays as-is
Your Firebase project and data are fully portable; no backend migration required if keeping Firebase
a Thunkable
Google Sheets data source
In code
Migrate to Supabase tables or keep Sheets with a REST API bridge
Supabase is recommended for apps with more than 1,000 rows or real-time requirements
a Thunkable
Airtable data source
In code
Migrate to Supabase or keep Airtable via REST
Airtable REST works fine for read-heavy content apps; Supabase for write-heavy or relational data
a Thunkable
Thunkable Navigator
In code
React Navigation stack/tab/drawer navigator
Map each Thunkable navigator type to its React Navigation equivalent before coding screens
a Thunkable
App store publishing
In code
Expo EAS Build + manual App Store Connect / Play Console submission
If Thunkable submitted to stores on your behalf, confirm and transfer developer accounts first
The migration roadmap
There is no code to export from Thunkable — migration starts with a thorough screen inventory and data backup before a single line of code is written. The rebuild order matters: data model and auth first, screens by traffic importance, edge cases last.
Inventory & Data Export
Days 1–5- Screenshot or screen-record every screen and user flow in the Thunkable app (this is your rebuild spec)
- Document every external API call, data source connection, and auth provider used
- Export all data from Firebase / Google Sheets / Airtable NOW — do not wait
- Verify you hold Apple App Store Connect and Google Play Console logins independently of Thunkable
- List all Thunkable-specific features (sensors, AR, native notifications) and find React Native equivalents
Watch out: If Thunkable submitted your apps to stores, you may not hold the developer accounts — request transfer immediately, as this is the longest lead-time item.
Architecture & Auth Decision
Week 1–2- Choose target stack: React Native (Expo) with Firebase (keep) or Supabase (migrate)
- Decide auth strategy: preserve Firebase Auth as-is, or plan forced password reset for Thunkable-managed users
- Design the data model in Supabase (if migrating) — map Sheets/Airtable columns to relational tables
- Freeze feature scope — no new Thunkable builds during the rebuild period
- Set up the Expo project and configure navigation skeleton
Data Migration & Auth Setup
Weeks 2–4- Import CSV exports from Firebase / Sheets / Airtable into Supabase (if migrating)
- Set up Supabase RLS policies or Firebase security rules for the new app
- Implement auth flow: sign up, sign in, password reset — test with a subset of migrated user records
- Draft and review the forced-password-reset email sequence if Thunkable-managed auth is involved
- Validate data integrity between source exports and Supabase tables
Screen & Feature Rebuild
Weeks 4–9- Build screens in order of traffic/importance — highest-use screens first
- Translate block-logic trees to TypeScript functions using screenshots as the spec
- Implement native features: push notifications (Expo Notifications), sensors, camera
- Connect all screens to Supabase / Firebase data layer and verify read/write behavior
- QA every screen against the original Thunkable screen recordings
Watch out: Scope creep — 'while we are rebuilding' requests inflate timeline; hold the feature freeze until the rebuild is live.
App Store Submission & Cutover
Weeks 10–12- Set up Expo EAS Build for iOS and Android production builds
- Submit to App Store and Google Play — allow 1–7 days for review
- Send forced-password-reset email to users with Thunkable-managed auth on launch day
- Monitor crash reports and user feedback for the first 2 weeks post-launch
- Cancel Thunkable subscription only after the new app is approved and live on all stores
Three ways to migrate — honestly
Every path has a real trade-off. Here is what each costs, how long it takes, and where it bites.
DIY (self-managed with AI tools)
$0–500 + time
3–6 months part-time
Fits
Founders with React Native experience who can translate block logic to TypeScript and manage Expo EAS Build setup themselves; works when the app has under 10 screens and simple data flows
Risks
Full rebuild with no code to reference is easy to underestimate. Block-logic translation is time-intensive. App Store rejection risk if UI is not sufficiently differentiated from template-like appearance.
Freelancer
$3K–10K
2–4 months
Fits
Non-technical founders with a well-documented screen inventory; freelancer handles the rebuild with screenshots and screen recordings as the spec
Risks
Scope is hard to fix without a complete block-logic inventory upfront. Scope creep from 'while we're rebuilding' requests is common. Vet React Native + Expo EAS Build experience specifically.
Agency (RapidDev)
Done-for-you$13K–25K fixed
8–12 weeks
Fits
Founders who want a fixed price, a structured specification process from screen recordings, and confidence that the rebuilt app passes App Store review without rejection for template-like UI
Risks
Minimum investment level — not the right fit for a prototype with under 5 screens; a freelancer is more cost-effective for small apps
The real risks — and how to defuse them
Full rebuild scope underestimate
Mitigation: This is not a migration of code — it is a rebuild from scratch. Timeline and budget must reflect that. Use Thunkable screenshots and screen recordings as the binding specification before any development begins.
User auth loss
Mitigation: If Thunkable-managed auth was used, no password hash export is documented. Plan a forced password-reset email campaign for all affected users, drafted and tested before the launch date is confirmed.
App Store account ownership
Mitigation: If Thunkable submitted apps to stores on your behalf, you may not hold the Apple App Store Connect or Google Play Console credentials. Request account transfer immediately — this has the longest lead time of any migration item.
App Store rejection on rebuilt app
Mitigation: Generic React Native apps can be flagged under Design 4.0 / Spam 4.3 if the UI looks templated. Ensure unique visual design and remove any duplicate or thin content before submission.
Scope creep during rebuild
Mitigation: Freeze the feature scope before development begins. 'While we're rebuilding' requests are the single most common cause of timeline and budget overruns on Thunkable migrations.
Should you actually migrate?
Migrating is a real project. Sometimes staying is the right call — here is the honest split.
Stay if
- The app is a prototype or internal tool and Thunkable's current feature set handles all your needs — no plans to scale beyond what the platform supports today
- Thunkable AI generates sufficient quality output for your use case and you do not need source-code ownership
- All your data is in Firebase / Sheets / Airtable and the app has no plans to scale beyond Thunkable's block-logic limits
- Publishing costs ($59–79+/mo) are justified by the value delivered and you have no investor, acquisition, or technical hiring requirements
Migrate if
- You need to own the codebase — for acquisition due diligence, technical team hiring, or investor requirements
- App complexity has hit block-logic limits and you need TypeScript, custom native modules, or real-time features
- Publishing subscription costs at $59–79+/mo per app exceed what a self-hosted React Native app would cost long-term
- App Store rejection under Design 4.0 or Spam 4.3 has become a repeated problem
Our honest verdict
Thunkable is one of the clearest lock-in platforms in mobile — no code export, block logic that does not translate, and a rebuild-by-definition exit. The honest advice is to migrate before complexity grows further, not after. Every feature added today increases the rebuild cost.
Do this today: pre-migration checklist
Whatever path you choose, protect yourself first. Work through this before you touch a line of code.
Export all data from Firebase, Google Sheets, and Airtable RIGHT NOW
This is the only data you control from Thunkable — do not wait until migration planning is finalized.
Screenshot or screen-record every screen and user flow in the app
This becomes your entire rebuild specification — without it, developers have no reference for what to build.
Document every external API call, data source connection, and auth provider used
Thunkable surfaces these as block connections — writing them down now prevents missed integrations during the rebuild.
Verify you hold Apple App Store Connect and Google Play Console logins independently
If Thunkable submitted on your behalf, you may not hold these — losing them means losing your app listing.
Decide on auth strategy: preserve Firebase Auth or plan forced password reset for Thunkable-managed users
This decision changes the rebuild architecture and requires a user communication plan drafted before launch.
List all Thunkable-specific features (sensors, AR, notifications) and confirm React Native equivalents exist
Some Thunkable blocks map to React Native packages that need evaluation before scoping the rebuild.
Freeze Thunkable feature development once the rebuild is scoped
Every new Thunkable feature added after the spec is frozen expands the rebuild scope and increases cost.
Frequently asked questions
Can I export my Thunkable app's code?
No. Thunkable does not offer source-code export of any kind — no block-logic export, no screen export, no component files. This is confirmed by Capterra reviews (Dec 2025): 'does not allow you to export raw code.' Leaving Thunkable always means a full rebuild from scratch, regardless of plan tier or how long you have been on the platform.
How long does a Thunkable migration take?
Typically 8–12 weeks for a production app. The timeline breaks down roughly as: 1 week for screen inventory and data export, 1–2 weeks for architecture decisions and Expo project setup, 2–3 weeks for data migration and auth, 5–7 weeks for the screen and feature rebuild, and 2 weeks for App Store submission and launch. Simple apps (under 10 screens, one data source) can hit the lower end; complex apps with sensor integrations or real-time features take 12+ weeks.
What happens to my users and passwords after migrating from Thunkable?
It depends on your auth setup. If you used Firebase Auth, your user records (including auth metadata) are in your Firebase project — you own them and can preserve them with no password reset required. If you used Thunkable's built-in auth system, no password-hash export is documented — you will need to trigger a forced password-reset email campaign for all users on the day the new app launches. Plan and draft this email sequence well before launch.
Is Thunkable shutting down?
No. Thunkable launched Thunkable AI on March 31, 2026 and shipped v560 in June 2026 — it is actively developing. The platform has 5 million creators and apps used by 29 Fortune 100 companies. Migration urgency comes from code lock-in and block-logic limits, not platform health.
What data can I take with me from Thunkable?
Any data in Firebase, Google Sheets, or Airtable is yours — export it directly from those services today. Thunkable-native data storage is not documented for export, so if you stored data only inside Thunkable (not in an external service), confirm with Thunkable support before relying on an exit path for that data.
Why do Thunkable apps get rejected from the App Store?
Thunkable apps can be flagged under Apple's Design 4.0 guideline (app looks like a template or generic reskin) and Spam 4.3 (duplicate or near-identical submissions). A custom React Native rebuild gives full control over unique visual design and content structure, which is the standard mitigation. Ensure your rebuilt app has a differentiated UI and avoids content patterns that Apple flags as duplicative.
How much does it cost to rebuild a Thunkable app?
DIY costs $0–500 plus your time (3–6 months part-time) if you are comfortable with React Native and Expo. A freelancer ranges $3K–10K for 2–4 months. A fixed-price agency engagement runs $13K–25K over 8–12 weeks and includes the screen-inventory process, architecture design, rebuild, and App Store submission. RapidDev offers a free scoping call to assess your specific Thunkable app before any commitment.
Should I migrate now or wait until the app is bigger?
Migrate before complexity grows — not after. The rebuild cost is the same on day 1 as it is after 12 months of new features, except the spec is larger and the rebuild takes longer. Every Thunkable block you add today is one more piece to re-implement in TypeScript. The cleanest exits happen when the app is at a natural feature pause, not when the block editor has become unmaintainable.
We migrate no-code apps to production code
- Fixed price — $13K–$25K (agency, fixed)
- No data loss, no downtime
- You own 100% of the code
30-min call. Quote within 48 hours.