Title: Guideline 5.6 and disclosed network fallback routing — how strict is "no concealment"?
We received a 5.6 rejection ("features that appear to have been intentionally hidden during review") for a VPN app. After investigation, we identified that some of our servers used SNI-based domain fronting (TLS handshake to a Google hostname, real destination in the HTTP Host header) as their primary connection method in regions where our own infrastructure is blocked at the network level.
We disclosed this fully in App Review Information before resubmitting: what it is, why it exists, and that we removed it from all servers. We received the same 5.6 wording again on the next submission.
Questions for anyone who has navigated this:
- Does prior undisclosed use of a technique like this permanently
flag the app/account for stricter automated review, even after the technique is removed and disclosed?
- Is domain fronting for VPN tunnel traffic (not just API calls)
treated as inherently disqualifying under 5.6, regardless of disclosure — i.e. is there no version of "explain it" that satisfies this, only "remove it entirely"?
- For apps serving regions with network-level blocking of VPN
protocols, is there a legitimate, App Store-safe way to maintain connectivity without triggering 5.6 — e.g. is Reality-protocol-style obfuscation treated differently from SNI fronting to a real third-party domain like Google's?
Any pointers to relevant guideline clarifications or past resolved cases would help. Thanks.