Apple rejected your Base44 app? Every reason, and its fix

You built the app. Base44's Mobile tab scanned it and said it was ready for the stores. You paid Apple $99, fought your way through the upload (probably without a Mac), waited a few days, and got a letter with a guideline number in it. So you fixed what the letter said, resubmitted, waited again, and got another one. I've watched a lot of people go through exactly this over the last year, and the maddening part isn't Apple. It's that you can't tell which rejections are about your app and which ones are about Base44.

Apple reviews two things: your app, and the wrapper Base44 puts around it

What Base44 uploads to Apple isn't your app. It's a small native app that opens your published Base44 website inside it. People call it the wrapper, and Base44 does too. Apple installs that wrapper on a device and reviews whatever it sees.

Some of what it sees is yours: your screens, your sign-in settings, your privacy page, your screenshots, the demo account you gave the reviewer. You can change all of that in an afternoon.

The rest is the wrapper itself: which permissions it declares, how it opens sign-in, how it behaves on an iPad, what it can't do about payments, whose name is on it. Base44 builds it, Base44 signs it, and there's no way for you to open it. When Apple rejects you for something in that pile, the AI tells you it's part of the wrapper code, support tells you it's a known limitation, and you spend credits and another round of review finding that out.

So before you touch anything, sort the letter into one of the two piles.

The rejections you can fix yourself, on Base44

1. Your only sign-in is Google (Guideline 4.8). The letter says the app “uses a third-party login service, but does not appear to offer as an equivalent login option”, and points you at Sign in with Apple. Every new Base44 app starts with Google as its only sign-in, so this is the first letter most people get. It's a switch: turn on Apple sign-in in your app's authentication settings, or turn Google off and keep email and password. Either one passes on the next round.

   What doesn't work is keeping Google and making its button redirect to your own login page instead. People have been rejected five times doing that. Apple taps the button.

2. The reviewer couldn't get in, or didn't understand what the app is for (2.1). This is Apple's most common rejection of all, for any app. The reviewer needs a demo login that works and doesn't expire, for every kind of user your app has. If you sell anything, a short note on what's paid and how. If the app is for one company's staff, say so. All of it goes into the review notes in App Store Connect. And the app has to be published and loading when they open it; a wrapper that opens on a blank screen is rejected within the hour.
3. No privacy policy or terms before sign-up, and no way to delete an account (5.1.1). A privacy policy link in the listing isn't enough. It has to be reachable inside the app before someone creates an account, and your terms with it. And any app that lets people sign up has to let them delete their account from inside the app, not by emailing you. Both are prompts: put the privacy and terms links on the login page, and add a “Delete my account” option in the account settings.
4. The “Edit with Base44” badge. The little button at the bottom of your published app reads, to a reviewer, like a link that sends people out of the app. One owner had every purchase going through Apple and still got rejected for sending users to another site to pay. Remove the badge (it's a setting on Starter and up) before you submit.
5. The listing itself (2.3). Screenshots of the login page or the splash screen instead of the app in use. A description that mentions Android. A category that doesn't fit. Small things, and each one costs you a round.

6. “Not sufficiently different from a mobile browsing experience” (4.2). This is the one I can't give you a switch for, because it's about your app. Apple's letter will even say that push notifications and location “do not provide a robust enough experience”. It hits apps made from websites everywhere, Base44 or not, and it comes down to whether the reviewer sees an app or a website in a frame. An app someone uses to do their work usually passes. A page that mostly shows content doesn't.

   What helps is making the app behave like one: open on the thing people do, not on a landing page; keep the navigation inside the app; no “visit our website” links; no content that's just your site reformatted. This one follows your app wherever it runs, so it's worth fixing in the app itself.

7. It looks like other Base44 apps (4.3, 5.6). Apple's reviewers see a lot of Base44 apps, and the stock Base44 login screen is identical on all of them. A 5.6 letter about “a pattern of unusual behavior commonly associated with fraudulent activity” sounds terrifying and usually just means that. Base44 lets you design your own login page now; do that, and never submit two bundles of the same app.

If your letter is on this list, you're a round away. Fix it, resubmit, and you're through. People with free, simple apps get approved on Base44's own build all the time, no wrapper service needed.

The rejections that come from Base44's wrapper, which nothing in the builder fixes

This is the pile that eats months. Every item in it is something Base44 built into the wrapper, and your only moves are to strip the feature out of your app, wait for Base44, or pay someone to build around it.

1. Your app sells anything digital (3.1.1). This is the most common rejection Base44 owners get, by a wide margin. Apple requires its own in-app purchase system for subscriptions, premium features, credits, anything you can't hold in your hand, and Base44's wrapper doesn't have it. Not yet, no date. The purchase plugins people try to bolt on break the build and get rejected anyway.

   Base44's own advice is to sell on your website instead and let people log in on the app. Outside the US, Apple rejects that too, and the letter says exactly why: “The app still accesses digital content purchased outside the app, such as subscriptions, but that content isn't available to purchase using In-App Purchase.” If something can be used inside the app, Apple wants it buyable inside the app. In the US App Store, Apple does allow a button that sends people to pay on the web. Everywhere else, what has actually passed is stripping every price, every upgrade button and every mention of your website out of the iPhone app, so it only shows what the account already has. For most apps that's a free app that can't make money.

2. Sign-in doesn't work inside the wrapper. Apple's letter reads “Tap Continue with Google or Apple. Buttons were not responsive.” Google refuses to show its sign-in inside an embedded browser. Apple sign-in in the wrapper opens as a web page instead of Apple's own sheet, or finishes in Safari and never comes back to the app, and when someone cancels they land on a raw Base44 error page. Base44's backend has no way to sign a person in from a native Apple or Google sign-in, which is why no wrapper, Base44's or a paid one, fixes this from the outside. What people do is turn the social logins off and keep email and password. Fine for an internal tool. A real loss for a consumer app.
3. The iPad. Apple reviews iPhone apps on an iPad too, and that's where Base44's wrapper falls apart: a floating “Main” pill sits over every screen (only on iPad), and sign-in and camera buttons that work on an iPhone do nothing there. Reviewers reject it under Guideline 4 for an iPad layout that's crowded or unusable, or under 2.3 when the app simply doesn't behave on iPad. There's no iPhone-only option in Base44's export and no Xcode project to set one, so owners end up removing features from the iPad version of their own app to get through.
4. Permission texts you can't write (5.1.1). Every permission an app asks for comes with a sentence telling the person why. Base44 writes those sentences, and you can't edit them. In July they fixed builds that shipped with no sentence at all, which Apple refuses to even look at. What's left is sentences that say nothing: a location prompt rejected as too vague, a game rejected over Bluetooth and speech-recognition texts for permissions it never asked for, and the regenerated build rejected for the same texts again.
5. Permissions your app never uses. The wrapper declares a fixed set of permissions whatever your app does. On iOS it carries a HealthKit entitlement, so App Store Connect refuses the upload over a missing health permission text for apps that have nothing to do with health. On Android it declares camera, contacts, calendar and phone, and Google Play refuses builds over a camera permission the app doesn't use. The scan can add permissions. It can't remove them.
6. The identity is Base44's, not yours. The bundle ID is com.base followed by your app ID, and you can't set it, so you rename your App Store Connect record to match, and you can never submit a Base44 build as an update to an app you already have in the store. Each new build creates a new signing certificate; Apple allows three, and then builds fail until you revoke one. The build number is 1 every time, so the second upload is refused. For a while the builds used an iOS SDK Apple stopped accepting in April. And if you're on Windows, the IPA comes without the file Apple's upload tool needs, which is where the “renting a Mac in the cloud” posts come from.
7. Base44 is on the screen. The splash screen is Base44's. The Apple sign-in sheet says “Base44” where your app's name should be. The iPhone's own prompt says your app “wants to use base44.com to sign in”. None of that is a rejection by itself, but one owner was asked to prove they own the website their app loads, and your users see all of it.

Base44's own position on all of this is that it can't guarantee approval and its support doesn't deal with store review feedback. So people spend two or three months and a few hundred credits in this pile before they find out that nothing they do in the builder reaches it.

What people do about the wrapper rejections

1. Strip the feature and stay. Google sign-in off, no payments, the iPad features removed. If your app is free, uses email and password, and doesn't need the camera, this works, and it costs nothing: plenty of people have several apps approved on Base44's own build this way. If your app sells something or lives on Google sign-in, you're shipping a smaller version of your app than the one you built.

   What a Base44 app can and can't do on a phone, feature by feature
2. Wait for Base44. In-app purchases have been “coming” since February. The iPad and sign-in threads on Base44's feedback board get closed as resolved while the issue stands. Nothing about the wrapper is on their roadmap.
3. Pay for a different wrapper. Despia, Natively, Median and the like replace Base44's wrapper with theirs and add RevenueCat for purchases, for $50 a month or a few hundred once. It does get you purchases. It doesn't get you native sign-in, because that problem is in Base44's backend, which no wrapper can touch; Despia's own fix for it is to build your own login system on top of Base44. And your app still runs on Base44 with everything that comes with that.
4. Rebuild it outside Base44. This works, and the agencies quote it at four to ten weeks. A full development project, to end up with the app you already have.

All of the wrapper rejections are one problem

Look at the second pile again. Payments, sign-in, the iPad, the permissions, the identity, the splash screen. They aren't seven bugs. They're one fact: the app Apple reviews isn't yours. It's a shell Base44 builds, signs and controls, around a website Base44 hosts, with a login system Base44 runs. Nothing in that chain is in your hands, so nothing in it can be fixed by you, and Base44's answer to each item is the same known limitation.

A normal app doesn't have this problem, and not because normal developers are smarter. It's because the shell is theirs. Sign in with Apple is Apple's own sheet signing into their own backend. Purchases go through Apple and their own server checks the receipt. The permissions are the ones the app uses, with sentences they wrote. The bundle ID, the certificate and the build number are theirs. There's no pill on the iPad, because nobody else put a shell on it. If your Base44 app were a normal app on normal providers, every item in the second pile would stop being a rejection and become a setting.

The hard part is getting a Base44 app there. Base44's export gives you the frontend and nothing that runs it; the backend, the login system and your data all stay on Base44, so wrapping the export yourself lands you in exactly the same place.

This is why I built EscapeBase44. I got stuck on Base44 with an app of my own, spent months reverse-engineering their entire backend until I could get my app out, and then automated the whole move. EscapeBase44 takes your Base44 app, exactly as it is, and turns it into a normal app on normal providers under your own accounts: every screen, every record, every user with their password, the backend functions, all of it. Nothing gets rebuilt. And because the whole point of a normal app is that the shell is yours, it builds the native app for you too:

• Store builds with one click, no Mac. The iPhone build is made in the cloud and lands in your TestFlight; the Android build is a signed Play file.
• Sign in with Apple, the real one. Apple's own sheet, signing into your own backend. Google sign-in works inside the app, so you keep both and Guideline 4.8 is a non-issue.
• Real in-app purchases. Subscriptions and one-time unlocks through Apple and Google, verified by your own server. You can sell inside the app the way Apple wants you to.
• Permissions that are yours. The permission texts live in your own code, so you write what your app actually does with the camera or location, and there's no HealthKit entitlement or Bluetooth text you never asked for.
• Your own identity. Your bundle ID, your certificates, build numbers that go up by themselves. If you already got a Base44 build into the store, the new builds go out as updates to that listing, so your installs and ratings stay.
• Account deletion built in, and no Base44 splash, badge or name anywhere in the app.
• Keep building with AI, like you did on Base44, for whatever native feature you want next. It's your code now, so there's no wrapper deciding what your app can do.

What the move doesn't change is the first pile. A demo account, a privacy page, screenshots and Guideline 4.2 are about your app, and they follow it anywhere. If Apple calls your app a website in a frame today, it'll say so tomorrow too, and that's the part you fix in the app itself. But it's the pile you can fix.

So: if your app is free, uses email and password, and doesn't lean on anything the wrapper breaks on an iPad, fix your pile and stay. Base44's build gets apps like that through. If your app sells anything, needs Google or Apple sign-in to actually work, or you're on your third round against something the AI says it can't touch, the wrapper is the problem, and no amount of resubmitting fixes the wrapper.

Google Play, briefly

Same wrapper, different walls. The package name is com.base plus your app ID, and some owners had Base44 change both the package name and the signing key between builds, which means a brand new listing and another 14-day closed test with 12 testers. Play refuses builds that declare permissions the app doesn't use, and if you run ads it's missing the advertising-ID permission Google requires. The version code is 1 on every build. Google's new developer verification asks for a signed app with a file inside it that the wrapper can't carry. And there's no Google Play Billing, same as Apple. On your own build, all of that is yours: your package name, your signing key, your permissions, and purchases through Play the way Google wants them.

Base44 App Store rejection FAQ

• Why did Apple reject my Base44 app?

  Usually for one of two kinds of reason. Either something in your app (no Sign in with Apple next to Google, no demo account, no privacy policy or account deletion), which you fix on Base44; or something in the wrapper Base44 builds around your app (no in-app purchases, sign-in that doesn't work inside it, iPad problems, permission texts), which nothing you do in the builder changes.

• Does Base44 support Sign in with Apple?

  Yes, as a switch in your app's authentication settings, since February 2026. Turning it on is what clears the Guideline 4.8 rejection. Inside Base44's iPhone app it opens as a web page instead of Apple's own sheet, and the sheet says Base44 on it, not your app's name.

• Does Base44 support in-app purchases?

  No. Base44 has no StoreKit or Google Play Billing, and has been saying an integration is coming since early 2026, with no date. Selling anything digital inside a Base44 iPhone app gets rejected under Guideline 3.1.1.

• Can I sell subscriptions on my website and let people log in on the iPhone app?

  In the US App Store, Apple allows a button that sends people to pay on the web. Everywhere else it rejects an app that uses content it doesn't also sell inside the app. What has passed review is removing every price, upgrade button and mention of the website from the iPhone app, so it only shows what the account already has.

• Why does Apple say my sign-in buttons don't respond?

  Because Google refuses to show its sign-in inside an embedded browser, and Apple sign-in inside Base44's wrapper doesn't open Apple's native sheet. Base44's backend can't sign someone in from a native Apple or Google sign-in, so no wrapper fixes it from outside. Turning the social logins off and keeping email and password is what gets people through.

• Can I make my Base44 app iPhone-only so Apple doesn't review it on an iPad?

  No. Base44's export has no iPhone-only option and no Xcode project to set one, and Apple reviews iPhone apps on an iPad anyway. The floating Main pill people see on iPad comes from the wrapper, and the only way owners have gotten through is removing features from the iPad version of their app.

• Why can't I change the permission text Apple rejected?

  Because Base44 writes the permission texts in the build and doesn't let you edit them. Since July every build has a text for each permission, but they're generic, and Apple rejects texts that don't say what your app does with the data.

• Does Apple reject apps because they were built with AI?

  No. Apple has no rule about how an app's code was written. The story in March 2026 was about Replit and Vibecode's own apps, which build and run other apps inside themselves, not about apps made with those tools.

• How many times can I resubmit after a rejection?

  As many as you want. But each round costs you credits in Base44 and days of waiting, and Apple says that repeated rejections for the same guideline make later reviews take longer.

• Will Apple approve my app once it's off Base44?

  The wrapper rejections stop: purchases, sign-in, the iPad, the permissions, the identity are all yours to set once the app runs on normal providers. What's about your app itself (a demo account, privacy and deletion, screenshots, Guideline 4.2) still has to be right, wherever the app runs.

• Can I keep my existing App Store listing if I migrate my Base44 app?

  Yes. If your app is already in App Store Connect under the bundle ID Base44 gave it, EscapeBase44 builds the new versions as updates to that listing, so your installs, ratings and reviews stay.

• Does Base44 help when Apple rejects my app?

  No. Base44's position is that it can't guarantee approval, and its support doesn't deal with store review feedback. The AI will tell you the rejected part is in the wrapper code, which it can't change.