Dev guide outlines direct desktop app sales and cross-platform offline licensing tools

How to ship and sell a paid desktop app outside the app stores (2026)

You built a desktop app — macOS, Windows, Linux, native or Tauri/Electron — and you want to sell it directly instead of handing 15–30% to Apple or Microsoft. Selling outside the stores means you keep the margin and own the customer relationship. It also means the plumbing the stores quietly handled is now yours: distribution, payments, licensing, updates, support. Here's the whole path, in roughly the order you'll hit it — with the licensing part (the one most people underestimate) covered properly. Why sell outside the app stores Margin. You keep 85–100% instead of giving up the store's cut. Control. Your own pricing, trials, upgrades, and refund policy — no review gatekeeping, no waiting on approval to ship a fix. The relationship. You get the customer's email and can actually support and re-sell to them. The tradeoff is that the things the store did invisibly — vouching for your binary, taking payment, enforcing the purchase — are now your job. This isn't a Mac thing. Windows devs sell direct constantly, Linux too, and a Tauri or Electron app ships to all three from one codebase. The work below applies across the board. 1. Distribution and updates Before anyone pays, they have to trust and install the thing. macOS: sign with a Developer ID certificate and notarize with Apple, or Gatekeeper will scare users off. Windows: an Authenticode code-signing certificate, ideally EV to build SmartScreen reputation faster. Linux: package as AppImage, .deb/.rpm, or Flatpak depending on your audience. Then updates, because the store won't push them for you: Sparkle (macOS), Squirrel/electron-updater (Electron), the Tauri updater, or your own endpoint. Decide this early — retrofitting auto-update onto a shipped app is miserable. 2. Getting paid Two real models: Stripe (you're the merchant). Lower fees, full control, your brand on the receipt. The catch: sales tax and EU VAT are your responsibility (handle it yourself or bolt on a tax service). Merchant of Record (Lemon Squeezy, Paddle, Polar). They become the seller of record and handle worldwide tax for you, for a higher cut. Less control, far less compliance headache. Rule of thumb: pick an MoR if tax/compliance is the thing you least want to think about; pick Stripe if you want margin and control and will deal with tax separately. 3. Licensing and activation — the part people underestimate Here's the trap: a payment is not protection. "They paid" and "this specific install is allowed to run" are two different facts, and the gap between them is where piracy and support tickets live. Licensing is the layer that closes it, and on the desktop it has to keep working with no network. What a real licensing layer actually has to do: Issue a key when someone buys. Activate that key on a device (bind it, so one key isn't infinite installs). Verify it on every launch — including offline, on a plane or behind a firewall. Enforce device limits and gate features or tiers (entitlements). Handle trials, expiry, refunds, and revocation without locking out honest customers. The cross-platform tax If you ship macOS and Windows and Linux — or native and Tauri and Electron — you need the same licensing logic everywhere. Re-implementing key validation per platform is exactly where subtle bugs and piracy creep in: a weaker check on one OS undermines all of them. One consistent verification path across every build is the goal. Build vs. buy Rolling your own means a signing server, key management, device fingerprinting, and an offline-verification scheme done correctly — which means never trusting a plain {"valid": true} from your server (a proxy forges that for free). The durable approach is a cryptographically signed lease: your server signs the license state with a private key, your app verifies it locally with the public key, no network required. (Here's how that works in detail.) Most indie devs underestimate this by a week or more. The done-for-you option is what Keylight exists for: one control plane with finished SDKs for Swift, Rust, JavaScript/TypeScript, C#, and C++, so the same licensing behaves identically across native macOS/Windows/Linux, Tauri, and Electron. Offline Ed25519-signed leases verify on-device, entitlements ride inside the lease, and connecting Stripe mints keys on payment — no webhook code. Disclosure: I build it. For the broader landscape — Keygen, Cryptolens, LicenseSpring, and the keys-as-a-feature options like Lemon Squeezy and Polar — there's an honest tool-by-tool comparison here; they're good at different things and the right pick depends on whether your bottleneck is control, payments, or time. 4. Piracy — the realistic stance You will not stop a determined cracker, and chasing that goal usually means punishing paying customers. The achievable goal: make casual copying inconvenient, keep honest people honest, and never ship online-only checks that lock out legitimate users when their network drops. Offline-friendly licensing beats aggressive DRM on every axis that matters for an indie business. 5. Refunds, support, and self-service The tickets you'll actually get: "I got a new laptop and can't activate," "I need to move my license," "I bought the wrong tier." A self-service portal — deactivate a device, move a seat, see your license — saves you from being a human license desk. Build a thin one or use a provider that includes it. The order to do it in Sign + notarize/package so people can install it. Wire payments (Stripe or an MoR). Add licensing + activation — keys, device limits, offline verification, entitlements. Add auto-update. Add a trial and a self-service portal. Ship it. The app was the hard part, and you already did it. The rest is plumbing — and licensing is the plumbing people get wrong, because paid and allowed to run offline on the right number of devices are different problems. Get distribution and payments handled, then make licensing boring: signed leases, device limits, entitlements, one SDK per stack. Then go sell it. If you want the licensing layer handled across every desktop stack in one place, that's Keylight — there's a free tier to start.

18 hours ago

I compared the licensing tools for my indie Mac app — the honest breakdown

I needed to license a macOS app I sell outside the App Store. I went down the rabbit hole so you don't have to. Here's the honest breakdown — what each tool is genuinely good at, and where it stops. No tool is "best"; they're good at different things. The two questions that decide everything Before the tools, answer these: Do you need real offline verification? (Desktop apps usually do — see firewalls, planes, air-gapped machines.) This eliminates the "license key is just a string you check over HTTP" options for serious use. Do you want payments handled too, or do you already have Stripe? Some of these are licensing-only; some are merchant-of-record that also do keys. The licensing-first tools Keygen — the one most people name first. Language-agnostic API, deep policy engine, open-source, self-hostable. Genuinely powerful. The cost is that it's primitives: you bring your own payments, wire the webhooks, and write the client code. Pick it when you want maximum control and don't mind assembling the flow. Cryptolens — classic license-key system with offline verification via signed responses. Strong .NET heritage. Solid if you're on Windows/.NET and want the traditional key + activation-count model. LicenseSpring — enterprise-leaning. Floating licenses, air-gapped activation, node-locking. Overkill for a solo indie app, right at home if you're selling into companies with offline/dark-site requirements. The payments-first tools (keys as a feature) Lemon Squeezy / Polar — merchant of record, so they handle sales tax for you, with a license-key API bolted on (activate / validate / deactivate). Great for getting paid fast across borders. The licensing side is basic — keys are essentially strings with an activation limit; offline verification isn't really their thing. Gumroad — the simplest possible "sell a thing, get a license key, verify over one endpoint." Fine for a cheap utility where piracy isn't worth fighting. Not infrastructure. StoreKit — only relevant if you ship through the Mac App Store and want Apple to manage purchases/subscriptions. If you're outside the store, it doesn't apply. Where Keylight fits Full disclosure: I now build Keylight, so weigh this accordingly — I'm telling you the seam it's designed for, not that it wins every row. The gap I kept hitting was the middle: Keygen gives you primitives but makes payments and client code your problem; Lemon Squeezy gives you payments but the licensing is thin. Keylight is the opinionated middle — finished SDKs (Swift, Rust, JS, C#, C++) with offline Ed25519 leases and Stripe wired in, so a payment mints a license with no webhook code and the SDK verifies offline with a checkOnLaunch() call. The tradeoff is the flip side of opinionated: it's hosted (no self-host like Keygen CE), and it's SDK-first rather than a bring-any-language REST API. How I'd actually choose Want primitives + max control, any language, maybe self-host? Keygen. Selling into enterprises with air-gapped/floating needs? LicenseSpring. Windows/.NET, classic key model? Cryptolens. Just want to get paid across borders, licensing is secondary? Lemon Squeezy or Polar. Cheap utility, piracy not worth fighting? Gumroad. Shipping through the Mac App Store? StoreKit. Swift/Rust/JS/C#/C++ app, want offline licensing + Stripe done for you? Keylight. The meta-point: match the tool to whether your bottleneck is control, payments, or time. For most indie desktop devs shipping outside the store, the bottleneck is time — you want offline licensing and payments to just work so you can get back to the app. I went deeper on the desktop-specific tradeoffs in this ranked breakdown if you want the long version.

18 hours ago