Categories
Languages Platforms

The Significance of AlphaGo: Has a golden age for artificial intelligence just dawned?

In recent years artificial intelligence (AI) has returned to the forefront of technological debate. That debate has moved on from when, and even whether, computers will ever display intelligent behaviour to how smart they will get, how quickly, and what the implications are for society. Although there are multiple approaches to creating AIs, the ones that involve machine learning from large datasets are generally outperforming all others. The results from such systems are often so impressive that large companies are rushing to hire data scientists, collect more data, and apply the latest machine learning techniques to inform their management decision making. Google’s DeepMind team recently demonstrated that without any human in the loop they can build a system that makes complex strategic decisions better than a human expert. Their approach suggests a way forward for building such systems in many diverse fields.

Machine_learning&artificial_intelligence

The game computers couldn’t beat

The announcement from the DeepMind team that their AlphaGo program had defeated the European champion at the game of Go was a highly significant landmark in AI. Not only did they accomplish a long-standing ‘grand challenge’ in AI and surpass rival Facebook’s efforts by an enormous distance, but the way the system works is in many ways very human-like. At first glance it’s easy to dismiss game-playing AI systems as not immediately applicable to real-world problems. The ‘world’ the AI operates in is incredibly simple compared to our physical world – in the case of Go, a 19×19 board where a black or white stone can be placed on each intersection. However, [tweetable]advances in AI from the pursuit of better Go playing programs are already being used[/tweetable] in real-world applications elsewhere. Also, the ‘deep convolutional neural networks’ that AlphaGo uses to ‘perceive’ the board are similar to those currently being employed to push forward the state-of-the-art in image and speech recognition, as well as natural language processing.

It’s different this time

Back in 1997, IBM’s Deep Blue beat the world Chess champion, Garry Kasparov. How is this different? First, Go is significantly more complex than Chess. There are nearly an order of magnitude more moves possible from every position and each move can have a bigger impact on the strength of a player’s position. Second, Deep Blue used a supercomputer and some hand-crafted heuristics to effectively do a brute force search of all reasonable future move combinations to pick the best move to make next. This was nothing like the way a human would play Chess and also not generalisable to other problems.

In contrast to Deep Blue, AlphaGo combines two deep convolutional neural networks with a Monte Carlo Tree Search algorithm to select moves in a way that’s quite similar to the way a human would play. The first neural network, called the policy network, picks a few promising positions for the next move. A human player doesn’t systematically evaluate all possible moves, rather through experience they develop an intuition for moves that should make their position stronger. They would struggle to explain why they selected a specific move over others in many cases. This suggests they’ve developed a model for how to play that exists below their conscious awareness. AlphaGo’s policy network is trained to predict the moves that expert players would make using a dataset of 30 million different positions from real games. The second neural network, called the value network, estimates how strong any given position is. It was trained, simplifying slightly, using the results of the policy network alone playing against itself from 30 million distinct positions. The Monte Carlo Tree Search is then used to look ahead from each move selected by the policy network at the opponent’s likely responses and AlphaGo’s subsequent moves. However, rather than search all the way to the end of the game, the value network is used to evaluate the end position after a sequence of moves. This is also similar to human play, looking a handful of moves ahead to assess the probability of gaining an advantage with each possible move. The lookahead searches are shallow (constrained by the processing power and time allowed for a move) and yet the results are better than existing leading systems that look much further ahead but with much less sophisticated move candidate selection and position evaluation capabilities.

Widely applicable artificial intelligence

This might all still sound a long way from a truly human style of thinking but if we abstract and generalise it slightly then it becomes more familiar. For any goal-oriented behaviour in a complex or changing environment we can assess our current situation versus our goal and generate some options for moving towards the goal. We can then simulate or predict the results of taking those actions and evaluate the new situations we could get into. We choose the option that moves us closest to our goal, or has the highest probability of moving us closer to that goal. This is just a description of iterative planning.

AlphaGo has shown that we can train a machine-learning system to emulate the options a human would select in a relatively-complex environment. If we simulate the immediate results of those selections we then just need to evaluate where we get to with each option. Again: machine learning comes to the rescue. If we can acquire or generate enough data we can train another machine learning system to perform the evaluation. None of this is really a new idea but now it has been demonstrated to be good enough to beat a professional at Go, it’s a fair bet it can be made to work for a huge range of other problems too. This is possibly why it’s such a landmark for AI research. It’s a challenge that until very recently was thought to require a completely new breakthrough in AI and probably another decade of research (and Moore’s Law) to get us there. It turns out the techniques we’ve already invented, when suitably combined, can achieve very intelligent behaviour.

Dawn of a golden age?

There’s an outside chance Go just happened to be a lot easier than we thought, or just unusually suited to these ‘deep learning’ techniques. However, given the progress that’s being made with deep learning on other longstanding AI problems it seems more probable that [tweetable]we’re about to enter a golden age for AI[/tweetable]. In this context it’s interesting to note that AlphaGo beat the European champion a month before Google opened the source code for their TensorFlow deep learning framework (which prompted Microsoft to follow suit with theirs). These open source moves can be seen as part of a land grab for talent and mindshare. The techniques are the subject of published research and efficient implementations are valuable but nowhere near as much as the data required for training and the talent to utilise it. Then of course, Google, Microsoft, Amazon and a bunch of startups will all offer managed solutions for training and running these kinds of framework on their clouds. As the significance of DeepMind’s accomplishment sinks in, more researchers and developers will rush to jump on the machine learning bandwagon and there will be no shortage of tech giants waiting to welcome them aboard.

Categories
Languages

So… is HTML really a programming language?

Earlier this year we polled more than 13,000 developers during our biannual Developer Economics survey (updating now), and 11% of those developers told us that HTML is their primary development language – that’s Hypertext Markup Language to the uninitiated. This response immediately begs the question: can HTML really be considered a “programming language” at all, or if we should consign to being a tool for the layout of JavaScript functions?

promo

Which is your favourite programming language? Take the DE survey and be the judge of which language will sit on the throne.

Developers answering our survey were asked to pick from a list of languages, HTML5 was on that list, along with JavaScript and more-traditional languages including C and Java. Most programmers work in more than one language, so perhaps those who selected HTML5 as their primary language really meant that they were JavaScript programmers who used a lot of HTML? It’s a nice thought, but the idea breaks down when look at those additional languages and see that only 13% of those who said their primary language was HTML admitted to also using JavaScript, so how are these people creating applications?

14% said they also use ActionScript, which can also come wrapped in HTML, but 12% of those primarily using HTML said they also program in C/C++, which is a combination we’re unlikely to see in the same project.

HTML was never designed as a programming language – the original 18 tags permitted the most-basic of layout options. The only interesting tag was the hyperlink itself; the revolutionary concept that created the web as we now know it, the rest are trivial. HTML was based, loosely, on SGML, which is another bastard offspring of XML – the eXtensible Markup Language – but the key word across these is “markup”: all three are intended to provide syntactical data to accompany textual information*, not applications as we know them.

But HTML has come a very long way since then, and has capabilities we would normally associate with a development language. Drag and Drop, Geolocation, and Local Storage, are blurring the line between applications and web sites, allowing cross-platform development where the only way to spot the difference is the title bar at the top of the window (and sometimes not even then), and there are a host of applications which bear testament to the fact that HTML can be used to create real applications.

Zero Lines JS is a fine example. A graphical game, requiring the player to navigate their ship between approaching enemies at increasing speed to a suitably-irritating soundtrack. It might not be the next Watch Dogs, or even the next Candy Crush Saga, but it would be hard to deny that it is a real application and one which (as the name infers) is written entirely in HTML with a few Cascading Style Sheets (CSS).

Less gaudy is the aptly named “You Don’t Need JavaScript for That”, which demonstrates various techniques to accomplish programmatical tasks without recourse to programming languages. Examples include a tabbed panel (bringing content to the front based on the selected tab) and an image slideshow, all done entirely in HTML5.

Purists will moan, of course, that these examples don’t make it a “real” programming language, that HTML is nothing more than a markup language made to enrich documents, and there was a time when that was true. Developers aren’t as hierarchal as they used to be, but those closer to the metal still look down on those who’ve traded an intimate knowledge of the hardware for speed of development. C programmers consider objects to be unnecessary fluff, but concur with users of C++ that anything which isn’t run through a compiler is just improper (and that includes Java with its bytecode nonsense). Java programmers consider anything without proper encapsulation to be faking its object orientation, while JavaScript developers see no reason for strong typing, and consider HTML to be a layout tool.

Meanwhile those versed in Assembler look down from their ivory towers, stroke their beards, and concur that when performance really matters they will always get the gig.

But despite being at the bottom of the heap we can see that HTML5 is being used to create applications, and it must therefore be considered a programming language. We might argue whether validating a filled-out form constitutes an application, but when you can crash a spaceship into an oncoming armada then there’s little room for discussion.

At Vision Mobile we’re currently updating our survey, asking developers what language and tools they’re now using, including those who choose to program in HTML. It will be interesting to see if an increasing number think that the layout tool has evolved, or if a momentary fad is passing. Take a look at the survey, and use the feedback from at the end to let us know how you feel about HTML being included in the list of languages, and what you think might end up on that list next time.

* To be accurate, XML is intended to be a framework from which one can derive markup languages, but that’s not really pertinent here.

 

The Developer Economics survey is now Live.
Have your say in which should be the next most popular programming language and you may win amazing prizes and gear. Discover more.

Categories
Business Languages Platforms

Who, What, How, and Why: software development laid bare

Every six months we ask developers around the world those four questions, to see how the industry is evolving. Now in its 9th edition the VisionMobile Developer Economics survey reached out to 13,000 developers, from 149 different countries, and the results are available in our biannual report: State of The Developer Nation Q3 2015.

Who

94% of our 13,000 developers are male, showing a gender imbalance which needs to be addressed if the industry is going to reflect society as a whole. North America is making some progress here, but even in the land of opportunity only a tenth of developers identify themselves as female, and the figures of the rest of the world are much worse.

It’s perhaps surprising that Africa is next best in terms of equality, while Europe is positively embarrassing with only 4% of developers ticking the box for the minority sex. South America offers the greatest imbalance, but nowhere do developers reflect the proportion of women in the general workforce.

What

Cloud is increasingly important for developers, and cloud developers the most likely to be generating revenue (67% of them are bringing in more than $500 a month). But there’s no rush to the public offerings such as AWS or the Google App Engine, despite all the media attention: 44% of cloud developers are creating apps in private, for use on private clouds.

The Internet of Things is also getting a lot of developer attention, though more a quarter of IoT developers (26%) don’t know who their eventual customer will be. Half of those developers are making applications, rather than hardware or firmware, reflecting the evolution of the IoT industry.

When it comes to mobile the two dominant players (Android and iOS) are squeezing out the competition and 37% of mobile developers are targeting both the leading platforms. Interest in creating apps for Windows Phone has dropped slightly since we last asked, from 30% to 27%, but developers are understandably nervous of Windows 10 and the uncertainty over Microsoft’s commitment to mobile.

How

Across the developer community the most-popular development language is now a combination of JavaScript and HTML5. The evolution of web languages has imbued them with functionality, while cross-compilers and packaging tools can make them indistinguishable from native applications. That’s been enough to attract 71% of developers in North America, though only 58% in Asia where old-school languages such as Java and C retain their presence.

Learning a new language is always a challenge, though the growth in Apple’s Swift shows that developers are willing to invest in their education. Swift is, perhaps unsurprisingly, attracting a good proportion of self-taught developers (27% of those primarily using Swift consider themselves self-taught), while Java, C#, and Objective C, all appeal to degree holders (around 60% have degrees) who prefer a more-formal learning environment (around 17% are self-taught).

Why

Not all developers are motivated by money, in fact many professional developers are hobbyists or amateurs in another field. More than half of our mobile developers, for example, are also mucking around with IoT – some professionally, but mostly just to see what it can do, and what they can do with it. Developers are predominantly young, with an average age of around 30, and have both the time and the motivation to explore new areas. Many are involved in open-source projects: 11% tell us that Linux is their primary desktop target platform, despite the fact that the open-source OS accounts for less than 2% of desktop installations.

In mobile the path to revenue, if not riches, is clearly selling products and services, in the manner of Uber or Just Eat, rather than downloads and booster packs, in the manner of Candy Crush and Minecraft. Only 10% of mobile developers are chasing e-commerce revenue, but almost a fifth (19%) are taking more than $100,000 a month – a figure that only 6% of those reliant on advertising can match.

The State of the Developer Nation

The whole report, complete with graphics and figures, is a free download, and packed with more insight and analysis from Vision Mobile.

Categories
Languages Platforms Tools

Why JavaScript will win on mobile

JavaScript is not the world’s most elegant programming language. So much so that one of the world’s top experts on the language wrote a book about “The Good Parts”. The book carries the headline “Unearthing the Excellence in JavaScript” because that excellence is quite deeply buried. Even so, it has rapidly become one of the most popular languages in the world. That popularity is deserved, because despite the flaws in the language, JavaScript gives developers significant advantages that they can’t get with other languages. Some of those advantages were created when browser vendors agreed to standardise on JavaScript (OK, technically ECMAScript) as the language for the web. Others are inherent to the web app programming model and more yet have been created through tooling enhancements. However, despite the fact that native apps are dominating web apps on mobile devices, JavaScript’s advantages are steadily transferring to mobile. Will it eventually dominate there too?

why-javascript-will-win-on-mobile

Popularity not priority

The latest TIOBE Community Index has JavaScript in 6th place amongst all programming languages and rising. The TIOBE method of ranking tends to favour older, more established languages and is not so quick to pick up trends. By contrast, the Redmonk rankings have JavaScript in first place. The Redmonk method is somewhat biased towards languages with strong open source communities but more accurately reflects current interest and trends. Our own Developer Economics surveys have shown that [tweetable]HTML5/JavaScript combination is the second most popular language amongst mobile developers[/tweetable] with 55% using it, just narrowly behind Java (at 57%). However, even if we combine those who prioritise HTML5 and JavaScript (19%), they’re still a long way behind Java (29%) on this metric. It seems likely this is going to shift significantly over the next few years. [What do you think? We have a new survey out, so take the survey and let us know your thoughts]

JavaScript breaking free from the browser

This is not a standard “the web will win” argument. I don’t believe that browser or webview-based apps will eventually dominate on mobile devices. Use will grow but they won’t be the norm. If true open web standards are to dominate in the future then they need to move on from the Document Object Model (DOM). The DOM is a base for building documents, not apps. Of course you can build an app around a platform originally designed for documents but you’re starting from a position of handicap. Look at the modern frameworks that allow you to build fairly performant apps for mobile browsers/webviews: React.js, Famo.us and Ionic. All three share the common feature of touching the DOM as little as possible.

Yes, there’s WebGL (or HTML5 Canvas if you must) too but those are low level graphics APIs. You need large, probably multi-megabyte, frameworks on top to create a good platform for building most apps. That’s not a good fit for the web app programming model, where the latest application code lives on a remote server, particularly not in a mobile environment. It’s true that you could have a hybrid app with a large framework on top of WebGL stored locally and just fetch the application specific code from the server but then why use the browser at all? Why not just JavaScript on top of some other cross-platform framework built for hardware graphics acceleration (hint: Qt has a nice offering here). One with a higher level API so there’s not so much overhead bridging between languages. Perhaps also one that’s less restricted when it comes to accessing device specific functionality.

There are now a couple of really interesting new options that fit this description, React Native and NativeScript. These work in different ways but both build apps with a native UI using JavaScript. Appcelerator’s Ti.Next may also be interesting, although they’ve been talking about it for a couple of years without an actual release yet, so we’ll wait and see.

The JavaScript exception

Here is where Apple has restored JavaScript’s advantage on mobile. A key thing that has prevented most developers from adopting an agile, web-style continuous delivery model on mobile is Apple’s ban on code downloading. Without that iteration is significantly slowed and split testing is much harder to do. This effectively means developers, particularly startups, learn slower. Until very recently, the only ways to get more rapid iteration were to go Android first, or build a hybrid app, since Apple made JavaScript downloaded in a webview an exception to the code downloading rule. In the first case it means moving away from the platform with the most early adopters. Unfortunately in the second case the UX trade-offs are too great, with most developers that went that route for a consumer app failing or switching to native. But in iOS 7 Apple added the JavaScriptCore interface to their own JavaScript runtime and in the latest iOS Developer Program License Agreement they modified the exception to code downloading rules to include JavaScriptCore.

This makes sense from a security perspective. Apple can audit and update their own runtimes, whereas if they allow 3rd party runtimes to download code they have no effective way of monitoring or dealing with security issues. Since JavaScript is Apple’s only scripting option and they can’t allow native code downloading, JavaScript is restored to a privileged position – the only option for those that want to iterate fast. The availability of JavaScriptCore triggered efforts like React Native and NativeScript and the timing of Apple’s relaxation of the code downloading policy has been perfectly timed for their public release.

Will open win?

Web advocates sometimes suggest that the open-standards-based web must eventually win because open always wins in the end. However, Linux is a very clear case where an open ecosystem thrives without a committee agreeing standards. With React Native, Facebook appears to be very rapidly building a developer ecosystem around their open source project. Already having a rapidly growing community around React.js obviously gives them a headstart but the NativeScript team at Telerik are working with Google such that Angular 2.0 should integrate seamlessly. Google are going to support non-DOM environments whether the web standards go in that direction or not. Microsoft and Google might take a long time to agree on the standards they’ll implement in their future browser versions but they’re working together on TypeScript, to make it easier to build complex apps with JavaScript (it turns out compilers are much better than people at spotting type mismatches).

Apple has built some fairly impressive tooling for their new Swift language, particularly the interactive playgrounds. However, Facebook possibly already has a better developer experience with React Native in terms of immediate feedback and rapid cycle times whilst coding. Apple will continue to iterate on that tooling alone, whilst the developer community can now enhance the tooling for these new JavaScript environments. Android may technically be open source but it’s not open in terms of community contribution. Google are enhancing the Android platform and tooling alone. [tweetable]Perhaps it’s really open developer communities that win[/tweetable] and genuine open source based communities can iterate faster than open standards based ones. For these “native UX built with JavaScript” environments to succeed, the platforms don’t have to lose. Apps will still be tailored to the platform look and feel and adopt new platform-specific APIs.

Javascript will win on mobile.

At the moment it looks like the very open JavaScript developer community will win because they get to build apps with native look, feel and performance but a web-style development experience. The closed platforms also win because apps are still being tailored for their captive ecosystems. For now, open web standards lose. It seems likely they can only win if the mobile browser vendors can agree to new standards that enable the creation of apps that genuinely offer an equivalent experience to native ones.

Update: Where we right in our predictions? Here is a latest update on the popularity of Javascript.

What do you use?

Do you think JavaScript will dominate on mobile in the future? Or Java, Objective-C and Swift will continue to lead? What about for the Internet of Things, or on the backend via Node.js? Let us know what you’re building your apps with by taking our survey.

Categories
Languages Tools

The Rise of Mobile C#

Microsoft have been struggling to get traction with their mobile computing efforts, with Windows Phone stuck at around 3% share of the smartphone market. Windows 8 is doing a little better in the tablet market but is still a distant third to iOS and Android. Despite losing in the platform wars, Microsoft’s developer ecosystem is still strong and they’re not showing much sign of wanting to give up their tools. The latest Developer Economics survey showed that 38% of mobile developers were using C# for some of their work and 16% use it as their main language. Those developers are not all focused on Microsoft platforms by a long way. They’re not all building games with Unity either. So what are they doing?

thumb

Not just Windows Phone, particularly not for pros

Whilst 30% of all developers in the survey were targeting Windows Phone, that doesn’t quite account for the majority of those whose main language is C#. Also, more than half of the developers targeting Windows Phone are Hobbyists and Explorers[bctt tweet=”more than half of the developers targeting Windows Phone are Hobbyists and Explorers” username=”DevEconomics”] – i.e. those not working on mobile apps full time. If we focus on full time professional mobile developers, as we will for the rest of this article, then just 50% of those that use C# as their main language are primarily targeting Microsoft platforms. Apple’s iOS (with 23% of developers) and Google’s Android (14%) are in fact more popular targets than Windows 8 (10%). So, how do developers use C# on other platforms? With cross-platform tools, particularly Unity and Xamarin.

More enterprise apps than games

Unity is by far the most popular engine for mobile games, in fact in the Q3 2014 Developer Economics survey a massive 47% of game developers were using it for some of their projects. C# is the most important language in the Unity developer ecosystem, although there are two other languages supported (UnityScript – a JavaScript variant with type annotations – and Boo – a statically typed language with Python-like syntax). However, a lot of developers are using Unity to build games in their spare time. When we look at the full time pros we find that games are only the 4th most popular category of app. The top 3 categories are Business & Productivity tools, Enterprise-specific apps and Utilities, all staples of the enterprise-focused app developer. Developers are either building these apps for Microsoft platforms, using Xamarin to reach iOS and Android with them, or both. Indeed it’s the combination of a familiar language (and code portability) and tooling for many enterprise app developers with the cross-platform reach they can get with Xamarin that’s making C# such a popular choice in this area.

A flexible cross-platform approach

A lot of popular cross-platform tools for mobile development only support iOS and Android. As such, for those also wanting support for Windows Phone and possibly desktop Windows and Mac too, Xamarin is one of very few serious options. That said, it’s not just a default choice. Using Xamarin.Forms, developers can get the write-once-run-anywhere efficiency that drives many decisions to use a cross-platform approach. The downside to this approach is that it can give a lowest common denominator of functionality; not allowing developers to really optimise for the unique features of each platform. However, Xamarin also directly wraps the native platform APIs, allowing developers to call anything in the native SDKs. They can even automatically create bindings for popular third party libraries on each platform. The other key reason developers often go with a native rather than cross-platform approach is performance. However, a recent independent performance test (by an early Google engineer) showed Xamarin’s compiler produces raw performance that’s comparable to native on iOS and Android. Raw performance isn’t the only thing that counts of course – a garbage collection pause causing a stutter in your animation is jarring, however fast the the code is executing otherwise. Enterprises customers will usually put up with mild inconveniences of that nature to get the cost savings and maintenance benefits of a single code base across platforms though.

Better revenues

Possibly the best measure of the success of C# on mobile devices is the revenues of the developers using it. Whether you believe the same level of smoothness in the user experience can be achieved or not, it only matters if it costs users and revenue. Here there is no room for debate. The revenues of full time professional developers whose main language is C# are comparable to, or better than, those of other developers targeting the same primary platform with the native language. For example, the revenue distribution for C# developers on iOS is extremely similar to that for Objective-C developers and the average revenues are higher. This is both because there are more C# developers earning more than $10K (46% vs 36%) per month and while there are slightly fewer earning more than $100K per month (16% vs 17%), a significantly greater fraction of those using C# earn more than $500K per month (14% vs 6%).

This is not to suggest that C# is somehow a better language for targeting iOS than Objective-C. This is correlation and not causation. The cause of the better revenues is that the C# developers are much more likely to be targeting enterprises than the Objective-C developers and that’s where the higher revenues are most likely to be found. There’s an enormous pool of developers trained in C# and related Microsoft technologies. A lot of them are working on desktop enterprise apps or the server side. As it becomes increasingly clear that C# is a viable language for successfully delivering cross-platform mobile solutions, C#’s rise on mobile looks set to continue for several years yet.

The Rise of the Mobile C#

Infragistics

Categories
Languages Platforms Tools

Comparison of 4 popular JavaScript MV* frameworks (part 1)

Finding a comprehensive comparison between any kind of JavaScript Frameworks, Libraries or Extensions is not hard these days. Especially when it comes to JavaScript MV* Frameworks, which are used to develop single-page applications (SPAs), and their notorious representatives, i.e. AngularJS, Ember, Backbone.js and newcomer React. A simple Google Search offers a plethora of technical comparisons to choose from.

mv-frameworks

Which are your favorite and worst frameworks? Take the survey, let us know and you can win awesome prizes and gear.

What they don’t usually mention, though, is the overall features those frameworks provide and how they compete for different use cases. Moreover, it is sometimes difficult, if not impossible, to find information on the origins of those Frameworks, i.e. how they have developed in time and, most importantly, how they will develop in the future.

This article is part 1 in a 2-part series, and will focus on comparing key features from some of the leading JavaScript MV*frameworks. In part 2, we’ll give you some insight on market-related qualities, followed by a conclusion.

Features Comparison

To get our comparison started, we will focus on the heavy-weight and most promising features you, as a developer, expect from a JavaScript MV* Framework.

Dynamic UI Binding

Dynamic UI Binding is not just passing data to our View or template at page load. You want to automatically have the View update when the data of the underlying Model changes. That being said, you may want to have a look at the following jsfiddle examples to get an idea of the huge improvement provided by dynamic UI binding over traditional server-side static data binding.

Ember.js:

Ember uses Handlebars as the default templating engine. To update a value, which is bound to the UI, you have to use a specific setter method on your Model while Handlebars takes care of rendering your page. Additionally, Ember offers much more binding options, such as its capability to have your Model in either a one or a two-way binding mode between a View or even another Model.

Angular.js:

In contrast with Ember’s approach, Angular.js allows you to use UI binding at plain object or even property level. At the end of every code execution, $scope.$apply() is run to check whether the value has changed and calls $scope.digest() to update your bindings. This may seem like a possible performance issue at first glance, but bear in mind that it allows you to update more than one binding simultaneously without requiring time-consuming DOM updates after each setter call. So the DOM rendering is triggered only once after you updated as many of the Model’s properties as you wish rather than being triggered after every single value change, like in Ember’s setter approach. Having all the magic happen in $scope.$digest() you don’t need to call your UI-Binding-Buddy yourself and even the $scope.apply() call is handled by Angular automatically (e.g. after events, controller init, http callback, etc).

React:

One of React’s rich UI Features is the straightforward linking of states directly to the UI. Since the UI is thought of as the representation of different states of a React Component, you just have to manage your states with the magical #setState(state, callback) method. The state parameter is passed as an object and will be merged into the internal state reference of your React Component. Meanwhile, React takes care of all the updating and re-rendering of your interface using the render method. The callback parameter from setState is optional and can be registered so you are informed after the UI update.

Reusable Components

While all frameworks provide out-of-the-box functionality, you will inevitably end up with a lot of custom code. Assuming you are developing more than one applications, you would like to be able to reuse that code, right?

Ember.js:
Ember is making use of a widget-based approach called Ember Components. It enables you to write your own ‘application-specific HTML tags’ using a Handlebars layout and the power of Ember’s backend infrastructure. Your custom element can be used in any Handlebars template you want. Keep in mind, though, that this is only possible at View level, while Controller level reuse is not supported by the Framework.

Angular.js:
Similar to Ember, Angular.js provides the ability to create custom HTML tags. Reusable components in Angular are called “directives” and are significantly more powerful than Ember Components. In fact, you will be able to create your own semantic and reusable HTML syntax using those directives. On the other hand, you may also make use of Angular’s extend or mixin system like in Backbone.js and React.

Backbone.js and React:
The way Backbone.js and React solve reusable components is not new, yet it is very reliable. They both use the mixin system for code reuse. You may know this feature already from the dojo toolkit and might remember how powerful mixins can be. Both Backbone and React let you use mixins at view or even controller level, so that your components are not forced to be UI-related and may contain just some utilities or even complex program logic.

Routing

The simplest routing infrastructure a MV* JavaScript Framework can offer is mapping functions to URLs, similar to their server-side relatives (e.g. Grails, Spring, ASP.NET, CodeIgniter). For Single Page Applications (SPAs) a URL is whatever follows the hashtag (or might even be full path assuming HTML5 push-state is enabled). This routing functionality is essential for any self-respecting SPA.

Ember.js:

The routing in Ember.js is quite intuitive, since you do not even need to provide a path for your route, as long as you follow the naming convention. You just provide the View and an optional Model to the route and there is no need for any kind of controller (as exhibited in the Fiddle above), unless you are planning to do some advanced stuff in your application.

Angular.js:

In contrast to Ember’s convention-over-configuration routing mechanism, Angular.js requires a template and even a controller to its router configuration. You have to manage your template and controller manually – but you can do that almost without restrictions.

Backbone.js:

Similar to Angular.js you provide a View with a Template for your route. The actual replacement of the DOM is done manually by instantiating the View and updating the DOM in your container node with the rendered view template. At the end of your routing configuration you just have to tell Backbone to listen for URL changes with the command Backbone.history.start().

Pit Stop – Concluding the Feature Comparison

It is quite unfair to compare React with the likes of Ember, Backbone and Angular. First and foremost, React is new, while the latter are already established frameworks in the MV* universe. Secondly, React is not a framework, but rather a View engine – even though it competes extremely well in terms of features. In fact Facebook explains it better: “React is mostly used as the V in MVC”.

Let’s look again at our JavaScript MV* candidates.

Backbone doesn’t provide UI binding and does a really good job at reusable, components but loses some of its fanciness when it comes to Routing. Ember offers a slick routing mechanism, keeping things clean and simple by introducing naming conventions. Its UI Binding concept and use of Handlebars, which provides you with very nice benefits, is flawless. The only thing Ember lacks is the reuse of components at Controller level.

To conclude, Angular is our winner – so far. The approach of extending HTML with custom syntax, the easy-to-use data binding features combined with the power of mixins or extends and a clear routing mechanism makes Angular more than just a swiss JS-Knife. With its high abstraction level and a bunch of features it may be the choice for a full featured CRUD application – client sided.

Stay tuned to find out more about how our rivals compete in market penetration, community support, their estimated future usage and, of course, our final conclusion to help you back the right horse for your SPA.

 

In the meantime, tell us more about what you love or hate for each framework and you might win cool gear. Take the Developer Economics Survey.

Categories
Languages

Understanding Swift: 5 things app developers should know

The most surprising thing to come out of Apple’s WWDC event this year was a new programming language for iOS and Mac development – Swift. To the sceptical this might not seem like anything more than a way to entice more new developers to build apps exclusively for Apple platforms and lock them in. While investment in developer tools is always partly about making a platform attractive to developers, this move has far more benefits and strategic implications.

Swift-de

1. What is Swift?

Swift is a statically typed, compiled language, interoperable with the Objective-C and C code that are currently used to build Apple’s platforms and the native apps that run on them. However, it also has the feel and features of more modern scripting languages. In creating Swift, Apple has attempted to give developers the best of both worlds, the performance of native code but the convenience and productivity of a scripting language.

2. Faster, Safer and Less Code

In fact, Apple claims that Swift is faster than Objective-C, yet at the same time developers are freed from the burden of explicitly declaring types (they’re inferred), or manually managing memory (it uses automatic reference counting). With features such as “optionals” (a generic way of checking if things exist before using them) and type safety (no default attempt at an implicit cast), the compiler is able to prevent many of the worst bugs that crop up in the C family of languages while reducing the amount of code that has to be written and maintained. Another productivity enhancing change from the legacy of C is the elimination of header files, keeping interface definitions and implementations in one place.

3. Interactive

Although reducing the amount of code required to perform simple tasks is productivity enhancing on its own, even greater benefits are obtained by reducing feedback cycles. In the same way that a simulator allows more rapid testing of new code and ideas than building for a device and installing, live coding environments provide almost instant feedback as the code is written. Such tools are not traditionally available to compiled languages but Apple has created “Playgrounds” for Swift. These don’t provide live coding for an entire app but allow developers to experiment with new algorithms or bits of UI in such an environment before copying them into an app. Similarly, whilst being able to inspect variables in a debugger is useful, it’s even better to be able to interact with an app while it’s running. Swift provides a REPL (Read-Eval-Print-Loop) for this, much like the debug console for JavaScript in most browser development tools.

4. Functional friendly

The language also has functions (and closures) as first class objects with a much more readable syntax than Objective-C’s blocks, making it easier to apply functional programming techniques. This could be particularly helpful for fans of Functional Reactive Programming (FRP) – a programming paradigm that has been gaining in popularity for app development amongst a lot of smart developers. It helps to eliminate complexity when dealing with things like user input and asynchronous network communication – two key areas for most mobile apps. A team at GitHub actually created an FRP library for Objective-C, called ReactiveCocoa, which is extremely well thought out but forced into the most painful syntax by the language.

5. What’s the catch?

Sounds a bit too good to be true, right? Being a compiled language and using reference counting, rather than a garbage collector, developers are still responsible for avoiding memory leaks due to strong reference cycles. These happen when two objects refer to one another, directly or via a chain of other objects. So, while the language may be beginner friendly, it makes it fairly easy to write code that leaks memory. To avoid this, developers need to understand how the memory is managed for them and how to break these cycles. It’s not horribly complex but it’s a long way from not having to worry about memory management at all. That said, most iOS apps will get away with leaking a bit of memory – usually the device will just silently kill them in the background when the memory is required for another app.

Being compatible with C and Objective-C makes Swift a fairly big language – there are quite a lot of concepts and bits of syntax to learn for a new developer, rather than one coming from an Objective-C background. Also, as a type safe language, Swift is going to be much less forgiving to the novice that would prefer the compiler just figured out what they meant when comparing the integer 1 with the floating point value 1.0 or the string “1”.

Swift is currently an iOS & Mac only proprietary language. Unlike Objective-C, which has an open source compiler and runtime (used by Apportable) there’s not likely to be any way to use the code on Android or other platforms. However, most developers wanting a cross-platform approach are unlikely to have started with Objective-C anyway, so this is not really creating significant extra lock-in. It might just persuade some developers choosing a cross-platform tool to target iOS because it’s easier, to create a fully native app instead.

Why does it matter?

First, more developers. Although modern Objective-C has a lot of good points, it’s an evolution of a very old language. Syntactically it’s quite different from most other modern languages – it borrowed from Smalltalk while the rest of the world followed C/C++. This creates a barrier to entry for developers in other languages because the code initially looks alien. Additionally, any language that has pointers is a hard sell and steep learning curve for complete beginners. Swift fixes those things and should make developing for Apple products attractive to an even wider audience.

Second, more productive developers. Greater productivity means lower cost of development and/or shorter time to market. The combination of more rapid development and lower fragmentation versus Android should help to keep iOS as the first platform developers target, even as its market share continues to shrink through the faster growth of Android globally. This is very important if Apple intends to stay exclusively at the premium end of the market.

Last but not least, happy developers. Although several cynical commentators have latched onto the proprietary language lock-in angle, it seems rather unlikely that giving developers a new language to learn is going to lock them into developing for a platform when the barrier to exit is, well, learning a new language! Instead consider that Apple is primarily aiming to retain developers through loyalty rather than lock-in with this particular move. It should not be underestimated how much good tools can contribute to the enjoyment of daily development work. If Swift can deliver on its promises then other platforms will have to be that much more attractive to tempt the best developers away.

Categories
Languages

Is HTML5 about to make a comeback?

The web is losing and apps are winning. At least that’s what the most recent data from Flurry says – 86% of time on mobile devices is spent in an app other than the browser, up from 80% last year. Does that really mean the web is losing? What about apps built with HTML5? Is the implementation technology more important than the distribution mechanism? Why should anyone care? A number of new tools and frameworks are maturing that should make it much easier to build great mobile sites and apps with HTML5. Could they stop the shift from web to native apps, or even reverse it?

is-html5-about-to-make-a-comeback-650px

Why the web is losing on mobile

Modern web browsers and standards were designed for a desktop computing environment and they built upon a base that was designed for sharing linked documents. Mobile computing environments have capabilities and constraints that desktops don’t. Native mobile app platforms were designed for building highly interactive, animated, apps utilising hardware graphics acceleration. The result is that apps running in a mobile browser are disadvantaged in terms of performance, user experience and access to device functionality versus their native counterparts.

The app is the new browser bookmark. People have favourite services and sources of information or entertainment even though a great deal of substitution is possible in most cases. Providers have to compete on user experience and that creates a bias towards native apps. You want to check the weather every day? You don’t search for a weather forecast every time, or find a favourite weather site and bookmark it, you download a weather app. Need to catch up with your friends on a social network? You don’t open the browser, type a URL or go to a bookmark and wait for the latest updates to download, you get update notifications pushed to you by the native social network app, or when you open the app it has already downloaded the latest content in the background. For frequently accessed apps, the native versions have much less friction, as well as a nicer user experience.

What about hybrid apps?

Delivering a web app in a native wrapper allows it to access device functionality and reduce some regular usage friction. However, it doesn’t fix performance (indeed on iOS it makes it worse), nor make it easier to deliver a great user experience. Another problem with delivering a packaged web app that uses a system WebView is that the functionality of the WebView itself can change with OS updates. Android recently switched to a new Chromium-based WebView and broke or crippled lots of hybrid apps. The flip-side to this problem is that WebViews upgrade slower than browsers; on Android the WebView is currently tied to OS upgrades (which are still lacking from most manufacturers) while the Chrome browser continuously auto-updates. This means it’s a long time before it’s feasible to start using new standards added to the browser specifically to tackle mobile issues. A hybrid app is also still subject to app store reviews and policies. It may be possible to update functionality without an app update in the store but the platform owner still controls what developers can and can’t do.

Another popular complaint about hybrid (and native) apps is the loss of ability to cross-link versus the web. I believe that Facebook’s recent App Links project puts all native apps (including hybrids) about on a par with web apps here. It may be possible to link to any web page but many modern web apps only have a single page. What’s actually needed with a web app rather than a web site is the ability to link to app states. This is only possible if the developer enables it by setting up routing for URLs to app states – native apps can already do this and App Links solves the “what if the app isn’t installed” problem with web fallbacks or store links. If platform providers enhance app interoperability then native (and hybrid) apps could significantly exceed the capabilities of the web here.

Engagement versus ease of access

As discussed above, any content or services you access frequently create less friction by providing native apps. Less friction enables more engagement and a virtuous cycle of greater usage. On the other hand, new or infrequently accessed content and services have extremely high friction if you need to download an app before you can do anything else. Here the web has significant advantages over native apps. The companies who really don’t get this are the ones that have a full screen popup asking you to download their app every time you visit their website on a compatible device! Another way to look at the Flurry stats linked at the top of the article is this: exclude games (which have almost always been native for performance) and social networking (which falls firmly into the frequent access category, plus a lot of the time will be using an in-app browser anyway) and the browser still has more than a third of the remaining mobile usage time. That doesn’t sound quite so bad.

New frameworks fill the gaps

With the threat of being relegated to the “infrequently accessed” category of apps, the web development community has not been sitting around doing nothing. A new framework recently into public beta, famo.us, attempts to solve the major performance problem for animated web app UIs. Their current approach is a series of clever hacks involving minimal manipulation of a very flat DOM structure. However their JavaScript APIs will also render to WebGL in future (when it’s sufficiently widely available, ahem, Apple). The approach is promising and the demos are impressive. Currently their homepage (on both my retina iPad Mini and Nexus 4) kinetic scrolls with a stutter that makes my 2006 Symbian device look slick, so there’s a way to go before they’re ready to come out of beta. Note that using Famo.us JavaScript APIs starts to make building web apps look more like creating a native app.

Another framework close to its 1.0 release is Meteor, a new way to create real-time web apps very rapidly. They fix common issues with the responsiveness of web apps out of the box – having to poll the server for new data and wait for it to update the UI after user interaction. The latter is achieved with a technique called latency compensation (UI is updated with local data immediately, then fixed if the server returns something different). The former is down to having long-running bi-directional connections between client and server rather than a more traditional RESTful API. Meteor actually supports native client apps too but with the ease of creating the web front end it would be unusual for developers not to have both web and native options if they go down that route.

Although there are lots of new and interesting frameworks in development I’ll highlight just one more that’s in a fairly mature beta stage. Ionic is a framework designed specifically for building hybrid apps. It’s built for performance and to provide common UI components and interactions out of the box so it’s easy to make an app with a native feeling user experience. The default styling is very similar to, although deliberately not exactly like, iOS 7. The major disadvantage to this approach is that while it works on recent iOS and Android versions you lose the broader cross-platform and device compatibility. It’s not for building mobile websites or desktop web apps. As such Ionic is building on HTML5 purely as an implementation technology and abandoning the browser. However, as it’s still running in a WebView developers retain the privileged position of being allowed to download new code on iOS.

Native user experience

I listed performance and user experience as two separate issues for a good reason. Despite all the great efforts at resolving performance issues for web apps, native user experience is not just about performance. For some apps it’s natural to take over the full screen and provide an immersive user experience. Games fall into this category, unfortunately they’re also the category of app most in need of full native performance. The majority on non-game apps use some standard platform components and need to follow platform user experience conventions. This makes it easy for users to learn how a new app works; navigation and controls work in the same way as most of their other apps. In this sense when we say “native” user experience we mean aligned with the platform culture and conventions rather than compiled to native binary code. The folks at Ionic are right not to mimic iOS 7 too closely. The more native looking an app’s UI, the more users will expect it to behave exactly like one (and get frustrated when it doesn’t always). A phenomenal amount of effort is required to make an app look and feel just like a native one when it’s not actually using native controls. Even if this can be achieved, the platform will change and the app won’t, making it stand out like a sore thumb until it can be updated (again at significant effort). This is an issue for all cross-platform environments that have their own rendering engine rather than wrapping native controls.

What the technology wants

Marc Andreessen famously said that the eventual application model on mobile will be the web application model, because the technology wants it to work that way. Having every app stored on a remote server and the latest version always updated to the device when it becomes available is a superior model to downloading and periodically updating local apps. This technological advantage applies almost equally to hybrid apps, assuming the native wrapper rarely needs changing. Native apps that automatically update is a step in the right direction but doesn’t aid lean development practices like split testing and continuous deployment. The latter are so valuable in figuring out what to build quickly that there are plenty of entrepreneurs and businesses out there who would build mobile apps with the web model if they were good enough for their customers.

The next wave?

Consumer apps that don’t have highly desirable unique content or features are going to have to compete on user experience for the foreseeable future. For most that will mean native apps. However, building native apps is significantly more expensive than building cross-platform web apps. Not all of the people who pay for apps are going to prioritise user experience. The next generation of software for large enterprises right down to small businesses is going to need a much better user experience than the last but the current state of web technology is probably good enough.

Revenues from consumer mobile software may look quite attractive but the bulk is in Free-to-Play games and is highly concentrated amongst a handful of publishers. The majority of the growth in that market is in Asia. A more interesting opportunity for many developers may be the only slightly smaller but faster growing Software-as-a-Service (SaaS) market for businesses. As mobile devices become increasingly essential in our work lives as well as our personal lives, maybe we’ll see more of that total usage time in business and productivity apps.

Conclusion

So, is HTML5 about to make a comeback? In a way. If the first wave of mobile computing adoption was primarily about consumers, the next wave will see many more businesses getting serious about using mobile devices to enhance productivity and collaboration. I suspect the use of HTML5 in business apps to be much more successful than in the consumer space. Possibly we’ll see a return to the browser but for now the hybrid app looks more likely. General purpose business apps like time and resource tracking or project management will have large enough user bases to justify native client apps, although of course they’ll need web access too. The more specialised the app, the more likely it is to be a hybrid app than a fully native one.

Categories
Languages

App Security 101: A list of top 10 vulnerabilities and how to avoid them

App security 101

App development is becoming more and more popular, as web and software developers are migrating to the mobile industry. Apps have become a part of mainstream culture and entered our everyday lives – at increasing levels. The app economy is comprised of approximately 2 million apps and is expected to continue growing in the years to come.

Secure development on mobile applications, however, has not shown the same level of growth or maturity. As an Information Security firm, we’ve seen quite a few apps suffer from vulnerabilities that are linked to development bad practices, mainly due to lack of awareness. Secure development guidelines do exist in the community, while organisations like OWASP have accumulated a lot of experience in the field and are now offering much of this knowledge for free. In this article we’ll sum up the best practices and show you the best ways to build secure apps. We’ll concentrate on OWASP top 10 (and similar) vulnerabilities, as these are the most common ones found in mobile apps.

So, let’s go through the list of the top 10 mobile app vulnerabilities and how to avoid them.

1. Insecure Data Storage:

This vulnerability occurs because information that is considered confidential is not stored in the device in a secure manner. You shouldn’t assume that the devices themselves are safe. Devices can be stolen and/or tampered with, and the confidential data contained in them may be stolen. Also, you shouldn’t assume that users will protect themselves against this possibility. In order to avoid this vulnerability, the best practices are:

  • Never store credentials on the device itself
  • Sensitive information such as user authentication credentials should only be stored in the device’s keychain, using the necessary API
  • All authentication should be done through HTTPS (updated)

Specific guidelines for iOS developers:

  • You could avoid using iOS Encryption Libraries such as Commoncrypto
  • You should encrypt SQLite databases with SQLcipher
  • You might want to avoid NSUserDefaults, as well as plists in general
  • Keep in mind that the NSManagedObjects will be stored in an unencrypted database

For Android devs:

  • You should use the SD Card Storage the javax.crypto.
  • You can use the enterprise Android administration API to force encryption for local files by utilizing “setStorageEncryption”

2. Weak Server Side Controls

You should implement most controls against input attacks on the server side of the application. Nevertheless, app design should include input validation checks and controls, in order to reduce the load of work to be done by the server. Therefore, you could ensure that both the server side and the mobile client development security requirements include at minimum:

  • Input validation. You can use this kind of data validation in order to detect, and therefore prevent, unauthorized input before it gets processed by the app itself
  • Canonicalization. Data input in the app should be converted to its canonical (simplest) form in order to be processed by it
  • White lists on allowable data. The white list validation approach allows only specific types of data as input to the application; everything else that’s not included in this list, is not authorized.
  • Output encoding. You should encode the output that is presented to the user in order to prevent different kinds of attacks (e.g. XSS[1][2], format string attacks).

3. Insufficient Transport Layer Protection:

You should enforce the TLS/SSL encryption with strong algorithms between communications. A common development mistake is unencrypted connections from the application to 3d party companies. You should program your apps to display any certificate error or warning messages, so that the user is informed of the quality of the encrypted connection.

For iOS developers:

  • Use the CFNetwork API that utilizes NSStreamSocketSecurityLevelSSLv3 / TLSv1.2.
  • You should use,the setAllowsAnyHTTPSCertificate parameter to prohibit accepting all certificates

For Android developers:

  • You should set the AllowAllHostnameVerifier parameter to prohibit accepting all certificates

4. Client Side Injection

This category is comprised of a wide variety of input attacks against the application itself. General best practices for mitigation of client side injection vulnerabilities include the input validation of the application entry points, on the server side.

For iOS developers:

  • You should consider using parameterized queries (e.g. ? instead of %@, libXML2 instead of NSXMLParser)
  • In addition, you should avoid functions that are known to be prone to code vulnerabilities, such as strcat, strcpy, etc.

Android developers:

  • You should use parameterized queries
  • You should disable Javascript and plugin support for Webviews
  • You should also disable file system access for Webviews
  • You might consider using input validated intent filters between Activities

5. Poor Authorization and Authentication

These vulnerabilities are controlled mostly on the server side. The best practices that you should follow are the same with web applications. In addition to these rules, specifically for app development, device identifiers should be avoided (UDID, IPs, MAC Addresses, IMEI) since devices can be stolen and tampered with. Finally, out-of-band authentication tokens should not be sent to the same device.

6. Improper Session Handling

Although session handling mechanisms are mainly applied at the server side of the applications, secure session management practices can be applied at the devices themselves. As with the Authorization and Authentication, you should apply the web application Best Practices for session handling. Same as with authorisation and authentication best practices, device identifiers should be avoided here as well and you should implement safe mechanisms to revoke session on lost/stolen devices. Finally, the Confidentiality and Integrity of session tokens should be protected at all times (secure transmission via SSL/TLS connections, etc).

7. Security Decisions Via Untrusted Inputs

While these issues mainly affect Android-based applications, there has been precedent for iOS apps too. In general, the Best Practices that you should follow are the same with the web application ones. Specifically, input validation, output escaping, authorization controls and canonicalization should be carefully examined. Also, you should exercise extra caution when validating and accepting URL schemes.

8. Side Channel Data Leakage

This category involves data exchange that usually enhances app performance (e.g.: keystroke logging, web caches). As with Insecure Data Storage, you should build your app under the assumption that the device might be stolen. All side channels and 3rd party libraries included should be identified and enumerated for any possible data leakage that might occur. The application should be dynamically tested in order to verify that it doesn’t leak data during runtime.

iOS developers:

  • You might consider disabling screenshots, along with cut-and-paste buffers. It is also recommended to disable keystroke logging from within the application.

9. Broken Cryptography

Crypto-keys should never be hard-coded in any construct (plaintext, property files, compiled binaries) and should be controlled at the server side.

10. Sensitive Information Disclosure

Different kinds of information may be considered sensitive in an app, as application logic/business purposes define that. You should keep mind that apps can be reverse-engineered and information like this might be exposed. The best practices in this case suggest avoiding storing private data inside the device; unless absolutely necessary.

The vulnerabilities presented here are not an exhaustive list – they’re just the tip of the iceberg! During the past year, we’ve witnessed numerous attacks against apps by direct code exploitation that usually leads to the device becoming compromised. We’ve also seen attacks that leverage various app weaknesses in order to hijack legitimate user sessions and steal information and money.

Since the app market is constantly growing, we expect to see an increase in the number of attacks against mobile devices themselves. So, if you want to keep up with the times, [tweetable]you should build your next apps with app security in mind[/tweetable].

For more insights, get in touch.

– George

George Karagiannidis is a Senior Information Security Consultant at TwelveSec (TwelveSec.com). George is a seasoned pen-tester, having accumulated a wealth of experience from performing, as well as leading, Information Security projects that range from System/Network/Web/Mobile Application Penetration Tests to Reverse Engineering, Security Design and Architecture of critical Information Systems, and Information Security Management System (ISMS) implementation.

Categories
Languages

How to succeed with HTML5

Although the debate on HTML5 versus native apps seems to be favouring native apps currently, particularly in terms of user experience and performance, average developer revenues tell a very different story. Our survey data shows the mean average revenue for developers who consider HTML5 for mobile devices their primary platform is the highest of all platforms, just over twice that of the next nearest (iOS)*. However, the rewards are very unevenly shared, with the median average revenue for the same developers under half that of their iOS counterparts. Diving into the data we can see significant differences in revenue depending on how mobile apps built with web technologies are delivered to users and the categories they target. Understanding these differences could improve your chances of succeeding with HTML5.

html5

Apps but not App Store sales

The majority of developers using HTML5 in their businesses still prefer to deliver it via the browser, either as traditional websites, or more complex web apps. The range of deployment options for developers using web technology and their relative popularity is shown in the chart below. The data throughout this post is filtered to only include developers whose organisations earn between $1 per month and $5 million per month. There are a large number of hobbyists with no revenue who are excluded and we also exclude a small percentage of super-high earners who create large distortions in the averages.

It turns out this browser-centric preference, despite the protests of the open web advocates, is bad for business – at least in the short term. On average (mean and median) [tweetable]developers deploying their code as standalone apps earn 50% more than those delivering via the browser[/tweetable]. If we exclude apps for platform native web frameworks (e.g. Firefox OS and BlackBerry WebWorks) because these are only available on niche platforms, then the advantage rises to 70% (mean, or 100% median). If we also only look at those developers who consider HTML5 their primary platform then the difference is larger still (mean revenue per person per month of ~$77.5k for app delivery versus $21.5k for browser delivery).

A popular misconception is that the web has poor monetisation and app stores solved this. However, as we’ve shown previously, [tweetable]the more developers rely on app stores for revenue, the less they make[/tweetable]. Web developers are no exception, in fact, avoiding reliance on app store monetisation is one of the keys to their success. Amongst developers using HTML5 for mobile devices as their primary platform who gave us a revenue breakdown, 65% had no revenue at all from app stores and of those that did, a further 65% generated less than 50% of their revenue from app stores. Contrast this with those targeting iOS as their primary platform – 67% of them generate some of their revenue from app stores and for 50% of those it was more than 50% of their total. So where do these web developers make their money? A much wider range of sources – more contract work than most platforms, many more sales outside of app stores and also e-commerce.

The right tool for the job

It’s also clear that HTML5 is not suited for all types of app and while in the case of enterprise clients it seems browser based delivery is still slightly preferred, an app delivery method opens up many more opportunities. The interactive graph below compares revenues by category for browser and app based delivery methods.

Outside the Enterprise software and Maps & Navigation categories, the revenues are at least an order of magnitude higher for app based delivery in this subset of popular categories. The outsized revenues earned by business productivity software developers suggest that the consumerization of IT is making significant inroads into the enterprise and even the comfortable revenues of those who focus on (mobile) browser based delivery for enterprise clients may not last.

Although we shouldn’t underestimate the impact that the relative maturity of many web businesses versus native mobile competitors has on the above figures, web technology seems very far from dead as a way to capture value in the mobile software market. Our data does suggest that those who want thrive in the age of mobile should embrace the consumer preference for apps rather than rely purely on the browser to deliver their services.

– Mark

A brief note on the figures presented in the article:

* Calculated as a mean revenue per person involved in app development and excluding organisations with $0 revenue per month or more than $5 million revenue per month. This is attempting to narrow our inquiry to real app businesses rather than hobbyist developers whilst excluding a small number of outliers that distort the averages. As such this is not comparable with our published reports based on market size estimates for all developers, including hobbyists, students etc. Average revenues on iOS are still the highest if we include all developers.