When building an app, it is very easy to put everything into one big backend. At the beginning this feels simple. One server, one API, one place for all logic. But after a while, the backend starts doing things it was never really meant to do. Redirects, small integrations, tracking, webhook handling, feedback forms and other tiny helper tasks all end up in the same system.

For Swiva, we decided to keep some of these tasks out of our main backend and move them closer to the user, to the edge. In our case, this means using Cloudflare Workers. A Worker is a small serverless function that runs on Cloudflare’s global network, close to the user. It can handle a request, run a bit of JavaScript or TypeScript and return a response without needing our main backend at all.

That makes Workers a good fit for small features that need to be fast, but do not need a full backend route, database connection or heavy infrastructure.

The problem with app store redirects

A simple example is our app download link. When someone scans a QR code on a poster, sticker or social media post, they should end up in the right place. iPhone users should go to the Apple App Store, Android users should go to Google Play and desktop users should go to our website.

The normal solution would be to send everyone to a page on our website. The page loads, JavaScript runs in the browser, checks the device and then redirects the user. That works, but it is not ideal. The user may see a blank page or a short loading screen before the store opens. For an app download link, every small delay matters.

A smart redirect at the edge

Instead of loading a full page, we use a Cloudflare Worker. The Worker runs before the request even reaches our main server. It checks the user agent from the HTTP request, decides if the user is on iOS, Android or desktop and immediately returns a 302 redirect. So the QR code does not point to a heavy website. It points to a tiny edge function.

A simplified version can look like this:

export default {
  async fetch(request, env, ctx) {
    const userAgent = request.headers.get("user-agent") || "";

    const isIOS = /iPhone|iPad|iPod/i.test(userAgent);
    const isAndroid = /Android/i.test(userAgent);

    const targets = {
      ios: "https://apps.apple.com/at/app/swiva/id6769160022",
      android: "https://play.google.com/store/apps/details?id=app.swiva",
      desktop: "https://swiva.app",
      fallback: "https://swiva.app",
    };

    let platform = "fallback";

    if (isIOS) {
      platform = "ios";
    } else if (isAndroid) {
      platform = "android";
    } else {
      platform = "desktop";
    }

    return Response.redirect(targets[platform], 302);
  },
};

This is not a huge feature. But it solves a real problem in a very clean way.

Tracking without a heavy analytics script

We also want to know where our downloads come from. A QR code on a poster, a link in a story and a link on a website should not all look the same. Instead of loading a full analytics script, the Worker can read a source parameter from the URL, add UTM parameters to the final link and count the redirect in Cloudflare KV. The important part is that this should not slow down the redirect. For that, we use ctx.waitUntil().

const source =
  url.searchParams.get("src") ||
  url.searchParams.get("source") ||
  "direct";

targetUrl.searchParams.set("utm_source", source);
targetUrl.searchParams.set("utm_medium", "smart_redirect");
targetUrl.searchParams.set("utm_campaign", "app_download");

if (env.DOWNLOAD_LINK_REDIRECT_STATS) {
  const today = new Date().toISOString().split("T")[0];
  const key = `${today}:${source}:${platform}`;

  ctx.waitUntil(
    (async () => {
      const currentCount =
        (await env.DOWNLOAD_LINK_REDIRECT_STATS.get(key)) || "0";

      await env.DOWNLOAD_LINK_REDIRECT_STATS.put(
        key,
        (parseInt(currentCount) + 1).toString()
      );
    })()
  );
}

The redirect is sent back immediately. The statistic update happens in the background. That is exactly the kind of small task where edge functions feel perfect.

Why this works well for Swiva

This setup works well because each Cloudflare product has a clear job. Our marketing website runs on Cloudflare Pages, which is made for hosting static websites and frontend projects. This is enough for a lightweight app landing page like swiva.app and keeps the website separate from the redirect logic.

The redirect itself runs as a Cloudflare Worker, because it needs to be fast and should happen before a full website loads. For simple tracking, we use Cloudflare KV. KV is a key value store, so we can save small pieces of data with a key, for example how often a specific QR code source was used on a specific day.

This gives us lightweight redirect tracking without setting up a full database or adding a big analytics tool. For this kind of use case, the free limits are more than enough. Cloudflare Workers currently include 100,000 requests per day on the Free plan, which is a lot for a smart redirect service.

Try it yourself

You can test the redirect yourself using this link or by scanning the QR code.

If you scan it with an iPhone, it should open the Apple App Store. If you scan it with an Android device, it should open Google Play. If you click the same link on a desktop device, it should redirect you to the Swiva landing page.

That is the nice part about this setup: one QR code can work for every platform, without loading a full website first.

Open the Swiva smart redirect