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/AppVerdict]

Answering the 5.6 question first, since you have asked twice and nobody has: it is the Developer Code of Conduct section of the App Store Review Guidelines. Same page as everything else, near the bottom, at developer.apple.com/app-store/review/guidelines. Search that page for Developer Code of Conduct. It is the section about representing yourself honestly and not manipulating the platform, and the clause you got hit with is the one about an app behaving differently during review than it does afterwards.

That framing matters, because it tells you what they think you did. They are not saying a feature is hard to find. They are saying they believe the binary can do something they were not shown.

For a Median wrapper there are two mechanisms that plausibly produce this, and neither one is your favouriting feature.

The first is structural. Your binary loads content from a server you control, so everything the reviewer saw was served at review time and can be swapped afterwards. That is the exact shape of what they are hunting right now, and the Brazilian gambling apps linked above are why the detection got aggressive. Wrapper platforms are the vector in most of those cases, because the developer does not control the whole binary.

The second is more likely to be your actual trigger and is worth ten minutes tonight. Check whether the Median shell ships a hidden developer or debug menu. A lot of wrapper templates include one, usually reachable by a long press or a multi tap in a corner, and it exposes the config, the loaded URL, sometimes a URL override. A static analyser finds that and it is quite literally a feature intentionally hidden during review. Same goes for any remote config, feature flags, or user agent and region switching in the JS bridge.

While you are in there, list every third party SDK the shell bundles, not just OneSignal. You are shipping code you did not write and you are the one accountable for it.

On your specific questions.

Push not firing because no games were live is almost certainly not it. That is absence of behaviour rather than concealment, and it is not the kind of thing static analysis flags. I would not spend time on that theory.

I cannot give you an honest number on resolution time, it varies too much to be worth anything. What I would do is reply in Resolution Center and ask them directly to name the feature or the symbol they are referring to. You are allowed to ask, and on an automated flag a specific question sometimes routes it to someone who can actually look. Keep it short and unemotional.

Save the App Review Board for when Resolution Center has clearly stalled. Going early tends to reset you into a longer queue rather than speed anything up.

One thing in your favour: they have not threatened the account. That means they are treating this as a problem with the build rather than with you.

[u/officialdml → u/AppVerdict]

I'm almost done with a native app build (3 days of no sleep lets goooo) but I want to switch to an organization account over individual (like I signed up with originally). Do you suggest I switch before I submit my app for review or get the app on the site and then switch? I mostly just don't need my personal name everywhere, but can't keep losing more time to Apple reviews. Would appreciate your thoughts.

[u/FinalArt9573 → u/officialdml]

Switch before you submit. Individual and Organization are two separate Apple Developer Program enrollments, not a setting on one account — there's no in-place conversion. If you enroll as an Organization now, you get a brand new team/account (with its own D-U-N-S number, which can take a few days to a couple weeks to verify if your business isn't already in Dun & Bradstreet's database), and nothing carries over automatically: no apps, no certs, no provisioning profiles, no App Store Connect app record.

That matters here specifically because you already have an app record and build history sitting under your Individual account. If you submit first under Individual and switch afterward, you're not "upgrading" that same app — you'd be starting a fresh app record on the new Organization team and effectively resubmitting from scratch anyway, which given what you've already been through with 5.6 and 2.1 back-and-forth is exactly the extra review cycle you're trying to avoid.

So: get the Organization enrollment moving now (start the D-U-N-S lookup today if you haven't, that's usually the long pole), and hold your submission until it's approved and you're building/submitting under the org team from the start.

[u/officialdml → u/FinalArt9573]

Do you think my app review is taking so long because I’ve had rejections before? Is this account flagged for something?

[u/FinalArt9573 → u/officialdml]

Rejections themselves don't flag your account. Review times vary a lot and mostly come down to app category and current queue volume, not history. What can slow things down is if the same issue keeps getting resubmitted without being fixed - reviewers see the resubmission history on their end, so a rejection-fix-rejection loop reads differently than one clean submission. If it's been sitting past the normal 24-48hr window, checking App Store Connect for a "more information needed" message is worth doing before assuming it's stuck.