How you hand the download link to users looks like a small decision. It isn't. My preference is blunt: I've basically stopped using raw download URLs — if a short link plus a landing page is an option, I take it.
The problems with a raw link (just throwing the .apk or .plist download URL out there) are immediate: every time you swap the package, the link has to change, and every entry you'd scattered across QR codes, posters, and chat logs is now dead. You don't know who downloaded, where they came from, or whether the install succeeded. A single link can't route iOS / Android / HarmonyOS users to the right package. And once a raw link lands inside an in-app browser like WeChat or QQ, it often gets blocked outright — the user just sees a blank screen.
A short link plus a landing page solves all of this at once. One stable short-link entry (say /d/xxx) fronts a landing page: the backend reads the User-Agent, routes iOS users to the right install path, serves the APK to Android, and splits by architecture when needed. Swap the package behind the scenes and the short link stays the same. Every visit and every install becomes data you can read. And the landing page can spell out "blocked by WeChat? here's what to do" right where the drop-off would otherwise happen.
I know some people feel the landing page is an unnecessary detour — the raw link is the simplest thing, after all. But the pain of distribution is never in the first release. It's in the third, the tenth, when you're swapping packages, debugging, and trying to count installs. That extra layer buys you swappability, analytics, routing, and a fallback — and together those are worth far more than skipping one redirect.
So if you're still on the fence, the advice is simple: unless you're shipping once and walking away, start with a short link and a landing page from day one. Don't wait until raw links are scattered everywhere to clean it up.