Softr App Rejected Under Guideline 5.6: Causes and Fixes

Key takeaways

Softr doesn't support App Store publishing, so a wrapped Softr app is your app in Apple's eyes – the 5.6 letter is addressed to you, not to Softr.
Most Softr 5.6 cases come from structure, not intent: user groups, visibility settings, record filters and invite-only sign-up hide sections from a fresh review account.
Google Sign-in is blocked inside WebViews, magic-link emails open Safari, and every Publish click changes the app without a new build.
Fix access per user group, freeze features during review, document every page and add native value with WebViewGold before you reply.

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.

Softr app rejected under Guideline 5.6: what the letter means

A Softr app rejected under Guideline 5.6 means App Review concluded that something about the app or your conduct breaks Apple's Developer Code of Conduct – most often because features seemed hidden during review. In a Softr portal, the "hidden" part is rarely a secret. It is a page only one user group sees, a sign-in the reviewer couldn't finish or a change you published after submitting.

Developers who received 5.6 rejections in 2026 report wording about "a pattern of unusual behavior" that is "commonly associated with fraudulent activity" and an app that "contains features that appear to have been intentionally hidden during the review process". The letter seldom names the screen. 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.

In 2025 Apple rejected more than 22,000 submissions for hidden or undocumented features, and it says machine learning helps it "flag potentially problematic changes in app updates" (Apple Newsroom, May 20, 2026). The general mechanics are in our article on 5.6 rejections of WebView apps and the pillar on AI-built apps; this one stays with Softr.

Softr doesn't publish apps – so the flag is addressed to you

Softr's own FAQ leaves no room for interpretation: "Softr builds are PWAs (progressive web apps) and cannot be published to the iOS App Store or Google Play. This applies across all plans." When a community member asked about native conversion in February 2025, a Softr team member replied that Softr "is meant for internal business applications so this is not a focus of ours".

So the native shell around your portal – WebViewGold, another wrapper or your own Xcode project – is your addition, and Softr support won't debug it. Apple only knows your developer account, and Guideline 5.6.2 requires your representation of "yourself, your business, and your offerings" to be accurate: seller name, support URL and privacy policy should point to the company that runs the portal.

Softr did nothing wrong, either. User groups and invite-only sign-up are exactly what a client portal needs – they only become a problem when App Review can't see past them.

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 →

Where Softr portals hide features without meaning to

Softr building block	What the reviewer experiences	Why Apple reads it as hidden
User groups with page visibility	Pages for, say, "Managers" never appear for the review account	Real users get screens App Review never saw
Block visibility and record filters	Lists tied to the logged-in user stay empty	The core feature can't be evaluated
Invite-only sign-up	The review login is the only door	If it sticks, everything behind it goes unreviewed
Google Sign-in	Google refuses the request inside the app (`disallowed_useragent`)	The reviewer can't get in – and Guideline 4.8 may follow
Admin magic links and invitation emails	The link opens Safari, so the session lands outside the app	The app looks broken or hands users off to a website
Publish button, AI Co-Builder and Vibe Coding blocks	New pages or blocks go live while the build waits in review	The app changed after review – the pattern 5.6 is built for
Stripe Checkout or PayPal on group-only pages	Purchase flows appear for paying members only	Payment flows App Review never saw

Two smaller details add to the impression. A floating PWA "install" button and the "Made with Softr" badge make the app look like a website in a frame – Guideline 4.2 territory. And since the AI Co-Builder (launched March 2026) assembles portals from Softr's own blocks, generated apps can look alike, while Apple says it analyzes app similarity. Give yours its own design and copy.

Audit your Softr app the way a reviewer meets it

Install the rejected build through TestFlight on a clean phone, sign in with exactly the credentials from App Review Information and open the Softr editor next to it.

User groups. For every group, note which pages and blocks it can see, and compare that with the review account's groups.
Record ownership. Find blocks filtered by the logged-in user. Does the review account own records in Softr Databases, Airtable or whichever source feeds them?
Sign-in settings. Which methods are on – email and password, email code, Google, SSO? Can the review account sign in with a password inside the app?
Publishing history. List everything published between submission and rejection, including AI Co-Builder output and custom Vibe Coding blocks.
Money. Which pages contain Stripe Checkout, the Stripe Customer Portal or PayPal, which groups see them and what they sell.
Identity. Does the app load your custom domain or the free softr.app subdomain, and do domain, seller name, privacy policy and support URL belong to the same business?
Leftovers. Badge, install button, rating pop-ups and links that open Safari.

The first three items are about access, where hidden-feature flags usually start. Fix everything you find in one build – a second 5.6 round costs more than a careful first pass.

How to fix a Softr 5.6 rejection step by step

Create one review account per real user group. Each signs in with email and password and owns realistic records. Don't invent a special "review" group with extra rights – the reviewer should see exactly what a real member of each group sees.
Make sign-in work in the app. Softr's documented sign-in options are email and password, email one-time codes, Google Sign-in, SSO and admin magic links – no Sign in with Apple. Google's OAuth policy forbids sending its sign-in to "an embedded user-agent under the developer's control", so never work around the block with a changed user agent. The native routes – ASWebAuthenticationSession or Google's iOS SDK – return the result to your app code, not to the WebView that holds Softr's session, and Apple calls linking out to the browser to sign in a poor experience. The robust fix: offer only Softr's email sign-in in the app, so Google users sign in with a code sent to the same address. See our Guideline 4.8 article for WebView apps.
Keep magic links out of review. Admin magic links are permanent pre-authenticated links that open Safari and expose an account to anyone holding the URL.
Freeze features during review. Editing records is fine; new pages, blocks and AI Co-Builder output wait for a build whose notes describe them.
Make purchases consistent. Invoices for real-world services can keep using Stripe; digital content sold to consumers needs In-App Purchase (see our 3.1.1 guide). Every app user gets the same flow.
Remove web leftovers. Turn off the badge (Pro plan and up), keep the install button out of the app and drop "rate us" pop-ups – 5.6.1 says Apple "will disallow custom review prompts".
Write review notes per user group: each page, who sees it, how to test it.
Upload a new build, test it in TestFlight with each review account, then reply.

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

Rebuild trust with a real native shell

A thin wrapper that only loads the portal gives App Review little reason to extend the benefit of the doubt. WebViewGold, the website-to-app product made by our team, turns your Softr URL into an Xcode project and lets you switch on native modules that close Softr's mobile gaps:

Push via OneSignal or Firebase for portal events such as a new document or an approval request, instead of browser push.
A native offline screen. Softr's docs say the PWA "won't be accessible when offline"; the app should explain that and offer a retry.
Face ID and Touch ID to bring clients back into their account quickly.
QR, barcode and VisionKit document scanning for inventory, field service or uploads.
Universal links for invitation links – if your domain can serve the apple-app-site-association file.
A custom user agent so your pages can recognize app sessions and drop the install button.

Use app detection for layout and native features only, never to show the reviewer different pages than your users get. No tool can promise an approval: WebViewGold fixes typical wrapper weaknesses, while user groups and sign-in remain yours to sort out.

Should an invite-only Softr portal be on the public App Store?

Many Softr apps are internal tools or client portals nobody can join without an invitation. On the public App Store, the reviewer then meets a login wall and a description promising things only invited users get. Apple has channels for closed audiences:

Unlisted app distribution: the app goes through App Review but doesn't appear in search, charts or categories; people get it through a direct link. Apple names employee resources and partner sales tools as good candidates.
Custom apps: distributed to specific organizations through Apple Business Manager (Apple Business) or Apple School Manager, via MDM or redemption codes. You have to choose this before the app is approved.

Our guide to converting Softr to an iOS app compares these channels, and appsubmitter.io includes MDM consulting for managed iPhones.

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

Answer through Reply to App Review in App Store Connect (up to 4,000 characters, attachments allowed). Explain that the portal shows content by role, list what changed and attach a short recording per user group. If Apple didn't name the feature, ask politely, and request a 30-minute App Review appointment through Meet with Apple if the exchange stalls.

Don't resubmit the same build and hope for a different reviewer.
Don't open a new developer account. Apple terminated 193,000 accounts over fraud concerns in 2025, and dodging a 5.6 decision is exactly the behavior the guideline describes.
Don't switch pages or sign-in methods back on after approval. Whatever you change for review stays changed.
Don't appeal by reflex. The App Review Board is for cases where the app really hid nothing and Apple misunderstood it, and Apple accepts one appeal per rejected submission.

Want a second opinion before you answer? Book a free consultation call. appsubmitter.io handles signing, review notes, the reply and the resubmission in your own developer account – code changes aren't included but are quoted upfront – through the iOS package. Planning Google Play too? Read how to convert Softr to an Android app.

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 [build number]).

[App name] is a client portal for [business]. Its pages depend on the user's role, which is why some were not visible to our earlier demo account. Nothing is switched on or off after review.

Changes in this build:
1. One demo account per role, each with sample data, signing in with email and password inside the app:
   - Client: [email] / [password]
   - Team member: [email] / [password]
2. [Google Sign-in is no longer offered in the app.]
3. No new features have been published to the web app since this submission.

Pages per role and how to test them:
- Client: [page] – [what to do]
- Team member: [page] – [what to do]

A screen recording per role is attached. If a specific screen raised the concern, we would appreciate a pointer so we can address it directly.

Best regards,
[Your name], [Company]

Checklist before you resubmit

Every Softr user group that real users belong to has its own review account with sample records.
Review accounts sign in with email and password inside the app; Google Sign-in is gone from the app for good.
Nothing new was published from the Softr editor or the AI Co-Builder while the build was in review.
Stripe Checkout and PayPal pages show the same flow to every app user; digital content uses In-App Purchase where required.
The "Made with Softr" badge, the PWA install button and custom rating pop-ups are gone from the app.
Custom domain, seller name, privacy policy and support URL belong to the same business.
The review notes list every page per user group with test steps.
A new build with native features in the main journey was tested in TestFlight with each review account.

Frequently asked questions

Softr app rejected under Guideline 5.6 – does Apple think I committed fraud?

Not necessarily. The wording sounds harsh, but it usually reflects a pattern: App Review saw features it couldn't reach or that changed after submission – in Softr apps typically a page hidden by user groups, a failed Google Sign-in or something published during review. Fix the access problem, document every page and reply calmly with test steps.

Does Softr support publishing to the App Store?

No. Softr's FAQ says Softr builds are PWAs that cannot be published to the iOS App Store or Google Play, on any plan. Wrapping a Softr app in a native shell is something you do yourself with a third-party tool, and you are the developer App Review deals with. For some internal teams, Softr's installable PWA is enough.

Can I give App Review an admin magic link instead of a password?

Better not. Softr's admin magic links are permanent pre-authenticated links: they open in Safari instead of your app and grant access to anyone holding the URL. Create a normal review account that signs in with email and password inside the app, one per user group, and enter the credentials under App Review Information.

Can I keep publishing changes in Softr after approval?

Yes, within limits. Updating records, fixing text and adjusting layouts is normal for a web-based app. New pages, new blocks, new purchase flows or new data collection should ship together with a new build whose review notes describe them. That keeps the app Apple approved identical to the one your users get.

Will WebViewGold stop a Softr app from being flagged under 5.6?

No tool can promise an approval, and 5.6 judges your conduct, not your wrapper. WebViewGold, made by our team, gives your Softr app the native side reviewers look for – push, an offline screen, Face ID, scanners and universal links. User groups, sign-in and publishing discipline are still yours to fix.

My Softr portal is only for invited clients. Is the App Store the right place?

Maybe not. Apple offers unlisted app distribution, where a reviewed app is reachable only through a direct link, and custom apps for specific organizations through Apple Business Manager. Both still go through App Review. A free consultation call helps you pick the channel before you resubmit.

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.

Softr App Rejected Under Guideline 5.6: How to Fix a Developer Code of Conduct Flag on Your Portal