Posts Tagged‘developers’

Microsoft’s Jupiter: A Panacea to Developer’s Ills.

If you’re a Windows developer the past few months of Microsoft’s various announcements about Windows 8 and the future of their developer ecosystem haven’t been particularly kind to you. With Microsoft announcing that their new Windows Phone 7 inspired UI for Windows 8 will be based on HTML5 and JavaScript many were left wondering if the heavy investment they had made Silverlight and .NET technologies was going to be wasted. It didn’t help matters much when Microsoft told everyone to wait until BUILD in September for more details, which let speculation run rampant amongst the community.

However it has come to my attention that Microsoft has been hinting at a potential panacea for all these woes, for quite some time now.

Back in January there were many rumours circling around the new features we could look forward to in Windows 8. Like any speculation on upcoming products there’s usually a couple facts amongst the rumour mill, usually from those who are familiar with the project. Two such features which got some air time were Mosh and Jupiter, two interesting ideas that at the time were easily written off as either speculation or things that would never eventuate. However Mosh, rumoured at the time to be a “tiled based interface”, turned out to be the feature which caused the developer uproar just a couple months ago. Indeed the speculation was pretty much spot on since it’s basically the tablet interface for Windows 8, but it also has a lot of potential for nettops and netbooks since underneath the full Windows 8 experience is still available.

The Jupiter rumour then can be taken a little bit more seriously, but I can see why many people passed it over back at the start of this year. In essence Jupiter just looked like yet another technology platform from Microsoft, just like Windows Presentation Framework and Silverlight before it. Some did recognize it as having the potential to be the bridge for Windows 8 onto tablets which again shoe horned it into being just another platform. However some did speculate that Jupiter could be much more than that, going as far to say that it could be the first step towards a unified development platform across the PC, tablet and mobile phone space. If Microsoft could pull that kind of stunt off they’d not only have one of the most desirable platforms for developers they’d also be taking a huge step forward towards realizing their Three Screens philosophy

I’ll be honest and say that up until yesterday I had no idea that Jupiter existed, so it doesn’t surprise me that many of the outraged developers wouldn’t have known about it either. However yesterday I caught wind of an article from TechCrunch that laid bare all the details of what Jupiter could be:

  • It is a new user interface library for Windows. (source)
  • It is an XAML-based framework. (source)
  • It is not Silverlight or WPF, but will be compatible with that code. (source)
  • Developers will write immersive applications in XAML/C#/VB/C++ (sourcesourcesource,source)
  • It will use IE 10′s rendering engine. (source)
  • DirectUI (which draws the visual elements on the screen, arrived in Windows Vista) is being overhauled to support the XAML applications. (sourcesource)
  • It will provide access to Windows 8 elements (sensors, networking, etc.) via a managed XAML library. (source)
  • Jupiter apps will be packaged as AppX application types that could be common to both Windows 8 and Windows Phone 8. (sourcesourcesourcesource)
  • The AppX format is universal, and can used to deploy native Win32 apps, framework-based apps (Silverlight, WPF), Web apps, and games (source)
  • Jupiter is supposed to make all the developers happy, whether .NET (i.e., re-use XAML skills), VB, old-school C++ or Silverlight/WPF. (Source? See all the above!)

Why does Jupiter matter so much? If it’s not clear from the technical details above, it’s because Jupiter may end up being the “one framework” to rule them all. That means it might be possible to port the thousands of Windows Phone apps already written with Silverlight to Windows 8 simply by reusing existing code and making small tweaks. Or maybe even no tweaks. (That part is still unclear). If so, this would be a technical advantage for developers building for Windows Phone 8 (code-named “Apollo” by the way, the son of “Jupiter”) or Windows 8.

In a nutshell it looks like Microsoft is looking to unify at all of the platforms that run Windows under the Jupiter banner, enabling developers to port applications between them without having to undergo massive rework of their code. Of course the UI would probably need to be redone for each target platform but since the same design tools will work regardless of the platform the redesigns will be far less painful then they currently are. The best part about Jupiter though is that it leverages current developer skill sets, enabling anyone with experience on the Windows platform to be able to code in the new format.

Jupiter then represents a fundamental shift in Windows developer ecosystem, one that’s for the better of everyone involved.

We’ll have to wait until BUILD in September to find out the official word from Microsoft on what Jupiter will actually end up being, but there’s a lot of evidence mounting that it will be the framework to use when building applications for Microsoft’s systems. Microsoft has a proven track record of creating some of the best developer tools around and that, coupled with the potential to have one code base to rule them all, could make all of Microsoft’s platforms extremely attractive for developers. Whether this will translate into success for Microsoft on the smartphone and tablet space remains to be seen, but they’ll definitely be giving Apple and Google a run for their developers. 

Windows 8: The Death of the Silverlight Ecosystem?

It’s only been just over a week since Microsoft demoed their latest iteration of the Windows platform but in that short amount of time it’s already managed to stir up quite a bit of discussion from friends and foes alike. The foes were quick to call out the new OS’s tablet envy, conveniently forgetting Microsoft’s rhetoric that the next version of Windows after 7 was going to have a much more web centric focus, with the possibility of it being entirely cloud based. More interesting however is the discussion arising from long term developers on the Microsoft platform, and it’s not the kind of adulation and praise you’d normally expect.

During the D9 conference Microsoft said that the new tile mode in Windows 8 was based around HTML5 and Javascript applications. Whilst they did mention that all current apps built on the .NET platform should run as intended when running in the familiar desktop mode they made no mention of whether or not the .NET and Silverlight platforms could be used to create applications in the new style of interface. With Microsoft traditionally being quite favorable to developers the notion of having to re-skill to HTML5 and Javascript (not to mention reworking existing codebases) came as quite a shock to a lot of developers and their reaction was akin to an open revolt on the forums.

Rampant speculation soon followed and wasn’t helped by the fact that Microsoft has asked everyone to remain calm until their BUILD developer conference in September. It’s not the first time this sort of thing has happened either, a similar level of hubbub was roused when Microsoft was coy about Silverlight’s future when talking about Internet Explorer 9 and it’s dedication to web standards. They soon came out saying that they still saw a future in Silverlight, especially for the Windows Phone 7 platform, but many of them were left unconvinced. It’s then quite likely that this second round of doubt that Microsoft has cast over their third party developer’s futures was the straw that broke the camel’s back and all the blame is being leveled squarely at Microsoft.

For what it’s worth I feel their concerns are valid if the reaction to them is somewhat overblown. Microsoft has a long history of eating its own dog food and many of their client facing applications are built upon the technologies that so many are worried are going to disappear in the near future. The best example of this is their Windows Azure management console which is built entirely on Silverlight. Couple that with the fact that Microsoft has many partners with a very heavy investment in the platform and I find it hard to jump on the “Silverlight is dead” bandwagon, but that doesn’t necessarily mean Microsoft is committed to bringing Silverlight into the Windows 8 tablet world.

Sure it would be great to be able to create Silverlight applications on the new Windows 8 tile system and Microsoft would be leveraging off a lot of preexisting talent to help drive adoption of the platform. However it would also hinder Microsoft’s adoption of web standards, as many developers would favor using proprietary Microsoft technologies instead of attempting to reskill. They’d then be the slave of two masters: on the one hand the Silverlight crowd demanding ever more features and tools that are constrained to that platform and on the other the web standards crowd that has been Microsoft’s bug bear ever since alternative browsers started to gain real market traction. It’s not like Microsoft doesn’t have the resources to deal with this though, but I can understand their motivations should they want to eschew Silverlight in favour of a more standard environment.

So is this the end of the line for the Silverlight ecosystem and the developers who built their skills around it? Hard to say, with Microsoft being mum on it for the next few months we’ll just have to play it by ear until we get more information from them. In all honesty even if they do end up dropping Silverlight for HTML5 and Javascript I’d expect that the next release of Visual Studio would bring enough tools and resources with it to make the transition much easier than everyone is making it out to be. Hell if Adobe can build a Flash to HTML5 converter then it’s quite possible for Microsoft to do the same for Silverlight, even if that’s just a band-aid solution to satisfy developers who refuse to reskill.

 

Experience, Not The Platform, Is What Makes The Developer.

I spent a lot of time, probably way too much of it, watching the start-up scene and getting a feel for the current trends of what’s hot and what’s not¹. Increasingly I find myself on the other side of the fence since I’m wholeheartedly a Microsoft supporter and everyone else seems to be into Linux, Rails and varying forms of Javascript like Node.JS. Sure there’s a great many websites built on these frameworks and the stuff people are able to churn out with them in seemingly little time at all certainly makes me feel like a total idiot when I’m floundering around in ASP.NET. But in reality those proclaiming that they created these things in just a weekend or could deploy a new app within minutes are often hiding one crucial fact from you.

The multiple years of experience that came prior to it.

It’s no secret that whilst I’ve been developing for a long time I’m no rockstar when it comes to the world of web programming. Indeed my first foray into this world was a bastard of a page that was lucky not to fall on its face constantly and the experience had me running to find better solutions, eventually falling to Silverlight. The reason for this was obvious, it allowed me to leverage my desktop development experience into a new platform. Sure I struggled with the ideas that just couldn’t be boiled down into the desktop world (like that whole REST thing) but it was a quick way to get myself into this world and expand from there.

So of course when I saw people saying they built this incredible website in only a weekend when it took me several months worth of weekends just to get mine working I was intrigued. I even made the foolish mistake of reading up on some of their “how I did it” posts on Hacker News and saw all these wonderful frameworks that they had been using, assuming this would make me a master overnight. Stepping through some of the tutorials and looking at the tools available started to raise some eyebrows since they were unlike anything I had seen before, and this is where I got suspicious.

You see I could whip up a simple desktop app or PowerShell script in minutes that would do some function using the tools I have in front of me, but that doesn’t mean you should be using those tools to create your site. Neither does that mean you would be able to whip up the same thing using the same tools in the same amount of time, no matter how skilled you were in other languages. The simple reason for this is that whilst you might be a rockstar in ruby or an expert in PHP your experience is confined to the environment to which you’re most accustomed and should you need to retool and reskill for a new language it’s going to be several months before you’re at your maximum competency again.

Sure good developers are able to adapt much faster than so-so developers but there’s a significant opportunity cost in switching away from your current knowledge comfort zone in order to try and emulate those who you idolize. I came to this realization a couple months back after staring at so many Ruby/Python/SomeDynamicLanguage web sites, wondering at how the heck they got them looking and functioning so well. In truth the platform they were using had little to do with it, these guys had just been in the game for so much longer than me that they knew how to get these things done. With me still in the grok stage of my first really truly web framework I really shouldn’t be comparing myself to them just yet, not at least until I can get my new application functioning the way it should.

It’s so easy to get disillusioned with what you’re doing when you see others progressing so much faster than you ever thought you could. My new application was supposed to be a testament to my coming of age as a web developer, having giving myself only a short time to get it off the ground before actually launching it. Since my deadline for that has come and past I’ve been forced to change the way I view myself as a developer and have come to realize that unless I’m working in something I’ve developed with before I shouldn’t expect myself to be a rockstar from day one, instead recognizing that I’m still learning and pushing through the pain barrier until I become the rockstar I thought I was.

¹If you’re interested, what’s hot right now is photo sharing apps. What’s not? Location apps, go figure.

Poisoning The Well That Once Sustained You.

A company is always reliant on its customers, they’re the sole reason that they continue to exist. For small companies customers are even more critical as losing one for them is far more likely to cause problems than when a larger company loses one of theirs. Many recent start ups have hinged on their early adopters not only being closely tied to the product so that they form a shadow PR department but also many of them hobbyist developers, providing additional value to their platform at little to no cost to them. Probably the most successful example of this is Twitter who’s openness with their API fostered the creation of many features (retweets, @ replies, # tags) that they had just never seen before. It seems however that they think the community has gone far enough, and they’re willing to take it from here.

It was about two weeks ago when Twitter updated their terms of service and guidelines for using their API. The most telling part about this was the section that focused on Twitter clients where they explicitly stated that developers should no longer focus on making new clients, and should focus on other verticals:

The gist of what Sarver said is this; Twitter won’t be asking anyone to shut down just as long as they stick within the required api limits. New apps can be built but it doesn’t recommend doing so as it’s ‘not good long term business’. When asked why it wasn’t good long term business, Sarver said because “that is the core area we investing in. There are much bigger, better opportunities within the ecosystem”

Sarver insists this isn’t Twitter putting the hammer down on developers but rather just “trying to be as transparent as possible and give the guidance that partners and developers have been asking for.”

To be honest with you they do have a point. If you take a look at the usage breakdown by client type you’ll notice that 43% of Twitter’s usage comes from non official apps, and diving into that shows that the vast majority of  unofficial clients don’t drive that much traffic with 4 apps claiming the lion’s share of Twitter traffic. A developer looking to create a new client would be running up against a heavy bit of inertia trying to differentiate themselves from the pack of “Other Apps” that make up the 24% of Twitter’s unofficial app usage, but that doesn’t mean someone might not be capable of actually doing it. Hell the official client wasn’t even developed by Twitter in the first place, they just bought the most popular one and made it free for everyone to use.

Twitter isn’t alone in annoying its loyal developer following. HTC recently debuted one of their new handsets, the Thunderbolt.  Like many HTC devices its expected that there will be a healthy hacking scene around the new device, usually centered on th xda-developers board. Their site has really proved to be invaluable to the HTC brand and I know I stuck with my HTC branded phones for much longer than I would have otherwise thanks to the hard work these guys put in. However this particular handset is by far one of the most locked down on the market, requiring all ROMs to be signed with a secret key. Sure they’ve come up against similar things in the past but this latest offering seems to be a step above what they normally put in, signalling this a shot across the bow of those who would seek to run custom firmware on their new HTC.

In both cases these companies had solid core products that the community was able to extend upon which provided immense amounts of value that came at zero cost to them. Whilst I can’t attribute all the success to the community it’s safe to say that the staggering growth that these companies experienced was catalyzed by the community they created. To suddenly push aside those who helped you reach the success you achieved seems rather arrogant but unfortunately it’s probably to be expected. Twitter is simply trying to grab back some of the control of their platform so they can monetize it since they’re still struggling to make decent revenues despite their huge user base. HTC is more than likely facing pressure from carriers to make their handsets more secure, even if that comes at the cost of annoying their loyal developer community.

Still in both these situations I feel like there would have been a better way to achieve the goals they sought without poisoning the well that once sustained them. Twitter could easily pull a Facebook maneuver and make all advertising come through them directly, which they could do via their own in house system or by simply buying a company like Ad.ly. HTC’s problem is a little more complex but I still can’t understand why the usual line of “if you unlock/flash/hack it, you’re warranty’s void” wasn’t enough for them. I’m not about to say that these moves signal the down fall of either company but it’s definitely not doing them any favors.

Resistance is Futile, Integration is Inevitable.

Enabling your users to interact with your application through the use of open APIs has been a staple of the open web since its inception over a decade ago. Before that as well the notion of letting people modify your product helped to create vast communities of people dedicated to either improving the user experience or creating features that the original creators overlooked. I can remember my first experience with this vividly, creating vast levels in the Duke Nukem 3D level creator and showing them off to my friends. Some of these community developed products can even become the killer feature of the original application itself and whilst this is a boon for the application itself it pose some issues to the developer.

Probably the earliest example I can think of this would have to be World of Warcraft. The client has a pretty comprehensive API available that enabled people to create modifications to do all sorts of wonderful things, from the more mundane inventory managers to boss timer mods that helped keep a raid coordinated.  After a while many mods became must haves for any regular player and for anyone who wanted to join in the 40 persons raids they became critical to achieving success. Over the years many of these staple mods got replaced by Blizzard’s very own implementations of them ensuring that anyone that was able to play the game was guaranteed to have them. Whilst most of the creators weren’t enthused that all their hard work was now being usurped by their corporate overlords many took it as a challenge to create even more interesting and useful mods, ensuring their user base stayed loyal.

More recently this issue has come to light with Twitter who are arguably popular due to the countless hours of work done by third parties. Their incredibly open API has meant that anything they were able to do others could do to, even to the point of them doing it better than them. In fact it’s at the point where only a quarter of their traffic is actually on their main site, the other three quarters is from their API. This shows that whilst they’ve built an incredibly useful and desirable service they’re far from the best providers of it, with their large ecosystem of applications filling in the areas where it falls down. More recently however Twitter has begun incorporating features into its product that used to be provided by third parties and the developer community hasn’t been too happy about it.

The two most recent bits of technology that Twitter has integrated have been the new Tweet button (previously provided by TweetMeme) and their new link shortening service t.co which was handled by dozens of others.  The latter wasn’t unique to Twitter at all and whilst many of the new comers to the link shortening space made their name on Twitter’s platform many of them report that it’s no longer their primary source of traffic. The t.co shortener is then really about Twitter taking control of the platform that they developed and possibly using the extra data they can gather from it as leverage in brokering advertising and partnership deals. The Tweet button however is a little bit more interesting.

Way back when news aggregator sites were all the rage. From Digg to Del.icio.us to Reddit there were all manner of different sites designed around the central idea of sharing online content with others. Whilst the methods of story aggregation differed from service to service most of them ended up implementing some kind of “Add this story to X” button that could be put on your website. This served two purposes: it helped readers show a little love to the article by giving it some attention on another site and secondly it gave content to the other site to link to, with little involvement from the user. The TweetMeme button then represented a way to drive Twitter adoption further and at the same time get even more data on their users than they previously had before. Twitter, for what it’s worth, said they licensed some of the technology from TweetMeme for their button however they have still in essence killed off one of their popular services and that’s begun to draw the ire of some developers.

The issue many developers take with Twitter building these services into their main product is because it puts a chilling effect on products based on Twitter’s ecosystem. Previously if you had built something that augmented their service chances were you could build yourself quite the web property. Unlike other companies which would acquire these innovator’s companies in order to integrate their technology Twitter has instead taken to developing the same products themselves, in direction competition with those innovators. The reasons behind this are simple, Twitter simply doesn’t have the cash available to do acquisitions like the big guys do. They’re kind of stuck between a rock and a hard place as whilst they need to encourage innovation using their platform they can’t let it go on forever, lest they become irrelevant past delivering an underlying service. Realistically the best option for them is to start generating some cash in order to start acquiring innovator’s technology rather than out competing them but they’re still too cash poor for them to this to be viable.

In the end if you build your product around someone else’s service you’re really putting yourself at their mercy. The chill that Twitter is putting on their developers probably won’t hurt them in the long run should they not continue to copy other’s solutions to their problems however their fledgling advertising based business model is at odds with all the value add developers. Twitter is quite capable of doing some impressive innovation on their own (see #newtwitter) but their in house development is nothing compared to the hordes of third parties who’ve been doing their part to improve their ecosystem. I’m interested to see what direction they go with this, especially so since I’m working on what could be classed as a competing service.

Although I’m hoping people don’t see it that way 😛

Apple Caves Under Developer Pressure.

Apple’s policies for the App Store have always been a bit vague and uneven, leading to quite a few good headlines over what apps got rejected and which ones got in. I put it down to the human element in the review process as one reviewer’s biases need not line up with another. Still though the developers worked out the inputs and outputs of the application review process and if your app was useful, family friendly and didn’t go rampaging through private APIs you were golden. Apple, not content with the amount of control it was already exerting over its developers, then decided to up the ante by banning all cross platform frameworks putting a big question mark over some of their most successful applications and developers.

The whole thing can be traced back to Apple’s public flamewar with Adobe. I’m not really sure what triggered this decision in the first place (although it smacks of Jobs’ idealism) but they did it with precise timing, just a few days before Adobe was to announce their Flash to iPhone app packager for CS5. Perhaps the idea of a torrent of applications hastily converted from flash onto the iPhone was a bit too much for them to bear but in casting their net so wide they caused many people to become hesitant about developing on the platform, especially those who found great success using such 3rd party frameworks.

Apple began doing some damage control in order to ensure that they wouldn’t lose some of their biggest money earners. They gave unofficial word that frameworks such as Unity3D were safe since they generated an actual iPhone application and didn’t require use of an intermediate interpreter. Still since coding in Unity3D is done in C# this ran up against yet another draconian rule that all iPhone applications must be written in one of the sanctioned C based languages. With Android starting to pick up at a phenomenal pace there’s no doubt that Apple began to rethink their stance on many of these matters with hopes of winning back the developers they had once scorned.

Last week saw Apple release what amounts to their set of principles and guidelines that are applied when reviewing apps that will make it onto their app store. You can get the full pdf of all the guidelines here and it makes for some interesting reading. Most of them are just formalisation of the rules that most developers knew about but couldn’t get solid verification from Apple that it was a hard and fast rule. Probably the biggest coup in this whole document is they abandoned their previous stance on not allowing any cross platform libraries, allowing such applications through as long as they didn’t download any code:

The black box that is the Applereview process is creaking open. In a very brief release, Apple has essentially relaxed the requirement that developers use Apple’s own development tools “as long as the resulting apps do not download any code.” They’ve also published some review guidelines, allowing programmers to understand just what will go on behind the curtains in Cupertino.What does this mean? Well, in the updated SDK license, circa April of this year, a number of paragraphs essentially bannedoutside development tools including systems that ported Flash, Silverlight, Java, and other platforms to the iPhone. Now, presumably, any app that runs on the iPhone, regardless of source, will be considered. The language is so mushy that it’s still unclear what this means.

On the surface it would appear that Apple has backpeddled on their previous stance. Indeed the news was enough for Adobe to state that they were going to restart developing their Flash to iPhone packager which had been shelved after Apple hamstrung it earlier this year. The not downloading any code exclusion is quite understandable as this could easily be exploited as an attack vector by a malicious third party. Still most attackers wouldn’t bother with an app (that leaves a paper trail) since the browser on the phone will happily download code and run it. But I’m sure Apple knows that already.

For what its worth it seems like Apple is finally caving into the developers who helped them make their products so successful and rightly so. Developing something for an Apple product has always been about the end user, much to the detriment of those creating for those users. This is in stark contrast to Google who’s always been about the developers, favouring their freedom to develop however they want with almost no thought to the user experience. Both approaches have their pluses and pitfalls but in the end if you don’t have developers you’re going to have a hard time attracting users to your platform.

Will this lead to a flood of low quality applications on the app store and the fiery death of the user experience on the iPhone? Most likely not as there’s already enough crap on the app store to make sure that any poorly ported Flash app will be lost amongst the noise. Realistically anyone looking to publish on the iOS platform knows what they’re getting into and will redesign the app as such, lest they get bad reviews that ultimately bury their app completely. In the end I think it’s just Apple realising that the road they were going down wasn’t going to do them any favours and the rising star of Android is beginning to look attractive enough for some to make the switch.

The question now is though, will they keep their hard line on Flash? Time will tell.

Windows Phone 7: An Inertial Juggernaught.

6 months ago saw the announcement of Microsoft’s attempt to remain relevant in the smartphone space: Windows Phone 7. At the time I poked fun at it the fact that it was basically Microsoft’s interpretation of what the iPhone would’ve looked like if they made it but realised that the platform had potential. If there’s one thing Microsoft is good at its throwing money at a problem until they eventually get it right, like with the Xbox (are they even making money on the consoles yet?) and Windows Phone 7 seemed to be one of those kinds of problems. One thing that it did have going for it was the fact that a Windows developer like me could code for the device without reskilling too much and that’s where the real power is.

As much fun as it is to learn a new platform it’s still a giant barrier to building an application on a new platform. I haven’t done any development on any mobile clients yet purely because the two major ones I want to target use a language that I’m not familiar with. Sure there are cross platform libraries that might help to ease the learning curve but unfortunately they’ve been hamstrung by Apple’s restrictions and aren’t fully compatible with my IDE of choice, Visual Studio. So for any enterprising developer looking to build a mobile application there’s always an initial hump to get over in order to be an effective developer on the platform. That or you shell out some dollars to get someone else to do it for you, but not everyone can afford that.

If you were just to look at the number of developers working on any platform, whether it was mobile/desktop/web/whatever, the largest group would arguably be those working on Windows. With the number of desktops, laptops and other devices running some form of Windows exceeding 80% of the total computers worldwide the number of developers working on that platform far outnumbers that of any other. Microsoft knows this and whilst anti-trust legislation will prevent them from using their current monopoly on the desktop to leverage into the mobile space that won’t stop them from making it damn attractive for developers to gravitate to the Windows Phone 7 platform.

Now I’ve been a developer for a while, about 6 years as an amateur and maybe half that as being paid to do it as part and parcel of my usual system admin responsibilities. In that time I’ve used my share of environments, languages and platforms and out of the lot the one that I keep coming back to is Visual Studio. Whilst some might hate me for this next comment Microsoft’s tools just make coding things so damned easy to the point where there’s nothing I don’t think I’m a tutorial away from being able to do myself. Microsoft knows this and the past few months have seen them trying to lure their developers over to the mobile space with things like free development environments only seeking to charge you once you’re sign up for their marketplace.

They just don’t stop there either. Microsoft made headlines about a month ago when they gave each and every one of their employees a new WP7 phone. It was however a veiled gift as it came with the instructions that not only should they evangelize them amongst their friends but also develop apps for them in their spare time. With Microsoft having 89,000 employees this is no small number of handsets and whilst not all of them are developers (I’d hazard a guess at 30~40%) there’s still enough of them there to have their numbers brushing up against both the iPhone and Android platforms. That doesn’t even include potential developers outside Microsoft who might just start developing for WP7 if it takes off merely because it would be easy to do so. Realistically if Microsoft can harness the power of their developer base in the same way Apple did with theirs they could really pull themselves around in the mobile space, maybe even turning it into a 3 horse race.

The question is of course whether or not the teaming masses of Windows developers will find any point in developing for the mobile space. It can be argued that many desktop applications, where the vast majority of Windows application developers reside, can’t be transitioned onto a mobile platform in any useful way. Realistically if any developer was looking to tackle the mobile market they would have done so already and consequently have substantial investment in their platform of choice. Still the ease at which WP7 applications can be developed using existing skills and knowledge means that the platform might just become dominate because it brings developers to the mobile space that would have never considered it before. Since it can be argued that Windows Mobile is arguably the same thing as WP7 (just not as sexy) it’s going to take a bit more wooing from Microsoft to draw those reluctant developers over and in the lead up to the first WP7 phone hitting the markets will show them doing just that.

Personally I’m still excited about it. I’ve tried to develop simple applications for Windows Mobile before and it was always a royal pain in the ass. The new Windows Presentation Framework based interface for WP7 means that developing code for them will be that much easier. Additionally the integration with existing code bases will mean that the kinds of functionality that would usually have to be developed for the specific platform can now be leveraged with minor modifications, something that I know will at least have developers playing around with WP7.

And that is what has the potential to make WP7 the dominant player in the mobile space.

Multi-Platform Development: Wise or Chumptastic?

Choosing a target platform when you develop an application is a big decision as your choice will influence many design decisions, make certain tasks easier and relegate some things to the realm of the impossible. For those of us with a managerial bent this dilemma is usually solved with a simple cost/benefit analysis, I.E. which of these platforms can net us the greatest revenue for the smallest cost? Usually this comes down to how large a particular user base of a platform is (although that’s not everything, as I’ve pointed out) as that translates into the largest number of potential sales. However the advent of application distribution channels such as the App Store and Xbox LIVE Marketplace has complicated this metric somewhat, especially for those developers making it on their own.

For large development houses the biggest market still appears to be the way that many of them gauge which platform to target first. One of the greatest examples of this is Call of Duty: Modern Warfare 2 as it owes its success to its beginnings on the PC. However the lack of dedicated servers angered the PC crowd who thought that their omission was a travesty against them and that their outrage was enough to sway Infinity Ward to change their minds. However if you took a look at the sales numbers PC copies of the game accounted for a  very small percentageof their overall sales putting that platform squarely in the minority. The developers rightly (from a managerial perspective) ignored the complaints as the additional work to develop the requested features would have far outweighed the potential sales that they could have derived. Still they catered to 3 platforms simultaneously as the opportunity cost for cross development for them was low thanks mostly to code portability between the Xbox and PC.

When you switch over to the other end of the spectrum the cost vs benefit analysis takes on a different form. You see in large organisations you have the benefit of being able to hire on people with the various skill sets required to develop a product for a targetted platform. If you’re lashing out on your own you are faced with the choice of either developing for what you know or training yourself up on the platform that you wish to target. Whilst most skilled developers won’t take long to become proficient when you’re looking to generate income every moment you spend not developing product is a sunk cost. Logic then dictates that you stay with what you know first before attempting to branch out into other areas lest you waste a significant amount of time developing a product that doesn’t suit your target platform.

You can see this kind of behaviour quite clearly in the mobile development space with a mere 2.6% of Android and iPhone developers having it both ways:

The answer (approximated in the graphic below) surprised us: of the nearly 55,000 mobile developers in our database over 1,000 (1,412, to be exact) had already publishedapps on both iOS and Android. This represents more than 3% of the published iOS developer population, and nearly 15% of the published Android developer group.

Despite the impressive total, we worried that it would be too easy for the fanboys on both sides of the aisle to dismiss these numbers as a crackpot minority. So we dug a little deeper, using our AppRank methodology to stack rank this cross-platform developer group based on the total volume and quality of coverage they’d received among the leading tech blogs worldwide.

Anecdotally the pattern I’ve seen is that most cross platform applications actually have their roots in a single platform. Take for instance the indy smash hit Braidwhich made its debut on the XBox LIVE platform. Whilst it was initially planned for a Windows release it took quite a while for it to make it to that platform. It has also made it onto the PS3 but not until long after it had proven success on 2 other platforms. My inkling is then that many of these cross platform developers started out as single platformers and as they had success in one they decided it was worth their time to attempt another one. Few, if any at all, would attempt to do more than one platform right from the get go.

So the question remains, is cross platform development actually worth it? For people like me probably not initially. The additional work to create a product for multiple platform not only increases the initial amount of work required it will also increase the on-going maintenance time for each of the individual versions. It seems like the best idea is to write and polish your application on your platform of choice and then, should you find success, begin the process of porting it over. This goes double if you’re looking to make some cash off a platform as the sunk costs of development and reskilling are one of the quickest ways to kill a potential revenue stream before it’s fully realized.

Symbian: The Ignored Giant.

Market research is a great way to procrastinate. I’ve spent quite a lot of time getting to know what platforms I should be targeting just so that I don’t waste my actual development time on building something that no one will bother using. In this time that would have been better spent actually coding something I’ve come to notice an interesting trend in the world of mobile applications: everyone seems to be ignoring the biggest market of them all, Symbian. Owned by Nokia Symbian smart phones still dominate the market with over 45% market share which dwarfs all of its competitors to the point of being more than RIM (Blackberry) and iPhone combined. So why isn’t every other developer jumping at the opportunity to exploit this market to the point that they have done for the likes of Android and the iPhone? The answer, to me at least, has its roots in simplistic ideals but overall is quite convoluted.

At its heart the neglect of the Symbian platform can be traced back to one thing: money. Symbian has been around for quite some time (its ancestors can be found as far back as the late 1980s) although its current incarnation in the world of smartphones made its first appearance back in 2001, opening up a world where a phone’s capabilities could be expanded by the installation of third party applications. Its release was closely followed by the first release of PocketPC (later renamed Windows Mobile) that supported smartphones but Symbian still had the upper hand thanks to its uptake with many of the large phone manufacturers. As time went on Symbian found its way onto nearly all of Nokia’s advanced handsets which, coupled with their easy to use interface and overwhelming feature sets, led to astonishing popularity with the 100 millionth Symbian handset being sold only 5 years later with total shipments today exceeding 390 million.

Still unlike the iPhone or Android platform there really wasn’t any incentive to develop for them. The segmentation of both the Symbian and Windows Mobile market was and still is quite vast with no real guarantee of what features or specifications one phone might have. Whilst there are still many applications that can be developed despite these limitations many developers shunned the mobile space because apart from corporate applications there was no tangible way to monetize their efforts. Then along comes the iPhone with one standard set of hardware, a large fanbase and a distribution channel with built in monetization for any developer willing to shell out the $99 fee. After that the mobile space began to open up considerably but Symbian, even with its giant market share, has yet to capitalize on the mobile application market.

This means that whilst the Symbian market might be the largest of them all its also the least likely for any developer to be able to profit from. Symbian handsets cater to a much larger market than any other, including the lower end that even Android fails to capture. Unlike Apple, which deliberately targeted a market with cash to spare, Symbian users are the least likely to pony up some cash for an application. Additionally since there’s been no real central, easy to use medium for users to get applications on their Symbian phones (I know, I tried it on my N95) the vast majority of them won’t be in the mindset to go after such an application, favouring web based applications instead.

There is also, of course, the technical challenge behind building an application on these platforms. Whilst I’ve only dabbled in Windows Mobile (which for a C# developer was incredibly easy) recent reportsshow that Symbian is not only the hardest it also requires two to three times the amount of code to complete the same application on an iPhone or Android handset respectively. Whilst learning another language is really just a lesson in semantics it still slows your development time down considerably and when you’ve got your eye on making some money from your venture a steep learning curve will be a major barrier to entry. There has been some work to reduce this somewhat with the integration of the S60 platform with the open source cross platform library QT, but my previous experiences with that framework don’t make me so hopeful that it will make developing for Symbian any easier.

The ignored giant Symbian is an interesting phenomenon as intuition would tell you that the largest install base would drive the largest secondary markets. As a developer I still find it hard to ignore the call of almost 400 million devices that could possibly run my software but knowing a few people who own Symbian devices (read: they use their phone as a phone, not much else) I still feel like my effort would be better spent elsewhere. As time goes by it will be interesting to see if Symbian can continue to hold onto its dominance in this space or if they will eventually lose out to the young upstarts Android and iOS.