Glide App Rejected Under Guideline 5.6? Find What Looked Hidden

Key takeaways

Glide says it does not endorse or support wrapping its PWA-based apps for the stores – whoever submits the wrapped app answers to Apple alone.
Email PIN and SMS PIN sign-in leave reviewers without static credentials; Glide makers documented Apple rejections over exactly this in 2023 and 2024.
Row owners, roles and visibility conditions can show a fresh review account an almost empty app, which reads like hidden features.
Sheet-driven switches and builder edits change the app without a build; ship new features with a build, never switch login off for review and add native value with WebViewGold.

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.

Glide app rejected under Guideline 5.6: the short answer

A Glide app rejected under Guideline 5.6 was flagged for behavior Apple associates with deception – usually features that seemed hidden during review. With Glide, the trigger tends to be access: the reviewer got stuck at an emailed PIN, landed in screens emptied by row owners, or reviewed a version that changed when someone edited the spreadsheet.

Developers who received the rejection in 2026 report wording about "a pattern of unusual behavior" that is "commonly associated with fraudulent activity" and "features that appear to have been intentionally hidden during the review process". Apple rarely says which feature. Our article on 5.6 in WebView apps explains the guideline itself; this one stays with what Glide makes likely.

Start with Glide's own position. Its help center says packaging a PWA for the stores is technically possible, but "Glide does not endorse or support this practice", and that people who try it "do so at their own risk, without official backing or troubleshooting from Glide" (July 2025). The wrapped app, its review and this rejection belong to your developer account alone.

Triage: match what Apple saw to the Glide setting behind it

What App Review likely saw	Glide setting behind it	Where the fix lives
A sign-in screen and no way past it	Email or SMS PIN sign-in; a demo mailbox that asked for extra verification	Sign-in setup and a reachable review mailbox
Empty lists and blank detail screens	Row owners and filters by the signed-in user; the review email owns no rows	Your data: rows owned by the review account
Fewer tabs and buttons than the description promises	Visibility conditions tied to a role column	One review account per role
Features that appeared after approval	A sheet column or table that switches tabs or components on	Feature switches under change control
Safari opening in the middle of sign-in	The magic link in the PIN email, Google sign-in or a GlideOS sign-in redirect leaving the WebView	Sign-in method and wrapper navigation
A Google button without an alternative	Sign in with Google enabled	Guideline 4.8 – remove it from the app for good

The App Review cases that Glide makers documented with a cause, in 2023 and 2024, started at the sign-in screen – so check the first row before anything else.

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 PIN problem: no password, no demo account

Glide Classic signs people in with a PIN sent by email – optionally with a magic link in the same email – with Google, with an SMS PIN through Twilio or through SSO as an Enterprise add-on. None of these gives you a fixed password to hand over, yet Apple asks you to "provide either an active demo account or fully-featured demo mode".

Glide makers have documented how that plays out. In February 2023, one reported repeated Apple rejections because the emailed code left no static credentials – "I have tried explaining this, but they reject it each time" – while Google Play accepted the same app with sign-in instructions. In March 2024, another was rejected under 2.1 because the reviewer couldn't get in when "additional verification was needed to access the Gmail account provided", and under 4.8 for Google login without an equivalent option.

What gives a reviewer a reliable way in:

A review mailbox you control on your own domain, readable in webmail with a password, without 2-step verification or new-device checks. Put the app email, the webmail address and its password into App Review Information with numbered steps.
A dry run from outside your network – a private browser window, ideally a VPN exit abroad – so you hit the checks a reviewer would.
For SSO apps, a demo identity in your identity provider that signs in with a password and skips MFA; our Guideline 2.1 guide covers these patterns.

Google sign-in is the other half. Google's OAuth policy forbids sign-in inside "an embedded user-agent under the developer's control", and native routes such as ASWebAuthenticationSession return the result to app code rather than to Glide's session. So remove Google sign-in from the iOS app – and keep it removed. In the 2024 thread, the maker summarized the reviewer's advice as adding Apple login or hiding the Google login "till the app gets approved". Hiding it is a valid fix; bringing it back after approval turns a 4.8 fix into a 5.6 problem. A later reply suggested switching sign-in off so testers can "open the main app without logging in" – the same trap. More in Guideline 4.8 for WebView apps.

Row owners, roles and visibility conditions: hidden by design

Glide is built to show each person their own slice of data. Row owners keep rows off the devices of people who don't own them, a role column groups users, and visibility conditions decide which tabs, components and actions appear. For an operations app that's exactly right. For a reviewer whose email appears in no row and no role, it produces a near-empty app next to a store description that promises dashboards and reports.

Add review users to your users table with roles real people have – one review email per role.
Give them data: realistic rows owned by each review email, such as jobs, orders or inspections. Empty states demonstrate nothing.
Walk every tab as each review user and note what appears; that list becomes your screen map for App Review.
Look for surprising conditions, such as components that only appear for a plan value or a flag column. If a real user can meet the condition, explain how; if nobody can yet, the feature doesn't belong in this version.
Disclose staff-only screens in the review notes and add an admin review login, so nothing is invisible but present.

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

When a spreadsheet edit turns into an app update

In Glide, data does more than fill lists. Menus can come from a table, a "features" sheet can hold switches and a column can drive a visibility condition. Change a cell and every user's app changes – no build, no review. Builder edits reach users the same way, and in GlideOS an agent that "works with full-stack application code" can add a screen from a prompt.

That speed is what Apple watches. Guideline 2.3.1 asks for new features to be "described with specificity in the Notes for Review", and Apple says its systems flag "potentially problematic changes in app updates" (Apple Newsroom, May 2026).

Fine without a new app build	Ship with a new build and review notes
New rows of the same kind (products, tasks, locations), corrected text, new images, small layout fixes	New tabs or screens, new actions and workflows, a role with its own screens, payments, newly collected personal data

A rule for teams: feature switches don't belong in a sheet that half the company can edit. Keep them in the builder, keep a short changelog and freeze new functionality while a build is in review.

Make the wrapped Glide app clearly more than a browser tab

Glide apps already feel app-like in a browser, which works against you in review: if the wrapper adds nothing, the reviewer compares it with Safari. WebViewGold, which our team builds, puts your Glide URL into an Xcode project with native modules that suit the business apps Glide is made for:

QR and barcode scanning for stock counts, asset check-out or event check-in.
NFC tag reading for equipment and inspection points.
Push via OneSignal or Firebase when a task is assigned or a status changes.
A native offline screen instead of a blank view at a site without signal.
Universal links for the magic link in PIN emails – impossible on a glide.page address, and on a custom domain only if you can serve the apple-app-site-association file there.

No tool can promise an approval, and WebViewGold can't seed your rows or fix your roles. It removes the "website in a frame" argument, so the conversation with App Review is about your features. If you built with GlideOS, also test sign-in on a device: its redirect step must stay inside the app.

Writing the reply: a screen map instead of a defense

Arguing that you hid nothing rarely moves a 5.6 case; showing how to reach everything does. In Reply to App Review (App Store Connect, up to 4,000 characters, attachments allowed), include:

sign-in steps, including where the PIN arrives;
one line per role with its email, its data and its tabs;
a screen map – every tab, what it does, how to test it;
what changed in this build, such as "Google sign-in removed from the app";
a polite request to name the screen that caused concern.

Don't open a second developer account, don't resubmit unchanged and don't appeal before you've answered Apple's questions – the App Review Board takes one appeal per rejected submission. A 30-minute App Review appointment via Meet with Apple often clears up a misunderstanding faster.

If the app is meant only for your team or one client, the public App Store may be the wrong venue anyway: unlisted and custom distribution are covered in converting Glide to an iOS app, and the Android guide covers Google Play. appsubmitter.io checks the build, writes the review notes and the reply and resubmits in your own account – start with a free call or book the iOS service. The bigger picture for no-code and AI-built apps is in our 5.6 pillar article.

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]). We understand that parts of the app were not reachable during review. Every feature is now accessible, and nothing changes after review.

How to sign in (the app sends a one-time PIN by email):
1. Open the app and enter [review email].
2. Open the review mailbox at [webmail URL] with [mailbox login] / [mailbox password]. No extra verification is required.
3. Enter the PIN from the newest email in the app.

Roles and sample data:
- [Role 1]: [email] – [what data it holds]
- [Role 2]: [email] – [what data it holds]

Changes in this build:
- [Sign in with Google is no longer offered in the app.]
- [Feature switches moved out of the shared spreadsheet; no feature is enabled after review.]

Screen map:
- [Tab 1]: [what it does] – [how to test]
- [Tab 2]: [what it does] – [how to test]

A screen recording per role is attached. If a specific screen raised the concern, we would be grateful for a pointer.

Best regards,
[Your name], [Company]

Checklist before you resubmit

App Review Information contains numbered PIN steps and a review mailbox that opens without 2-step verification.
Each role has a review email in the users table that owns realistic rows.
You walked every tab as each review user and turned the result into a screen map.
Sign in with Google is off for the app permanently, not just during review.
Sign-in stays switched on – the reviewed app has the same login your users get.
No sheet column or table can switch on tabs, actions or payments without a new build.
GlideOS sign-in redirects stay inside the app on a real device.
Native features such as scanning, NFC, push or an offline screen serve the main tasks.

Frequently asked questions

Glide app rejected under Guideline 5.6 – what did Apple think I hid?

Usually something it couldn't reach. If the reviewer can't get past an emailed PIN, every tab behind it counts as unreviewed; if row owners and visibility conditions leave a fresh account with empty screens, the app looks thinner than its description. Spreadsheet edits after approval add the third pattern: features that appear without review.

How do I give App Review a demo account for a Glide app with PIN sign-in?

Create a review user with a realistic role and data, plus a mailbox for that address that opens in webmail with a password and no extra verification. Enter the app email, webmail address, password and numbered steps under App Review Information, then test the whole flow from outside your own network.

Can I switch off sign-in or hide Google login just for the review?

No. An app that skips the login during review and asks for one afterwards is a different app from the one Apple approved – the core pattern Guideline 5.6 describes. Removing Google sign-in from the iOS app is a legitimate fix for Guideline 4.8, as long as it stays removed after approval.

Does Glide help with App Store rejections?

No. Glide says its apps are PWAs, that publishing directly to the App Store or Google Play is not supported and that it does not endorse or support wrapping them. Makers who do it act at their own risk, without troubleshooting from Glide, so the review is between you and Apple. If you'd rather not handle it alone, appsubmitter.io prepares the review notes, replies to App Review and resubmits in your account.

Can I keep editing my Google Sheet after the app is approved?

Yes, for content: new rows, corrected text and updated images are what a data-driven app is for. Anything that adds screens, actions, payments or data collection should come with a new build and a specific description in the Notes for Review, so the approved app stays the app your users get.

Is WebViewGold enough to get a Glide app approved?

No tool can promise an approval. WebViewGold, made by our team, gives a Glide app native scanning, NFC, push, an offline screen and universal links, so it no longer looks like a browser tab. Reviewer access, roles and sheet-driven switches are still yours to fix.

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.

Glide App Rejected Under Guideline 5.6: PIN Logins, Visibility Conditions and How to Recover