App Store QR Code Generator

Generate a QR code linking directly to your app on the App Store or Google Play. Boost installs with a scannable download link.

One code, two app stores: the actual problem

You have an app on both the App Store and Google Play. You have one physical poster. A QR code encodes exactly one URL. Someone has to work out which store the scanner should be sent to, and there are only two places that can happen: on your server, or in the user's hands.

Server-side detection is the standard solution. The code points at a short URL on your domain; that endpoint reads the User-Agent header, sees iPhone or Android, and issues a 302 redirect to the correct store listing.

GET /get  →  iOS      → https://apps.apple.com/app/id123456789
          →  Android  → https://play.google.com/store/apps/details?id=com.example.app
          →  other    → your landing page with both badges

The third branch matters more than people expect. Desktop scanners, tablets, and unrecognised user agents all need somewhere sensible to land — a page with both store badges and a short description works, and it also catches anyone who scanned out of curiosity rather than intent.

A landing page with two buttons is the alternative. It costs the user a tap and gains you the ability to explain what the app is before asking them to install it. For an unfamiliar brand this often converts better than dropping a stranger straight onto a store page.

Store URL formats

Apple App Store. The canonical form is:

https://apps.apple.com/app/id123456789

The app ID alone is sufficient — the name slug in longer URLs is decorative and can be dropped. A country code (/gb/, /us/) restricts the listing to that storefront; omitting it lets Apple route the user to their own country's store, which is what you want on international material.

Google Play. The package name is the identifier:

https://play.google.com/store/apps/details?id=com.example.app

There is no shorter canonical form. The ?id= query string forces byte-mode QR encoding, and the package name is often 25 characters or more, so Play URLs produce noticeably denser codes than App Store ones. This alone is a decent argument for routing through a short URL on your own domain.

What happens after the install

The default outcome is poor: the user installs, opens the app, and lands on a generic home screen with no memory of the poster they scanned. If your code was on a specific product, offer or event, that context is gone.

Universal Links (iOS) and App Links (Android) solve this for users who already have the app. A single https:// URL opens the app directly at the right screen if it is installed, and falls back to the web page if it is not. This requires hosting an association file on your domain — apple-app-site-association for iOS, assetlinks.json for Android — and configuring the app to claim those paths. It is a development task, not a marketing one, but it is the correct foundation.

Deferred deep linking handles the harder case: user does not have the app, installs it, and should still land on the right screen on first open. This needs a third-party attribution service, because neither store passes install context through by default. Worth it if you run campaigns at scale; overkill for a single poster.

Attribution: knowing which poster worked

Both stores support campaign parameters, and they are the only reliable way to tell which placement drove installs.

Google Play accepts a referrer parameter that the Play Install Referrer API surfaces to your app on first launch:

...details?id=com.example.app&referrer=utm_source%3Dposter%26utm_campaign%3Dspring

Note the double encoding — the referrer value is itself a query string, so its = and & must be percent-encoded as %3D and %26. Getting this wrong silently truncates the value.

Apple provides campaign attribution through App Analytics using ct (campaign token) and pt (provider token) parameters, visible in App Store Connect.

Both add substantial length to the URL. Put them on the far side of your own redirect rather than in the QR code itself — the code stays small, and the parameters are added server-side where you can change them without reprinting.

Smart App Banners are the better tool on the web

If you are reaching for a QR code to promote an app on your own website, you probably want a Smart App Banner instead. A single meta tag in your page head shows an Apple-styled banner offering the app, with no design work:

<meta name="apple-itunes-app" content="app-id=123456789">

Android's equivalent is the native app install prompt via a Web App Manifest, or a <link rel="alternate"> App Link declaration.

QR codes earn their place off the screen — posters, packaging, receipts, table cards, vehicle livery, event signage. Putting a QR code on a web page that the user is already viewing on their phone asks them to scan their own screen, which does not work.

Making people actually want to install

A QR code leading to a store listing asks for a bigger commitment than any other code type. Downloading an app costs storage, time, an account, and usually some permissions. "Scan to download our app" answers none of that.

What works better is naming the benefit and the cost:

Consider whether the app is even the right destination. If the task is "look at the menu" or "check the timetable," a web page does it with no install at all, and pushing an app instead costs you most of the audience.

Before the poster goes to print

  1. Scan on an iPhone and confirm you land on the App Store listing, not a web page.
  2. Scan on an Android device and confirm the Play listing opens in the Play app.
  3. Scan on a desktop webcam or a tablet and confirm the fallback page is sensible.
  4. Test from a different country if you sell internationally — a hard-coded storefront will show "not available in your region."
  5. If you use referrer parameters, install from the code and confirm the value arrives in your analytics rather than silently truncating.
  6. Print at the right size for the viewing distance — poster codes read from 2 metres need to be around 20 cm across.

Frequently asked questions

Can one QR code work for both the App Store and Google Play?

Not directly — a code encodes one URL. Point it at a short URL on your own domain that detects the operating system and redirects accordingly, with a two-badge landing page as the fallback for desktop and unrecognised devices.

What is the shortest App Store URL?

https://apps.apple.com/app/id123456789 — the app ID is all that is required and the name slug can be dropped. Leave out the country code so Apple routes users to their own storefront.

Why is my Google Play code denser than my App Store one?

Play URLs use a query string (?id=com.example.app) which forces byte-mode encoding, and package names are usually long. Routing both through a short URL on your own domain evens this out and keeps the code coarse.

Can the app open at a specific screen after install?

For users who already have the app, yes — Universal Links on iOS and App Links on Android do this with a single https URL, given the right association files on your domain. For users installing fresh, you need a deferred deep linking service, since neither store passes context through by default.

How do I track which poster drove installs?

Google Play supports a referrer parameter surfaced by the Install Referrer API; Apple uses campaign tokens visible in App Store Connect. Add these on the far side of your own redirect rather than in the QR code, so the code stays small and the parameters stay editable.

Should I use a QR code on my own website?

No. A visitor already on their phone cannot scan their own screen. Use a Smart App Banner on iOS and a native install prompt on Android. QR codes belong on printed and physical material.

What if the app is not available in someone's country?

They will see a "not available in your region" message. Avoid hard-coding a country code in the store URL, and if you have limited availability, say so on the printed material rather than letting people discover it at the store page.