Publishing to Microsoft Store: MSIX, Certification, CI/CD
Developers often face certification rejection due to an invalid manifest or icons. The error The package manifest is not valid in WACK is a typical problem even for experienced teams. Add another complexity: the app must run correctly on different architectures (x86, x64, ARM64) and versions of Windows 10/11. Incorrect binding to a specific build is a common cause of WACK failure. We help navigate this path in 3–5 days—from MSIX packaging to turnkey publication. Pinpoint your case and we’ll prepare your app for release.
Microsoft Store supports three formats: packaged MSIX (Win32), UWP, and PWA. MSIX ensures clean installation and removal without traces. Electron and other cross-platform frameworks are published via MSIX—this allows using the full Win32 API without rewriting on WinRT.
Publication formats in Microsoft Store
| Format | Audience | Features |
|---|---|---|
| MSIX (packaged Win32) | All Windows 10/11 | Full Win32 API access, Electron support |
| UWP | Windows 10/11 (Store) | Sandbox, limited file system access |
| PWA | Windows 10/11 (Edge) | Web apps only, no desktop features |
How to package an Electron app into MSIX?
electron-builder can build MSIX directly. Example configuration:
# electron-builder.yml win: target: - target: nsis - target: msix icon: build/icon.ico msix: applicationId: com.company.AppName backgroundColor: "#transparent" displayName: "App Name" publisherDisplayName: "Company Name" identityName: "CompanyName.AppName" npx electron-builder --win msix Signing the package requires a developer certificate from a Trusted CA (DigiCert, GlobalSign) or a certificate from Partner Center. Self-signed certificates are not accepted. We use automatic signing via CSC_LINK and CSC_KEY_PASSWORD in CI.
Why MSIX is the preferred format for the Store?
MSIX provides an isolated environment, guarantees correct removal and updates through the Store. Unlike UWP, MSIX packages can use Win32 API, so existing apps do not require a full rewrite. The format is certified by WACK, which checks compliance with Microsoft requirements. WACK errors are the main reason for rejection, so we pay special attention to preliminary verification.
A real case: reducing certification time from 2 weeks to 3 days
On a recent project for an Electron-based analytics tool, the client had failed WACK three times due to incorrect icon sizes and a mismatched publisher in the manifest. We analyzed the package, rebuilt it with correct manifests, generated proper icons, and pre-ran WACK locally. The fix took one day, and the app passed certification on the first resubmission. The entire process—from initial analysis to Store publishing—took three days.
How to pass WACK certification on the first try?
Before uploading, always run WACK locally:
& "C:\Program Files (x86)\Windows Kits\10\App Certification Kit\appcert.exe" ` test -apppackagepath .\AppName.msix -reportoutputpath .\report.xml WACK checks: valid manifest, no forbidden APIs, correct icons (required Square44x44, Square150x150, StoreLogo 300x300). Check the Publisher in the manifest: it must match the certificate. Our experience—5+ years in publishing Windows apps, over 30 successful Store releases. We guarantee passing WACK on the first attempt.
What if WACK gives an error?
| Error | Cause | Solution |
|---|---|---|
| Invalid Publisher in manifest | Differs from certificate | Use Publisher from certificate |
| Missing mandatory icons | Not all sizes in manifest | Add Square44x44, Square150x150, StoreLogo |
| Use of forbidden APIs | Incompatibility with Store | Replace with equivalent Win32 APIs |
| Package size exceeded | >10 GB (Store limit) | Optimize or split |
Registration in Partner Center
- Register a developer account (one-time fee).
- Create a new app: Partner Center → Apps → New product.
- Reserve the name and fill in metadata: description, screenshots (minimum 3, resolution from 1366×768), category, age rating.
- Set the pricing model (free or paid product).
Filling in metadata is critical: incorrect age rating or wrong category leads to rejection. We recommend entrusting this work to our specialists.
Automating update publication
Use GitHub Actions with the microsoft/store-submission-action. Example workflow:
- name: Build MSIX run: npx electron-builder --win msix env: CSC_LINK: ${{ secrets.WIN_CERTIFICATE }} CSC_KEY_PASSWORD: ${{ secrets.WIN_CERTIFICATE_PWD }} - name: Upload to Partner Center uses: microsoft/store-submission-action@v1 with: seller-id: ${{ secrets.MS_SELLER_ID }} product-id: ${{ secrets.MS_PRODUCT_ID }} package-path: dist/AppName.msix tenant-id: ${{ secrets.MS_TENANT_ID }} client-id: ${{ secrets.MS_CLIENT_ID }} client-secret: ${{ secrets.MS_CLIENT_SECRET }} After uploading, Microsoft performs moderation (1–3 business days). Updates go through faster—in 1–2 days. For GitLab CI, the configuration is similar—use the corresponding action or a shell script with Azure CLI.
What's included in the work?
- App analysis and format selection (MSIX, UWP, or PWA)
- MSIX package creation with correct manifest and icons
- WACK certification and error resolution
- Partner Center registration and metadata filling
- CI/CD setup for automatic publishing (GitHub Actions, GitLab CI)
- Guarantee of successful publication on the first attempt
Timeline
MSIX preparation, WACK certification, and first publication: 3–5 business days. For complex apps (with drivers, extensions), the timeline may extend to 7–10 days. The cost is calculated individually based on project complexity.
We have years of experience, with dozens of projects published in Microsoft Store. Our engineers hold Microsoft certifications and are ready to solve non-standard problems. Get a consultation—we’ll assess your project and propose the optimal path.