Author: Mark Wilcox

Mark is developer who has worked on everything from the lowest level smartphone firmware to games and apps that sell pizza. He's also a project leader with a focus on lean methods and a consultant who loves rapid prototyping, app economics and business models.

Categories
Platforms

Angular vs React: Battle for the future of front-end web development?

angular react

Google and Facebook are two of the world’s most powerful companies and each has created a framework for building web apps. Angular and React respectively appear to be in a battle for the future of the web, with the active online debate and adoption for large consumer-facing apps seeming to lean quite strongly in React’s favour at present. Are they collectively taking over the front-end? Is React really leading? Our data from a broad cross-section of nearly 6,000 web developers may surprise you.

angular vs react

Which is your favourite framework? Take the Developer Economics Survey and win amazing prizes.

Although traditional, largely static, web pages still have an important place, mobile is now the dominant computing paradigm and mobile users have come to expect the interactivity of native apps. To attempt to match a native app experience, a web app cannot be entirely rendered on the server side, the page has to be changed dynamically on the client. The more extensive the changes the greater the need for a better abstraction than the DOM (Document Object Model) to manage the complexity. This has driven ever growing usage of third-party JavaScript libraries and frameworks.

Historically jQuery was the first library to get really popular, enabling easier manipulation of the DOM on the client side. It’s still the most popular today, as the primary front-end library for 34% of web developers. However, manually manipulating the DOM turns out to be extremely complex and error-prone when it’s happening extensively, so frameworks that provide a better abstraction are increasingly important. Overall just 12% of web developers don’t use any kind of framework and another 6% have written their own. That leaves 48% of web developers currently using a third-party framework other than jQuery as their primary way of doing front-end web development. Of those, Angular and React account for 30% of all usage, leaving all the others far behind. Indeed front-end web development is such a fragmented space that no other single library or framework accounts for more than 2% of primary usage. So React and Angular certainly lead other frameworks, although only around half of all web developers have fully embraced any single page application framework so far.

Angular is still king despite the React hype.

AngularJS (Angular 1.x) was the first single page app framework to get the stamp of approval from an internet giant, when Google started to back the open-source side project of one of their employees publicly. Google’s backing gave many large enterprises the confidence to adopt, and with broader adoption came a flourishing ecosystem of components and tools. As this was happening, React was built internally at Facebook and deployed on the Facebook newsfeed in 2011 and then Instagram’s web app in 2012. Yet React wasn’t released as open source until 2013, by which time Angular had an enormous lead in both adoption and ecosystem. Then in late 2014 Google appeared to stumble previewing Angular 2.0, which was going to be incompatible with Angular 1.x and use a new language. Reaction from the developer community was not good. By mid-2015 Google had agreed to work with Microsoft so that TypeScript became the official language for Angular 2.0, while the 1.x series had a promise of continued support, and a migration path between versions was created. This discontinuity for the Angular community seemed like a gift to the already rapidly growing React.

Although Angular still had many vocal fans, anyone following the broader front-end web developer community online would have to assume that React was taking Angular’s crown. At the time of writing React has passed Angular 1.x in terms of stars on their respective GitHub projects, with around 61,500 to 55,000. Angular 2.x trails both of these by far with 21,500. In the independent State of JavaScript survey run in late 2016, React came out way ahead of both versions of Angular in usage, interest, and retention. However, our own survey, which reaches out across many different developer communities does not reflect this result overall at all. Not only is Angular 2.x the primary framework for about as many developers as React (10% vs 9% globally), but Angular 1.x is still the most popular overall by a slim margin (11% use it as their primary framework). In total those using one or the other version of Angular number more than double those using React.

angular vs react

React is favoured by front-end specialists.

In order to see how reality in the market could be so different from the online buzz and even a large community survey, it’s interesting to look at the breakdown of JavaScript library and framework usage by primary programming language. If we only look at the users of the latest versions of JavaScript – those who like to stay at the forefront and are more likely to be found debating framework choices on the internet – we see React is the primary framework for 27% of them. So amongst those who have made the switch to ESNext (i.e. the 2015 version of the JavaScript standard or later), who then use tools to convert their code to the JavaScript that’s widely supported in browsers (known as ES5, introduced back in 2009), more are using React than both versions of Angular combined. However, this is the only group of developers for which React beats either version of Angular alone. These forward-looking JavaScript users are less than half of those primarily using JavaScript, and just 16% of all web developers (who almost all use some JavaScript).

A further 18% of web developers are still primarily using ES5. More of these are currently still using Angular 1.x (21%) as their primary framework than Angular 2.x (9%) and React (8%) combined. These developers are getting on with what they know and are productive doing. They may be following the new standards and frameworks but most of them don’t see enough benefit in switching yet. Another 3% of all web developers are primarily using TypeScript, which could be seen as the most advanced version of JavaScript currently available. However, some web developers understandably don’t want to adopt anything not yet in the standards, others don’t want to use the optional static types, and a significant minority still avoid anything from Microsoft. Given that Angular 2.x has adopted TypeScript it’s not surprising to find 41% of those primarily using the language have adopted the framework. There are another 18% currently still using Angular 1.x that will most likely migrate to Angular 2.x.

Backend web developers prefer Angular on the front-end.

After some flavour of JavaScript, the most popular language for web developers is PHP, with 21% still considering it their primary language. Given the focus on rendering pages server-side in most of the popular PHP content management systems, it’s not too surprising to find less interest in single page app frameworks in general amongst these developers, with 52% still using jQuery as their primary library. Interestingly only 3% of PHP developers are primarily using Angular 1.x, with 8% on Angular 2.x, and just 4% for React. In fact almost as many PHP developers don’t use any library or framework for the front-end (14%) as use React plus either Angular version.

Developers primarily using server-side languages other than JavaScript/Node.js or PHP (totalling 42% of all web developers) are significantly less likely to be using jQuery than PHP developers but they are also significantly less interested in Angular and React than the JavaScript developers (26% vs 38%). When they do primarily use one of these front-end frameworks, far more choose Angular (20%) than React (6%), and more of the Angular users are on version 2.x (11%) than version 1.x (9%). Considering all of those who are server-side developers not using Node.js, which is 63% of the web developer population, Angular is significantly preferred to React at this point, probably because it is complete framework, rather than forcing the developer to make lots of other library and tooling choices as they currently have to with React.

What happens next?

There are a many alternative futures that could be inferred from this data. The simplest story would be that framework preferences won’t move much for the different groups. Server-side developers will continue to have relatively little interest in the front-end frameworks and ES5 developers will stick to Angular 1.x when they eventually transition to ESNext or TypeScript. This doesn’t fit the current trend of increased JavaScript usage across the web, front-end and server. It also ignores the fact that Google will be migrating to Angular 2.x internally and developers will not want to be left without support one day. We could also imagine that as developers start using ESNext or TypeScript their framework preferences shift accordingly. Both React and Angular gain greater share, with React growing faster than Angular.

There’s probably some truth in this, but it’s too focused on the front-end developers. Server-side developers who aren’t using Node.js are less likely to find React attractive without a much simpler learning curve for the ecosystem. Then again, the most popular PHP framework is still WordPress, and the company behind WordPress has chosen React as the new front-end framework for WordPress.com – many PHP developers may follow them. Facebook has significant momentum with React, but Angular is likely to remain the most popular for smaller projects and internal apps. What we can predict is that despite the inevitable churn on the front-end, both frameworks have successfully built a critical mass of developers creating valuable ecosystems, and both are set for significant growth in the years ahead. We’d be surprised if the 30% of web developers using either Angular or React didn’t become 40% in the next 2 years.

So, what do you prefer? Angular or React? Take the Developer Economics Survey and win amazing prizes.

Categories
Platforms

The Rise of the Chat Bots?

Developers struggling to get noticed on the app stores, or hoping to capitalise on the growth of enterprise messaging, are looking to a new way to reach their users – via a chat interface. The logic of reaching users where they spend the most time seems sound, and that is clearly in messaging apps. Does the typical consumer or business user really want to be taken back to the days of the command line interface though? Is this the next big market, or will it just be a trendy niche? [tweetable]Natural Language Processing (NLP) technology seems to be the key to mass market adoption[/tweetable]. Can that interface scale across thousands or millions of apps, or will it be dominated by a few key players and use cases?

the_rise_of_the_chat_bots

An old idea

[tweetable]Chat bots – apps that communicate via a textual, conversational interface are nothing new[/tweetable]. A convincing conversational computer program has been a goal of artificial intelligence research since Alan Turing proposed his famous test in 1950. As long as there have been chat-rooms, including the bulletin board systems that dominated the Internet before the invention and adoption of the web, there have been chat bots. Even commercial scale and conversational access to internet services are far from recent developments. The SmarterChild bot on AOL Instant Messenger and MSN Messenger (now Windows Live Messenger) had 10 million active users and processed 1 billion messages per day. It provided access to news, weather, sports, a personal assistant, calculator etc.

New scale & changing habits

Why the renewed excitement in chat bots? Two reasons – mobile messaging scale and enterprise messaging growth. Third party mobile messaging apps are rapidly heading towards 2 billion active users globally. These apps are typically the most used on any mobile device. Following the model of Asian messaging apps WeChat and LINE, the owners of other messaging apps want to turn them into platforms. At the same time, Slack is attempting to create a platform out of their enterprise messaging product. [tweetable]The impressive growth of Slack in the enterprise, where people are actually happy to pay for software[/tweetable], means a lot of entrepreneurs would like to ride their coattails to success. There are two separate markets here, with a common interface and some common technology.

Better technology for smarter chat bots

It’s the improvement in that common technology, particularly for NLP, that leads many people to think it might be different this time. Conversational interfaces might finally be able to deliver a great experience. However, there are some tradeoffs here for developers. One appealing aspect of a textual interface is that it can be much less effort to develop than a mobile app UI. Unfortunately NLP research has been disproportionately focused on English so far – the technology isn’t as good in other languages, so these interfaces automatically have a more limited audience. The more sophisticated the NLP, the more work involved in developing the interface. Using a 3rd party NLP service can significantly reduce this effort but also removes a key source of differentiation if your product is only a chat bot. Without NLP a bot is either focused on a very specific task or only for power users – mass market consumers aren’t going to want to memorise a lot of specific command syntax. At the other end of the NLP sophistication spectrum, is it going to be viable trying to compete with the likes of Google and Facebook as the best way to access mass market services?

Will Facebook own the consumer market?

Telegram’s bot platform might seem interesting as it reduces the need for NLP (and typing) with dynamic custom keyboards but their reach is a tiny fraction of the likes of Facebook Messenger or WhatsApp. Unfortunately [tweetable]Facebook doesn’t have a good record as a developer platform provider[/tweetable], which they managed to prove again recently, if such a reminder were needed, by announcing they’re shutting down Parse after promising developers their backends were in safe hands. Indeed chat bots on the big consumer messaging platforms may have some success at first but it’s likely to be the platform owners that take the lion’s share of the revenue in the end. These platforms will probably be great for businesses to reduce marketing and customer support costs with chat bots and they’ll be paying Facebook (and possibly others) for the privilege of talking to their customers in this way. There are probably also good opportunities for smaller developers to help companies build these bots.

An opportunity to differentiate enterprise services

The enterprise opportunity is different. As a growing number of companies reduce their email usage and build workflows around chat in apps like Slack and HipChat, the most natural way to access some premium services will be through chat (at least for some use cases). For example, when discussing past sales, or future sales projections, it would be much more natural to ask an accounting, or forecasting SaaS tool to give you a chart for the relevant period than to switch away to another application to look that up. However, as with most of the obvious examples you could imagine, it’s unlikely that these services would operate entirely through a chat interface. It doesn’t make much sense to enter all of your accounting data via chat or build your sales forecasting model that way. As such, chat bots become just one of many interfaces to a cloud service. There are opportunities for new services to get discovered, or existing services to gain market share, by being early to support chat interfaces but 100% chat-based is unlikely to be a giant new market.

Evolution not revolution

In most cases, consumer or enterprise, conversational interfaces are just another channel. Much like mobile apps are just another channel for many services. They can be a channel that increases convenience or reduces friction for some key use cases. This also follows mobile but their increased convenience and usability lead to a massive increase in total use. The change messaging platforms will bring is nowhere near the same scale as the shift to mobile. The things that were really interesting on mobile were the ones that couldn’t be done, or were too inconvenient to bother with on desktop platforms. What new possibilities do conversational interfaces bring on mobile platforms? What mass market use cases haven’t already been tried (and widely under-used) by Apple with Siri? The most interesting areas are probably those that involve some element of discovery – when you don’t know which app to go to – or embrace the asynchronous nature of messaging. That said, how do you discover a new chat bot to help if you don’t know what you’re looking for? What business models would work for a purely conversational interface? The chat bots may be on the rise, but it’s likely this is more of an evolutionary step than a revolutionary one.

Categories
Languages Platforms

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

artificial intelligence

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 Platforms Tools

Why JavaScript will win on mobile

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
Business Platforms

Microsoft’s Mobile Opportunity

Microsoft’s Mobile Opportunity

Microsoft was slow to react to the step change in user experience provided by iOS and Android versus the first generation smartphone platforms. Windows Phone was then late to market and has finished a distant third in the smartphone platform wars. Smartphone adoption was consumer led and in the race to catch up Windows Phone skipped some enterprise friendly features. This has left it out of the running for business adoption too. In tablets, Windows RT was largely rejected by the market and Intel processor based devices running Windows 8 have only managed a weak third place in the market so far. In terms of their share of the mobile OS market, Microsoft is a long way behind Apple and Google. However, as enterprises are increasingly making big investments in mobile, Microsoft’s mobile opportunity is still not lost.

infragistics-2-cover

If you can’t beat them, join them

Microsoft’s new CEO, Satya Nadella, has made it clear. The company’s focus is now mobile-first and cloud-first. This includes aggressively rolling out their services across iOS and Android.

In fact they already have more than 100 apps across the two platforms and that number is growing fast. Nadella has not been hesitant to acquire technology where previous strategy has left gaps. The new Outlook apps for iOS and Android is based on the Acompli apps that Microsoft acquired late last year. It will likely be enhanced in the near future with the technology from recently acquired calendar app Sunrise.

In addition to filling out their offering and buying in talent for their competitors platforms, they have also moved to protect their dominance in productivity software. Microsoft Office is free for consumers on mobile platforms. To sweeten the deal for those who pay they’ve added unlimited storage via OneDrive. They then removed reasons to switch by opening up to competing storage solutions such as Dropbox and Box.

Following the old adage that the best form of defense is a good offense, these moves help keep Microsoft’s central position in the daily life of business users whilst starving startups hoping to topple them of revenue. No-one without Microsoft’s scale can compete directly on price whilst offering similar value.

Developers, developers, developers!

The other key to protecting Microsoft’s core enterprise revenues is keeping their technology stack at the heart of enterprise app development. For this to happen, third party enterprise app developers need to stick with .NET and related tools to build apps for iOS and Android. Developer loyalty is where Microsoft has been very strong.

Slashdata’s Developer Economics surveys repeatedly show Windows Phone with massively higher developer mindshare than the installed base of devices merits. That mindshare also continues to grow despite ongoing lack of traction with device sales.

One of the reasons for this developer loyalty is that Microsoft makes top class developer tools. They’ve invested heavily in this area for a very long time. Most developers don’t want to downgrade their tools and productivity in order to target another platform.

While Microsoft didn’t do the groundwork necessary to let developers target iOS and Android with their tools, Xamarin did. Microsoft and Xamarin have a global partnership to enable C# developers (and to some extent Visual Basic developers) to target iOS and Android via Visual Studio. Microsoft open sourced their state-of-the-art Roslyn compiler technology for .NET, presumably mainly so that Xamarin could integrate it. It seems likely that the partnership between the two companies will deepen at some point, probably through investment or acquisition. In any case, it seems to be working.

In the Q1 2015 Developer Economics survey, Xamarin was the second most popular cross-platform tool, behind only PhoneGap/Cordova.

The survey data also shows that C# is clearly on the rise as a language for mobile development.

Microsoft’s Mobile Opportunity: The next best thing

If you can’t own the OS and platform APIs then the next best thing is to own the developer tooling and thus the key relationship with developers. If you want to introduce or drive new features or standards (that don’t require new hardware or OS level support) then it’s the developer relationship you need to own rather than the platform itself.

Arguably a lot of innovation in mobile going forward will be achieved through cloud services. Microsoft would love to own those APIs. This only goes so far in the consumer space. Apple and Google can veto Microsoft’s moves at the public app store interface. However, in the enterprise, where most apps are not distributed via the public app stores, anything goes. This is where Microsoft’s biggest mobile opportunity lies. It’s also where the bulk of the revenue in app development will end up.

If Microsoft can keep a huge pool of developers fed and happy on mobile then they’ll be in a much better position for whatever comes next in computing.

Categories
Languages Tools

The Rise of Mobile C#

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
Business Platforms

How to Make More Money with Enterprise Apps

enterprise apps

According to our latest developer research, 20% of mobile app developers primarily target enterprise apps. This decision produces a significant boost to their revenues, with 43% making more than $10K per month versus 19% of those who target consumers above the same revenue level. Similarly at the $100K+ per month revenue level we have 18% of developers who target enterprises versus just 7% of those who target consumers. Aside from selling to businesses, government or non-profit organisations rather than consumers, what are these developers doing differently?

profiling-enterprise-app-devs

Custom apps

Although it’s far from the only thing developers are building to sell to enterprises, 64% of enterprise app developers are making enterprise-specific apps. In some cases this will be apps that are common to a particular vertical that are either re-skinned or sold as part of a service offering. In other cases these will be entirely custom apps designed and built for one company. Automating or streamlining parts of business processes that naturally happen away from a desktop computer via mobile apps can enable significant efficiency savings that businesses are very willing to pay for. Allowing developers to do more of their work whilst mobile can also improve productivity and company efficiency. This type of development can also cover apps that are explicitly designed to help make more money, for example, sales aids, such as product visualisation or demonstration solutions.

The second most popular category for enterprise developers, at 52%, is business & productivity tools. This is likely to include typical cross-vertical apps for functions such as human resources, customer relationship management and accounting. Also, 20% are making more general utilities and 17% are developing communications and social networking apps for enterprises. In the latter case we see [tweetable]some of the innovation in the consumer apps space being brought to the business world[/tweetable].

Globo_03

Better revenue models

Enterprise app developers have a very different mix of revenue models to consumer app developers. By far the most popular revenue model, used by 49% of enterprise developers, is contract work. Part of this is the bespoke app development discussed above but even those selling products into enterprises will often have a significant customization component. In general, the larger the company, the more likely they are to have complex integration needs for a new software product. Subscriptions, in the form of Software-as-a-Service is the fastest growing segment of enterprise software spending and 27% of enterprise app developers are already using this model. Moving software to the cloud, where upgrades and maintenance are continuous and shared with other users, makes a lot of sense for most businesses. Once key software a business uses is in the cloud it’s often highly desirable to have it accessible from mobile devices too, giving SaaS providers with a strong mobile offering a major advantage.

It’s not so surprising that we have to wait for 3rd place in the revenue models list to find app store sales, with 21% of enterprise developers using it. Indeed, although Apple has special volume discount programs for businesses and schools, it’s slightly surprising that the percentage is still so high. For some SaaS offerings, the mobile client or extra utilities to interact with the service are paid extras. This will probably reduce as mobile support becomes the norm rather than a differentiator. App stores for businesses and education are probably still working as discovery mechanisms for some too. This is also likely to reduce, just as the consumer app stores became so full that it’s almost impossible for most apps to get noticed, so will enterprise app stores. Also higher than average in terms of preference for enterprise app developers are selling physical goods and royalties & licensing. Having an app as a component of a larger hardware product is increasingly popular. A tablet can be incorporated into all kinds of kiosk or point of sale systems. Developers can then capture some of the value of the software through higher margins on the hardware. Alternatively, high value software is often sold to enterprises on a per-seat or per-device licensing basis – mobile is no exception. For high value software where sales are typically made directly it’s entirely sensible that this is done as a licensing deal rather than sold through an app store with the store owner taking a cut.

More platforms, much more web

Enterprise app developers are more likely than average to support each of the major platforms. The majority of them support Android and iOS. Most also support at least one other platform too, with the mobile browser and Windows Phone being the top candidates for that. When we look at priorities though, the picture is slightly different. [tweetable]Enterprise developers are slightly more likely to prioritise iOS than average[/tweetable] (with 33% doing so versus 31% for all developers) and slightly less likely to prioritise Android (39% versus 42%). When we consider only full-time professional developers though, these differences are not significant. The major differences are further down the platform mindshare list, with enterprise app developers being significantly more likely to target and prioritise the mobile browser. Also, whilst they are slightly more likely than average to target Windows Phone, they are less likely to prioritise it. Overall the platform picture is one where more platforms must be supported to serve enterprise clients and there’s a heavier emphasis on the web.

Heavier tool users

In order to support more platforms, enterprise app developers turn to cross-platform tools much more frequently than their consumer app developing peers. 41% of them are using cross-platform tools to reduce the cost and complexity of supporting multiple platforms. However, it’s not just cross-platform tools that are more frequently used to create enterprise apps. Other important tools are push notifications (28%), crash reporting (28%) and mobile Backend-as-a-Service (18%). User analytics, at 46%, is still the most popular tool amongst enterprise app developers, as it is in the developer population as a whole, although used slightly less than average. Heavy use of user analytics and crash reporting tools suggests a greater emphasis on quality. Push notifications are key workflow and efficiency enablers, providing access to timely updates and the latest info available at a glance. Last, but not least, mobile Backend-as-a-Service lets developers rapidly build out cloud services to accompany their apps. The features of these BaaS solutions for enterprise apps are likely to become increasingly differentiated from those designed for consumer apps. Most legacy backend systems were designed before mobile access was even a consideration and they often aren’t very suitable for direct interfacing. We expect to see significant growth over the next 5 years or so for solutions that can simplify the integration of legacy systems whilst enabling rapid development of mobile apps. Where we’ve seen consolidation in the consumer tools sector giving rise to mega-SDKs for solving multiple needs, it’s not surprising that several enterprise focused tools vendors are already covering most of these developer needs in a unified package.

Enterprise developers clearly have slightly different tools and tactics from consumer app developers for good reasons. Consumer app developers looking to switch their primary audience in search of better revenues should re-evaluate what they build, how they build it and how they sell it.

Categories
Business

App developer trends Q1 2015

Our 8th Developer Economics survey has once again achieved an industry-leading scale, including responses from more than 8,000 app developers and 143 countries. Their collective insight shows us an app economy that’s beginning to mature. Platform mindshare and priorities are fairly stable and developers are increasingly turning to cross-platform technologies to deal with the multi-platform reality. Tool adoption is gradually increasing and a shift in focus towards enterprise app development is underway. You can get a copy of the full report here – it’s a free download.

DE8-illustration

The big changes on their way are in development languages and the Internet of Things. Apple’s new Swift has had an impressive level of uptake but C# and JavaScript are also growing in importance. Meanwhile mobile developers are showing a very strong interest in the next wave of connected devices.

Platform Wars
The platform wars have ended in a stalemate. [tweetable]Apple have an increasing lock on the high-end with iOS and Android dominates everywhere else[/tweetable]. Windows Phone is still growing, now at 30% mindshare, but not generating enough sales to break through the app-gap. The split of developer platform priorities amongst full time professionals best illustrates the stalemate. Android has 40% of developers, iOS has 37%, whilst Windows Phone and the mobile browser have just 8% and 7% respectively.

fulltime-pros-duopoly

Although not yet a priority the mobile browser has also bounced back strongly from an all-time low in terms of mindshare 6 months ago, with 25% of developers now supporting it. With the massive growth of mobile apps it’s important to remember that the desktop and mobile web combined is still the most important digital channel for the majority of businesses. [tweetable]The web is definitely not dead[/tweetable].

The Rise of Swift
Our development language rankings show absolutely unprecedented growth for Apple’s new Swift language. [tweetable]20% of mobile developers were using Swift just 4 months after it was introduced[/tweetable] to the world. For comparison, Google’s excellent Go language doesn’t make it onto our new top chart for server-side programming languages, having reached just 5% mindshare amongst mobile developers after more than 5 years. [tweetable]Amongst the first wave of Swift adopters, 23% were not using Objective C[/tweetable], a sign that Swift may succeed in attracting a much wider range of developers to build native iOS apps.

rise-of-swift

Revenues
Growth in direct revenues from the app stores is slowing. As these direct revenues are preferred sources of income for the Hobbyists, Explorers and Hunters that make up around 60% of the mobile developer population, competition for them is becoming more intense. 17% of developers who are interested in making money generate no revenue related to apps at all. A further 18% of developers make less than $100 per month and the next 17%, bringing us to a total of 52%, make less than $1000 per month.

below-1k-month

Those low revenue earners are not at all evenly distributed across platforms. Of those that prioritise iOS, only 37% are below the app poverty line, making less than $500 per month on iOS. On the opposite end of the revenue scale, 39% make more than $5,000 per month on the iOS platform. Rather surprisingly, the revenue distribution for Android-first developers is not much different than for those targeting BlackBerry 10 or Windows Phone. In fact, developers that go iOS first actually earn much more revenue on Android than those that prioritise the platform.

Internet of Things
Despite the relative immaturity of IoT platforms, mobile developer interest is high. A massive [tweetable]53% of mobile developers in our survey were already working on some kind of IoT project[/tweetable]. Smart Home was the most popular market with 37% of mobile developers working on IoT projects targeting it. Wearables were a close second with 35% mindshare. The majority of these mobile developers involved in IoT development are doing it as a hobby (30% involved at this level) or side project (just under 20%), whilst working on mobile apps in their day job. This is expected at this stage of the market where revenue opportunities are still limited.

Tools
Tool awareness is increasing. The fraction of developers not using any third party tools at all has fallen to an all time low of 17%. The second most popular category of tool is ad networks, with a 31% adoption rate. Unfortunately this is the one category of tool that’s negatively correlated with revenues. Cross-platform tool adoption is on the rise. The percentage of developers using these tools has grown from 23% to 30% over the last 6 months. While cross-platform tool use was previously uncorrelated with revenue it’s now a positive revenue indicator. We don’t believe this is due to a significant improvement in the tools, rather it’s because of their disproportionate use in enterprise app development.

Enterprise vs. Consumer
The enterprise app gold rush is now well underway with 20% of developers primarily targeting enterprises, up from 16% in Q3 2014. This shift in focus is paying off. [tweetable]43% of enterprise app developers make more than $10K per month[/tweetable] versus 19% of consumer app developers reaching the same revenue level.

Amongst consumer app businesses, the majority of the revenue is coming from free-to-play games. A typical game is giving a third of gross revenue to the app store provider as a cut of in-app purchases and spending half of what’s left on ads to acquire new users. These game developers are starting to look more like typical fast moving consumer goods businesses, with significant benefits from scale. Despite overall revenues from the stores still rising, life is getting much harder for the small independent developers that try to serve consumers.

The good news for consumer app developers is that 3 of their top 5 favourite categories are common with enterprise app developers. It’s definitely not too late to re-focus on B2B rather than B2C sales. Also, the skills developed building consumer apps are in greater demand than ever now that more and more businesses are taking mobility seriously. This is a trend that will keep running for several years yet.

Want more? Download and read the full report!

Categories
Tools

Are prototyping tools becoming essential?

prototyping tools

How do you design the UI for a new app or feature? Good old fashioned pencil and paper? Photoshop or Sketch? Perhaps a wireframing tool like Balsamiq? Maybe you build clickable mockups or fully interactive prototypes? However you go about it, using prototyping tools to get some feedback on a design before it’s fully coded is a great way to save time and effort.

prototyping-tools-developer-economics

When building an app for a client, they’re usually a lot happier if they can see and touch what they’ll be getting before it’s built. For your own apps, being able to rapidly iterate on the design with prototypes can get you to market with a quality product much faster. There’s been a lot of activity in the prototyping tools space over the last year or two, providing a variety of ways to build brilliant prototypes. In this post we’ll look at some of the most interesting and promising ones.

Animation era

In iOS 7 Apple made a major change to their UI design. The old realistic textures and skeuomorphic design elements were out and flatter, cleaner look was in. Many of the hints at what interface elements were for, or affordances in designer-speak, are now gone – replaced by animations that make it clear what’s happening as you start to interact with the interface. This arguably makes it harder for complete beginners to discover functionality but also makes it easier to understand what’s happening and how apps work. Well designed animations can delight and surprise, making the whole experience more engaging. The danger here is that developers building custom UIs in a similar style can mimic the look of the new UI without adding the animations. This effectively takes away almost everything that helps a user learn how to interact with the app. [tweetable]Animation became essential to a good UI design[/tweetable]. At the time there were almost no tools for designers to help them create or communicate this aspect of the user experience – developers largely had to add these animations in code and tweak parameters across many slow and painful iterations to get them right.

In the Android 5.0 update last year, Google has also adopted a much more minimalist UI style – they’ve called it Material Design. Here also, animation is a core part of the user experience; this is made very explicit in their design guide. Fortunately we’re now in a much better place in terms of tooling to design and prototype these animations. Which tools you’ll want to use is likely to depend on your current process, what sort of app you’re building and what level of fidelity you want to achieve in the prototype.

Exploring ideas

If you primarily want to create a prototype to explore an app idea or communicate about one, then it’s hard to beat the efficiency of pencil sketch on paper. That’s fine for showing a basic app layout but what if you want to explore interactions. Prott lets you capture your sketches and turn them into interactive prototypes that are fully tappable, along with custom gestures and transition animations. The tool also has collaboration functionality built in.

Prott Web UI
Prott Web UI

For those who prefer to start sketching out their ideas in a digital form but want a low-cost and low-effort way to add some basic interaction and animation, Apple gave us a peek at part of their prototyping process in one of the talks at WWDC (video requires developer login and Safari). They use Keynote! Creating slides with the dimensions of a device screen and animating from one to the next (particularly the “Magic Move” animation) allows for a surprising amount of sophistication. Since there’s a Keynote app for iOS devices too, you can actually preview the designs on the device. The major restriction here is that you can’t tap different areas to cause different actions – tapping anywhere transitions to the next slide, so you have to prototype individual flows through the app rather than the whole thing.

If you’re only designing for iOS and only want to use standard UI elements and screen transitions, then a fun alternative for exploring new ideas on the go is AppCooker. This is an iPad app for designing iPhone and iPad apps. It’s necessarily limited compared to many desktop tools but still very capable. There’s no custom animation support here though and while you can import images, it’s not really suited to designing a custom UI.

High fidelity prototypes without code

The majority of designers have limited coding skills. Being able to create a basic page layout and style it with HTML and CSS is an excellent start but it doesn’t get you to a place where you can easily build screen transitions or custom animations. Professional animators have almost always had tools that didn’t require coding but there was nothing for app designers. Facebook started using Apple’s Quartz Composer, a motion graphics tool, for prototyping. They built a toolkit on top of it for prototyping apps and released it for free as Origami. This is a highly capable toolset but since it wasn’t originally built for for designing apps it’s somewhat complex and difficult to learn and use. Quartz Composer itself is also not very actively maintained or stable.

Quartz Composer with Origami
Quartz Composer with Origami

For anyone that wants a similar tool to Origami that’s easier to use there are a couple of excellent new options. If a complete freedom is what you want then Form is an excellent option. It was released by RelativeWave as a paid tool but then rapidly acquired by Google and made free. They initially launched for iOS only with plans announced to also support Android. With the tool in Google’s hands we can assume that Android support will come quickly. Like Origami, Form provides a node and graph based visual programming environment. They also have a viewer app so you can preview the design on as many devices as you like and it updates automatically as you make changes.

Form Mac App
Form Mac App

If you want to build prototypes that look and feel just like native apps using the built-in OS frameworks then Pixate is definitely worth checking out. It lets you build iOS and Android prototypes that use the native UI components directly. You can add your own custom styling and animations in a visual programming environment. The Pixate team are currently working on direct import functionality from Photoshop and Sketch, so it can be added seamlessly to existing static design workflows. They’re also planning to add native code export, so that when a design is complete, the native code generated for it can be used as the basis for the final app UI. Generated code doesn’t have a great history of being maintainable but if they can pull it off it would be a killer feature.

EDIT: Just after this was published, Pixate added a free tier that lets you use all of their features for 1 app.

Pixate Web UI
Pixate Web UI

HTML5-based solutions

There are lot of prototyping solutions on the market that involve building app UIs with HTML5. Some of them are for custom designs and others provide libraries of native component clones. Some do both but very few provide a good level of support for custom animation. A couple of interesting exceptions are Proto.io and Framer.

Proto.io is another non-coding solution which also has collaboration features, allowing you to get feedback from your team or a client. Unlike most of the tools on the market, it has a library of Windows Phone components as well as those for iOS and Android. You can test on real devices and export the final HTML5, which could be useful as the basis for a hybrid app, or just as a guide for the developers. It is a fairly expensive subscription solution compared to most of the others but would clearly produce an excellent impression in a consulting and contract development environment.

Proto.io Web UI
Proto.io Web UI

For designers that know their way around JavaScript (or CoffeeScript), developers with some design skills or those rare unicorns – true designer/developer hybrids – Framer is one of the most interesting options out there. Framer already has direct imports from Photoshop and Sketch and focuses on rapid iteration, including live device previews. If you do a lot of design work and iterating quickly is a key goal then Framer might be the tool to beat. The underlying prototyping framework, framer.js, is open source and could be used independently but a lot of the productivity boosting features are in the paid Framer Studio tool.

Framer Studio Mac App
Framer Studio Mac App

What about functional prototypes?

What if your prototype needs to do more than just look and feel like the final app? Some app concepts can only really be understood and tested with live data or working features like using the device camera. Depending on the level of complexity it may even be possible to prototype these too. One option would be to hook up the output of an HTML5 prototyping tool to some real device functionality in a hybrid app. Another option is to build a fully functional prototype in a rapid application development tool like LiveCode. Although there may be areas where performance or functionality are lacking compared to building a native app, LiveCode has a visual UI design environment and good animation capabilities. It also makes it very quick and easy to add a database of real data or mobile specific features. When you get to this level of prototyping complexity, it starts to get time consuming and costly to build the prototype. It may make sense to only prototype parts of an application in this way, where it’s critical to get the design right before a very lengthy and expensive coding phase.

Consider prototyping your next app in more detail

[tweetable]The most common problem in software projects is not the technical execution[/tweetable], although that often takes longer than expected. By far the most common reason for app projects to fail is building the wrong thing. Although on the surface building a prototype only to throw it away might seem like wasted effort, it can massively reduce the risk of much more effort going to waste building something either the client doesn’t want or insufficient customers are willing to pay for. Prototyping the UI and putting it in the hands of clients or potential customers in a real device is one of the best possible ways of getting concrete, actionable feedback. Pick one of these tools, or find another that suits you better and give it a try with your next app. If you’re already a prototyping convert and we haven’t listed your favourite tool here then let us know in the comments.

Categories
Business Community

Can the app stores sustain 5.5 million developers?

5.5 million developers

In our latest report, App Economy Forecasts 2015 – 2017, we estimate the number of mobile ecosystem in 2014 at 5.5 million developers. Demand for mobile development skills has never been higher and yet revenue from app store sales cannot possibly pay their salaries. Luckily they don’t have to as developers aren’t all building apps full time and there are several other revenue sources in the app economy, some of them comparable with or even significantly larger than the app stores.

Βlueprint of the app economy preview 4

Estimating the developer population

Counting mobile developers is hard. A lot of software developers look into mobile platforms and a lot of people are curious enough about how they’d make an app for their phones that they’ll try to find out. We can’t meaningfully count all of these as mobile developers. However, we also know from our Developer Economics surveys that a huge percentage of developers creating the apps that fill the app stores are not full-time professionals. Popular programming Q&A site StackOverflow has around 35 million unique visitors and it is only an English speaking community. That probably includes a lot of students trying to get help with their coursework. Meanwhile bottom up estimates for the global professional developer population based on job classification data from multiple sources are just under 20 million. This is highly error-prone due to the way developers are classified along with other IT professionals in many places around the world. How many of those are really building mobile apps anyway? Apple has over 9 million developers registered on their developer portal. Some of those are for Mac and Safari but the majority are iOS developers. Then again, the number of developer accounts with any apps published on the App Store for iOS is only around 350,000. Google Play has fewer active publishers than iOS. The truth must lie somewhere between these extremes.

For the purposes of our estimate we decided to count developers who are actively building, or planning to build in the very near future, publishable apps for a mobile platform. Students building toy apps to learn and hobbyists who only build things for themselves aren’t taken into account. Those people could join the ranks of mobile developers in the near future but they aren’t doing anything to satisfy mobile app demand yet. 5.5 million is the number of developers required to maintain all of the published apps that have been updated in the last 12 months, plus build all of the new ones released in the same period. In our report we also forecast the number of new and updated apps going forward and the number of developers required to sustain that app growth through 2017.

Keeping the pizza and coffee flowing

Developers are in high demand and as employees in the US they will typically earn upwards of $100k per year with relatively little experience. Proven talent in Silicon Valley can easily earn 50-100% more. Salaries in Western Europe are not quite as eye-catching but not that far behind either. In countries where the cost of living is much lower, developer salaries are obviously more modest but actually often a greater multiple of the national average wage.

Why would anyone with such earning potential build and sell apps that are likely to produce a poor return on their time. There are several answers:

  • Some apps make fantastic returns and some developers believe, or at least hope, they could emulate those and use their skills to make a small fortune
  • Other developers are trying to build small but sustainable businesses on the app stores, targeting niches and working as artists and entrepreneurs
  • Some developers build their own apps as proof of their abilities in order to sell their skills for a higher rate on contract development work
  • Many developers just love to code and already earn a full time salary in their day job, they build apps as side projects or for a hobby, either for fun, a little extra income or to sharpen their skills for their next career move
  • Some developers are purely learning and having fun, usually either at the beginning of their careers and in some cases after they’ve retired.

Note that only the first two of these are depending on the apps for income. Of course not all developers are trying to make a return from apps via paid downloads or in-app purchases. Advertising is also a big source of revenue in the app economy, although most of it goes to a few giant corporations. The typical developer monetising through ads does much worse than those using in-app purchases, so that’s not the answer. However, there are other models where developers have better odds of making money. Subscriptions are the fastest growing revenue opportunity according to our forecasts, although for pure Software as a Service rather than content subscriptions that will mostly be selling to enterprises. The biggest revenue opportunity of all in app economy over the next few years is definitely not in pure software businesses. Indeed, it’s the rather old-fashioned business of selling real physical things! Find out just how big it is by purchasing our latest report.