Key takeaways
- Base44's store build opens your published Base44 app, so one Publish click can show iPhone users a feature App Review never saw – the gap Guideline 2.3.1(a) targets.
- Content and fixes may keep flowing through Publish; a new page, workflow, role area, checkout or kind of data collection belongs in a new app version whose notes describe it.
- Check what the review account can open: the published app only reads production data, Private and Workspace visibility turn outsiders away, and admin areas stay invisible to the User role.
- GitHub sync (Builder plan and higher) records every editor change – a ready-made changelog for specific notes and What's New text.
- WebViewGold, made by our team, tells your Base44 web code which app version is running, so a feature can appear only in the build whose notes described it.
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.
What the rejection typically looks like
Guideline 2.3.1 - Performance - Accurate Metadata
The app includes features that were not available during our review or are not described in the Notes for Review.
Next Steps
Make every feature accessible for review and describe new features and changes specifically in the Notes for Review.
Paraphrased example – the exact wording in your message may differ.
Why your Base44 app was rejected under Guideline 2.3.1
If your Base44 app was rejected under Guideline 2.3.1, App Review found functionality it could not reach or that your Notes for Review never described. In Base44 projects this usually traces back to a feature published after you submitted, a review account without the data or permissions to open it, or notes too vague to test against. All three can be fixed before you resubmit.
The rule is Guideline 2.3.1(a) (App Store Review Guidelines, last updated June 8, 2026). Right after banning hidden, dormant and undocumented features, it adds the sentence that catches most Base44 builders:
All new features, functionality, and product changes must be described with specificity in the Notes for Review section of App Store Connect (generic descriptions will be rejected) and accessible for review.
That gives you two duties: describe every new capability in the notes of the version that brings it, and keep it accessible to the reviewer. Base44 makes the first easy to skip and the second easy to get wrong. Apple counted more than 22,000 rejections for hidden or undocumented features in 2025 (Apple Newsroom); our overview of 2.3.1 rejections in AI-built apps has the cross-builder picture.
Why a Publish click in Base44 can change your approved iOS app
Since February 3, 2026, Base44 turns projects into store files itself: the Mobile app tab scans the app against the store guidelines, lets the AI chat fix flagged issues and generates an IPA and an AAB (downloads need the Builder plan or higher). Per Base44's documentation, the iOS file "runs your published Base44 app inside a secure web view" and "opens only your app's URL". So most content and design changes you publish appear in installed apps automatically. New files and a new submission are only needed for shell changes: name, icon, bundle identifier, push or a new device permission.
That rule describes the binary, not App Review's expectations. To Base44, a new booking flow and a corrected typo are the same kind of change, because neither touches the shell. To Guideline 2.3.1 they are opposites: the typo is content, the booking flow is functionality that has to be described and reviewed – and it lands in every installed copy at once, including the version Apple approved last month.
Base44 won't catch that gap for you. Its docs say support doesn't follow your submission or contact Apple, and that even a high readiness score doesn't mean Apple will approve the app.
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.
Which Base44 changes need a new app version – and which don't
Sort each change by the route it takes to your users and by what Apple expects in return:
| Change in Base44 | Reaches app users through | What App Review needs from you |
|---|---|---|
| Records, texts, images, translations | The database or Publish | Nothing – this is content |
| Bug fixes, faster pages, a tidier layout for an existing screen | Publish | Nothing; mention a visible redesign in the next What's New text |
| A new page or workflow: bookings, chat, file uploads, an AI assistant | Publish | A new app version, a specific note and access for the review account |
| A new admin area or user type | Publish | A new version plus credentials for that role in the Notes field |
| A checkout through Base44 Payments or Stripe | Publish | A new version; sell only physical goods and services this way – digital content needs In-App Purchase, which Base44's export can't run |
| New form fields, analytics or a third-party AI service | Publish | Updated App Privacy details, consent before data goes to third-party AI (Guideline 5.1.2(i)) and a line in the notes |
| Name, icon, bundle identifier, push or a new permission | New store files | A new submission, which Base44 requires anyway; for push, say what triggers a notification |
Rows three to six are where 2.3.1 cases start: Base44 ships them with a click, Apple counts them as new functionality. Develop such a feature on a branch (see our Base44 Guideline 5.6 article), then publish it behind a switch on the user record that only the review account and a few testers have. Generate fresh files in the Mobile app tab, submit them as a new version whose notes describe the feature, and switch it on for everyone once that version is approved.
A reviewer seeing a feature before your customers do is a staged rollout. Customers getting a feature the reviewer never saw is what 2.3.1 prohibits.
What the review account can reach: data, visibility, roles and sign-in
Undocumented is one half of 2.3.1; inaccessible is the other. App Review sees your Base44 app through one account on one device, and four settings decide how much of it that account can open.
| Base44 setting | Where | What the reviewer runs into | Fix |
|---|---|---|---|
| Test data | Dashboard → Data, Test or Production | The published app always uses production data, and the test database starts empty and never syncs. Records prepared there don't exist in the store app, so history, dashboards and search stay blank. | Create the review account and its sample records in Production |
| App Visibility | Dashboard → Overview → App Visibility | Private apps admit only invited people, Workspace apps only members of your Base44 workspace. On a Private app, anyone else gets an invalid login error, even with correct credentials. | Public with sign-in, or invite the review email under Invite Users |
| Access level | Invite Users → Access level | Admins can manage the areas restricted to admins on the live app; a User account never sees them. | If customers work in admin areas, add a second review account with the Admin role |
| Sign-in methods | Dashboard → Settings → Authentication | Default Google login runs through Base44's own OAuth client, branded base44.com, and Google blocks OAuth in embedded WebViews. Base44 doesn't document how its store shell handles that. | An email-and-password review account, plus Sign in with Apple (supported since February 17, 2026) |
Apple's page on providing information for a complete review fits Base44's two access levels almost word for word: "If your app has multiple account types, such as administrative and general user accounts, use the Notes field to add additional credentials for each type." Handing App Review an Admin account doesn't expose your project: Base44 states that neither role gives access to the editor or dashboard.
Native Google sign-in through ASWebAuthenticationSession or Google's Sign-In SDK needs custom code in your own Xcode project, and sending users to Safari is no shortcut: Apple says linking out to the default web browser to sign in or register "isn't appropriate, per App Review Guideline 4" (Apple Developer). For most Base44 apps, email and password plus Sign in with Apple is the dependable in-app setup – list the methods in your notes (login rules: Guideline 4.8 for WebView apps).
While you're in the dashboard, remove the Base44 badge – possible from the Starter plan up since August 11, 2026 – so the reviewer meets your product rather than a builder's branding.
Sample Notes for Review for a Base44 booking app
The Notes field under App Review Information holds up to 4,000 bytes, and the demo account must not expire (App Store Connect Help). For an update, Apple wants what changed and where to find it, plus the external services behind your core functionality, "for example, data providers, authentication services, payment processors, or AI services". For a Base44 class-booking app:
| Part of the notes | Example |
|---|---|
| How the app works | The app shows our Base44 web app at [domain] in a native iOS shell. Class schedules and texts update through the web app; new functionality only arrives with new app versions. |
| New in 1.3 | Waitlist for full classes: Classes tab → open a class marked Full → Join waitlist. The review account is already on two waitlists, visible under Profile → My waitlists. |
| Admin tools | Studio owners manage waitlists: sign in with the admin account below, open Admin → Classes and move a member into a class. |
| Accounts | Member account in the sign-in fields. Studio owner (Admin role): [email] / [password]. Both live in production data. |
| Sign-in and payments | Email and password or Sign in with Apple; Google sign-in is offered on our website only. Card payments cover in-person class passes only. |
| Services and devices | Base44 (hosting, database, sign-in), Stripe (class passes), [AI provider] (class suggestions). Tested on [iPhone and iPad models, OS versions]. |
The waitlist belongs in the What's New text as well, since Guideline 2.3.12 wants significant changes described for customers. More templates: Notes for Review under Guideline 2.3.1.
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.
Use Base44's GitHub sync as the changelog behind your notes
Specific notes need an exact list of what changed since the approved version, and a long AI chat history is a poor source for that. GitHub sync (Builder plan or higher) is a better one: Base44 syncs your editor changes to the connected repository automatically, and changes merged into main on GitHub come back into Base44, where they go live only after you click Publish.
- Tag what App Review saw. When you submit, tag the commit that matches your published app, for example
git tag ios-1.3. - Diff before the next submission.
git diff --stat ios-1.3..main -- src/pages functionsshows which routes and backend functions changed. In Base44's project structure, each file insrc/pagesbecomes a URL path, so a new file there usually means a new screen. - Check the Data tab too. Base44's docs note that with GitHub connected, entities are managed in Base44 rather than stored locally, so a new data table may not show up in the diff.
- Translate, don't paste. With a shared connection, commits carry Base44 as their author and may say little about the user-facing change. Turn each one into a note line: what it is, where it lives, how to try it.
An empty diff in src/pages and functions is a useful signal too: you are most likely looking at content and fixes that can keep going out through Publish.
Base44's export or WebViewGold: which build is easier to document?
After a 2.3.1 rejection, the shell matters for two questions: can you tie a feature to the version that describes it, and does the reviewer meet anything the website doesn't offer? Base44's export is quick and may suffice for an internal tool without digital sales, but it gives you few levers for either.
| What you need | Base44 Mobile app export | WebViewGold build |
|---|---|---|
| A feature that appears only from the version describing it | Every installed copy loads the same published app | The App Version Check API hands version and build number to your web code; a version marker in the custom user agent works too |
| Native features a reviewer can test | Web view, optional push | Push via OneSignal, Firebase or Pushwoosh, offline screen, Face ID, QR and document scanners, native navigation footer or sidebar, native rating dialog |
| Digital purchases | No StoreKit, and Base44 warns against Stripe for digital content | StoreKit In-App Purchases with the Extended license |
| Info.plist and bundle identifier | Set by Base44 | Your own Xcode project |
WebViewGold is the website-to-app product built by our own team, and Base44 is one of the builders it supports. You enter your published Base44 URL in Config.swift, switch on the modules your users need and publish in your own developer account; the separately sold Cloud Builder builds without a Mac. For 2.3.1 the key part is version awareness: with autoInjectVariable enabled, the app passes versionNumber to your web code, and Base44's AI chat can show the waitlist only from version 1.3 on. Browser visitors get it right away, app users with the build whose notes describe it.
Switching doesn't mean starting over: the app record lives in your own App Store Connect account, so you can usually keep its bundle identifier and ship the new build as an update. No tool can promise an approval. Base44's docs also name Capacitor, PWABuilder and Trusted Web Activities as self-managed routes; our guide to converting Base44 to an iOS app compares them, and appsubmitter.io handles signing, the store listing and App Privacy details for whichever shell you pick.
Replying to App Review after a Base44 2.3.1 rejection
List what was published between submission and rejection and decide per feature: what stays becomes reachable and described, and what isn't ready is unpublished for every user, not just hidden from the reviewer. Then update the Notes for Review, generate new files only if the shell changed, and reply under the rejected submission in App Store Connect – up to 4,000 characters, with attachments such as a screen recording.
Skip the moves that deepen a 2.3.1 case: switching the app to Private during review, resubmitting the same notes or opening a second developer account. Guideline 2.3.1(b) calls egregious or repeated behavior grounds for removal from the Apple Developer Program, and features that keep arriving after review are how a documentation issue becomes a conduct issue – see 2.3.1 for WebView apps for the server-side switches behind such cases.
Prefer not to handle it alone? appsubmitter.io pairs an AI-powered guideline check with a human App Specialist who reads the rejection, rewrites your notes feature by feature, submits from your own Apple developer account and answers App Review. Changing your Base44 code isn't part of the package – if the fix needs it, we tell you and quote it before you decide. Book the iOS submission service or bring the letter to 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]), and for your feedback on Guideline 2.3.1. [App name] shows our web app, built with Base44 and published at [domain], inside a native iOS shell [generated by Base44 / built with WebViewGold]. We compared what the review account could reach with what our users see and made these changes: 1. [The class waitlist was published to our web app after we submitted. It is now described below, and the review account can use it.] 2. [The sample data for the review account had been created in our test database. It now exists in production.] 3. [The app was set to private. It is now public with sign-in, so the credentials below work.] 4. [Admin tools for studio owners require the Admin role. A second account is listed below.] 5. From now on, new functionality reaches app users only together with a new app version whose Notes for Review describe it. Accounts: - Member: [email] / [password] - Studio owner (Admin): [email] / [password] Features in this version and where to find them: - [Feature 1] – [tab or page] – [steps] - [Feature 2] – [tab or page] – [steps] Content such as [class schedules and articles] is updated through our web app without a new version. Payments in the app cover [physical goods / in-person services] only. A screen recording of these steps is attached. Please let us know if any feature is still hard to reach. Kind regards, [Your name] [Company]
Checklist before you resubmit
- Every page, workflow and role area published since the last approved version is in the Notes for Review with location and test steps.
- Features not ready for review stay unpublished for all users, not hidden from the reviewer only.
- The review account and its sample records exist in Production, not only in test data.
- App Visibility lets the review account in: Public with sign-in, or the review email invited.
- If customers use admin areas, a second review account with the Admin role is in the Notes field.
- The review account signs in with email and password, and Sign in with Apple appears wherever Google login does.
- No Stripe or Base44 Payments checkout in the app sells digital content.
- App Privacy details cover every form field, analytics tool and AI service the Base44 app uses today.
- A Git tag marks each submission, and the diff since the last tag became your notes and What's New text.
- The Base44 badge is gone (removable from the Starter plan up), and the TestFlight build was tested with the exact review credentials.
Frequently asked questions
Why was my Base44 app rejected under Guideline 2.3.1?
Can I keep publishing in Base44 after my iOS app is approved?
Which account should I give App Review for a Base44 app?
Does Google sign-in cause trouble for Base44 apps in review?
Does WebViewGold prevent 2.3.1 rejections for Base44 apps?
Recommended solution
From WebView rejection to approval: WebViewGold + appsubmitter.io
- 1 Build with WebViewGold Turn your website into native iOS and Android projects.
- 2 Add native value Push, offline screen, deep links or scanning in your main flow.
- 3 We submit it Our App Specialists submit and talk to the review team.
WebViewGold is made by our team (jocapps GmbH). It is a tool, not a guarantee – approval decisions are made by Apple and Google.
Sources and further reading
- Apple – App Store Review Guidelines, 2.3.1 Accurate Metadata
- Apple – Provide information for a complete review
- Base44 Docs – Submitting your app to app stores
- Base44 Docs – Testing your app with test data
- Base44 Docs – Choosing who can access your app
- Base44 Docs – Managing login and registration
- Base44 Docs – GitHub integration
- Base44 – Product changelog (store export, Sign in with Apple, badge removal)
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.