Important information for developers with Windows Phone apps in the Store

Update (April 29th, 2019): Looks like Microsoft has fixed the issue with http Store URLs, so it should be safe to use those once again. The “ms-windows-store” protocol workaround described below is still needed if you want to use protocol links.

Last week it has come to our attention that it wasn’t possible to open the Store application on Windows Phone 8.x by clicking on the “Get” button in the web version of the Microsoft Store. We reached out to Microsoft but are yet to hear anything actionable on the subject. This post will cover a workaround that developers may use to mitigate the issue.

Why is this important?

Some of you may wonder “why would anyone care about Windows Phone 8?” That’s a valid question, so here’s the answer:

Here at AdDuplex, we have served more than 11 million ad impressions to more than 3,000 Windows Phone apps on more than 400,000 WP8 devices just yesterday. And we are in only a small portion of available apps and games. While obviously, no one is building their future on Windows Phone in 2019, many developers rely on passive income still coming from their Windows Phone apps to fund their current and upcoming projects.

Plans and calculations have been made on the assumption that the Windows Phone 8.x store will function properly at least until July 1st, 2019.

What’s the issue, exactly?

Developer web sites, ad networks, news sites, blogs, social media posts, and other resources usually link to apps in the Microsoft Store with an official standard link that looks something like this:

At the time of this writing, when you follow such a link on a Windows Phone 8.x device you get to the web version of the Microsoft Store where you see a button to get the app or game. When you click it you are not taken to the phone’s Store app like it was before, and therefore can’t download the application.

To be clear, those super-enthusiastic users who really want it, can still launch the store app manually and search for the game in question and download it from there, but it’s obvious that a lot of users won’t go through the motions or don’t even know that this is what they should do in the situation.

The fix

We don’t know when (or whether) Microsoft will fix the web store to work on WP8 as expected. Obviously, Windows Phone is not a priority for the company. In the meantime, we need to take matters into our own hands.

In addition to the HTTP store URL, App identity page in the Partner Center (Your app -> App management -> App identity) contains a Store protocol link which is a scheme that should open the Store app right away. And it does on Windows 10.


Unfortunately and bizarrely, at the time of this writing, these links open Xbox Music (!) app on Windows Phone 8.1 (contradicting both common sense and documentation).

The real fix… or rather a workaround

This is where we got stuck for a couple of days while we assumed that everything is totally broken and only Microsoft can help us. Fortunately, we have a great geek friend, Microsoft MVP and overall awesome person Rafael Rivera (check out his great EarTrumpet volume control app in the Store (duh!)).

Rafael suggested we try several old-school/undocumented protocol options and, to our delight, two of them worked. Namely:




Yes – Zune!

Note: both worked for us every time (both on Windows Phone and Windows 10) but one of our clients reported that the “ms-windows-store” one didn’t work for him while “zune” worked. It’s unclear how thorough his testing was but just to be on the safer side we went with implementing the “zune” version.

You may be wondering where to get the GUID version of your app’s ID? In current Partner Center it’s not presented anywhere on the App identity page. However, you can most likely get it in your .appxmanifest file in your solution or WNS/MPNS (push notification) page under the same App management section in the Partner Center:


What should I do?

We have implemented this workaround for all Windows Phone apps/ads served on AdDuplex, so if this is your only exposure to Store links, then you don’t have to do anything.

However, if you have a website for your app or other places under your control where store links are used, we encourage you to implement the above Store protocol workaround for all your links.

In our testing the “zune:” protocol link worked everywhere, but if you want to be on a slightly safer side and don’t mind some extra work you may differentiate links for Windows Phone 8.x versions of your app (use “zune:navigate”) and Windows 10 version (use the regular http link).

Additionally, please let your fellow developers know about this so they can maximize the returns of the final months of the Windows Phone 8.x lifecycle.

And, please, let us know in the comments or at if you have any additional insights or feedback about this issue.