A practical, end-to-end guide to taking a Thunkable project from finished design to a live iOS App Store listing, including the Apple Developer setup most beginners miss.
Publishing to Apple's App Store has hard prerequisites, and skipping them is the number-one reason beginners stall.
First, you need a completed, tested Thunkable project. Do your bug fixing before you think about publishing, because each store submission cycle costs time.
Second, and non-negotiable, you need an Apple Developer Program membership. This is a paid annual account from Apple, separate from Thunkable, and there is no way to publish to the public App Store without it.
Third, you need access to App Store Connect, Apple's web portal for managing app listings, which comes with your developer membership.
Finally, prepare your marketing assets in advance: app name, description, keywords, a privacy policy URL, and screenshots sized for the required iPhone displays.
Having all of this ready before you start makes the rest of the process dramatically smoother.
Go to Apple's developer website and enroll in the Apple Developer Program. Enrollment can take time to process, sometimes a day or more, so do this early.
Use the Apple ID you want tied to your app's business. If you are publishing as a company, Apple may require a D-U-N-S number and verification, which can add days — plan for it.
Once approved, you'll have access to App Store Connect and to the certificates and identifiers that iOS distribution requires.
Thunkable will lean on this account to generate the iOS build, so it must be active and fully set up before you attempt to publish.
Do not skip ahead assuming approval is instant — enrollment delays are common, and this step is often the single biggest schedule risk for a first-time publisher.
Back in the Thunkable editor, treat this as your last design pass.
Set a proper app name, app icon, and any splash or launch imagery. Apple is strict about icons — provide a clean, correctly sized icon with no transparency issues.
Walk through every screen and confirm navigation works, forms submit, and any external data or API connections respond correctly.
Check permissions carefully. If your app uses the camera, location, photos, or microphone, Apple requires a clear usage description explaining why, and a missing or vague reason is a common rejection cause.
Remove test data, placeholder text, and any debug screens. Reviewers will find them.
When the app feels genuinely finished, you're ready to generate the iOS build.
Thunkable's publishing flow will guide you through producing an iOS build. Look for the download or publish option that targets iOS specifically.
During this step you'll connect your Apple credentials so Thunkable can create a build signed for distribution. Follow the on-screen prompts and Thunkable's official iOS publishing documentation, since the exact screens evolve over time.
You'll set a bundle identifier — a unique reverse-domain string like com.yourcompany.yourapp. Choose it carefully, because it permanently identifies your app to Apple and cannot be reused across different apps.
Thunkable then compiles the project into an iOS build artifact suitable for upload to Apple.
If the build fails here, the cause is almost always a credential, certificate, or bundle-identifier mismatch — note the exact error and address it before retrying.
In App Store Connect, create a new app record. This is where Apple stores everything about your listing.
Enter the app name, primary language, the bundle identifier you chose in Thunkable (they must match exactly), and an SKU for your own tracking.
Fill in the App Store listing details: description, keywords, support URL, and category. Write the description honestly — overpromising features you didn't build invites rejection.
Upload screenshots for the required device sizes. Apple mandates specific pixel dimensions, so capture or resize accordingly.
Complete the App Privacy section. You must declare what data your app collects and how it's used, which matters especially if you integrate third-party analytics or backends.
Get your Thunkable-generated build into App Store Connect. Depending on Thunkable's current flow, the build may be delivered to your account directly, or you may upload it using Apple's tooling such as Transporter.
Once the build appears in App Store Connect, it goes through Apple's automated processing, which can take a little while. Wait for it to finish before selecting it.
Attach the processed build to your app version, answer the export-compliance and content questions, and set pricing and availability.
Then hit Submit for Review. Your app enters Apple's queue.
Review times vary, often from roughly a day to several days. If Apple rejects it, they'll cite the specific guideline — read it carefully, fix the issue, and resubmit rather than arguing.
Once approved, you can release immediately or schedule a release date. Congratulations — your no-code app is live on the App Store.
Monitor early reviews and crash reports. Real users will surface issues your testing missed, especially around network conditions and older devices.
For updates, you repeat the cycle: change your app in Thunkable, generate a new iOS build with an incremented version number, upload it, and submit the new version for review.
Keep in mind the honest limitation throughout: because Thunkable apps aren't native Swift, some advanced Apple features may remain out of reach. If you hit that wall repeatedly, it may be time to plan a native rebuild.
But for shipping a working iOS app without writing code, this workflow gets you all the way to the App Store.
A few recurring mistakes trip up first-time publishers, and knowing them in advance saves review cycles.
The most frequent is treating enrollment as instant. Start your Apple Developer Program enrollment before you finish the app, so account approval isn't blocking you at the finish line.
Another is a mismatched bundle identifier between Thunkable and your App Store Connect record. They must be identical, character for character.
Missing permission descriptions are a classic rejection: every device capability you use needs a clear, honest reason string.
Thin functionality is also risky — an app that is essentially a wrapper around a website can be rejected under Apple's minimum functionality guideline, so make sure your app does something genuinely app-like.
Finally, always test the final installed build, not just live preview, before you submit. Some behaviors only appear in a real signed build.
You don't need to write Swift in Xcode, since Thunkable produces the iOS build. However, you do need an Apple Developer Program membership and access to App Store Connect, both of which are handled via the web.
Apple's review typically ranges from about a day to several days, though times vary. Enrollment in the Apple Developer Program can also take extra time, so start early.
The bundle identifier you set in Thunkable must exactly match the one in your App Store Connect app record, because Apple uses it to uniquely identify and route your build.
Yes. Apps built with no-code tools follow the same App Store Review Guidelines as any other app. Common issues include missing permission descriptions, thin content, or broken functionality.