今日已更新 412 条资讯 | 累计 19972 条内容
关于我们

标签:#desktop

找到 7 篇相关文章

AI 资讯

Migrate License Keys Without Breaking Existing Customers

Originally published on the Keylight blog . The thing that stops developers from moving their licensing isn't the work. It's the fear of one specific moment: a paying customer opens the app after you've switched, and it tells them they're unlicensed. That's the nightmare — you reach for lower fees and customer ownership, and the bill comes due as a wave of "I already paid for this" support tickets. It's a reasonable fear, and it's also avoidable. Migrating onto Keylight doesn't require invalidating anything, re-issuing anything, or asking customers to do anything. This post is about the one rule that keeps everyone working, the two situations you might be in, and why a scary-sounding "major version" jump changes none of it. When you're ready for the click-by-click mechanics, the companion piece covers them: How to Import an Existing Customer Base into Keylight . Why migrating licensing feels risky A license check is binary in the moment a customer experiences it: the app either lets them in or it doesn't. So any change to the system behind that check feels like it's playing with a live wire. Switch the layer that answers "is this person allowed in," the thinking goes, and you risk every existing customer getting the wrong answer at once. That instinct is right about the stakes and wrong about the mechanism. The wave of lockouts people picture comes from one specific mistake: treating migration as a cutover , where the old keys stop being recognized the instant the new system goes live. If your migration invalidates the old keys, yes — everyone breaks. The entire trick is to not do that. The one rule: old keys stay valid Here's the rule the whole migration hangs on: you bring your customers' keys in as they are, and nothing gets invalidated. When you import an existing customer, their license is a live, active record from the first second. If you include the key string they already have, that key is what Keylight stores — not a replacement. So when your new build ask

2026-06-27 原文 →
AI 资讯

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 Sque

2026-06-27 原文 →
AI 资讯

Claude Desktop vs Antigravity 2026: Why I Moved Back

Originally published on rikuq.com . Republished here for Dev.to's readers. I dropped my $100/month Claude Max subscription and migrated entirely back to Antigravity. If you want the verdict upfront: Claude Desktop is still the best tool for beginners who need the AI to guess their intent from clumsy prompts. But if you have solid documentation discipline and cost efficiency is a serious factor for your SaaS, Antigravity is now the clear winner. I'm a Chartered Accountant by trade with zero formal coding experience. I’ve shipped three production AI SaaS— Prism , Citare , and BatchWise —relying entirely on AI tools. I started with VSCode, moved to Antigravity (when it was just an IDE), and eventually landed on the Claude Desktop App. Claude was incredible; it operated in the background, handled my stack, and I didn't need to know what was happening under the hood. But the bills started stacking up. When my Claude usage consistently hit $100 a month, efficiency became a priority. I fired up the new version of Antigravity and found the recent updates had completely transformed it. It is no longer just an IDE—it is a full agentic desktop experience that mirrors what made Claude so good. TL;DR — The 2026 Reality Feature Claude Desktop App Antigravity (New Update) Best for Beginners, unlimited budgets, "pure performance" Experienced AI directors, cost-conscious solo founders Pricing $100+/mo (Claude Max) $20/mo (Gemini Advanced) Agentic Workflow Exceptional. The benchmark. Identical. Background execution, zero friction. Context Handling Better at anticipating intent from messy prompts Huge total memory, but requires tighter prompting MCP Support Native Native (handles them just as well) Verdict Keep it if cost doesn't matter Switch to it if efficiency is the goal The Catalyst for Switching My path to Antigravity wasn't a calculated feature comparison. It was pure economics combined with a pleasant surprise. I had previously dropped Antigravity when it was just an IDE. When

2026-06-16 原文 →