DEV Community: Aykan KÖMÜRCÜ

Publishing an Electron AI App to the Microsoft Store: Everything I Got Wrong

Aykan KÖMÜRCÜ — Thu, 06 Aug 2026 16:35:47 +0000

I published a Windows desktop AI assistant to the Microsoft Store as a solo developer. It took two submissions, one rejection and a handful of undocumented surprises.

This is the list I wish I had found before I started.

Why the Store at all

I had a working NSIS installer and a payment flow running through an external provider. The Store was not obviously worth the trouble. Two things changed my mind.

Microsoft signs the package for you. Without the Store, a Windows SmartScreen warning greets every single user on first launch, and the only way around it is a paid code signing certificate. For a solo developer shipping a privacy-focused product, telling users to click through a security warning is a bad first impression.

The second reason is the 2026 policy allowing non-game apps to use their own payment systems. My entire purchase flow lives outside the Store and none of it had to change.

Surprise 1: electron-builder ignores your icon for appx

My package.json had a perfectly good build/icon.ico. NSIS used it. The appx target did not.

Appx packages need PNG assets at specific sizes, and electron-builder will not generate them from your ico. You need a build/appx/ folder containing at minimum:

Square44x44Logo.png
Square150x150Logo.png
StoreLogo.png (50x50)
Wide310x150Logo.png

Miss these and the build succeeds but your app shows up with a blank tile.

Surprise 2: the runFullTrust justification field silently truncates

If your Electron app touches the filesystem, you declare runFullTrust and Partner Center asks you to justify it in a text box.

That box has a very low character limit and it does not tell you what it is. Long explanations get cut off without warning. Write two sentences, not two paragraphs.

Surprise 3: package size

My first appx came out at 526 MB. My second one, functionally identical, was 191 MB.

The culprit was the files array in my electron-builder config. **/* means everything, including development dependencies you never ship. Audit that array before you upload half a gigabyte.

The rejection: policy 11.16

My first submission was rejected. One reason, nothing else.

Policy 11.16, Live Generative AI Content. If your app produces generative AI output, you must give users a way to report inappropriate content, in the app, visible, one click away.

I had spent months on the privacy architecture. Zero data retention, no file uploads, local processing, provider-side data collection disabled. I had thought carefully about where data goes and not at all about what happens when the model says something wrong.

The fix took half a day:

A flag button under every assistant message, next to copy and read aloud
A modal where the user writes what went wrong
An endpoint that writes the report to the database and sends a notification email
No credit cost, because reporting a problem should never cost the user anything

Resubmitted. Approved in 24 hours.

Surprise 4: your app will pass certification and still be broken

This is the one that actually hurt.

My server spawned a child process like this:

spawn("node", [path.join(__dirname, "dist/index.js")])

That works on my machine. Node.js is installed on my machine. It is not installed on my users' machines.

The app launched fine. The UI rendered. Nothing crashed. Certification passed. And every single user who typed a message got a sixty second wait followed by a generic error, because the child process never started.

The fix is one line:

spawn(process.execPath, [path.join(__dirname, "dist/index.js")], {
  env: { ...process.env, ELECTRON_RUN_AS_NODE: "1" },
})

Electron ships its own Node runtime. Use it instead of hoping the user has one.

To verify the fix I renamed my Node installation folder, which makes the machine behave like a clean user machine:

Rename-Item "C:\Program Files\nodejs" "C:\Program Files\nodejs_off"

Run your packaged app in that state before every single submission. Five minutes of testing against two days of certification turnaround.

What certification actually checks

Store certification is a compliance review, not a functional one. It verifies signing, manifest validity, declared capabilities, policy compliance and that the app does not crash on launch.

It does not verify that your app works. That is entirely on you.

Bonus: IARC ratings transfer

Filling out the age rating questionnaire produces an IARC Global Rating ID. That ID works across other IARC-licensed stores without redoing the survey. If you add a feature that would change your answers, you redo it.

The short version

Generate appx PNG assets manually
Keep the runFullTrust justification short
Audit your files array
If your app generates AI content, ship a reporting mechanism before you submit
Never assume the user has your development dependencies installed
Test the packaged build in a clean environment every time

The product is NeonCore, a Windows AI assistant that processes documents without uploading them anywhere. Built solo.

I built FHIR R4 support into a local-first desktop AI assistant. Here is what I learned.

Aykan KÖMÜRCÜ — Tue, 28 Jul 2026 19:06:04 +0000

Healthcare software has a problem that most AI tooling ignores completely. The data cannot leave the building.

Not "should not." Cannot. A hospital that ships patient records to a third party API is not making a tradeoff between convenience and privacy. It is breaking the law in most jurisdictions, and it is breaking the trust of every person whose record is in that system.

I build NeonCore, a Windows desktop AI assistant that parses documents entirely on the machine it runs on. No cloud upload, no data retention. A few months ago I started getting the same question from people in the health sector: can it read our patient records?

The honest answer was no. So I built it.

Why FHIR and not something simpler

FHIR R4 is the standard most modern hospital systems already speak. If you want to read patient data without asking an institution to change anything about their infrastructure, FHIR is the door that is already open.

The alternative would have been asking hospitals to export data into some format my app understands. That is a non-starter. Every export step is a copy of sensitive data sitting somewhere it should not be, and no IT department will approve it.

So the design constraint was simple: talk to the FHIR server the institution already runs, on their own network, and never write anything back out.

The architecture

Three pieces:

1. A local FHIR client. NeonCore connects to the institution's FHIR R4 endpoint over the local network. The endpoint address is configured by the institution, not by me. I never see it.

2. Query tools exposed to the model. Two functions, fhir_sorgula for searching resources and fhir_kayit_oku for reading a specific record by ID. The model calls these the same way it would call any other tool.

3. On-device reasoning. The record comes back, gets reasoned over locally, and the answer appears on screen. Nothing is written to disk unless the user explicitly saves it. Nothing goes to a cloud endpoint.

The important part is what is missing from that list. There is no sync layer. No telemetry on query contents. No caching of patient data between sessions.

What was harder than expected

FHIR is a large standard. R4 defines well over a hundred resource types. I did not implement all of them and I do not intend to. Patient, Observation, Condition, MedicationRequest and DocumentReference cover the overwhelming majority of what a clinician actually asks about. Scope discipline mattered more than completeness.

Authentication varies wildly. Some institutions use SMART on FHIR, some use plain bearer tokens, some sit behind a network boundary and use nothing at all. I ended up supporting a configurable auth layer rather than assuming any one flow.

Search parameters are inconsistent in practice. The spec says one thing. Individual server implementations do their own interpretation. Defensive parsing was not optional.

Explaining it is harder than building it. I spent months describing "on-device processing with zero data retention" and watching people nod politely. The moment I changed the sentence to "patient records never leave the institution," people understood immediately. Same architecture, different words.

What I would tell someone building in this space

Do not treat privacy as a feature you add. Treat it as a constraint that removes options. Once you accept that data cannot leave the machine, a lot of architectural decisions make themselves. You stop reaching for the cloud service that would have been easier, because it is simply not available to you.

That constraint is also the entire product. There are plenty of AI assistants that can read a document. There are very few that a hospital's compliance officer will approve.

Where this is going

FHIR support is live in NeonCore now. Next on the list is expanding resource coverage based on what people actually ask for rather than what the spec suggests, and better handling for institutions running older FHIR versions.

If you work in health IT and want to poke holes in this, I would genuinely like to hear it. The failure modes I have not thought of are worth more to me than the ones I have.

https://neondijital.com/blog/fhir-r4-local-first-ai

NeonCore is at neondijital.com. Built and maintained solo, self funded, from Izmir.