Windows Code Signing — The EV Certificate and SmartScreen Wall

On Windows, Microsoft Defender SmartScreen will loudly warn users about any unsigned installer. Even with a regular OV certificate, you'll see the warning until SmartScreen builds reputation — which can take weeks. An EV (Extended Validation) certificate establishes reputation immediately, but they cost ¥40,000–100,000 per year. My approach is to ship initially with an OV cert, build reputation, and upgrade to EV only if user warnings are actually hurting conversion.

EV certificates live on a USB token or HSM, which makes CI signing tricky. The cleanest solution is Azure Key Vault's Code Signing service — your CI calls a signing API instead of needing physical access to a token. The PowerShell script looks like this:

# sign.ps1 - Windows EV signing via Azure Key Vault
$ErrorActionPreference = "Stop"
 
$ExePath  = "src-tauri\target\release\bundle\nsis\MyApp_1.0.0_x64-setup.exe"
$VaultUri = $env:AZURE_KEY_VAULT_URI
$CertName = $env:AZURE_KEY_VAULT_CERT_NAME
 
# Auto-install AzureSignTool if missing
if (-not (Get-Command AzureSignTool -ErrorAction SilentlyContinue)) {
    dotnet tool install --global AzureSignTool
}
 
try {
    AzureSignTool sign `
      -kvu $VaultUri `
      -kvi $env:AZURE_CLIENT_ID `
      -kvs $env:AZURE_CLIENT_SECRET `
      -kvt $env:AZURE_TENANT_ID `
      -kvc $CertName `
      -tr "http://timestamp.digicert.com" `
      -td sha256 `
      -fd sha256 `
      $ExePath
 
    # Verify the signature actually applied
    $sig = Get-AuthenticodeSignature $ExePath
    if ($sig.Status -ne "Valid") {
        throw "Signature invalid: $($sig.Status) — $($sig.StatusMessage)"
    }
    Write-Host "✅ Signed: $($sig.SignerCertificate.Subject)"
}
catch {
    Write-Error "❌ Signing failed: $_"
    exit 1
}

When Antigravity drafts this script for you, insist on parameterizing the timestamp server URL and configuring two fallback servers. DigiCert's timestamp server has gone down once or twice a month in my experience. Add http://timestamp.sectigo.com and http://timestamp.globalsign.com/tsa/r6advanced1 as fallbacks, and your build failures from this cause drop to nearly zero across a year.

A Self-Hosted Update Server on Cloudflare Workers + R2

Tauri 2's tauri-plugin-updater reads a JSON manifest, compares versions, and downloads the new binary. You could host the manifest on GitHub Releases — many tutorials suggest this — but I push back. Cloudflare Workers + R2 wins on three points:

First, staged rollout (10% → 50% → 100%) is trivial Worker logic. Second, future requirements like region-specific distribution or A/B-tested updates slot in cleanly. Third, R2 has zero egress fees, so your binary distribution costs are essentially the storage bill.

Here's the minimal Worker. When delegating this to Antigravity, I always specify "rollout percentage lives in KV, SHA256 hashes come from R2 metadata" — that constraint produces code that's resilient to operational changes:

// src/index.ts - Tauri 2 update manifest endpoint
interface Env {
  UPDATES_KV: KVNamespace;
  UPDATES_R2: R2Bucket;
  UPDATE_SIGNATURE_PUBLIC_KEY: string;
}
 
interface UpdateMeta {
  version: string;
  notes: string;
  pub_date: string;
  rollout: number; // 0-100
  platforms: Record<string, { url: string; signature: string }>;
}
 
export default {
  async fetch(req: Request, env: Env): Promise<Response> {
    const url = new URL(req.url);
    const match = url.pathname.match(/^\/api\/update\/([^/]+)\/([^/]+)$/);
    if (!match) return new Response("Not Found", { status: 404 });
 
    const [, platform, currentVersion] = match;
    const userBucket = hashToBucket(req.headers.get("x-client-id") ?? crypto.randomUUID());
 
    try {
      const metaJson = await env.UPDATES_KV.get("latest_meta", "json") as UpdateMeta | null;
      if (!metaJson) return new Response("No update available", { status: 204 });
 
      // Staged rollout gate
      if (userBucket > metaJson.rollout) {
        return new Response("Not eligible for rollout", { status: 204 });
      }
 
      // Skip if client is already up to date
      if (compareSemver(currentVersion, metaJson.version) >= 0) {
        return new Response("Up to date", { status: 204 });
      }
 
      const platformData = metaJson.platforms[platform];
      if (!platformData) {
        return new Response(`Unsupported platform: ${platform}`, { status: 400 });
      }
 
      // Tauri Updater's expected response shape
      return Response.json({
        version: metaJson.version,
        notes: metaJson.notes,
        pub_date: metaJson.pub_date,
        platforms: { [platform]: platformData },
      });
    } catch (err) {
      console.error("Update endpoint error:", err);
      // Return 204 on error so the client treats it as "no update"
      return new Response("Internal error (silenced)", { status: 204 });
    }
  },
};
 
function hashToBucket(id: string): number {
  let hash = 0;
  for (let i = 0; i < id.length; i++) {
    hash = ((hash << 5) - hash + id.charCodeAt(i)) | 0;
  }
  return Math.abs(hash) % 100;
}
 
function compareSemver(a: string, b: string): number {
  const parse = (v: string) => v.replace(/^v/, "").split(".").map(Number);
  const [a1, a2, a3] = parse(a);
  const [b1, b2, b3] = parse(b);
  return a1 - b1 || a2 - b2 || a3 - b3;
}

There's a deliberate design choice here that's worth flagging. When the Worker errors, I return 204 (No Content) instead of 500. Tauri Updater treats anything other than 200 as "no update available." Returning 500 would surface "Failed to check for updates" dialogs to users every time something hiccups upstream. Quietly degrading to "no update right now" is the correct UX for a background updater.

The expected behavior: when a new version exists, Tauri Updater receives the JSON, downloads the binary with SHA256 verification, and proceeds to install. Promoting from 10% to 50% to 100% rollout is just a KV write — no redeploys, no manifest re-uploads.

Don't forget to design rollback. I keep the previous version's manifest under a previous_meta KV key, so I can roll back by swapping two key values. R2 binaries are never deleted and URLs never change. That immutability is what makes rollback safe.

A pragmatic operational tip about KV updates: I always update the manifest by writing to a versioned key first (meta_v42), then atomically updating the latest_meta pointer to that version. That gives me a write-ahead log of every release I've ever shipped, and rollback becomes "point latest_meta back to meta_v41" — no rebuilding, no rebundling, just a KV write. With Cloudflare's eventual-consistency guarantees, the change propagates globally within a minute, which is fast enough for emergency rollbacks while being safer than directly mutating the active key.

The other thing worth designing carefully is the previous_meta semantics. I keep the prior release accessible at the dedicated key for at least 30 days, separately from the versioned history. The versioned history exists for archival and rollback; previous_meta exists for graceful degradation if the latest manifest gets corrupted, allowing the Worker to fall back transparently. These look like the same data but they answer different operational questions, and conflating them has bitten me before.

Offline-Capable License Verification

Paid desktop apps face a real tension: users expect to launch the app on planes and trains without internet, but you also want some defense against casual piracy. The pattern I've settled on is server-signed payload + client-side verification. No constant phoning home, no "you're offline, please connect" friction.

The flow: Stripe checkout completes → server signs a license payload (user ID + expiry + device fingerprint) with a private key → client embeds the matching public key → app verifies the signature on launch. Offline-friendly, stateless, no online dependency.

// src-tauri/src/license.rs - Ed25519 offline license verification
use base64::{engine::general_purpose::STANDARD as B64, Engine as _};
use ed25519_dalek::{Signature, Verifier, VerifyingKey};
use serde::{Deserialize, Serialize};
use std::time::{SystemTime, UNIX_EPOCH};
 
const LICENSE_PUBLIC_KEY: &[u8] = include_bytes!("../keys/license_pub.bin");
 
#[derive(Debug, Serialize, Deserialize)]
pub struct LicensePayload {
    pub user_id: String,
    pub email: String,
    pub expires_at: u64,
    pub device_fingerprint: String,
    pub plan: String, // "lifetime" | "annual"
}
 
#[derive(Debug)]
pub enum LicenseError {
    Malformed,
    InvalidSignature,
    Expired,
    DeviceMismatch,
}
 
pub fn verify_license(
    license_str: &str,
    current_fingerprint: &str,
) -> Result<LicensePayload, LicenseError> {
    // Format: <base64(payload)>.<base64(signature)>
    let (payload_b64, sig_b64) = license_str
        .split_once('.')
        .ok_or(LicenseError::Malformed)?;
 
    let payload_bytes = B64.decode(payload_b64).map_err(|_| LicenseError::Malformed)?;
    let sig_bytes = B64.decode(sig_b64).map_err(|_| LicenseError::Malformed)?;
 
    let payload: LicensePayload =
        serde_json::from_slice(&payload_bytes).map_err(|_| LicenseError::Malformed)?;
 
    let key_array: [u8; 32] = LICENSE_PUBLIC_KEY
        .try_into()
        .map_err(|_| LicenseError::InvalidSignature)?;
    let verifying_key =
        VerifyingKey::from_bytes(&key_array).map_err(|_| LicenseError::InvalidSignature)?;
    let signature = Signature::from_slice(&sig_bytes)
        .map_err(|_| LicenseError::InvalidSignature)?;
    verifying_key
        .verify(&payload_bytes, &signature)
        .map_err(|_| LicenseError::InvalidSignature)?;
 
    // Skip expiry for lifetime plans (encoded as expires_at = 0)
    if payload.plan != "lifetime" {
        let now = SystemTime::now()
            .duration_since(UNIX_EPOCH)
            .map(|d| d.as_secs())
            .unwrap_or(0);
        if now > payload.expires_at {
            return Err(LicenseError::Expired);
        }
    }
 
    if payload.device_fingerprint != current_fingerprint {
        return Err(LicenseError::DeviceMismatch);
    }
 
    Ok(payload)
}
 
#[tauri::command]
pub fn check_license(license: String, fingerprint: String) -> Result<LicensePayload, String> {
    verify_license(&license, &fingerprint).map_err(|e| format!("{:?}", e))
}

The non-obvious decision here is how to compute the device fingerprint. MAC addresses are trivially spoofed by virtual NICs. Hard drive serial numbers break in dual-boot setups. I use the OS-level install UUID — IOPlatformUUID on macOS, MachineGuid on Windows — combined and SHA256-hashed. It's not bulletproof, but it stops casual sharing among friends and family. Going further than that gets into pixel-counting paranoia that costs more in user friction than it gains in piracy prevention.

You'll notice I don't maintain a server-side license revocation list. That's a deliberate trade-off. Revocation lists demand an online check, which destroys the "works offline" property. They also complicate refund automation. For genuinely abusive cases, I bake a blacklist of revoked license IDs into the next app release — slow, but doesn't require running an authoritative server.

Stripe Checkout to License Issuance End-to-End

The other critical piece is wiring up Stripe webhooks to the license issuance flow. A Cloudflare Worker receives the webhook, generates the license, and uses Resend or Postmark to email it to the buyer. With Antigravity splitting this across agents, the entire flow takes about an hour to build.

The single most important detail: idempotency. Write the Stripe event.id to KV before processing, and skip if it already exists. Stripe legitimately retries webhooks, and double-issuance is a customer support disaster. Just as importantly, build a "resend my license" endpoint from day one — let users get their license re-emailed without contacting support, and your support load drops dramatically.

One more design decision worth highlighting: I generate licenses with a 30-day "grace period" for annual plans. The expires_at timestamp is set 30 days past the actual subscription end date. The reasoning is empathy — when a user's payment method expires, you don't want to brick their app the same day. Send them a reminder, give them time to update billing, and only enforce the cutoff if they ignore three weeks of email. This single decision dropped my refund rate noticeably; people who were going to renew anyway just needed a few days, and people who genuinely wanted to cancel weren't surprised by anything.

For monthly subscriptions, I take a different approach: instead of issuing a license with a 30-day expiry every month, I issue a license that expires 75 days out and have the app silently re-fetch a fresh one every 30 days when online. This means a user who goes offline for 2 months still has a working app, and only after that do they need to reconnect to refresh the license. The trade-off is more server hits per month, but R2 + Workers handle that scale for pennies.

For the Stripe-side details (Checkout localization, Webhook signature verification under Cloudflare Workers), the Antigravity × App Monetization with Stripe Guide has the full picture. Combine its Stripe integration with this article's Tauri-side license verification and you have a complete commercial distribution system.

Pitfalls You Will Hit (Field-Tested)

Five pitfalls I learned the hard way. None are well documented in the official Tauri docs.

Updater public key changes. If you regenerate tauri signer generate keys in CI, every existing user's app will reject your updates as "invalid signature." Generate the key once, back it up obsessively, and when you need to rotate, ship a transitional release that's signed with both the old and new keys.

Universal Binary RPATH issues on macOS. Building Intel and Apple Silicon separately, then merging with lipo, can embed mismatched RPATHs that crash on one architecture. Use cargo-zigbuild or Tauri's --target universal-apple-darwin to keep both architectures in the same toolchain.

SmartScreen reputation reset on Windows. This one cost me three weeks. If you distribute your signed .exe inside a .zip, Windows applies "Mark of the Web" to the inner executable and treats it as untrusted again, even though it's signed. Distribute the signed installer directly, never zipped.

License keys stored in plaintext config. Always use the OS keychain — Keychain on macOS, Credential Manager on Windows, Secret Service on Linux. Tauri 2 has tauri-plugin-stronghold, which gives you encrypted local storage with a clean API.

Untestable updaters. Don't believe anyone who says you can only test the updater by actually shipping a release. Ask Antigravity to "spin up a local Worker with a stub manifest endpoint," and you'll have a development loop that exercises the updater from your dev machine. Before shipping, walk through five cases: same-version (no update), minor update, major update, key mismatch, and network disconnected.

One additional pitfall worth flagging because it bites every team eventually: treating "release" as a single atomic event. In practice, building, signing, notarizing, uploading to R2, and publishing the manifest are five separate operations across two operating systems. Any one can fail independently. I structure my GitHub Actions workflow so each stage produces an artifact that subsequent stages consume. If notarization fails, I haven't already announced the release on the manifest. If R2 upload fails, the manifest update never runs. This pipeline shape — not a single big script — is what lets you sleep through a botched release.

A related operational mindset: I never push manifest updates manually. Even when I'm about to deploy a hotfix at 2am because something is broken, I run the same pipeline. Manual ops are fine when nothing's wrong; under stress, they're how you ship the wrong binary or forget to staple a notarization ticket. Antigravity helped me lock this in by writing the entire workflow in a way that the local dev loop produces the exact same artifacts as CI — that symmetry is what keeps the release process trustworthy.

Real-World Application

This is the architecture I run for several apps in production: an AI-assisted writing tool, a lightweight SQL client, and a local-first image generation GUI. They share three properties: they have to run well offline, they have a "buy once" or "annual" pricing model, and they ship to both Mac and Windows.

One thing I cannot recommend enough: document this entire production deployment design in your project's AGENTS.md. Six months from now, when you're modifying the updater and start wondering "why didn't I add a server-side revocation list," your past self will have written down the answer. My AGENTS.md includes the pitfall list above almost verbatim, so future-me — and Antigravity's agents reading the file — don't fall into the same traps.

A practical observation about pricing: I've found that buy-once licenses outperform subscriptions for desktop apps in the indie space. Web apps train users to expect monthly billing; desktop apps still feel like "products you buy." My own data: the same app sold at $39 lifetime converts at roughly 2.3x the rate of $5/month, even though long-term revenue is comparable. Your mileage will vary, but worth A/B testing rather than assuming subscriptions are universally better.

I'll add one more architectural note. The license verification code lives in src-tauri/src/license.rs for a reason — it's Rust, not JavaScript. A determined attacker could patch a JavaScript verifier inside the WebView, but patching Rust requires modifying the binary itself, which invalidates the code signature. The Rust path forces them to also re-sign the binary, which means re-distributing the modified app. That additional friction stops most casual cracking attempts at the boundary, and it's a free benefit of how Tauri is structured.

If you're scaling beyond a few thousand users, the Antigravity × Cloudflare R2 File Upload Optimization Guide has the binary-distribution and bandwidth optimization patterns you'll want to layer on top of this foundation.

Closing

If I had to compress this whole article into one line: shipping a Tauri 2 app to production takes more time designing the system than writing the app code. Signing, notarization, updates, licensing, payments — each is its own small project. The reason Antigravity makes this tractable for solo developers is that the agent-oriented workflow lets you parallelize the boilerplate across all of these systems at once.

If you do one thing today, add the macOS notarization script to your existing project. The moment that script lands in your CI, your app crosses the line from "side project" to "product I can sell." Hook it into GitHub Actions so cutting a release tag produces a notarized build automatically — that single piece of infrastructure changes how you think about your project. From there, work outward to the other pieces, and pair this article with the Antigravity × App Monetization with Stripe Guide to round out the commercial side.