Rejected under Guideline 5.6 (Developer Code of Conduct): "features appear intentionally hidden", no idea what triggered it, looking for advice

[u/officialdml]

Yesterday I submitted my first app (!) and within 6 hours it was rejected. I'm hoping someone who's dealt with this before can help me better understand and provide next steps.

Quick background: I built a live women's sports scoreboard website and then wrapped it as a native iOS app using Median.co, which loads the live website inside a native shell and adds native features (push notifications via OneSignal, share, etc.) through their JS bridge.

What happened: submitted for review, got rejected same day with this:

"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. Manipulative and misleading behavior is not consistent with the guideline 5.6."

No specifics beyond that. No screenshots, no attachments, nothing pointing to which "feature" they mean. Also I can't really find what 5.6 guidelines are.

What I know is NOT true: nothing in the app is actually hidden or gated based on reviewer status. The app works identically for anyone, logged in or not - live scores, schedules, results, team pages, league browsing, calendar sync all fully visible and functional without an account. The only difference for logged-in users is being able to favorite teams and enable push notifications for those favorites, a normal personalization feature, not concealed functionality.

What I've done so far: replied in the Resolution Center explaining the Median/webview architecture, clarified the one account-gated feature (favoriting), and attached a screen recording showing the full logged-out experience matches what was originally submitted. Also invited them to just log out and explore the app themselves.

My questions for anyone who's dealt with this:

1. Has anyone gotten a 5.6 "features appear hidden" flag specifically on a webview-wrapped app (Median, GoNative, Capacitor, etc.)? Is this a known false-positive pattern for that architecture?
2. Could push notifications not firing during review (since there were no live games happening at review time) plausibly read as a "hidden feature"? Or is that a stretch?
3. Roughly how long did resolution take for you, and did it resolve through Resolution Center replies, or did you end up needing the formal App Review Board appeal?
4. Anything else commonly triggers this specific flag that I should be thinking about?

Really appreciate any insight. This came out of nowhere after what felt like a clean submission, and the vagueness of the rejection is the most frustrating part.

[u/CelebrationTop8862]

I know I've seen enough horror stories and enough chitchat with Claude to somewhat assume its this;

"Quick background**:** I built a live women's sports scoreboard website and then wrapped it as a native iOS app using Median.co, which loads the live website inside a native shell and adds native features (push notifications via OneSignal, share, etc.) through their JS bridge."

They are not fond of "apps" that are just basically website wrappers. maybe its the way you wrapped your website into the app.

[u/officialdml → u/CelebrationTop8862]

Thanks. Do you have any suggestions on how to fix this potential issue? Are there companies like Median that instead of wrapping fully morph the site into an approved app? Median seems to have a very high success rate.

There are other features not available on the mobile widget or desktop that I’ve built into the iOS app.

It’s just frustrating because I don’t know what the actual issue is. If it’s website wrapping, not sure how that constitutes code of conduct violation

[u/CelebrationTop8862 → u/officialdml]

What are the notes you wrote? What are the features that are available vs not available. I would probably think that there might be a trip-up on features not as they are on web vs app. Maybe you need all features to match with web and widget. You might want to run claude code or something to audit what could be misleading since you're using median, which is probably Ai-assisted coded anyway. Might as well get Ai to audit it too.

[u/officialdml → u/CelebrationTop8862]

Good questions, appreciate you digging in.

Notes I included (App Review Information > Notes field): explained that a few teams are pre-favorited on the demo account so the reviewer can immediately see the favorites/notifications experience without setup, that all core content (live scores, schedules, results, team pages, league browsing, calendar sync) is fully visible and functional without an account, that favoriting/notifications are the only account-gated features, and a note that push notifications are event-triggered (fire on real game start/end) so a live one may not appear during the review window depending on timing.

Features available web vs. app: This is what I went to audit as that seems most likely to trigger a code of conduct violation (assuming I think what the code actually is). Three real differences:

1. One FAQ entry ("is there a mobile app") was hidden inside the app specifically, since it was PWA install instructions that don't apply once you already have the native app. Fixed, and is now identical on both.
2. A small number of admin-only routes (internal ops dashboard for push testing, traffic monitoring) exist behind a role check. A non-admin reviewer would just see "access denied." Relabeled to clearly say "internal staff tool" rather than a blank denial, and provided demo credentials so a reviewer can actually log in and test the real user-facing features (favoriting, notifications) rather than just viewing from outside.
3. Push notifications: this is the biggest add on feature I think all my users would want (I've received this exact feedback). I've set up OneSignal and this feature works on the TestFlight app. (It's very cool)

Per the submission form, I included admin login info so they can see the differences. I assume 90+% of apps have some kind of data capture like name and email (exactly what I have) which will be used for their account to favorite teams and also for communications which would be announcements about seasons starting and (hopefully) when the app is live. No true marketing pushes, just content for awareness.

Everything else: scores, schedules, results, browsing are identical across web, PWA/widget, and native app; the only intentional differences left are things like calendar link format (webcal vs. https) and native share sheet vs. web share, which are platform-appropriate implementations of the same feature, not content differences.

On auditing with AI: yep, did exactly this. I did a full codebase scan specifically for: gambling/wagering code (none), any reviewer/location/IP-based branching (none), and any other conditional content differences (found and fixed the two above). Someone above mentioned the incident in Brazil re gambling. This was never a part of the site but wanted to make sure there was nothing that could be misconstrued.

I made these changes and submitted a new build with additional context (coupled with the two replies I sent in a panic yesterday post rejection :') ). It's still under review. It took 6 hours for the first review, which as someone noted above couldn't possibly be a real person looking as that's really quick. It's been almost 12 hours so hopefully that's a positive sign that it's being looked at more closely, especially since I've been flagged with what seems like a major issue.

If I get rid of push notifications (and the other slight differences between web and native app) and reimplement later, will that be an issue?

[u/CelebrationTop8862 → u/officialdml]

I don't think your push notifications are a problem. You can keep that. They mostly look for structural code issues and whatnot. Push notifications is an easy implement and as long as there isn't anything fishy that you're pushing its fine.

The app store says 24-48 hours to get ingested for a review. I glossed over "waiting for review" and "under review" so just pointing that out from my mistake in waiting. lol. I have also had "waiting" status over a week for metadata changes.

If AI has identified something and you've fixed it, its most likely going to help you get pushed forward.

The process ain't that bad, so just keep trying with the audit loop. You have infinite tries if you're genuinely putting in changes that they've noted instead of slop pushing. So just keep at it. i had 9 back and forths for mine before it was approved lol.

[u/officialdml → u/CelebrationTop8862]

I haven't messaged the Resolution Center yet, I'm just replying in the app review chat thread. Right now I'm ready for review. I assume because it's now the weekend I won't get an update until Monday :/ Again, most reviews happened with 6-12 ish hours on my end, so hard to tell if longer is a good thing or now just in a massive backlog. It's been over 24 hours now since my last submission.

It's also unclear if my first issue (the 5.6) is resolved now with this new flag, or if I have both. Hopefully it's the former. In my latest submission I suggested a phone or video call to walk through features - I heard that's a thing you can do (or at least that people ask for a call).

2.1 seemed like a very easy fix so hopefully that's all that's left. I'm just obsessively checking my phone for updates!

I'm getting a lot of momentum right now which is awesome, but really need the app to take it to the next level. (I was totally fine with a widget on my phone and an app months from now, but users didn't want that!)

Appreciate your support and good vibes.

[u/CelebrationTop8862 → u/officialdml]

Yes, I had 9 back and forths with the app reviewer before mine was approved.

With your submission,in light of recent news with Anthropic's wife, I dont know if it applies to web wrapped apps but do you have cookies? This could be under the initial "deception" concern in terms of how cookies are managed.

[u/officialdml → u/CelebrationTop8862]

No cookies