In March, I watched our Thunkable prototype go from "works on my phone" to "blocked by store rules" in a single afternoon. The gap was not code, it was publishing. If you have a working Thunkable app but feel stuck on bundle IDs, signing, screenshots, privacy forms, and review feedback loops, this case study walks through the practical decisions that got us from prototype to two store submissions with fewer surprises and a repeatable release workflow.
Everything You Need to Know About Apple and Google Developer Accounts goes deeper on the ideas above and adds concrete next steps.
Early proof: what changed between the prototype and the store-ready build?
A concise proof card showing the move from a working Thunkable prototype to App Store and Google Play submission readiness, with a simple before/after workflow and notes on review prep time.
| Snapshot | Before (prototype) | After (submission-ready) | Time and effort | Reader impact |
|---|---|---|---|---|
| Distribution | Thunkable share link | App Store Connect + Play Console tracks created | ~1-2 hours once accounts existed | You can start a real beta with installs, updates, and feedback loops |
| Identity and versioning | No release naming discipline | Bundle ID/package name + versioning set in Project Settings | ~30-60 minutes, but changing it later can cost days | Fewer "we have to rename everything" delays mid-review |
| Store assets | 0 store assets | Icons + screenshots for both stores | 3-6 hours depending on devices, locales, and UI states | Less back-and-forth over missing sizes and mismatched imagery |
| Compliance and metadata | Hand-wavy notes | Privacy answers, permissions declarations, age rating drafts | 1-3 hours, plus time to verify claims | Avoids rejections that are not code-related |
| Review cycle | N/A | 3 rejected builds before first approval | 1-2 weeks to submission-ready; review time varies | Sets expectations: resubmits are normal and need calendar slack |
What happened (explanation): in our case (one small team, one app), we went from a single-device prototype to two submission pipelines in about 14 calendar days. We paid $198 in developer fees (Apple + Google for that year) and saw three rejected builds before the first approval.
What it means (interpretation): most of the work was operational: accounts, assets, app identity, and compliance details. Exporting from Thunkable was rarely the blocker; waiting on reviews and fixing listing or disclosure mismatches took more time than we expected.
Why it matters (impact): if you budget a few focused work sessions for store assets and forms, and you assume at least one resubmit, publishing becomes more predictable. Example numbers are from our team and app; your mileage will vary based on region, category, account verification speed, and whether you need tablets, multiple languages, or data collection disclosures.
When you move from outline to execution, How to Publish Your Lovable App: From Export to Approval helps close common gaps teams hit here.
What made publishing harder than building the Thunkable app?
A simple flow diagram that maps the actual publishing path for a Thunkable app: finalize app identity, prepare store assets, test on devices, submit to App Store Connect and Google Play Console, then handle review feedback.
Our build was already doing real work: a lightweight customer utility we were sharing as a link after sales calls. It looked fine in demos, but it broke down when we tried to onboard testers at scale. People wanted a familiar install flow, updates, and a place to leave feedback.
The bigger constraint was the platform split. Half our early users were on iOS, the rest on Android, and we could not afford two different timelines. Publishing became the milestone because it was the only way to run a clean beta and collect consistent feedback.
Store rules are not just technical. They also care about identity, safety, and honesty in your listing. That means you can have a correct app and still get blocked.
A complementary angle worth comparing lives in How to Publish a Bubble Mobile App to App Store and Google Play.
Where do first submissions usually stall?
Most stalls happen before review even starts, or because a small listing detail triggers a reject.
- Account gates come first. Apple Developer and Google Play Console setup is the real starting line, not your first build (see Thunkable's guides: https://docs.thunkable.com/publishing/publish-to-app-store-ios/user-guide and https://docs.thunkable.com/publishing/publish-to-play-store-android/user-guide).
- Identity and signing are easy to underestimate. Bundle or package IDs, version numbers, and assets in Thunkable Project Settings are the backbone of a repeatable release (https://docs.thunkable.com/settings/project-settings).
- Listings create silent delays. One missing screenshot size, icon, or privacy declaration can push release by days because you are waiting on review cycles, not fixing code.
A concrete example from our rejects: we marked a permission as required "for functionality" even though the app still worked without it. That mismatch (what we claimed vs what the app actually did) cost more time than any UI bug.
For tradeoffs, checklists, and edge cases, Submitting vs Publishing an App: What's Different rounds out this section.
What steps do you need to publish a Thunkable app to App Store and Google Play?
Step 1: lock the app identity before touching store forms
Decide the name and IDs you can live with
We picked the final app name and froze the bundle identifier and package name before any export. Changing these later can ripple through reviewer notes, listings, analytics, and upgrades, so we treated Thunkable Project Settings like release plumbing, not branding (Project Settings).
Make sure the people who submit can also fix and resubmit
We confirmed the Apple Developer Team and the Google Play Console listing owner were the people who would be around for resubmits. If the submitter is a contractor or a temporary account, access issues can stall changes for hours or days, especially when 2FA or role permissions are involved (iOS guide, Android guide).
Pick a launch path that matches your risk tolerance
We chose an internal-first release instead of a public v1. That let us validate store setup, versioning, and the submission flow without burning goodwill on a rough first impression. The tradeoff is slower public momentum, but you buy yourself room to learn the pipeline.
A lightweight release checklist (the operational detail that helped)
We tracked this in a shared sheet so anyone could see status and links. The point was not perfection, it was reducing "Where is that file?" time during resubmits.
| Artifact | Owner | Where it lives | Done? |
|---|---|---|---|
| App icon (required sizes) | Design or PM | Drive folder + exported PNGs | |
| Screenshots (iPhone, iPad if needed, Android) | PM | Drive folder + naming convention | |
| Privacy policy URL + data collection notes | PM or legal | Doc link | |
| Thunkable Project Settings (IDs, version) | Builder | Thunkable project | |
| Release notes (v1.0.0 -> v1.0.1) | Builder | Sheet tab or doc | |
| Store listing copy (title, subtitle, keywords) | PM | Sheet tab |
One small detail that helped us move faster: we named screenshots like ios_6.7in_home_v1.0.1.png and android_phone_settings_v1.0.1.png, and captured them with an emulator plus a simple annotation tool (FastStone on Windows, Preview on macOS). It made reviewer follow-ups and asset swaps less chaotic.
The tradeoff: this kind of checklist feels like overhead when you just want to ship. The payoff shows up the first time you need a fast resubmit and you are not hunting for files or waiting on account access.
Why Publishing Requires Structured Execution, Not Guesswork reframes the same problem with a slightly different lens - useful before you finalize.
What did we change after the first review cycle?
A timeline block showing first submission, reviewer feedback, fixes to permissions or metadata, resubmission, and the next release checklist for ongoing Thunkable app updates.
The review feedback became a working checklist
We stopped treating iOS and Android as one funnel. Each rejection note got tagged by store, reviewer message, and the artifact involved (binary, metadata, privacy text, screenshots). That made fixes faster because we could answer "What failed?" before touching anything else.
Common failure modes we now watch for:
- Metadata mismatch (description vs actual behavior)
- Permissions unclear (declared but not used, or needed but not explained)
- Screenshot size issues or inconsistent UI states
- Account verification or signing blocked by missing access or 2FA
- Play Console "Data safety" answers that do not match what the app actually collects or shares
Build your Thunkable release checklist
Copy the table above, assign an owner for each artifact, and add links to the exact files you will upload. Then run it before every export.
Download the checklist
Timeline (first cycle)
Submit (Day 0) -> feedback (Day 2-4) -> targeted fixes (Day 5) -> resubmit (Day 6) -> checklist updated for v1.0.1.
In practice, plan at least one resubmit and keep a few slack days in the calendar. Also avoid promising an external launch date until both store accounts are verified and you have uploaded a first build at least once.
Review your next submission risks
Before you export again, sanity-check IDs, permissions, screenshots, and who has console access. This 10 minute review often saves days of waiting on preventable rejects.
Run the risk review
