So the Windows 7 phone launched recently, to much fanfare but not huge initial sales – reports were as low as 40k initial sales on launch day. I dare say they are larger than that but still, MS has to be disappointed with those kinds of numbers on the outset.
However, to give it it’s fair due, having played with a friends Win7 phone for a bit, this really is a nice piece of kit. The UI is finally where is needs to be and the whole experience is pretty much on a par with the iphone, even if functionally it is not – lack of cut and paste, small irritations like that. Overall it’s definitely a worthy competitor, no question.
But for lots of mobile devs, on closer examination, there is a hidden gotcha that absolutely astounded this author upon discovery.
All development on the windows mobile has to be done in XNA / C#. The Windows Mobile experience is basically a platform where you build CLR assemblies of what is basically pseudo asm code, which is then recompiled at run time into a native platform binary code.
What that difficult-to-parse sentence means, at root, is that all that mountains of C, C++ and potentially Objective C code that already exists for apps/games on other platforms cannot be ported across to the Windows 7 mobile platform. You have to rebuild from scratch. If you are a developer, you begin to see where I am going with this.
So why is MS doing this? From thinking and asking I’ve come to the conclusion that the reasoning behind this is many fold, to whit :-
1) You get automatic access to all the Xbox Live api’s that already exist in the XNA environment for the Xbox 360. This isn’t to be sneezed at – high score tables, achievements and so on, plus the entire infrastructure is there to expand on. There’s a lot there and it also gives rise to the idea of linking a mobile implementation with an XBox 360 implementation – sharing of data or game play.
2) MS gets to hide the metal. Any developer who was around in the early 90’s,- or indeed is mainly a PC developer today, – will know the pain of the compatibility lab testing. Where you have to deal with many strains of video card drivers, sound cards, memory and CPU combinations and so on. Even today, when DirectX has pretty much taken over as the graphical api of choice on the PC, there are still lots of little gotcha’s that developers have to take into account to handle the wide diverse abilities of the all the PC’s out there. Smart phones are heading in this direction – traditional handsets have already been there for years. It’s not unusual to have over 50 different sku’s for a java based game for different handsets – and now smart phones (particularly android) are heading in this direction. If you can’t control the hardware you run on (as Apple does) then you have to support everything, and that’s time consuming and painful for the developer.
In this situation a developer never really needs to know anything deeply specific about the hardware (some assumptions are necessary, but that’s in the spec for the platform anyway – you will *always* have X memory and some degree of hardware graphical acceleration). This frees up developers from having to worry about targets – he doesn’t care if this is a phone, an MS XNA driven tablet or an XNA enabled Internet Fridge – and lets them concentrate on the game instead, plus giving MS the ability to push this platform onto more varied physical platforms without worrying about the developers code running on it.
3) Exclusives. As Sony no doubt thought with the PS3, the more different and specific your platform is, the more specific and exclusive developers will be on it. If you can’t write code to easily port to other platforms then you tend to stay on whatever platform you are comfortable with, has the best tools and cuts the best deals in terms of royalties OR who has the biggest install base.
4) Tools. Pretty much all the development tools for XNA exist now, are in constant use and will be familiar to those who’ve done any XNA (or to a certain degree, C++) coding for the Xbox 360. There’s familiarity in them there hills!
5) Run Time expansion. This ones a bit technical – but as it was explained to me, XNA’s Just In Time compiler system will actually page bits of the code in and out of memory as they are used – so effectively you can have a much larger executable than memory in the target device and XNA will just ‘handle it’.
6) Competition for Android. MS is less worried about Apple in this scenario simply because Apple is both a hardware and a software company. MS is purely a software company, so it must provide a platform that can run in multiple different hardware configurations. But so is Google, and frankly they’ve stolen a march on Microsoft here – there are Android phones all over the place, Android tablets appearing and MS has almost nothing in the market to match. So they need to develop a platform similar to Android to at least compete – and I dare say they see XNA as that.
So yeah, it’s understandable why MS went this way. But, there’s some definite cons to the whole situation too.
Firstly, the idea that the JIT compiler will produce decent code is fairly unrealistic. It’ll produce workable code that’ll run, but optimised for a specific platform? It’s taken 10 years to produce decent compilers for X86 and that’s been around for many years. The idea that several JIT compilers will produce optimal code for their specific platform is fairly unlikely. And because it’s occurring at run time, when developers have no tools to go in deep and see what’s going on, makes it that much harder to really optimise. How do you optimise pseudo assembly code when you have no idea what it’s final implementation is actually going to look like?
Secondly, the Run Time Expansion, where XNA compiles just bits of your program that are heavily used on pages out parts that aren’t – well, it’s a cute idea but really it’s a hangover from when mobile devices were far less capable than they are now. Apples IOS doesn’t have this feature and I’ve not seen anyone complaining about it? As a justification for XNA, no, not really there.
Thirdly – and most importantly – the idea of exclusives, and thereby the implication of the push down to developers to only allow them MS approved dev environment and language – is the biggest “excuse me??” point. Many mobile smart phone developers develop in C++ purely in order to be able to port their stuff across platforms easily. Android operates in Java, but drops down into C++ relatively easily. IOS can be developed in Objective C and/or C / C++ – you can mix and match to your hearts content. So my big old C++ codebase that runs Zipzap on the IOS platform is almost instantly portable to the PC, Android, Mac, hell, even the PS3 if I want to spend the time doing that. But Windows 7? Nope. I have to either start from scratch with that, or use one of those C++ to C# convertors and cross my fingers that a) the code runs (and it’s unlikely given the complexity and usage of some external template libraries I have) and b) it runs well, which is also frankly unlikely.
So basically Microsoft has pushed the onus of redevelopment onto my shoulders – I cannot reuse code but must code specifically to their platform. Now this is kind of what Apple has already done with XCode and Objective C and lots of developers have accepted that – but this isn’t an apples to apples (ha! See what I did there?) comparison. There’s a phrase well known in game dev circles – Be First or Be Best. Microsoft, in this case, is neither. They are competing head on with a VERY established and VERY popular platform (IOS) and so requiring their developers to jump through very time consuming extra hoops to develop for them is a problem. You only get to push practices like that on developers if you are the best platform (and unfortunately Win7 phone sales denote that market share wise, they are decidedly not) or first – and obviously they are not here either. It’s an unfortunate fact that most of the very small 2 or 3 man shops who have made the Iphone App store what it is look at the Win7 phone, think “Yeah, I’d like to port iFart to that!” then discover the fact they would have to re-engineer from scratch and just say “Screw it”.
The lack of C++ support on Win7 mobile phones is a damning and, while a gutsy move on Microsofts part, ultimately going to result in it loosing to Apples juggernaut. And what’s worse is that it’s only this way because Microsoft has decided it has to be. There is no reason why a Win7 phone could not have a C++ code compiler on it – games would be faster and yes, although it does mean that developers may have to deal with differing target abilities, they have to deal with that with Android anyway, so scalable code is the order of the day regardless. Microsoft just has to recognise that this is desirable, as so many of the developers they ultimately depend on have already pointed out, although it’s also worth pointing out the entire infrastructure of how XNA is designed is built to NOT allow direct native code running on the target platform. XNA doesn’t even like managed C++ code very much (where C++ code is reduced out to the same set of CLR assemblies as C# code is) because the CLR code that is generated specifically and explicitly does not allow some of the features of C++, specifically to stop a C++ application from taking total control of the device.
This is definitely a David and Goliath moment, the Win7 phone vs the giant that is the Iphone / Ipad. But Microsoft is making it into a David and Goliath moment where you need to go get David a Latte and it had BETTER be a non fat milk, with whipped cream and chocolate bits, or he’s not even going to show up for the fight.
To be clear – I like this new platform and I want it to be successful. I think it’s well made, responsive and the UI is great. In an Iphone-less world, this would rule the roost. However, this is not an iphone-less world and MS seems hell bent on making life as difficult as it can be for developers, and I fear this will be the downfall of this platform.
Jake Simpson