Being a mobile developer over the past 4 years has been an interesting experience. With the advent of modern smartphones with differentiate experiences, we found out that not only is there a viable market for great apps, but that market is booming and very competitive. We have seen mobile apps that have literally changed the way we interact, live our lives and found ways to fill the lulls in our day with experiences that are both fun and addictive. And along the way, we all seemed to figure out that finding a center of gravity for all the apps within a mobile platform was an effective way to make an app popular by consumers and monetize the efforts of the developer as a result.
During that time, the web has evolved a great deal as well. The debates over which plug-ins were best were fought and then along came HTML5 (or rather the promise of HTML5) that many believe will fundamentally change the way we see the web and how we interact with content on the internet. Even though HTML5 is in its infancy (it’s not even a ratified set of standards from the W3C yet and likely won’t be for a while yet!), already we are seeing some very interesting examples of what HTML5 can bring. Frankly, this is game changing stuff.
As HTML5 standardization marches on, becoming more popular for web developers/designers and as more and more people start building native mobile apps, it seems that a line in the sand is forming between the pro-HTML5 and pro-App groups. There is a polarity that is appearing between the two and we are starting to see a sentiment that the two camps are becoming mutually exclusive (adopt one or the other, but not both).
There is a decent argument being made by both camps. HTML5 enthusiasts are advocating that mobile experiences should turn into HTML5 websites that can be made to look and feel exactly like mobile apps native to the smartphone platform in question. They also advocate it as a way to centralize administration and maintenance of the experience (change once on the server and the new experience is delivered to anyone and everyone without the need to download an update). The fact that HTML5 is being created as a set of standards is very compelling as it allows developers and designers the ability to design their web-based experience without having to deal with the vagaries found in each browser. Given that most modern mobile platforms have a good HTML5 story around their browsers (either today or in future direction of their browsers), it’s a strong argument. The other side of the coin is that the set of standards that are commonly referred to as HTML5 won’t be ratified until 2014 at the earliest. There is also no guarantee that each of the major browsers will interpret the standard the same way which could negate the benefits of the “write once, display on any browser” vision of HTML5.
The pro-native app enthusiasts, on the other hand are make a great point in that the development platforms for their apps are rich, well-documented, support rapid dev cycles and a centralized store where smartphone users can easily find, install and socialize the apps they like. Apps that are native to the platform can take full advantage of the features that the platform vendor has exposed, leading to incredible innovation. Finally, apps found in a marketplace have the advantage of marketing support that comes out of the box. Data shows that being featured in a marketplace creates a huge spike in downloads and revenue that has the opportunity to be sustained over long periods of time. The negatives for native apps include the need to share revenue with the marketplace the app resides in as well as the app being subject to the terms and conditions of that marketplace with the risk of being pulled with only short notice.
So who is right? Well, you could say both are. They both have valid arguments and the positives for each are tangible while the negatives are equally relevant. I would also say that combining the two (a native smartphone app leveraging HTML5) is equally right and should receive more consideration than it currently is getting.
To make my case, let’s consider the Windows Phone 7 Codename Mango platform (I use Mango instead of the original WP7 platform as Mango introduces IE9, an HTML5-ready browser, while the original WP7 platform used a browser that was a hybrid of IE7 and IE8 which are not HTML5-ready). For example, using the Qantas demo that was seen in Joe Belfiore’s keynote at MIX11, re-imagine the implementation of the app Qantas built as a native Mango app that utilizes a browser control within the app to deliver a rich, web-hosted experience via an HTML5 canvas.
The power of HTML5 allows you to create a truly immersive experience that is hosted purely within the browser. If you are a registered WP7 developer on the App Hub and you have downloaded the Mango beta build you can check out its capabilities for HTML5 on a WP7 device (or you could just bring up the emulator that came with the Mango beta dev tools). With Mango, you can leverage the power of IE9 and HTML5 to create amazing apps that can be skinned to fit the look and feel of the Mango platform (i.e.: the metro design language). You can then use this same experience, if you wanted to, on normal desktop browsers or even in other mobile browsers.
Likewise, if you hosted that web experience within a browser control, you could still leverage the amazing features of the Mango platform to create a truly immersive experience that you simply couldn’t by only using an HTML5 app in the mobile browser. By using a native app to host the browser control, you could still leverage new features in Mango such as Agents and Alerts, double-sided tiles, fast app switch and even deep app linking.
Even if you were looking to avoid revenue sharing for your paid app within the Marketplace (paid apps are split as a 70/30 with you retaining the 70% portion), you could make your app free in the Marketplace and implement your own in-app purchase mechanism within the HTML5 part of your app (assuming, of course, your app isn’t a Mango game, as the Marketplace certification guidelines prohibit any in-app purchase within WP7 games as of the publish date of this post).
So I’ve made my case for hybrid native/HTML5 apps. I suspect some of you may have different ideas around this, so please let me know what you think!
I think it's unfair for developers that there is a restriction of not allowing in-app purchases in games, but allow it in apps?
I can see if there is a restriction and MS provides the ability to code in-apps. But alas, we don't have this privilege.
I really do hope that MS catches up quickly with the ability to have in-app purchases. With having an iOS game in the store, I can tell you first hand that the $ coming in from in-apps out performs the $ from regular sales.
Your complaint is a common one and one that we have voiced to the Marketplace product team as well. As you can imagine, the XBOX Live brand is a very important one to Microsoft and as such we are trying to find the right balance around in-game purchase and the like. Unfortunately for those that want to provide this type of feature to their games, this means that no in-game purchase is supported.
If you would like to discuss this further, feel free to send me an email via the "contact us" page on this blog or send me an email on Twitter (@plaberge). I know it's an issue for many of you and if you have feedback in addition to what you've provided below, I'd like to make sure that the product team sees it.