Base44 App Rejected Under Guideline 5.6: Causes and Fixes

Key takeaways

Base44's store build is a web view that opens your published app, so every Publish click changes the app App Review approved – park new features on a branch until a reviewed version ships them.
Typical Base44 triggers: a Google sign-in the reviewer can't finish, review data that only exists in Base44's test database, Private visibility or admin-only pages, and a Stripe paywall for digital features.
Diagnose in the editor: act as the review account, compare Production and Test data, check App Visibility and Authentication, then re-run the App Store scan.
A single-URL shell with push as its only native feature is a 4.2 risk on top of 5.6 – WebViewGold, built by our team, adds offline handling, Face ID, scanners, native ratings and StoreKit purchases.

Our recommended solution

Rebuild your wrapper with WebViewGold – a real app, not just a website in a frame

WebViewGold turns your website into native iOS and Android apps with push notifications, a native offline screen, deep links, a QR scanner and more – the building blocks App Store reviewers look for. Built by our own team, and we submit WebViewGold apps all the time.

Get WebViewGold How it helps ↓

What the rejection typically looks like

Guideline 5.6 - Developer Code of Conduct

We've identified a pattern of unusual behavior with the app that is commonly associated with fraudulent activity. Specifically, the app contains features that appear to have been intentionally hidden during the review process.

Paraphrased example – the exact wording in your message may differ.

Base44 app rejected under Guideline 5.6: what App Review is telling you

A Base44 app rejected under Guideline 5.6 has been flagged for behavior, not for its code. App Review concluded that the reviewer saw something different from what users get, or that features looked deliberately hidden. In Base44 projects the cause is usually live publishing, a sign-in the reviewer couldn't complete, an empty demo account or an inconsistent paywall – and each of these can be fixed before you resubmit.

Developers who received the letter in 2026 report the same wording: Apple identified "a pattern of unusual behavior" that is "commonly associated with fraudulent activity", and the app "contains features that appear to have been intentionally hidden during the review process". The screen concerned is rarely named. The rule underneath is Guideline 2.3.1(a):

Don’t include any hidden, dormant, or undocumented features in your app; your app’s functionality should be clear to end users and App Review.

Apple's fraud report of May 20, 2026 explains how such cases surface: machine learning helps it flag potentially problematic changes in app updates, and more than 22,000 submissions were rejected in 2025 for hidden or undocumented features (Apple Newsroom). For the general mechanics, read our overview of 5.6 rejections for AI-built apps and the WebView-specific 5.6 walkthrough; this article covers what is specific to Base44.

What Base44's Mobile app tab actually puts in the store

Since February 3, 2026, Base44 prepares store builds itself. Under Publish → Mobile app you scan the app against the App Store or Google Play guidelines, let the AI chat fix flagged issues and generate an IPA and an AAB; downloading them requires the Builder plan or higher. Base44's documentation describes the result like this:

Your mobile app runs your published Base44 app inside a secure web view. This is a lightweight native wrapper around your web app that opens only your app's URL.

Publishing changes the store app. Most content and design changes reach installed apps without a new version. Only shell changes – name, icon, identifiers, push, new permissions – need new files and a new submission.
The entry point is fixed. Base44 picks the start URL from your published app; a separate start page for the app isn't available.
Review is your part. You submit in your own App Store Connect account. Base44 support doesn't follow submissions or contact Apple, and Base44 says plainly that a high readiness score is no promise of approval.

Apple accepts changing web content – that is what such apps are for. The catch: the app the reviewer approved is whatever your Publish button shipped last. A booking flow, chat or members area that goes live the day after approval is a feature nobody reviewed.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

The Base44 settings behind most 5.6 flags

Base44 setting or habit	What App Review experiences	Fix
Publishing new features from main after you submitted	It approved one app; users now get a bigger one	Build upcoming work on a branch and release it with the next reviewed version
Default Google login through Base44's own OAuth client	A consent screen branded base44.com – or a Google error inside a third-party wrapper – and nothing behind it	Email and password for the review account, Sign in with Apple, your own Google client
Sample records for the review account created in Test data	An empty account in the store app, because the published app always reads production data	Create the review account's records in Production
App Visibility set to Private	An invalid login error for anyone who wasn't invited	Invite the review account or make the app Public
Pages restricted to the Admin role	Menu items and areas that never appear	Give the review account the role real customers have and describe admin tools in the notes
Stripe or Base44 Payments checkout for digital features	A paywall that breaks 3.1.1 – or none during review and one afterwards	One compliant purchase path for every account
Legacy built-in login, default theme, AI-generated logo	An app that resembles many other Base44 apps	Custom login pages, your own design and icon

Two smaller traps: Base44's reset email always links to /reset-password, built together with /forgot-password – if an AI edit renamed either page, a reviewer recovering the demo account hits a dead end. And generated sign-up forms often ask for company, role or phone number; 5.6 counts forcing users "to share unnecessary data" as manipulative, so ask only for what a feature needs.

Tracing the trigger in your Base44 dashboard

Reconstruct what went live. Open version history and list every publish between submission and rejection. Entries show the code behind them and can be compared with your live app.
Check who gets in. Dashboard → Overview → App Visibility. Private apps only admit invited people.
Check how people sign in. Dashboard → Settings → Authentication: default Base44 OAuth or your own Google client, and is Apple switched on?
Check where the demo data lives. Dashboard → Data, switching between Production and Test. The review account and its records belong in Production.
Walk the app as the reviewer. More actions → Act as a user, pick the review account and open every page your Notes for Review mention. Changes you make there are saved to that account, so use a dedicated one.
Re-run the scan. Publish → Mobile app → Check Your App → Run App Scan against the App Store guidelines and clear every critical item.
Test the submitted build. Install it from TestFlight on an iPhone and an iPad and repeat sign-up, sign-in, password reset and any purchase.

The fastest fix for most WebView rejections

WebViewGold: native features for your web app

Instead of building native features from scratch, start from WebViewGold. You get ready-made Xcode and Android Studio projects for your website, with native modules you switch on in the configuration:

Push notificationsOneSignal or Firebase, for real, personal events
Native offline screenNo browser error pages when the connection drops
Native splash screenApp-like start instead of a loading web page
Deep linksLinks open the right screen inside the app
QR & barcode scannerDevice features the website alone can't offer
In-app purchasesNative purchase flows where the store requires them

No tool guarantees an approval: Apple still judges what your app offers. Use the native features in your main user journey – our App Specialists review your WebViewGold app before it goes to the App Store.

Discover WebViewGold Let us submit your WebViewGold app

Fixing a Base44 app the reviewer can trust

Hold back features, not content

Keep publishing texts, records and bug fixes. Build new functionality on a branch instead – there, Merge to main replaces the Publish button, and Base44's own docs suggest keeping a feature "on a branch until launch day". Launch day is the next app version whose Notes for Review describe the feature and give the review account access to it. Our Base44 2.3.1 article sorts which changes can go out through Publish and which need that new version.

Make every sign-in path work in the app

Give App Review an email and password account. Base44 has supported Sign in with Apple since February 17, 2026, so offer it wherever Google appears – Guideline 4.8 for WebView apps explains why. Your own Google OAuth client (Builder plan or higher, custom domain required) replaces the base44.com branding with your domain. Inside an app, Google blocks its OAuth page in embedded WebViews. Native code with ASWebAuthenticationSession or Google's Sign-In SDK solves that, but Base44 documents no way to hand such a session back to the web view – so the reviewable setup is email and password plus Sign in with Apple in the app, with Google kept for the website.

One purchase path for everyone

Base44's store documentation is blunt: Stripe is fine for physical goods and services, but an app that uses Stripe for digital content is rejected. Its recovery advice – sell on the web and let the app check who has paid – needs a second look against Guideline 3.1.1: outside the United States storefront, links and buttons to other purchase methods need a regional entitlement, and web-bought digital features may be unlocked without In-App Purchase only in cases such as reader apps (3.1.3(a)) or enterprise services (3.1.3(c)); multiplatform services must offer the items as In-App Purchase too (3.1.3(b)). Whatever you choose, every account sees the same thing.

Close the trust gaps

Add account deletion inside the app. Base44's login documentation doesn't cover it, and Guideline 5.1.1(v) requires it.
Move from the legacy built-in login to custom login pages (available to everyone since June 2, 2026) and apply your own design and icon.
Connect a custom domain and remove the Base44 badge – both possible from the Starter plan up since August 11, 2026.
Publish under the business that runs the service, with privacy policy and terms reachable before sign-up.

Base44's IPA or a native wrapper: what makes the app reviewable

Base44's export is a fast way to an IPA, and for a simple internal tool it may be enough. But a shell that "opens only your app's URL" with push as its single native feature is the classic profile of a Guideline 4.2 rejection, and live publishing puts it squarely under Apple's change detection. After a 5.6 flag, a build that is unmistakably an app strengthens your case.

	Base44 Mobile app tab	WebViewGold
Native features	Web view, optional push	Push via OneSignal, Firebase or Pushwoosh, offline fallback and local HTML, Face ID, QR and document scanner, universal links, navigation footer or sidebar, widgets
In-App Purchase	Not supported; Base44 says RevenueCat and Capacitor plugins can't reach its native layer	StoreKit purchases via RevenueCat or a manual setup (Extended license)
Rating requests	Whatever your web app shows	Apple's native rating dialog, as 5.6.1 expects
Info.plist and permissions	Set by Base44's scan, not editable	Your own Xcode project
Feature releases	Live for every installed version at once	App Version Check API lets your web app enable a feature only from the version that introduces it
Pricing model	Builder plan or higher to download files	One-time purchase; Cloud Builder sold separately

WebViewGold is the website-to-app product our own team builds, and Base44 is one of the builders it explicitly supports. You point the Xcode project at your published Base44 URL in Config.swift, switch on the modules your users need and publish in your own developer account. It can't decide how Apple judges your conduct – no tool can promise an approval – but it removes the thin-wrapper weakness that makes a 5.6 case harder to argue. Our guide to converting a Base44 app to iOS walks through the setup, and the Android counterpart covers Google Play.

Replying to App Review – and the moves that make it worse

Upload the fixed build, then reply under the rejected submission in App Store Connect (up to 4,000 characters, attachments allowed). Say what you found, what changed in Base44 and in the build, and how to test each feature with the review account. If nothing in the letter points to a screen, ask politely which flow raised the concern. Appeal to the App Review Board only if the app hid nothing and was misread – Apple accepts one appeal per rejected submission – and consider a 30-minute App Review appointment when the letter names nothing.

Avoid the moves that deepen a 5.6 case: resubmitting unchanged, switching the app to Private or hiding the paywall while review runs, showing reviewers a trimmed version based on app detection, and opening a second developer account.

appsubmitter.io takes this stretch off your plate: an App Specialist checks the Base44 app with AI-powered pre-submission checks plus a human review, writes the Notes for Review, submits from your own developer account as a member of your team and handles the conversation with App Review. Code changes aren't included; if your app needs some, we quote them upfront. Book the iOS service or walk us through the rejection in a free consultation call.

Template: how to reply to App Review

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Hello App Review Team,

Thank you for reviewing [App name], version [x.y] (build [number]). We have checked the app against Guidelines 5.6 and 2.3.1. Its web content is built with Base44 and published at [domain].

What we found and changed:
1. [A booking feature was published to our web app after submission. It is part of this version now and described below.]
2. [The sample data for our review account existed only in our test database. It is now set up in production.]
3. [Google sign-in could not be completed inside the app. The review account uses email and password, and Sign in with Apple is offered on the login and sign-up screens.]
4. From now on, new features are released together with a new app version and described in the Notes for Review.

Review account: [email] / [password] (role: [User], access to every feature below)

Features and how to test them:
- [Feature 1] – [tab or page] – [steps]
- [Feature 2] – [tab or page] – [steps]
- Purchases: [physical goods are paid by card / digital items use In-App Purchase]

A screen recording is attached. If a particular screen raised the concern, we would be grateful for a pointer so we can address it directly.

Kind regards,
[Your name]
[Company]

Checklist before you resubmit

No new feature was published from main between submission and approval; upcoming work sits on a Base44 branch.
The review account and its sample records exist in Production data, not only in Test data.
Acting as the review account reaches every feature named in the Notes for Review.
App Visibility, roles and invitations let the review account in without an invalid login error.
Email and password sign-in works inside the app, and Sign in with Apple appears wherever Google login does.
/forgot-password and /reset-password exist at exactly those paths and work for the review account.
Digital features aren't sold through Stripe or Base44 Payments inside the app, and every account sees the same purchase path.
Users can delete their account inside the app.
Custom login pages, your own design and icon replace the defaults, and the Base44 badge is gone.
The App Store scan shows no unresolved critical issues, and the build was tested on an iPhone and an iPad.

Frequently asked questions

Why was my Base44 app rejected under Guideline 5.6?

Because App Review saw a pattern it associates with hidden features – not because the app was built with Base44. Typical causes are features published after review, a Google sign-in the reviewer couldn't complete, sample data that only exists in Base44's test database, Private visibility or a paywall that behaves differently for the reviewer. Trace the trigger with the dashboard checks above, fix it and reply with a complete feature list.

Can I keep publishing in Base44 after my app is approved?

Yes. Content, records, design tweaks and bug fixes can keep flowing through the Publish button – that is how Base44's store build is meant to work. New functionality should reach users together with a new app version that App Review has seen: describe the feature in that version's Notes for Review and make sure the review account can use it.

Does a high Base44 readiness score mean the app will pass?

No. The scan in the Mobile app tab is a useful pre-check, and Base44 recommends clearing every critical item before you generate files. Base44 itself says a high score is no promise of approval, though, and no scan can see what you publish after review, who can sign in or how your paywall behaves for different accounts – the questions behind most 5.6 flags.

Is Google sign-in a problem for Base44 apps in review?

It can be. The default Google login runs through Base44's own OAuth client, so the consent screen is branded base44.com, and Google blocks OAuth inside the embedded WebViews of third-party wrappers. If the reviewer can't sign in, everything behind the login looks hidden. Give App Review an email and password account, offer Sign in with Apple and test Google on a real device.

Will WebViewGold stop my Base44 app from being flagged again?

No tool can promise an approval, and 5.6 is about how the app behaves. WebViewGold, which our team builds, removes the thin-wrapper problem with push, an offline screen, Face ID, scanners, native ratings and StoreKit purchases, and its App Version Check API lets your web app tie a feature to the version that introduces it. Release discipline in Base44 stays your job.

Should I open a new developer account and submit the Base44 app again?

No. Guideline 5.6.2 requires accurate developer identity, and a fresh account for the same app looks like evasion – Apple terminated 193,000 developer accounts over fraud concerns in 2025. Fix the cause, upload a new build and reply in App Store Connect. If the letter names nothing concrete, a 30-minute App Review appointment is the better next step – appsubmitter.io can prepare it with you.

Sources and further reading

Store policies and third-party products change regularly – always check the current versions. This article is independent advice and not affiliated with or endorsed by Apple, Google or any other company or product mentioned; all trademarks belong to their owners. WebViewGold and appsubmitter.io are made by our team at jocapps GmbH.

Base44 App Rejected Under Guideline 5.6: Find the Trigger, Fix It and Get Back Into Review