Windows, Windows Phone and The App Market


Recommended Posts

With the recent "confirmation" of 7", 8", etc Tablets from MS, I am convinced these new smaller form factors will be running WindowsRT.

To this effect, I am wondering how the different App Markets (Windows Phone & Windows) will cater for these new form factors (app development and most importantly, pricing). I think Microsoft got it wrong allowing apps made for ARM chips to run on x86 chips just for the x86 PCs to have some Metro Apps. I think what MS ought to have done is to allow an app be developed and compiled for the different chips with little or no code required thereby allowing separate App Markets for the different chips architecture.

Imagine if the current scenario is carried on with these new form factors (7", 8", etc.) and an app is sold on the Windows Phone App Market for US$1. Will the that same app be priced the same in the Windows Store for a 7" tablet (which will also run x86 PC)? Or most notably say a game like Need For Speed, etc. Will the game developer price its app same on both Windows Phone and on a PC?

I think MS should merge Windows Phone OS with WindowsRT (and probably rename the OS for the ARM chips) and allow apps already developed for Windows Phone to run on WindowsRT and vice versa. Let the x86 chips have it's own App Market and disallow ARM apps to run on it.

This would clear up the ambiguity in app development and pricing which would in turn give app devs less headache.

Link to comment
Share on other sites

With the recent "confirmation" of 7", 8", etc Tablets from MS, I am convinced these new smaller form factors will be running WindowsRT.

To this effect, I am wondering how the different App Markets (Windows Phone & Windows) will cater for these new form factors (app development and most importantly, pricing). I think Microsoft got it wrong allowing apps made for ARM chips to run on x86 chips just for the x86 PCs to have some Metro Apps. I think what MS ought to have done is to allow an app be developed and compiled for the different chips with little or no code required thereby allowing separate App Markets for the different chips architecture.

huh? that's already how it is. when you compile a winrt app,you can get 2 binaries. one for arm,and one for x86. most of the time you don't have to do any code modifications at all. arm binaries will only show on arm devices,and x86 binaries will only show on x86 devices.

Imagine if the current scenario is carried on with these new form factors (7", 8", etc.) and an app is sold on the Windows Phone App Market for US$1. Will the that same app be priced the same in the Windows Store for a 7" tablet (which will also run x86 PC)? Or most notably say a game like Need For Speed, etc. Will the game developer price its app same on both Windows Phone and on a PC?

I think MS should merge Windows Phone OS with WindowsRT (and probably rename the OS for the ARM chips) and allow apps already developed for Windows Phone to run on WindowsRT and vice versa. Let the x86 chips have it's own App Market and disallow ARM apps to run on it.

I think youre confused, like I said,arm apps don't run on x86. x86 apps run on x86.

Link to comment
Share on other sites

I don't think there should be different markets based on process architecture. However, I do think Windows and Windows Phone stores should both use the same store. It's irritating to have to buy the same app twice for different devices and MS should have done more to avoid this separation.

  • Like 3
Link to comment
Share on other sites

huh? that's already how it is. when you compile a winrt app,you can get 2 binaries. one for arm,and one for x86. most of the time you don't have to do any code modifications at all. arm binaries will only show on arm devices,and x86 binaries will only show on x86 devices.

This is correct, but only for C++ apps. For C# and HTML/JS script apps there is only one binary because the code is JITed at runtime.

Also they are working on merging the stores/platforms. The platforms already share much of the same Windows Core and runtimes/APIs. Part of Blue is to expand this even more so the APIs are the same on both platforms. Once this happens it will be easy to run apps from the different stores on each other. At that point they can probably merge the stores completely.

Link to comment
Share on other sites

This is correct, but only for C++ apps. For C# and HTML/JS script apps there is only one binary because the code is JITed at runtime.

Also they are working on merging the stores/platforms. The platforms already share much of the same Windows Core and runtimes/APIs. Part of Blue is to expand this even more so the APIs are the same on both platforms. Once this happens it will be easy to run apps from the different stores on each other. At that point they can probably merge the stores completely.

correct sir

Link to comment
Share on other sites

This would clear up the ambiguity in app development and pricing which would in turn give app devs less headache.

Your suggestions just create more headaches. Why should an app developed for the Surface RT not work on Surface Pro?

Link to comment
Share on other sites

I thought Windows Phone 9 was meant to combine the app stores as one or something?

Nope, that change is for Blue (however, it is a rumor).
Link to comment
Share on other sites

Your suggestions just create more headaches. Why should an app developed for the Surface RT not work on Surface Pro?

My thoughts are:

1. Functionality - Tablet and it's app interface is scaled down and can't really do much. All we see are some glossy ish...

2. Pricing: Yes, pricing. We all know how much a game cost on mobiles (I am talking about high end games of almost 2GB in size even though they are also scaled down for Mobile devices but for PC, they are full blown). I don't think these games will be priced same?

3. Consumer Rip-Off: Why the heck do I have to pay for a glossy app on a mobile device twice?

These thoughts led to my "assumption" that Windows Phone and Windows RT be merged in order to pay same for these scaled down apps. I am not saying my assumption is the best. I am only trying to figure out how it could be done better.

Link to comment
Share on other sites

This topic is now closed to further replies.