Categories
Business

The Science of Mobile Game Marketing

mobile game marketing

Two years ago, I stepped into the mobile games market when I joined Planeto in Malmö, Sweden. With more than 5 million downloads, Planeto is a leader in knowledge-based mobile gaming. The experience at Planeto has changed me as a product creator and marketer.

Like many of my Scandinavian tech colleagues, I come from the planet where they build mobile phones. One step up the software stack to apps did not seem like a huge leap, especially as Planeto develops games for smartphones. As it turns out, one of the most talented game designers in Southern Scandinavia took me to a planet that was significantly different.

This is part two of a three part series on battle insights by a mobile game CEO.

science-of-mobile-game-marketing

Living in a World of Algorithms

In my first blog post, I addressed the development of the magical gameplay loop, a process that involves human beings at a very fundamental level working with basic needs like happiness, competition, and the urge to progress. In stark contrast, [tweetable]the marketing of mobile games hardly involves any human beings at all[/tweetable].

The mobile gaming market is at the extreme end of the digital revolution. In other industries, there is an existing physical distribution and marketing channel that gently slows down the product life cycle. There are fashion shows ever so often. There are retailers, who stock up on new items once in a while. In mobile game distribution and marketing, there are no physical inventories. There are just algorithms and a furious pace.

In a world of appfication, anyone involved in product creation and marketing needs to understand the basics of algorithm-driven marketing. That is where we are heading.

Starting with the App Store

Most people find apps by browsing the App Store or Google Play. A close second is recommendations from friends and family. People across the globe discover games in those two ways. It is as simple as that.

Apple and Google have not disclosed how their search algorithms work, but app marketers suggest the following parameters have an impact:

  1. Title
  2. Keywords
  3. Rating value & numbers
  4. Downloads over time

Title and keyword optimization is a topic on its own. Let us instead explore how rating and downloads can be improved.

Getting Your 4+ Star Rating by Beating the Algorithm

If you have read my first post about the magical gameplay loop, then you already know that perfecting the gameplay loop is crucial to creating a good game. In most cases, a good game does not automatically guarantee a good review. Customers will give you a one star rating for many different reasons: connection errors, strange chat messages from other players, tiny features that they do not like, etc. Often bad reviews do not contain any text – just a single star, a negative impact on your ranking, and a customer that rapidly moves on to the next app.

To avoid the info-less one star review, you need to take the pace out of the rating algorithm by implementing a funnel system that leads customers to the right place. The objective is to get only happy customers, who are willing to spend time on your app, to leave reviews. Unhappy customers, who are also willing to spend time on your app, send you an email with their issues instead. Quite a simple change that actually provides much more valuable info – you may find the details here.

Boom… first small victory against the algorithms. 🙂

Cross-promotion is a Friendly Face in the Sea of Algorithms

Once you have your ratings sorted out, the next step is to drive downloads. By far [tweetable]the easiest and cheapest way to drive downloads is to cross-promote in your existing games[/tweetable]. This is of course not an option for first-time developers, who instead should be thinking of including mechanisms to cross-promote the next game. Never think of your business as a one game business. We have successfully used Appboy in all our products, and it works wonders for us. Chartboost is another option.

Create your own friendly faces!

Living with the User Acquisition Algorithms

If you do not have a successful app already, then you need to follow the painful path of acquiring new users. No friendly faces here. It all comes down to math. The basic equation you need to be aware of is this:

Average Cost Per Install (CPI) < Average Life-Time-Value (LTV) * k-factor

LTV can be calculated in many different ways, but in simple terms, it can be thought of as Average Revenue Per Daily Active User (ARPDAU) * Average retention in days. K-factor is the number of users invited by each new player. If your CPI is $2, your LTV is $1, and each player invites another player (k-factor = 2), then you are break-even.

As such, the concept is simple, but it explodes rapidly. There are hundreds of different advertising channels to use and hence CPI never stands still. ARPDAU is easy to calculate on a given day for all your users, but as soon as you break it down into segments/cohorts (time, advertising channel, segments, geo, etc.) it becomes very complex fast.

Very few developers win in their fight with the UA algorithms. This is truly a scary beast. Experiment with UA, but do not get carried away, until you have a winning formula. In general, nothing is 100% guaranteed. The formula might work for one geographical area and might be totally inoperative for another.

Apple Recognizes the Challenges with Algorithms

Over the last couple of years, the big game developers and publishers have gotten bigger and customers struggle to find new games – however good they are. Apple has been trying to curb the negative side effects of the App Store algorithms by including more editorial content. The aim is to promote quality games by letting human beings select the games that gets most visibility in the App Store. That has sparked an entirely new set of recommendations on how to get featured by Apple. Google stays true to its roots and is still working to solve the quality versus quantity issue with algorithms.

In a market where there are only two relevant stores, I am not sure I feel completely at ease with the thought that the storeowners decide what goes on the shelves. It drives up the bargaining power of those storeowners to new heights.

Optimizing Your Advertising Revenue by Playing Algorithms Against Each Other

Getting plenty of downloads is only one-half of a successful game. The other half is revenue. Most first-time F2P (Free to Play) game developers make the mistake of implementing their own advertising solution with one or two advertising networks. This does not work and it will hurt you badly, if your game makes it through the noise and becomes successful.

You need an ad mediation layer from the get-go – an algorithm that allows you to fight all the other ad algorithms for you. More about revenue options in the third and final blog post of the series.

…and That is Only the Beginning of Mobile Game Marketing

I have not touched on keyword optimization, user engagement campaigns (i.e. how do you convert users from free to paying users), user acquisition tracking, k-factor optimization (i.e. how do you get users to invite other users), and retention funnels. For each of these areas, there are plenty of algorithms to learn and speak.

To make your apps successful you need to take on the algorithms that govern the marketing and distribution of games. As a rule of thumb (and to set your developers’ expectations right), it is reasonable to budget with 50% of a quality free-2-play game development project being on components (in-house or 3rd party) that does not relate to the actual gameplay loop.
We all love to work on the magical gameplay loop – it is truly rewarding – but the right infrastructure components allows you to take advantage of the algorithms. Do not underestimate the power of the algorithms.

Interested in part three of the series on mobile gaming? Read about Business Models here

Categories
Business

Forget about Gamification – It is All about the Gameplay Loop!

Screen shots from Battlefield 4: Gameplay loop takes less than 3 secs from target spotted to kill confirmed, but type of enemy, weapon type, and environment adds depth to the loop, which is repeated over and over again!

Two years ago, I stepped into the mobile games market when I joined Planeto in Malmö, Sweden. With more than 5 million downloads, Planeto is a leader in knowledge-based mobile gaming. The experience at Planeto has changed me as a product creator and marketer.

Like many of my Scandinavian tech colleagues, I come from the planet where they build mobile phones. One step up the software stack to apps did not seem like a huge leap, especially as Planeto develops knowledge-oriented games for smartphones. As it turns out, one of the most talented game designers in Southern Scandinavia took me to a planet that was significantly different.

This part one of a three part series on battle insights by a mobile game CEO.

The Magical Gameplay Loop

Having built products with some of the best people in their field, I claim to have a good understanding of how to approach a new product idea. In simple terms, the process involves a deep dive into the needs of the particular user, understanding what technical approach might deliver a product that caters to those needs, creating a first version (1.0), shipping it to the users, learning from the users, and then building an even better version 2.0. Each step has a number of tools you can use to deliver as much “bang for the bucks” as possible. You aim to capture as many facts as possible to keep learning and testing assumptions. Although user experience design and prototyping can make up significant parts, the overall creation process resembles a deductive science project where uncovering the truth is the overarching aim.

The magical gameplay loop makes mobile game creation a very different process. The magical gameplay loop builds on the fundamental premise that delivering entertainment is hard, but when you get there, it is obvious that you have arrived. You will see it in the smile, in the clenched fist raised in the air, or a loud “damn it!” – quite magical, when it happens. 🙂

Endless Iteration of the Loop

[tweetable]The gameplay loop is what the player does over and over again[/tweetable]. In a First Person Shooter (FPS) game, the gameplay loop goes like this:

  1. a target appears
  2. you aim at the target
  3. you pull the trigger
  4. the projectile moves towards the target
  5. you hit the target
  6. the target loses life

You will do this over and over again, so this loop has to work to perfection – because if not, the player will immediately notice a glitch in one of the steps. Sounds easy, but as soon as you start adding depth to the gameplay, you start challenging the loop: different targets (speed, size, life, etc.), different weapons (power, range, accuracy, etc.), different environments (complexity, dynamics, etc.), and so on.

Screen shots from Battlefield 4: Gameplay loop takes less than 3 secs from target spotted to kill confirmed, but type of enemy, weapon type, and environment adds depth to the loop, which is repeated over and over again!
Screen shots from Battlefield 4: Gameplay loop takes less than 3 secs from target spotted to kill confirmed, but type of enemy, weapon type, and environment adds depth to the loop, which is repeated over and over again!

[tweetable]The process of developing a mobile game starts with the gameplay loop[/tweetable]. You iterate the gameplay loop many times. Planeto is on more than 20 iterations of the next game. Forget about graphics. Forget about login. Forget about high score. It is all about getting the gameplay loop nailed down, testing it with real people, and observing whether you get a fist in the air or the “one more time!” that you are looking for.

It is an inductive process, in which you start with the gut feel and experience of the game designer, observe the reaction from the players, and then iterate until you get to something that is highly entertaining. Although you can access courses and tools, like “F2P Toolbox” creating great gameplay requires experience and a lot of patience. The development of the gameplay loop deals with human beings at a very fundamental level of basic needs, like happiness, competition, and the urge to progress.

Only when the gameplay loop is truly magical do you begin the “normal” development process.

Looking for the Loop

Once you realize the significance of the gameplay loop, you start playing games in a completely new way. You appreciate the beauty of the loop in good games and you become much better at looking beyond beautiful graphics and distilling the essence of a game. You also start benchmarking games against each other on a detailed level.

This brings out a number of interesting perspectives. First, can you find a gameplay loop in other types of products than games? Is there something that the user does repeatedly and therefore needs special attention and many development iterations? I have looked back at products that I have been involved in and I can point to the core loop in most of them. Some of the core loops were brilliant, but some of them were average to poor, as the features and general infrastructure detracted from the essence of what the product was supposed to deliver. My first take-away: look for the loop and make it perfect!

Gamification – a Contradiction in Terms?

My second take-away is about the inherent contradiction in the popular notion “gamification.” If the essence of a game is the gameplay loop, then you cannot gamify something that has an entirely different user experience loop and purpose.

Let’s take CRM as an example. The purpose of a CRM system is to improve the relationship with the customer. In other words, a CRM system offers a set of mechanisms that remind/drive the sales person to interact with the customer. A gamification project might introduce badges for different activities, high score lists for the best performing sales people, or other elements you might find in a game. Gamification does not, however, change the core user experience loop in a CRM system, which is: 1) enter data to qualify the relationship with the customer, 2) create a profile of the relationship with the customer, and 3) get notified about needs for actions/next steps, which in turn creates qualification data. This set of user actions is not a game. You might get a fist in the air when a deal is won, but sales people will still hate updating the account in the CRM system – even, if they get a nice “Sales Person of the Month” badge 🙂

Games Can be Much More than Fun

This does not mean a game cannot deliver more than just fun. As I will explore in my upcoming blog post “Mobile Gaming as a Business,” I am a firm believer that business model innovation is one of the biggest opportunities in the mobile games industry. At Planeto, games are used for lead generation. Games can also tell stories or educate. It is, however, essential that the starting point is the magical gameplay loop. If you do not get that right, then you cannot deliver on anything else.

Interested in how to combine Magic and Algorithms to create a successful Business Model? Read part three of this Blog series here.

Categories
Tools

Android cryptography tools for beginners

android cryptography tools

Mobile applications draw the attention of hackers more and more each day because they have something that the attackers want, user data. Hard-coded secret keys, personal information stored in plain text on SD cards, usernames and passwords found unencrypted in databases, analytics collected and sent in the clear to remote servers, are just a few cases that make the life of an attacker easier. This post focuses on Android Cryptography tools for beginners

android-cryptography-tools-for-beginners

How do you go about protecting your users’ data? Take the Developer Economics Survey and let us know. You might win amazing prizes and new gear.

Cryptography is the right tool to use in order to protect sensitive data, and ensure confidentiality and/or integrity. On the other hand, [tweetable]cryptography is hard to use and easy to misuse[/tweetable]. Note that broken cryptography (e.g. using insecure algorithms or hard-coding keys into binaries), is listed in the top 10 mobile risks for 2014. So what’s the lesson to be learned? Well, whereas not using cryptography can be bad, not using cryptography in the right way is just as bad (not to mention time-consuming).

Let’s see then how cryptography can be used in a way that’s both easy and appropriate, in order to develop secure applications for the Android platform.

First, an overview of some popular cryptographic libraries that can be integrated into Android applications. Cryptographic libraries can be seen as cryptographic toolsets that contain tools, such as encryption algorithms, padding schemes, and hash functions.

Bouncy Castle

The Legion of the Bouncy Castle is a charity from Australia that has written Bouncy Castle, a widely used library that provides both a light-weight cryptography API and a Java Cryptography Extension (JCE) provider. The Android platform already ships with a cut-down and outdated version of Bouncy Castle (with small changes in order to make it work on Android). Consequently any attempt to build and use the latest full version of the library in your application, results in classloader conflicts.

Spongy Castle

The motivation behind Spongy Castle is to allow Android developers to bundle any version of the Bouncy Castle library they want with their applications. Spongy Castle is basically a repackage of the latest version of the Bouncy Castle library; all org.bouncycastle.* packages have been renamed to org.spongycastle.*, and the Java Security API provider’s name has been changed from BC to SC.

OpenSSL

OpenSSL is an open-source toolkit that provides implementation for the SSL and TLS protocols, as well as a general-purpose cryptography library. OpenSSL has been ported to many platforms, including Android. As an alternative, you can also build it from source (using the Android NDK) and bundle it with your application.

Let’s assume now, that for application purposes, you want to encrypt some data. What encryption algorithm should you use, AES or DES? How long should your key be, 128 or 256 bits? Which encryption mode should you use, ECB or CBC? If you do not have an answer to all these questions, along with a good reason for each answer, then it seems that you have found yourself in a position where, although you probably have all the tools you need, you are not absolutely sure which ones to use and how.

This is exactly the point where cryptographic toolkits for dummies come into play. These toolkits do not implement any exotic cryptographic functionalities, nor do they intend to replace the cryptographic libraries presented above; they rather built on some of them with the sole purpose of making cryptography easier and safer to use.

Contrary to a general-purpose cryptographic library, such a toolkit normally supports only a subset of the algorithms, modes, schemes, parameters, and other cryptographic tools that are out there. Instead it provides you with sensible defaults in case you (a) know what you want to do but don’t know how to do it, or (b) don’t really care as long as you end up with a safe solution. Let’s examine some of these toolkits to better understand their role.

Keyczar

Keyczar is an open-source toolkit originally developed by two members of the Google Security Team. It has implementations in Java, Python and C++. It supports authentication as well as both symmetric and asymmetric encryption. Keyczar provides safe defaults for algorithms, key lengths and modes, key rotation and versioning, automated generation of initialisation vectors and authentication codes, and internationalisation. This specific toolkit is based on JCE, and its demo for Android (available here), uses Spongy Castle’s security provider.

AeroGear Crypto

AeroGear Crypto is a small Java library provided by AeroGear. It supports authenticated symmetric encryption, elliptic curve cryptography, and password-based key derivation. It also provides sensible defaults for algorithms. AeroGear Crypto depends on Spongy Castle for Android and Bouncy Castle for other platforms. The library is also available for iOS, Windows Phone and Cordova.

Conceal

In an attempt to find a fast and memory-efficient way to encrypt and authenticate large files on SD cards, Facebook developed Conceal. Conceal supports both authentication and encryption, and provides default implementations for key management. It uses OpenSSL, but includes only the necessary parts of it, thereby keeping its size at 85KB. Results published on the site of the library show that Conceal outperforms Bouncy Castle.

A summarised view of the libraries presented above is given in the following table. Note that, although all these libraries aim to safely fill in the gaps for developers that are new to cryptography, advanced developers can skip the defaults and specify all the details themselves (as they would do when using any crypto library).

Library Company License
AeroGear Crypto AeroGear Apache 2.0
Conceal Facebook BSD
Keyczar – Apache 2.0

To sum up

If you are a mobile developer, you need to spend time making your applications usable, functional, and attractive BUT you also have to spend time making your application secure. If you do not know how to do so or if you’re worried that you might not get it right, then use one of the libraries described in this article in order to get started. No matter what cryptographic tools you decide to use, avoid implementing your own cryptographic algorithms and/or protocols; use only algorithms and protocols that are widely used, accepted, and ones that users have already spent enough time trying to break.

 

Which skills you can develop to be more effective in protecting your data?Take the Developer Economics Survey and we will let you know. Plus you may win new gear.

Categories
Platforms Tips

4 out of 10 sites unaware of the Google’s new Mobile Ranking Signal

mobile ranking signal

A variety of mobile devices have flooded the Web in the past years. To no one’s surprise, Google announced that starting April 21st, they’ll expand the use of mobile-friendliness as a mobile ranking signal, in fact penalizing all sites that don’t have a mobile strategy – dubbed “Mobilegeddon” in the recent press.

Furthermore, Google just paid $25 million for exclusive rights to the “.app” top-level domain. Although the company hasn’t yet announced any specific plans for .app, this could be the signal that the Mobile Web will evolve beyond Responsive Web Design (RWD) and lean more towards rich UX/UI and mimicking of the native environment.

Presumably, [tweetable]the update to their algorithm will have a significant impact on Google’s mobile search results[/tweetable]. If you’re like me, you’d want to go all the way and find out the specifics: what is the current distribution of mobile web strategies, how many websites will be impacted by this change and to what degree? If you already have a mobile web strategy in place or just started developing one, you’d probably also want to know how to optimize it: how “lengthy” should your pages be or how “heavy”? And what Google’s PageSpeed Insights has to says about it?

We have searched the answers to these questions by analyzing the top 10,000 Alexa sites, from 5 different categories: News, E-commerce, Tech, Business and Sports. What we discovered was no less surprising and we felt like this is something worth sharing with the community. Before diving into the data let me tell you a few words on the methodology.

As per Google’s guidelines, we have taken into consideration three types of configurations for building mobile sites:

google-table

Google recognizes three different configurations for building mobile sites. (Google Developers)

  • Responsive web design: serving the same HTML code on the same URL, regardless of the users’ device; render the display differently based on the screen size.
  • Dynamic serving (also known as adaptive): using the same URL regardless of device, but generating HTML code dynamically by detecting the browser’s User Agent
  • Separate URLs (also known as mobile friendly): serving different code to each device and a separate web address for the mobile version

To detect the strategy used by different websites, we have crawled them using an iPhone User Agent.

Mozilla/5.0 (iPhone; CPU iPhone OS 5_0 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A334 Safari/7534.48.3

On top of that, we also identified those sites that implemented a Smart App Banner meta tag in the head of their home page, to market their iOS app:

<meta name="apple-itunes-app" content="app-id=myAppStoreID">

For analyzing the performance, we have used the PageSpeed Insights API, which takes into consideration not only the size of a webpage, but also compression, server response time, browser caching and landing page redirects, among others.

We also wanted to see how long mobile pages have become. Since RWD relies heavily on scrolling, we asked ourselves if this is an effective way to display content and what can be considered an optimum page height. Throughout the rest of the article, you’ll see references to “X5” height rate, which means that a site’s main page height is 5 times the height of the viewport on iPhone 6 (375 x 667). This is an indication of how much scroll needs to be done in order to reach the last piece of content.

visionmobile-infographics

Overview of Mobile Strategies on the Web

It’s 2015 and if you think that RWD is winning over mobile friendly sites (separate URLs), you’re spot on. Nearly 28% of the sites we’ve researched are responsive, while 26% have opted for a separate mobile address. The gap is indeed there, but it’s not as wide as we might have assumed. The surprising fact is that 40% of the researched sites have no mobile web strategy whatsoever! To me, that’s HUGE! Since Google’s new algorithm update is just around the corner, we can easily imagine that ignoring mobile users will no longer be an option.

Deeply buried in the data, we’ve also found another interesting fact: approximately 4% considered that being adaptive (serving different content under the same web address) is the right strategy for their mobile web presence.

2% of the researched websites have chosen to target their mobile users through applications (iOS). The number may in fact be bigger, but the inconsistency in promoting their apps makes them difficult to track.

Let’s dig a little bit more and see the variations between different categories and the impact that each strategy has on the overall mobile experience.

Newspapers – resistive as always

Being “stuck in the past” seems to be rightly attributed to the publishing industry, especially to newspapers: 38% of the websites from this category are mobile-friendly (separate URLs) and only 25% responsive.

In the PageSpeed Insights (PSI) results, adaptive comes on top with 75% scoring between 40 and 60 (although only 15% are above 60). Interestingly enough, mobile-friendly sites score even better (19% with PSI > 60), while only 11% of responsive sites have a score higher than 60. In fact, most of the sites that score under 20 are responsive (10%).

Wait, what? I thought Google loves responsiveness, right? There are countless articles about how Google recommends RWD as the best way to target mobile users. Surely, something doesn’t add up!

Or maybe most of the responsive sites don’t comply with Google’s own recommendations. A plausible explanation might be that developers have mistaken Google’s love for good mobile experience with the love for responsiveness, thus taking Google’s guidelines for granted. Instead of taking advantage of RWD, they end up producing sites that score poorly on all aspects.

When looking at sites’ height distribution on mobile devices, we see that the average for mobile-friendly ones is X8, which is pretty close to the X7 average rate represented by adaptive sites. However, 54% of adaptive sites have a less than X5 height rate.

In all fairness, “old” doesn’t necessarily mean wrong for newspapers sites and this time it might be working in their favor: 47% of responsive sites have a X10 – X15 height rate and 14% even over X15, which means that mobile users have to do a lot of scrolling before reading a certain piece of content.

So why are mobile friendly pages shorter? Did they notice that not so “lengthy” pages are more suitable for reading content on mobile? Is that the reason behind choosing mobile friendly (separate URLs) over responsiveness? But if that’s the case, why not going all the way towards adaptive? They’re doing a better job in terms of producing closer to optimum mobile pages (averaged at 2.5MB for both mobile-friendly and adaptive, compared to 3.7 MB for responsive) so perhaps it’s the ease of managing a separate mobile site all together.

Looking at Alexa’s popularity ranks, we notice that as the rank decreases, the number of responsive websites grows. The majority of sites with a low popularity rank are in fact responsive (14%), while 53% of the analyzed adaptive sites place themselves among the top ranked ones.

Tech sites – leaning towards RWD

In contrast with the above findings, responsive sites predominate in the “Tech” category (33%), while only 12% are mobile friendly (separate URLs).

In addition to that, 58% have page sizes under 2MB and consequently – a higher score on PageSpeed Insights: 51% mark over 60 and only 1.5% under 20. A page size of 2MB might sound a bit too much, but in fact, caching and other factors are influencing the overall PSI score.

When comparing the results to the newspapers category, tech websites show a major improvement. Yes, responsive sites still have the biggest height ratio (X6), but the average is significantly lower than what we’ve found earlier (X8).

Unfortunately, the “Tech” category also has the biggest percentage of sites that have NO mobile strategy whatsoever: 51%. It would seem that we have either modern responsive sites or nothing at all.

Overall, adaptive sites are still the most efficient in terms of score, but responsive sites are stealing the 1st place when it comes to height ratio, with a slightly bigger percentage of websites having a height rate of X5.

E-commerce sites fare better than most

For the “Shopping” category, mobile-friendly (separate URLs) and responsive sites are at a tie: 26%. Surprisingly though, adaptive e-commerce sites scored the biggest percentage of all categories: 6%. What would cause e-commerce sites to lean towards adaptive?

One plausible reason can be their appetite for improving conversion rates, thus their attention to optimize everything related to the buying funnel, which is influencing their mobile strategy as well.

If we analyze the height distribution for all three configurations (separate mobile URLs, responsive and adaptive), we see a pattern emerging: e-commerce sites, regardless of their mobile strategy, have the biggest percentages for under an X5 height rate: 90%, 58% and respectively 81%.

One could speculate that the reason for keeping their pages shorter is related to the influence that a lower height ratio might have on conversion rates. On top of that, PageSpeed Insights offers the highest score for all three mobile strategies: ~90% of mobile friendly/adaptive sites and 75% of the responsive ones have scored at least 40 points.

[tweetable]Clearly, e-commerce sites are doing a great job at optimizing for mobile[/tweetable] and, regardless of their favorite strategy (adaptive sites seem to be leading by a low margin), they’re mastering it like no other.

Apps – still luxurious game to play

Among other categories, we’ve found that mobile applications are appealing too: close to 6% of sites from “Business” and “Sports” have created their own iOS application, even if most of these previously opted for mobile friendly sites: 9% respectively 15%.

As a general rule, regardless of the category, if a site doesn’t have a mobile web strategy, chances are it won’t go for an application either. You’d expect it to be the other way around, but if a site owner ignored all previous mobile web strategies at his disposal, would he really be open to a more laborious and expensive approach (apps)? Not really.

Optimum Height and Page Size on Mobile

Analyzing ~10,000 sites in various categories surfaced a couple of guidelines that you might want to take into consideration when implement your mobile web strategy. In essence, what’s the maximum height and page size that your mobile friendly, responsive or adaptive site should have to ensure a 50+ PageSpeed Score?

If we analyze page sizes less than 2M, we realize that mobile-friendly sites, particularly in the Sports category, come on top with little over 91%. We also notice that only 30% of responsive sites score over 50 on PageSpeed Insights. Again, just keeping the page size at this level isn’t enough to ensure a high PSI score since caching can be equally important, but it’s a good place to start.

Interestingly enough, the “News” category is the only one where the majority (52%) of the adaptive sites with scores over 50 has page sizes between 2MB – 4MB. Even if adaptive sites seem to be able to “carry” more weight, their height rate should be kept at the minimum (X5) to ensure a good score.

Applying the same logic to height rates, clearly X5 seem to be the optimum rate for scoring 50+ on PageSpeed Insights. Once more, responsive sites seem to have the least chances of scoring over 50, even if they aim for a lower height: 62%.

Is the Mobile Web Heading Towards “Appification”?

[tweetable]Today, mobile web consumption occurs mostly from in-app browsers[/tweetable]. Just look for example at the Facebook app, that used to open links by using an external browser. Now, they have embedded a browser directly in the app and it makes sense – they don’t want their users to have a broken experience.

With that in mind, shouldn’t mobile websites offer a more app-like experience? Isn’t the linear scrolling experience we see on responsive sites a bit outdated?

In all fairness, what we’ve concluded thus far doesn’t take into account various UI/UX aspects and doesn’t answer some critical questions: When scrolling becomes too much for a mobile site? What’s the impact of having a long scroll and is this the reason for poor mobile reading experience on the web? What else can we do to ensure that mobile users have a good experience on the web?

That’s why in the second phase of the study we’ll analyze how much scrolling is actually being done on a responsive page, on mobile devices. After gathering relevant information on how mobile users interact with responsive sites we’ll be able to complete the next phase of the study by answering some key questions:

  • What’s the mobile device and browser they’re using for accessing a site?
  • How much time they spend on a particular page?
  • What’s the maximum scroll height they reached on a site?

From “Nice To Have” To Mandatory

We’ve seen that 40% of the top 10,000 Alexa sites from 5 categories (News, Tech, E-commerce, Business, Sports) don’t do anything when it comes to their mobile users. However, we’re in the middle of a big shift: [tweetable]having a mobile strategy on the web is no longer just “nice to have”[/tweetable]. If we take into consideration the impending change of Google’s mobile ranking algorithm, we can conclude that at this point any mobile web strategy is a good strategy.

As far as this first part of our study is concerned, from a technical point of view, a page that fits within 2MB and has a height rate of X5 has a good chance to score 50+ on Google’s PageSpeed Insights. Although adaptive websites are overall the most efficient ones regarding these aspects, they are not very popular either. Even though the study clearly shows that RWD is far from being optimum, responsiveness is the leading strategy adopted when targeting mobile users.

If we add to the mix the “.app” top-level web domain bought by Google, the line between native apps and web apps is getting thinner and thinner. The Mobile Web is already evolving beyond responsiveness into something new and exciting where everything is an app instead of a site, where user interactions are more important than just page views and ultimately where all apps are interlinked into a Web of apps.

If you are interested in learning more about mobile app development read the third post of our series on Mobile App Marketing, on Business Models.

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
Platforms

How Soon Is Now For The Mobile Web?

This may be the year when the mobile web apps finally go mainstream. Or, at least, their hybrid cousins will.

how-soon-is-now-for-the-mobile-world

Not because the technology will finally be ready. For most apps, it already is. Rather, the web will finally hit the big time with mobile apps precisely because we’ll talk about it less and use it more.

Time for HTML5
Oh, sure, there are good reasons for the mobile web to finally hit its stride. Sencha’s Nick Harlow offers five:

  1. High quality WebViews are now available on most platforms (and getting dramatically better thanks to Apple’s new WKWebView in iOS 8). While low-quality WebViews persist within the Android device base, on balance things are looking up;
  2. Broad platform support is only economically feasible using web tech;
  3. Web tech bridges the desktop-mobile divide;
  4. Using web tech helps to simplify application management and security; and
  5. Device fragmentation is accelerating. The web helps developers keep up

But before we herald the future of hybrid, it’s worth pointing out that some believe that future is already here. As EmberJS co-creator Tom Dale tells me, “”The dirty little secret of native [app] development is that huge swaths of the UIs we interact with every day are powered by web technologies under the hood.”

While Dale may be getting ahead of himself – [tweetable]the reality is that the web still has a long way to go to achieve mass-market app adoption[/tweetable], and maybe constitutes 10% of apps within the app stores – the trends do point toward more hybrid apps, especially among the enterprise set. VisionMobile’s own survey data shows that today 30% of developers are using some kind of cross-platform tool, of which 60% are using PhoneGap.

This is great, but it doesn’t obviate the need for the mobile web to get better to erase complaints about performance. And it will.

Getting better all the time
Summarizing the Google Chrome Developer Summit, Divshot CEO Michael Bleigh says, “Google is doing everything it can to get mobile web to 60fps, which gives you about 16ms per frame to do everything you need to do. It’s hard to even enumerate all the different ways they’re working on this.” Speed will bolster web app performance, perhaps eliminating the “jank” that many associate with web apps.

But it’s not just about accelerating the mobile web.

We also need to rethink how we approach mobile web apps, as Ionic (based on Google’s AngularJS) and React Native (from Facebook) do. While the latter is not “web technology,” strictly speaking, these frameworks are actively advancing the state of the art for web apps.

The result, as Mozilla (and longtime native app) developer James Long puts it, is impressive:

It only takes a few minutes playing with React Native to realize the potential it has. This works. It feels like I’m developing for the web. But I’m writing a real native app, and you seriously can’t tell the difference. At the UI level, there is no difference; these are all native UIViews beautifully sliding around like normal.

Indistinguishable from native performance… but with a far more accessible development platform. That’s powerful.

A question of competence
But let’s be clear: [tweetable]if your development team isn’t any good, it really doesn’t matter which development platform they choose[/tweetable]. A bad iOS programmer is going to lose every time to a good HTML5/web programmer, and vice versa.

Indeed, one of the primary problems with the web is that it so dramatically lowers the bar to development that virtually anyone with Javascript and CSS skills can build a mobile app.

A lame one, that is.

Mobile developer Nic Raboy nails this:

All my applications, native and hybrid, have mostly positive reviews and if you visit the apps on Google Play, you’ll see no reviews include mention about how the application was crafted. This is an important thing to notice because many haters will attack developers on the idea that hybrid applications do not perform or look as good as native applications. This is simply not true. Native or hybrid, if the developer or designer is no good, the application will suffer regardless.

So as fantastic as advancements like AngularJS and ReactJS will be for web app development, they’re not going to be enough if developers underinvest in learning them. There are already exceptional hybrid apps like Instagram that demonstrate what strong developers can do with the web. We just need more of them.

Or maybe what we need is better tools.

That’s one primary takeaway from VisionMobile’s “How Can HTML5 Compete With Native?” report. As report author Dimitris Michalakos concludes, “The question is no longer *whether* HTML5 can produce quality apps, but *how* easy it is to create quality web apps.” Given that “HTML5 is like driving a car without a dashboard,” the key is to deliver better dashboards, or tools, to make it easier to build great web apps.

This involves significant improvements to the debugging, profiling, and memory management tools available, but it’s also something the web frameworks can help with.

As such, it increasingly looks like a question of WHEN, not IF, mobile web apps will take off.

And the answer to that question is either “now”, if you’re paying attention to how developers actually build apps today, or soon, if you’re waiting for them to start talking about the fact that they’re building with the web.

Categories
Community Tools

Developer Interview: Building Apps for Wearables Isn’t about Tools

apps for wearables
Digital magazines

Softeq Development is involved in everything mobile: from business apps, digital imaging and utilities to mobile games, wearable technology, sensor-rich equipment and its remote management. They have built dozens of embedded solutions, web, and mobile applications for such clients as Nike, NVIDIA, Omron, AMD, Atlas Copco, EPSON, Disney Parks and Resorts. T. Our associate author, Alkis Polyrakis, discussed with Softeq’s CEO, Chris Howard.

What is the philosophy that you employ in order to assist companies take advantage of the full potential of the latest technology?

To me, our philosophy is to be ahead of the curve. It means we try to know and adopt new APIs, tools, and technologies before customers actually need it. We obtained and evaluated Google Glass, EPSON Moverio, Oculus Rift, LEAP motion controller and many more new tech novelties long before the first project came along. Once a customer approaches us with a project for those new technologies, Softeq is already the most competent tech provider the customer can possibly find on the market. Having close ties with many companies in Silicon Valley, we were one of the first tech firms in the world to access and implement, for example, Microsoft’s high speed video APIs on Windows Phone before they were available to the public.

Digital magazines
Digital magazines

What are the benefits of implementing a Proof of Concept in business projects?

A proof-of-concept (PoC) is a great first step on the way to a new product, device or technology that was never seen before because it’s a low-risk and low-investment approach. Often, it requires a 10-20 times smaller budget than actual new product development.

In our business, we have come across two different goals, or approaches if you like, to building PoC apps. One is when a customer is looking to prove the feasibility of his new business idea. At times, our clients need to demonstrate a working prototype of an upcoming product at a trade show, board meeting, or at an investor meeting. Prototypes later can become Minimum Viable Products (MVPs) and both can be stages of a full product development cycle if the idea gets approval.

Xamarin framework Business apps development
Atlassian Jira Project management
LabView – LabWindows – MathLAB Wearable devices
Flurry – Google Analytics – Localytics – Adjust – Parse Monetization
Unity Games development

Softeq’s Toolset

The second typical need is when a technically advanced company researches next-gen ideas, software or hardware they’re looking to jump into. Here, building a proof-of-concept in the first place is a way to test the feasibility of their vision for the application of new technology, a hardware component, or form factor. Just like that, our R&D teams have been working for Nike, Intel, and EPSON to help then visualize their new ideas and prove it is actually possible to do what they envision.

Do you have a specific development procedure when working on a PoC?

As a PoC is always something pretty innovative and non-standard, generally the development procedure is to identify the key features of what a client is trying to do in a bigger project, focus on only testing and proving out the specific new APIs or new hardware, and building a very simple framework in order to demonstrate that specific capability. After the PoC is approved by the management team, the investor, or the end-client, we proceed to flesh out the rest of the features and ship an actual product.

Which development and project management tools do you employ in order to facilitate your needs in cross platform development?

There are several cross-platform frameworks trending on the market now, and this is fair enough. The mobile market is no longer dominated by one platform, and most of our customers, both in the B2B and B2C segments, need to target wider audiences with various OS preferences. We use the C# based Xamarin framework for business apps, and Unity for games. Speaking of project management tools, we use Atlassian Jira by default or any other tool the client is more comfortable with.

Our readers would like to hear some examples that show how you managed to pump up a company’s marketing efforts with your apps.

Marketing apps for Blizzard and Branson Ultrasonics
Marketing apps for Blizzard and Branson Ultrasonics

Marketing apps vary, and we’ve delivered several dozen of them: from Blizzard’s BlizzCon event management app for helping improve the guest experience, to mobile CRM, promotional games, mobile magazines for corporate clients, and demo apps for tech events and industry-specific trade shows and all the way up to international tech summits and even Mobile World Congress where companies present their new or would-be products. We’ve built several kiosk apps for in-store demonstration of new gadgets to buyers. One of them was for NVIDIA’s SHIELD – the world’s first Android TV console. The kiosk mode allows demonstrating all functional features, including games, videos and music playback, while blocking access to system settings.

What are the main challenges that you face when you attempt to build solutions for wearable devices?

We’ve been working on embedded devices for a very long time, over 15 years now, that’s why the era of wearables came very natural to us. The challenges anyone designing a wearable device inevitably faces are technical limitations of the form factor, such as short battery life, small amount of memory, insufficient performance, custom communication protocols (infrared, Bluetooth low energy) and more.

However, Softeq is uniquely positioned in this market and beyond, in the Internet-of-Things (IoT) space, because we do everything from hardware, low-level and firmware to web backends and mobile apps covering all our departments end-to-end. To extend that further we have a game department, and that even gets mixed in with wearables and the IoT.

Hardware Design and Embedded Development Lab deployed in Softeq's HQs in Houston, Texas
Hardware Design and Embedded Development Lab deployed in Softeq’s HQs in Houston, Texas

Can you tell us about some of your wearable device projects and the tools that you employ?

One of our current projects involves embedded touch panels, and we do both firmware for the panels and Qt-powered games for them. Another product we helped create – the BlinkFX Wink, which is a wireless control LED light wearable device – is being used for an upcoming game show at CBS.

There’s a wide range of tools and instruments, mainly in C, that we use for such projects. For instance, recently we started receiving multiple requests for projects involving drones. We suggest using such behavior modelling tools as LabView, LabWindows and MathLAB, but it’s not the tools that matter most. The most complex part is building math models and algorithms based on them.

Do you provide consulting services as to which model can maximize a game’s revenue?

The monetization system of a game is usually built by a tandem of experts – a game designer and a marketer. The game designer is responsible for building game mechanics in terms of monetization and balancing economics while the marketer drives user acquisition campaigns.
To ensure we deliver the maximum amount of effort on our end to ensure the game’s success, our game designers invest a lot of time in research, comparative analysis of top apps, exploring best practices and efficient mechanics to put them in our arsenal. From the game design perspective, we certainly consult developers at the early stages of building the monetization system: building the core loop, the in-game store, retention mechanics, economics balance, analytics, A/B testing system implementation, etc. For instance, we work with such analytical tools as Flurry, Google Analytics, Localytics, Adjust, Parse and the selection of tools depends largely on the game specifics and client’s preferences.

Thank you very much for taking the time to share your strategy with our readers.

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
Tools

Developer Interview: Which tools is WillowTree using?

The official University of Virginia app for Android

WillowTree (www.willowtreeapps.com) is a leading app development company that has produced over 300 titles since 2007, such as My Pregnancy Today that has seen more than 12 million downloads. Our collaborator, Alkis Polyrakis, discussed with their Systems Architect, Alex Shafran, who led the development of projects for GunBroker, Quintiles, the Red Cross and the NBA, about their strategies and tools of preference.

Please begin by giving us some information on a few of WillowTree’s most successful apps.

WillowTree has helped clients succeed in a variety of markets. Johnson & Johnson’s Baby Center apps have been a worldwide success, grossing over 10 million downloads and consistently ranking high in the App Stores. We recently released the new version of the official NCAA app, which is the main source of college sports scores and news. In the enterprise, we built an app for the AOL marketing team that auto-generates sales slideshows based on a quick questionnaire. This app saves each salesperson hours each day and allows them to prepare less and sell more.

BabyCenter Birth Class offers advanced video integration
BabyCenter Birth Class offers advanced video integration

WillowTree claims to tackle complex enterprise-grade mobile deployments by beginning with a simple question: “Where should what logic live?”. Can you explain what this quote means to our readers?

Even the simplest “mobile apps” require infrastructures to support them. Ordinarily, this “backend infrastructure” is software running on a collection of servers in a data center. By asking where should live, we are referring to the separation of concerns between the app on the phone and the backend servers. Consider Pandora, the popular music streaming app. When the Pandora app is downloaded from the App Store, the phone now has the code to run the app. However, the phone must get the music from somewhere — the entire music catalog is not stored on each user’s phone (that would be redundant…and impossible). This is where backend servers come into play. At a basic level, Pandora has a collection of severs that store the millions of songs in their catalog. When the apps need to play a song, they use the internet to download the song in real time from one of these servers.

Pandora is the most obvious example of “where logic should live” — clearly the entire music catalog should not be on each phone. But we encounter different flavors of this problem everyday, from “Should the phones store the user’s password” (the answer is no, NEVER), to something as basic as “Should we use the phone’s clock or the server’s clock in our realtime bidding app?”. While the answers might come easy to us, talking through these details can help our clients understand the benefit of adding an additional component to the system.

The Barclays Center app helped the stadium become one of the most technologically advanced arenas in the world
The Barclays Center app helped the stadium become one of the most technologically advanced arenas in the world

The sheer number of mobile apps that you have developed for major clients is impressive. In addition to quality project management, this is a clear indication that you are using the right development tools. What are those, and how do they make your job easier?

Development tools are only part of the story. They are critical to keeping projects on track, but they must be used as a supplement, not a replacement, to in-person communication. Our entire development team is colocated in Charlottesville, Virginia, which gives us massive efficiencies. When possible, we like to share those efficiencies with our clients. We regularly send entire project teams to client sites, and their development teams visit us just as frequently. There is no replacement for in-person collaboration.

Of course, we also make regular use of phone checkins and online tools. We use Teamwork for project management and communication. It is so simple and powerful that many of our enterprise clients have also adopted it internally. Project/sprint planning is done in Jira, which helps us gauge project burndown and overall progress.

Our continuous integration system (CI) is the most automated tool in our process. When a developer commits code, the CI downloads the newest code, builds it, runs the auto-mated tests, and releases it to our QA team (and the client, if appropriate). This entire process can take under a minute, but the same tasks could take a developer half an hour.

Is prototyping part of your development process? If so, which tools do you prefer for your apps?

Absolutely. We try to get usable software into our client’s hands as quickly and as often as possible. Prototyping is often the fastest way to do this, via static prototypes or even stubbed code. Before development even begins, our UX team uses InVision to turn visual mockups into clickable prototypes. These prototypes run on the phone just like real apps, which allows us to get critical feedback very early in the process. We highly recommend using InVision when possible.

The official University of Virginia app for Android
The official University of Virginia app for Android

Clients often want their apps to support in-app purchases and ads. Do you prefer to build a business model around the project before the development even begins? What is your monetization platform of choice?

There are a several monetization models available on mobile, from: free, ad-supported, in-app purchases, and paid download. The first goal of any application is to get the user to download the app, and we have found that a price-tag of even $0.99 can be a deter-rent for apps in saturated markets or lower-income demographics. In these situations, our clients should consider alternate monetization policies. If the basic functionality can be provided at a low cost, then it might be a good idea to consider a “freemium” model, where the app is free to download but premium features must be purchased (e.g. Evernote). Ad-based models (Facebook, Flixter) can also work, and companies are getting very creative with “native” ads that look like real content. The freemium-ad hybrid model is also popular, which is where a user can pay to remove the ads. However, the paid-download model, like the Dark Sky realtime weather app, can succeed if the app provides functionality that is otherwise unavailable.

Compare the development tools that were at hand when WillowTree started out 8 years ago to the current ones.

When WillowTree first started out 8 years ago, mobile was a very small (but rapidly-growing) industry. The tools we used were either provided by Apple/Google (the xCode IDE) or ported from other tools (Eclipse for Android). There was no third-party ecosystem of tools to modify for our needs.

Now, we use Android Studio, which is an extension of IntelliJ specifically for Android development. xCode for iOS is more robust (and hardly crashes), and both tools are a core part of our Continuous Integration (CI) workflow, which took years to fine-tune. It allows us to automatically (and safely) ship tested code to clients and to the App Stores. Our build distribution tools, TestFlight and HockeyApp, now allow us to see which versions of the app the client has installed/tested. These automated workflows take the burden off developers and allow them to focus on writing quality code.