We Got Our Desktop App Live on the Microsoft Store. Nine Things the Checklist Didn't Tell Us.

The short version: the Microsoft Store is the one major app store where a small company can ship a desktop app with zero upfront cost — no $99 annual fee, no paid code-signing certificate — but only if you package as MSIX and navigate Partner Center’s submission flow, which hides about nine traps that no blog post warned us about. We did our first submission from Huizhou in one day. What follows is the shape of the process plus the parts that broke.

Why we even started here

File Guardian, our file version-history tool, is a plain desktop app: you point it at a folder, it records snapshots locally so you can undo a bad save. Windows is where that kind of tool lives, and the Store is where Windows users look. Two facts decided it for us:

1. Store submissions get free code signing and free CDN hosting. You upload the package; Microsoft re-signs it and delivers it. The alternative path (submitting a raw EXE/MSI installer) requires a commercial code-signing certificate chaining to a trusted root — roughly $9–15 a month before you sell anything. For a small team, that alone decides the packaging format.
2. The developer account is free. Yes, free. You register in Partner Center with a company profile, and you pay nothing until you’re ready to sell — and even then, the fee structure only bites as a revenue share, never as an entry ticket.

So the money question was settled. The interesting part was everything else.

Trap 1: the package identity must match character-for-character

When you reserve a product name in Partner Center, it hands you a package identity: a publisher string (a CN= followed by a long GUID) and a name in the form YourOrg.PlanetName. Your MSIX manifest must carry those values exactly — one character off and the submission is rejected.

The obvious advice is “copy and paste.” The less obvious advice: build the packaging step around that string from day one. Our first development build was packaged with the framework’s default identity (an internal project code, plus a placeholder publisher), which looked completely fine locally — installed, ran, all green — and was 100% unsubmittable. The fix is just editing the build config, but only if you knew to look. Check your manifest’s Identity block before you waste a certification slot.

Also: versions are four-part (1.0.0.0), and every resubmission must increment. Keep a spare segment for rebuilds under the same semantic version.

Trap 2: free is a setting, not an absence

The Pricing page complains in red until you explicitly set a base price. The base price dropdown includes Free — that’s the button that silences it. (If instead you left the retail price field blank, you get “no price schedule” errors that read like a bug. It isn’t.)

Two follow-on details people miss:

• Prices are tiers, applied globally by conversion. You pick a tier in one currency; the Store mirrors it across 240+ markets using a conversion table it updates periodically. Crucially, Microsoft will not change your price without your approval — it just shows you a warning when your tier drifts from its current suggestion. So a quarterly “any yellow pricing warnings?” glance is the whole maintenance burden.
• The same tier table governs add-ons. Which matters for trap 3.

Trap 3: “free app, paid upgrade” is two products, and their IDs are different kinds of animal

We ship a free app plus a one-time Pro add-on (unlimited history, all file types). In Partner Center these are two separate submissions: the main app, and a “durable” in-app product created under the add-ons section, which has its own Store ID.

The trap is in the names: creating an add-on asks you for a product ID — a slug you type yourself, invisible to customers, unchangeable after publishing. The thing your code must actually reference is the Store ID the system generates for that add-on (another 9X… string, different from your app’s Store ID). Two IDs, similar-looking, different jobs. Fill the wrong one into your purchase flow and the button will fail silently on real users while passing every test you can run locally. We made the mix-up on a scratch note, caught it before code, and it still ranks in the top three “why is my purchase not working” hypotheses to check.

The purchase flow itself is one API call (requestPurchaseAsync with the add-on’s Store ID) and a license check (addOnLicenses keyed by that same ID). No payment server, no card data touching your machine. Genuinely nice engineering, once the ID confusion is cleared.

Trap 4: the privacy URL gate bites before you think it should

In the Properties section, declaring that the app touches personal information (it does — file paths and contents count, even if processed locally) makes a publicly reachable privacy policy URL mandatory. Mandatory means: save fails, red text, full stop.

Not “have a draft.” Not “it’s in the repo.” A live HTTPS URL returning 200, ideally checked in incognito. If ops and dev are different people — or different time zones — sequence this first: the developer finishes the policy text, ops deploys it, then the Properties page gets filled. We wrote a plain-language policy that says the quiet part loudly (“we do not transmit your files; network use is mainly Store licensing”) and hosted it on our main domain as a static page. Five minutes of ops work that unblocks the whole form.

Trap 5: runFullTrust needs a one-sentence apology letter

Desktop apps declare the runFullTrust capability (without it, you get mysterious sandbox crashes — a filesystem and child-process app cannot live in the UWP sandbox). But full trust on a file-monitoring app makes reviewers squint. The certification-notes field is where you defuse it in advance: why the app needs broad file access (it watches a folder the user explicitly selects), and that data stays local. One paragraph, written before submission, not after a rejection email.

Trap 6: the trailer uploader is broken; skipping the trailer is a feature

The Store lets you attach a product trailer video. Our pipeline (a programmatic video renderer) produced a spec-perfect 1080p MP4. The portal then demanded a title and a thumbnail for each trailer, and the thumbnail control did not cooperate: the upload cell accepted only the MP4, the browse button inside the edit dialog did nothing (popup blockers, extensions, or a portal-side bug), and dropping the PNG onto the page just… opened the image in a browser tab, uploading nothing.

Community threads show Microsoft has fixed portal-side upload bugs before, so this may be temporary — but plan around it: v1 without a trailer is fully submittable. Delete the trailer entry, choose “remove from this listing only” (not “all listings,” unless you mean it), and the red text disappears. Our video assets sit in the repo, ready for a follow-up submission when the uploader behaves. A Store listing with four honest screenshots outperforms one with a broken upload ritual anyway.

Two small facts while we’re here: Xbox-only fields and “super hero” art are genuinely optional for desktop-only packages, and screenshot order is drag-adjustable in the portal.

Trap 7: your own words become the reviewer’s yardstick

One free-plan bullet read “1 protected folder.” During review prep we realized a user could (and a reviewer could) read that as “one shallow directory.” The app actually protects a top-level folder and all subfolders. Same feature, two readings — and the Store holds you to what your listing says. We rewrote every boundary claim (“one top-level folder, subfolders included”) and deleted marketing adjectives that described behavior the code doesn’t guarantee (a stray “unlimited folders” claim had to die — Pro removes the folder cap only after we ship the multi-folder watcher; honesty tax paid).

Generalize: screenshots, listing text, help page, and app behavior must form one sentence that fits four places. Certification checks a subset; user reviews check the rest.

Trap 8: the status flow is slower than it looks, and that’s fine

After “Submit for certification,” a submission walks through preprocessing → certification → publication. The official range: hours to a few business days; MSIX with unusual capabilities may get a human glance. We set the release option to manual publish so we control the moment of visibility, then stopped refreshing. Two useful postures: don’t open support tickets for a normal in-flight review (the report emails will come), and do read the certification report literally — it’s mechanical, keyed to policy sections.

Trap 9: the whole thing cost what you feared it wouldn’t

Tally for the first submission, honest numbers: developer account $0, code signing $0 (MSIX path), hosting $0 (Store CDN), payment processing a revenue share (double digits, only when selling). The costs were time and attention: one packaging config fix, one ops deploy, one rewritten listing, one broken uploader worked around. If you are a one-person shop eyeing the Store, this is the friendliest front door of the three major stores — the caveats above are its whole toll.

The checklist we wish we’d had

• Package identity strings copied into build config before first store-bound build
• Base price explicitly set (Free is a value, not an empty field)
• App and add-on treated as two submissions; note which ID goes into code (the add-on’s Store ID)
• Privacy policy live at a 200-returning HTTPS URL before touching Properties
• Certification note explaining full file access in one paragraph
• Listing claims verified against actual behavior (“protected folder, subfolders included”)
• Trailer optional; skip it if the uploader misbehaves, keep assets for v1.1
• Manual publish selected if you want to control the go-live moment

That’s the whole story. The machinery underneath — identity, licensing, signing, CDN — is genuinely well built for small publishers; the portal’s rough edges are shallow, and each one is worth knowing about in advance. The first submission is the expensive one.

Filed from the desk of a two-product, zero-employee company in Huizhou. If you’re mid-submission and found the two-add-on-IDs mess reassuring, that’s the point.