A common frustration: a user scans the QR code you shared in a WeChat group, or taps a download link in an official-account article, and the app will not install — the page goes blank, the download does nothing, or a blocking notice appears. Your package is not broken; the "in-app browser" inside WeChat, QQ, and Alipay deliberately blocks external downloads and store redirects. Here is why, and how to fix it.

Why in-app browsers block downloads

The WebViews inside WeChat, QQ, and Alipay, for security and ecosystem reasons, block by default: jumps to other app stores, downloading .apk files, triggering iOS's itms-services:// install protocol, and invoking the system browser. The result: your install page works perfectly in a normal browser but "fails" inside these environments.

Step 1: detect whether you are in an in-app browser

The method is to read the User-Agent on the front end and match its signatures:

  • WeChat: UA contains MicroMessenger.
  • QQ: UA contains QQ/ (note the distinction from MQQBrowser, which is the QQ Browser app and does not block).
  • Alipay: UA contains AlipayClient or Alipay.

If any matches, enter the "guide to system browser" flow instead of attempting a direct download.

Step 2: guide the user out of the in-app browser

The most universal fix is an overlay prompting the user to "tap the top-right ··· menu and choose 'Open in browser'," with an arrow icon pointing to the top-right corner. Once the page opens in the system browser, downloads, installs, and store redirects all work normally. This is currently the most compatible and reliable approach.

Do not try to fight the platforms' blocking rules — that is a cat-and-mouse game you will lose. Smoothly guiding users to the system browser is the steady solution.

Advanced: smoother paths inside WeChat

  • Configure a business domain: add your download-page domain to the "business domain" allowlist in the WeChat Official Account platform (requires a verification file) to reduce some blocking.
  • Use a Mini Program as an intermediary: point the QR code at a WeChat Mini Program that uses a web-view or guide button to jump out. Higher dev cost, but smoother within the WeChat ecosystem.
  • Copy-link fallback: offer a "copy link" button so users can paste it into the system browser.

Extra iOS note: Universal Links

On iOS, in-app browsers also frequently block universal links. If your install flow depends on them, expect them to fail inside WeChat/QQ and provide an "open in Safari" fallback.

What good guidance looks like

  • Detect on page entry; if matched, show the overlay immediately so users do not waste time wondering why nothing happens.
  • Keep copy short and specific; the icon points to the accurate menu location (the top-right menu differs slightly across apps).
  • Offer "copy link" as a backup exit.
  • When an external browser is detected, do not show the overlay — go straight to the normal download or install flow.

Conclusion

In-app browsers blocking downloads is an unavoidable hurdle for app distribution in the Chinese market. The right fix is not to fight the platform rules but to: accurately detect the environment via User-Agent, guide users to the system browser in restricted environments, and install directly in normal ones. A mature download page implements this logic end to end so users coming from WeChat and QQ can still install your app smoothly.