Migration snapshot
ActivePlatform
a Kodular
Kodular is community-driven and operating; GitHub org shows active repos into 2026 (Kodular/aia-kit updated May 2026; website repo updated April 2026); service-health status page exists. Longevity depends on community involvement and ad-monetization (AdMob) revenue — stable for Android hobbyist apps but niche and without corporate backing.
Typical timeline
8–12 weeks
Typical cost
$13K–$25K (agency, fixed)
Why teams leave a Kodular
Kodular works well for Android hobbyist and small-business apps. The migration trigger is almost always a specific ceiling: needing iOS, hitting block-logic limits, or handing the app to a professional development team that cannot work with .aia files.
Android-only ceiling
Kodular builds Android apps only — no iOS, no web. Reaching a wider audience (iPhone users, web browsers) requires rebuilding the app in React Native, Flutter, or a web framework. There is no iOS path inside Kodular.
.aia portability trap
The .aia export file is portable only within the App Inventor family of builders (MIT App Inventor, Niotron, etc.) — not to any modern native or cross-platform framework. It is not a migration asset for React Native or Flutter; it is a documentation artifact.
No Swift, Kotlin, or React Native code produced
Block logic is compiled to an APK/AAB binary. No modern source code is generated during export. A developer team handed a .aia file cannot extend or maintain it in a standard IDE.
Community-driven longevity risk
Kodular has no VC backing and no corporate parent. Platform health depends on volunteer contributors and AdMob-based economics. This is a smaller but real risk for apps a business depends on long-term.
Export failures on complex projects
Community threads document export failures when exporting large or complex .aia files. A cottage industry of paid '.aia to APK' workaround services exists — a signal that the tooling's reliability for complex apps is limited.
What can you actually take with you?
Kodular's .aia file is the only code export — useful as a human-readable spec (it is a ZIP of XML/JSON), but not importable into any modern IDE or framework. Data portability depends entirely on which external backend you used.
| Asset | Can you export it? | How | Notes |
|---|---|---|---|
| Data | Partial | Data lives in connected services (Firebase, TinyWebDB, Google Sheets); export from those directly. Firebase: export via Firebase Console or Admin SDK. TinyWebDB: export via your TinyWebDB server's API. Google Sheets: export as CSV. | No Kodular-centralized data export is documented. If using TinyWebDB on a third-party host, confirm you control that server before starting migration planning. |
| Code | Partial | Export the .aia project file from Kodular's My Projects panel (three-dot menu → Export AIA). The .aia is a ZIP containing XML screen definitions, JSON block logic, and component metadata — human-readable but not importable into modern IDEs. | Portable only within the App Inventor family (MIT App Inventor, Niotron). Not importable into React Native, Flutter, or any modern framework. Treat it as your rebuild specification, not as migrated code. |
| Design/UI | Partial | UI layout is encoded in XML inside the .aia file; readable in MIT App Inventor–compatible tools. Use MIT App Inventor to open the .aia and view screen layouts as a reference for the rebuild. | Not importable into standard IDEs or design tools. Screenshot each screen in MIT App Inventor as part of your rebuild spec process. |
| Logic/Workflows | Partial | Block logic is stored as JSON inside the .aia (blocks/*.bky files). Community documentation describes porting between App Inventor forks via manual component-rename and SCM edits, but this is manual and error-prone. | Block logic is human-readable in the .aia; use it as a functional spec when translating to TypeScript or Dart. Do not attempt automated conversion — no reliable tool exists. |
| Users & Auth | Partial | Via Firebase Auth or TinyWebDB. Firebase Auth: export user records (including metadata) via Firebase Console or Admin SDK. TinyWebDB: user records via your server's data store. | Password hashes are not documented for export by Kodular. Firebase Auth gives full control of hashed credentials if Firebase Auth was used — no forced reset required in that case. |
Swipe the table sideways to see the full breakdown.
Where each piece moves in code
The target stack is React Native (Expo) for JavaScript/TypeScript teams or Flutter for teams that want stronger native performance — both produce iOS and Android from a single codebase, which is the primary migration goal.
a Kodular
Kodular screens (Designer view)
In code
React Native screens (React Navigation) or Flutter screens (GoRouter)
Use MIT App Inventor to view screen layouts from the .aia as the rebuild spec
a Kodular
Block-based logic
In code
TypeScript functions (React Native) or Dart functions (Flutter)
Read block JSON in the .aia as the functional spec; translate block-by-block, not all at once
a Kodular
Firebase backend
In code
Firebase SDK stays as-is — available in both React Native and Flutter
No backend migration needed if Firebase was used; Firebase SDK is production-ready for both frameworks
a Kodular
TinyWebDB
In code
Migrate to Supabase (PostgreSQL) or Firebase Realtime Database
TinyWebDB is a simple key-value store; map keys to Supabase table columns or Firebase Realtime DB paths
a Kodular
Google Sheets data source
In code
Migrate to Supabase tables with a REST API bridge, or keep Sheets via Google Sheets API
Supabase recommended for write-heavy or relational data; Sheets API acceptable for read-only content
a Kodular
AdMob integration
In code
react-native-google-mobile-ads (React Native) or google_mobile_ads package (Flutter)
New app bundle ID requires re-registering the app with Google AdMob — plan the review period
a Kodular
App Inventor components (camera, sensors, BLE)
In code
expo-camera, expo-sensors, react-native-ble-plx (React Native) or camera/sensors/BLE Flutter plugins
Audit all custom Kodular extensions for React Native/Flutter equivalents before scoping — some have no direct match
a Kodular
APK/AAB publishing
In code
Expo EAS Build for Play Store (React Native) or Flutter build for Android
Use Play Store app transfer to move the existing listing to your new bundle ID if you own the developer account
The migration roadmap
Export the .aia immediately and use MIT App Inventor to turn it into a human-readable spec. The rebuild follows a standard order: choose target framework, migrate backend data if needed, build screens, add native components, submit to stores.
Export & Specification
Days 1–5- Export the .aia project file from Kodular today (before any service interruption)
- Open the .aia in MIT App Inventor and screenshot every screen and block workspace
- Unzip the .aia and inspect the XML/JSON to produce a screen and component inventory
- Confirm ownership of all backend accounts: Firebase, Google Sheets, TinyWebDB server
- Confirm ownership of Google Play Console developer account and the app listing
Watch out: Large or complex projects may fail to export cleanly from Kodular — verify the .aia opens correctly in MIT App Inventor before assuming it is complete.
Framework Decision & Architecture
Week 1–2- Choose target framework: React Native (Expo) for JavaScript/TypeScript teams; Flutter for native performance priority
- List all custom Kodular extensions and confirm React Native/Flutter equivalents exist before finalizing scope
- Design Supabase schema if migrating from TinyWebDB or Google Sheets
- Register new app bundle IDs with Google Play and Google AdMob (if AdMob is used)
- Set up the Expo or Flutter project and configure navigation structure
Backend Migration & Data Import
Weeks 2–4- Export Firebase / TinyWebDB / Google Sheets data and import into Supabase if migrating
- Set up Supabase RLS policies or Firebase security rules for the new app
- Validate data integrity between source exports and the new data store
- Confirm Firebase project ownership if Firebase was configured by a third party
- Test all backend connections from the new app before building screens
Screen & Feature Rebuild
Weeks 4–9- Build screens in order of importance using MIT App Inventor screenshots as the spec
- Translate block logic to TypeScript or Dart functions; reference block JSON in the .aia
- Implement native components: camera, sensors, BLE, AdMob
- Re-register AdMob ad units under the new bundle ID and test ad loading
- QA every screen against the original Kodular app behavior
App Store Submission & Cutover
Weeks 10–12- Submit to Google Play Store; use Play Store app transfer if keeping the existing listing
- For iOS (the primary migration goal): submit to App Store for the first time — allow 1–7 days for review
- Monitor crash reports and user feedback for the first 2 weeks post-launch
- Cancel Kodular subscription after the new app is live and validated
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
Developers comfortable with React Native or Flutter who can read the .aia XML/JSON as a spec and implement screens and native components themselves; works when the app is under 10 screens with straightforward logic
Risks
Custom Kodular extensions may have no direct equivalent — discovering this mid-build causes scope surprises. AdMob re-registration and new bundle ID can trigger app store review delays.
Freelancer
$3K–10K
2–3 months
Fits
App owners who have a clean .aia and a complete screen/component inventory; the freelancer handles the React Native or Flutter rebuild with the inventory as the spec
Risks
Extension audit is critical before scoping — missing a custom component that has no equivalent can blow the budget. Vet React Native/Flutter and Expo EAS Build experience specifically.
Agency (RapidDev)
Done-for-you$13K–25K fixed
8–12 weeks
Fits
App owners who want a fixed price and a structured process from .aia inventory through iOS + Android launch; particularly suited when the app needs multiple native components (BLE, camera, sensors) or a backend migration from TinyWebDB
Risks
Minimum investment level — a simple Android app under 5 screens with Firebase backend may be better served by a freelancer
The real risks — and how to defuse them
.aia export failure on complex projects
Mitigation: Export immediately and verify in MIT App Inventor before starting migration planning. If the export is corrupted or incomplete, troubleshoot in Kodular before canceling any subscription.
Custom Kodular extensions with no React Native/Flutter equivalent
Mitigation: Audit all custom extensions before scoping the project. Some Kodular community extensions (hardware integrations, specialized APIs) have no direct equivalent — budget custom development time for these.
App store re-submission with new bundle ID
Mitigation: A new bundle ID means a new app listing — existing reviews and download count are not transferable. Use Play Store app transfer (if you own the developer account) to move the existing listing to the new bundle ID where possible.
Firebase project ownership by a third party
Mitigation: If the Firebase project was set up by an agency or third party, request Firebase project transfer through the Firebase Console before starting migration. Without ownership, data extraction may require the third party's cooperation.
Community longevity
Mitigation: Kodular has no corporate parent. Export the .aia and document everything now as insurance against community shrinkage or service degradation — do not wait for a shutdown notice.
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 Android-only and you have no plans for iOS or web — Kodular handles Android hobbyist and small-business use cases well within its niche
- The app is simple (under 10 screens, basic data reads, no complex state) and current functionality is fully sufficient with no plans to extend
- Revenue from AdMob covers costs and the audience is satisfied with the current store-app quality
- A professional development team does not need to maintain the app — it runs autonomously without code changes
Migrate if
- iOS is needed — Kodular cannot produce it, and this requirement has no workaround on the platform
- App complexity has outgrown the block editor: complex state management, real-time data, deep API integrations, or BLE that the editor cannot express cleanly
- A professional team needs to take over maintenance and cannot work with .aia block-based source as a maintainable artifact
Our honest verdict
Kodular is best for hobbyist and indie Android apps. If the app has grown into something a business depends on — especially if iOS is needed — the .aia format is a dead end and a rebuild is the only path forward. The good news: the .aia is a surprisingly readable spec for that rebuild.
Do this today: pre-migration checklist
Whatever path you choose, protect yourself first. Work through this before you touch a line of code.
Export the .aia project file from Kodular today and open it in MIT App Inventor to verify integrity
Large exports can fail; verifying now means you have a working spec before any service interruption.
Unzip the .aia and review the XML/JSON structure to produce a screen and component inventory
The .aia is your rebuild specification — a systematic inventory prevents missed screens or logic.
Confirm ownership of all backend accounts: Firebase, Google Sheets, TinyWebDB server
Data you cannot access independently cannot be migrated — confirm access before planning.
Confirm ownership of your Google Play Console developer account and the app listing
Without Play Console ownership, you cannot transfer the app listing to a new bundle ID.
List all custom Kodular extensions and find React Native or Flutter equivalents before scoping
Custom extensions without equivalents are the most common cause of scope surprises and budget overruns.
Decide on the target framework (React Native / Expo vs Flutter) based on your team's language skills
This decision determines the entire rebuild architecture — committing early prevents mid-project pivots.
If the app uses AdMob: register new app bundle IDs with Google AdMob before launch
AdMob re-registration is required under a new bundle ID and takes time to review before ads serve.
Frequently asked questions
Can I export my Kodular app's code to React Native or Flutter?
Not directly. Kodular exports a .aia file — a ZIP containing XML screen definitions and JSON block logic — which is portable only within the App Inventor family (MIT App Inventor, Niotron). It is not importable into React Native, Flutter, or any modern IDE. However, the .aia is a human-readable format: unzip it, read the XML/JSON, and use it as your rebuild specification. No automated conversion tool exists for .aia to React Native or Flutter.
How long does migrating from Kodular to React Native or Flutter take?
Typically 8–12 weeks. The timeline includes: 1 week for .aia export and screen inventory, 1–2 weeks for framework decision and project setup, 2–3 weeks for backend migration (TinyWebDB to Supabase, or keeping Firebase), 5–7 weeks for the screen and feature rebuild, and 2 weeks for App Store/Play Store submission. Simple apps under 10 screens hit the lower end; complex apps with custom extensions or native hardware integration take 12+ weeks.
What happens to my users and their passwords when I migrate from Kodular?
If you used Firebase Auth, user records and auth metadata are in your Firebase project — you own them and no forced password reset is required. If users were managed via TinyWebDB or a custom approach, password hashes are not documented for export by Kodular — confirm with your backend provider. As a safe default, plan a forced password-reset email campaign for any users whose auth source is uncertain.
Is Kodular shutting down?
No shutdown signals as of 2026. Kodular's GitHub org shows active repository updates into 2026 (aia-kit updated May 2026; website repo updated April 2026) and a service health page exists. The platform is community-driven without corporate backing, which creates a lower-level longevity risk — not an emergency, but a reason to export your .aia and document everything as insurance.
Can Kodular build iOS apps?
No. Kodular builds Android APK/AAB binaries only. If iOS support is required, a full rebuild in React Native (Expo) or Flutter is the only path — both produce iOS and Android apps from a single codebase. This is the most common migration trigger for Kodular users.
What should I do with my .aia file before I start migrating?
Three things: (1) Export it from Kodular's My Projects panel before canceling any subscription. (2) Open it in MIT App Inventor and screenshot every screen and block workspace — this is your visual spec. (3) Unzip it and inspect the XML/JSON files — the screen definitions and block logic are human-readable and become your functional specification for the rebuild. Store the .aia in your own version control immediately.
Which framework should I use to replace Kodular — React Native or Flutter?
Choose based on your team's language preference. React Native (Expo) uses JavaScript/TypeScript and has the largest ecosystem of community libraries and Expo-specific tooling (EAS Build, Expo Router). Flutter uses Dart and offers stronger native rendering performance and a consistent UI across iOS and Android. Both produce production-grade iOS and Android apps. If you have no strong preference, React Native (Expo) is easier to find freelancers for.
How much does migrating a Kodular app to code cost?
DIY costs $0–500 plus your time (3–6 months part-time) if you are comfortable with React Native or Flutter. A freelancer ranges $3K–10K for 2–3 months. A fixed-price agency engagement runs $13K–25K over 8–12 weeks and covers the .aia inventory, framework setup, backend migration, native component implementation, and App Store / Play Store submission. RapidDev offers a free scoping call to evaluate your .aia before any commitment.
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.