Check these first
Sixty seconds, no AI. Most people are fixed by one of these and never need the prompt below.
- 1
First question: do you sell digital goods inside the app? If no — the app is free, or you sell physical goods or real-world services — you are in the easy case and the rest of this page is mostly reassurance. If yes, keep reading, because that is where every rejection comes from.
- 2
If you sell digital goods, take Stripe out of the mobile app. Base44's own documentation is blunt: "If your app uses Stripe for digital content, your app is rejected." Apple requires in-app purchase for digital content under guideline 3.1.1. This is not a Base44 limitation you can prompt your way around — it is Apple's rule, and it is enforced on review.
- 3
Know the route that actually ships: sell on the web, keep the app free. Users subscribe on your website; the app signs them in and unlocks what they already paid for. Do not link to your payment page from inside the app, do not mention pricing, do not put a "go to our site to upgrade" button in it. Apple's 3.1.3(f) is the relevant carve-out and it is narrow — read it rather than paraphrasing it.
- 4
Check whether you need the store at all. A PWA installs to the home screen, works offline if you build for it, and has no review process, no 30% cut and no rejection risk. For a lot of Base44 apps — internal tools, club apps, booking systems — the store adds a quarterly compliance chore and nothing else.
- 5
If your Play Store tester link says "item not found": that is closed-testing configuration, not your app. The tester has to accept the invitation with the same Google account they are signed in with, and the release has to be live on that track. It is the most common false alarm in this whole process.
- 6
Expect to handle review yourself. Base44's docs say plainly that support "does not check on the status of your submission, contact Apple or Google on your behalf, or manage store review feedback". Whatever the reviewer says, you are answering it.
Set this in your dashboard
Nothing in the Base44 dashboard puts you on the App Store. There is no toggle. Wrapping is done outside the platform, with a wrapper service or a native project you maintain, and the store accounts are yours — $99/year for Apple, one-off $25 for Google.
What matters in the dashboard before you wrap:
Your custom domain must be live and stable, because the shell loads it. A domain that stops resolving takes your app store listing down with it, silently, to everyone who already installed.
Auth has to work on mobile web. Test the whole sign-in flow in a phone browser before you wrap anything — OAuth redirects behave differently inside a shell, and debugging that after review is miserable.
Decide about push before you choose a wrapper. If you want SendPushNotification to do anything, the shell has to support it, and they vary.
And make the app work offline enough not to look broken. A blank screen on a bad connection is the kind of thing a reviewer will hit once and fail you for.
Why this happens on Base44
A Base44 app on the App Store is your web app inside a native shell. That one architectural fact explains every constraint below.
Why the payment rule bites. Apple requires digital goods to be sold through in-app purchase, which means StoreKit, which is native code. A web app in a shell has no native billing unless the shell provides a bridge to it. Base44 does not currently ship that bridge, and builders in the Discord this week were still asking what everyone is using in the meantime — "The official Base44 integration doesn't seem to be available yet, and Stripe can't be used for digital purchases on iOS." So you have three honest options: sell on the web and keep the app free, use a third-party wrapper that bridges StoreKit, or do not ship a paid app to iOS.
What the shell does and does not change. It does not change your data, your rules or your backend — those are the same app. It does change what the reviewer sees: they will look for native-feeling navigation, working offline or error states, permission strings that explain themselves, and no dead ends. A web app that is obviously a website in a frame gets rejected on 4.2 — minimum functionality — regardless of payments.
Push notifications work, but only for the native build. Base44's SendPushNotification reaches your native app rather than your web app. That is genuinely a reason to wrap, and often a better one than the store listing itself.
And Android is the easier door. Play review is faster, closed testing is straightforward once configured, and the digital-goods rules, while similar in principle, are enforced less aggressively on a wrapped web app. If you want to learn this process, learn it on Play first.
Then run this
Paste into your Base44 builder chat. The first one only reads — it changes nothing, so it is safe to run on a live app.
Open Base44, opens in a new tabBase44 links on this page are affiliate links. If you sign up through one, Dean may earn a commission at no extra cost to you.The store-readiness audit — read only, changes nothing
Audit this Base44 project for App Store and Play Store readiness. I plan to wrap
it as a native app.
READ ONLY. Do not edit, create or delete any file. Do not publish. If something
should change, describe it.
EVIDENCE RULE
Every finding carries [CODE] file:line, [LIVE] a URL and its status code, or
[UNVERIFIED]. No PASS without evidence. Do not guess how a reviewer will behave
— report what is in the app and let me judge.
1. THE PAYMENT QUESTION — do this first, it decides everything else
- Does this app sell anything? What, and through what?
- Is what it sells DIGITAL (subscriptions, credits, unlocks, content) or
PHYSICAL/REAL-WORLD (goods shipped, services performed in person)?
- Find every Stripe or payment call. File and line.
- Find every price, plan name, "upgrade", "subscribe" or "buy" string in the
UI. File and line, and quote the string.
…63 lines · 2,984 characters
The fix prompt — make it shippable
Using the audit, make this app store-ready. This turn writes.
FIRST, THE DECISION I NEED FROM YOU — ASK ME BEFORE TOUCHING PAYMENTS.
If the app sells digital goods, tell me which route you recommend and wait:
a) remove purchase flows from the app, sell on the web, app is free
b) keep purchases, use a wrapper that bridges to StoreKit, accept the cut
c) skip the App Store, ship a PWA
Do not start ripping out payment code on your own judgement. That is a business
decision with revenue attached.
Then, in this order:
P0 rejection risks — whatever the audit flagged under guideline 3.1
P0 anything broken for a brand-new account with no data
P0 missing account deletion, missing privacy policy link
P1 screens that look like a website rather than an app: tap targets under
44px, horizontal scroll at 390px, hover-only interactions
P1 offline and slow-connection states that currently show nothing
P2 placeholder content, debug UI, test data
…33 lines · 1,543 characters
Run this only after you have read the audit above, and only when you are happy for it to change files.
The reviewer simulation — run before you submit
Play the reviewer. Be pessimistic — assume they are looking for a reason to
reject, because on a wrapped web app they often are.
PART 1 — WALK THE APP AS A BRAND NEW USER
List, screen by screen, what someone sees who has just installed this, created an
account thirty seconds ago, and has no data. For each screen say whether it looks
finished, whether it explains what to do next, and whether anything is blank,
spinning or broken. A reviewer never sees your populated account.
PART 2 — THE REJECTION CHECKLIST
For each, answer YES, NO or UNVERIFIED with the file and line or the screen:
- Does any screen show a price, plan, subscription or purchase for digital
content?
- Does any link take the user out to a payment or pricing page?
- Is there a working account deletion path?
- Is there a privacy policy reachable from inside the app?
- Does every permission request have a string explaining why, in plain words?
- Does the app do something useful without a login, or is it a wall?
…32 lines · 1,682 characters
An agent that reports its own work as done is not evidence. This pass re-checks from outside the change.
What this can’t fix
The store accounts are yours and so is the review. Apple Developer is $99 a year, Google Play is a one-off $25. Base44 support "does not check on the status of your submission, contact Apple or Google on your behalf, or manage store review feedback" — their words. Whatever comes back, you answer it.
Read guideline 3.1 properly rather than trusting anyone's summary, including this one. The carve-out for free apps that sell elsewhere is real and it is narrow, and the details change. Fifteen minutes on Apple's own page is the cheapest fifteen minutes in this whole process.
Start on Google Play. Review is faster and more forgiving, and you will learn the process on the platform that punishes mistakes less. Then take what you learned to Apple.
Decide honestly whether you need the store at all. For an internal tool, a club app, a booking system or anything with a known user base, a PWA gives you a home-screen icon and no review process, no annual fee and no 30% cut. The store is worth it when discovery matters or when you need native push. If neither is true, you are buying a compliance obligation.
If the tester link says "item not found", it is almost never the app. Closed testing on Play requires the tester to accept with the same Google account they are signed in with, and the release has to be live on that track. Check both before rebuilding anything.
Links you’ll need
- Base44 — uploading to app stores"If your app uses Stripe for digital content, your app is rejected." And Base44 support will not chase your review.
- Apple — App Review Guidelines, section 3.13.1.1 requires IAP for digital goods; 3.1.3(f) covers free apps that do not sell inside the app.
- Base44 — built-in integrationsSendPushNotification reaches a native app rather than your web app — relevant once you wrap.
- Google Play Console — closed testingWhere the "item not found" tester-link problem usually resolves.
Asked in the Base44 Discord, 12 Sept 2026. Facts on this page verified 15 Sept 2026. v1. Google and Base44 both change things — if something here has gone stale, tell me.