Additional interesting data points from the Yahoo Mobile Developer Conference 2016

Having found last year’s first YMDC pretty informative (see my post on it) I decided to attend yet again this year the 2nd edition of the Yahoo MDC. I took shots of the slides I found interesting and I’ll replace them with higher quality ones as the slides and/or videos become available on

This time I did arrive in time for Marissa Mayer’s keynote. One interesting slide was the growth in usage time having shifted towards the lower tier apps, not in the Top 25. The rest of the deck was a summary of what was detailed in the later sessions.

IMG_20160218_101443-2 (1)

Session: The State of Mobile 2016

Simon Khalaf followed with interesting insights into the state of mobile. First he gave us the good news.


The mobile growth of app sessions last year was an average of 58% with media consumption and productivity apps leading the growth.


Mobile addicts are still on the rise, this year by 60%. Apparently you’re a mobile addict if you’re checking the phone more than 60 times a day, which is almost 4 times during every awake hour.


So how many mobile addicts are there? 280 million by this year. If they were a country, it would the 4th largest, just after the US.


Next we were introduced to some statistics about the US mobile users.

On average, mobile users in the US spend more than 4 hours a day on their devices. 91% of that time (3.8 hours) they use apps and only 9% of the time is spent in a browser. The time spent in the mobile browser reduced by 50% during the past two years.


Time spent in gaming apps reduced by 36% year over year. This is explained part by an increase in monetization (gamers making in-app purchases to get faster progression in games) and e-sports (just like for traditional sports, gamers like to watch other more skilled gamers play).


Messaging and social apps saw a whopping 50% increase in usage time, at least in the US. This makes it on average over an hour a day.


This is an even more dramatic increase if we aggregate the messaging and social usage with the other media media consumption apps. This leads to a 108% increase compared to last year and up to an hour and a half.

It took the TV 37 years to reach the same engagement level which mobile reached in only 7 years. Unexpectedly the TV industry is in crisis especially as the 12-34 years age group is watching around 40% less TV compared to 5 years ago (a drop of almost 10% per year).


Mobile is absorbing those TV minutes:


and some of its revenue:


Now comes the less than good news. First the growth rate in app sessions is still declining. Last year was the first when the growth rate dipped below 100%. But to put this in context, it’s no longer an explosion just high growth.


The smartphone shipments also slowed down. The new devices are not that much better to warrant an upgrade.


Both are signs of a maturing market. Now the growth is in software which is reflected in the fluctuation of the US stock prices of some of the major mobile hardware and software companies.


Simon’s theory that we’re approaching a Mobile 2.0 moment towards the end of 2016: developers need to enrich the app experience on phablets with larger screens and batteries and also more processing power.



Phablets are also where users increasingly spend their time.


The phablet form factor is expected to dominate the smartphone market in a few quarters.


Media consumption and phablets go hand in hand.


Apps for content creation, messaging and productivity have seen a 20-30% growth above the average of 58% growth in app sessions.



The other growth opportunity hinted at by Simon are local services which he considers to be currently underserved by mobile at this time. We’re talking about a $800B market (again, just for the US alone).


Session: What’s Next? The Messaging Revolution

Before lunch there was a discussion panel on messaging with the tech execs of Slack, Uber and Assist. Operator was a notable absence (announced but missing – insert bad joke here 🙂 ).


Some thoughts from the discussion:

  1. Apps are expensive to build
  2. App fatigue is a reality with users being increasingly reluctant to install new apps to their phones
  3. Messaging apps dominate the app dock of both iOS and Android
  4. Messaging platforms are on the rise
  5. Messaging apps have less UI functionality and more server heavy. This allows instant publishing (on the server side) of new features
  6. Still, there’s also a lot of fragmentation of messaging apps and platforms
  7. Supporting multiple languages in messaging apps is a challenge
  8. While text is archaic, voice is easier, yet they do coexist nicely and are useful in different scenarios (text on bus, office, voice at home etc.)
  9. Bot messaging counterparts can be human, machine or hybrid (human for triaging and/or exceptions and bot for routine)
  10. SMS is still mostly too expensive, stale, not real-time and does not support user sessions
  11. Will we see few or lots of bot agents (like Amazon’s Alexa)? They expect probably few because a bot agent requires commitment and trust. They do expect Google to be the biggest player.
  12. Messaging with bots is still in the early stages and there are still many unknowns.

Session:The App Lifecycle

David Iudica shared some results of study they did on 2k+ users from the US.

A third of these users do need a new apps, mostly in the entertainment, content and manage/navigate space.


There is a general consensus that the apps on phablets should do more and be of different types, suitable for more use cases. 42% also expect to be able to use more apps.


So what apps would they want to see changed on a phablet? Again, it’s the entertainment, content and manage/navigate types which lead their preferences.


What makes users download a new app? Apparently boredom, personal recommendation and kids’ preferences lead the pack.


However, apps with negative reviews will be a big deterrent to downloading an app. But storage space restrictions are also a significant factor.

IMG_20160218_141137 (1)

Assuming an app got installed, David went on to describe the life expectancy of such an app. First of all, users delete installed apps mostly during periodic clean out, which happens up to twice a month.


Depending on the category, most dormant apps survive up to 3 months before getting deleted.


There are also other factors which trigger the deletion of an app. Boredom, alternative apps, too many ads and storage constraints are primary reasons.


Friends and family suggestions as well as ads are effective in convincing at least half of the users to restart using an otherwise dormant app. Discounts are also effective but so are new feature notifications.


Actions to be taken against app replacement:


Other sessions

Just as the last year, there was a big push for Flurry and native ads. This is understandable since flurry is free and so was the conference. In the end that’s how they make money.

Flurry has gender and age based analytics and some notable new features: real time analytics, support for Apple tvOS and they just announced monitoring mobile apps for iOS and Android.

Mobile Action went through some app store optimization strategies. That’s what they do.

PicCollage had a separate session. They use tools to optimize the app store keywords. They grew to 100M+ downloads in 7 months and the app is localized in 12 languages. They started running lots of experiments with partial rollouts (in Google play; they did not talk about the App Store).

Final notes

Although heavily focused on Flurry, it was still a conference worthwhile to attend, especially if you’re local to the SF Bay Area. I would rate it more towards a product manager conference because on the technical side there weren’t many deep dives. There’s hope that, despite the difficulties that it’s facing, Yahoo will keep this conference going for the next years and maybe diversify it a bit, especially on the technical side (e.g. more case studies from their big apps).

A key takeaway is the rise of phablets and the need to optimize apps to their improved capabilities.


My ideal cross-platform mobile development framework

Let me state up front that I haven’t yet found an ideal (to me) cross-platform mobile development framework. But let’s see what would it take to have one. Then I’ll take a look at what’s out there and which of those are heading toward that (my) ideal state. If your criteria is different, shoot a comment.



The technology must be open-source. Nowadays only an open-source framework can reach large popularity in the software industry. The reasons are multiple, but fundamentally engineers will only go the extra mile if they can fully understand and influence how a system works.

The project needs those extra miles to increase the quality of the framework (both code and documentation) and get a constant influx of valuable code contributions.

A paywall is the opposite of openness and prevents widespread adoption.


The framework mustn’t have magic under the hood. It should have layers of abstraction and allow engineers to go as deep as required to understand its inner workings and fix bugs. There should be minimal behavioral differences across platforms to enable highly portable skills. Being open source goes a long way towards transparency.

Optional Web support

It’s time we put the Web behind us. The Web today is a hack. The mix of HTML, JavaScript and CSS is trying hard to make us forget that we’re fundamentally working with a document. Think of a Microsoft Word document with lots of customizations to pass as an actual application. You can try it, but it will never pass the uncanny valley.

There are no good solutions to make the Web work with just patching something here and there. Give an engineer one minute with any Web UI and she’ll point out several flaws. It’s either a layout broken by a particular browser DPI, the CSS loading late and the page showing HTML garble, accidentally pressing a select all which makes the page surreal by the text highlighting, the page not fully utilizing the page width, the contextual menu showing out of this world entries for non-engineers (view page source, inspect this item). Give a regular user one minute with any Web UI the he’ll find the same things except he won’t be able to spell out the issues clearly.

The Web has fueled the exponential growth of the computer industry.We should be grateful for that, but it’s time to up the game on the software side. Software engineering can do so much better than HTML/JavaScript/CSS and users can have superior experiences.

Mobile is the first step in that direction. It’s not perfect, but even in its current state is an engineering marvel compared to the Web development model. As soon as the mobile OSs will make it to the desktop the role of the Web will be marginalized. Windows is already there, Android will follow in 2017 and iOS will reluctantly have to as well. Yes, you will still be able to read the newspaper or a blog on the web but for any more complex functionality you’ll prefer an app.

While Web support would be desirable for a cross-platform mobile framework, it shouldn’t be a mandatory requirement.

Historical data

What’s the best cross-platform software development solution to date for frontend and backend software. It’s Java.

The backend and any non-UI Java code works very well on all major platforms. This isn’t accidental though but the result of large investments made by the major players from the software industry of the 90s in making the JVM robust: Sun, IBM, BEA and even Apple (up until JDK 6) just to name a few. Microsoft is the notable exception as the company wasn’t at all happy with Java as it was endangering its PC and server market monopoly. Instead it focused its attention on .NET, a completely parallel ecosystem.

For frontend desktop Java there are two serious UI toolkits: Swing and SWT.

Swing was all about rendering the UI in pure Java and applying themes to match the look and feel of the host operating system. First it failed short on performance when operating systems started using hardware acceleration for rendering the UI widgets. UI rendered by Java simply cannot compete with native UI widgets whose rendering is offloaded to the GPU. Even plain text looked awful and slow because it was font aliasing rendered differently from how the host OS would render it. Secondly Swing failed at platform integration: getting access to things like a file context menu, file actions, native dialogs for file selection and so on. By far the most popular Swing application today is IntelliJ IDEA. It shows Swing at its best, but the UI isn’t perfect. Try a small exercise on MacOS X: right click the code editor and while the pop menu is showing go and open the menu. You’ll end up with something similar to this awkward layout (one is a native menu and the other is a Swing rendered menu):

Screen Shot 2015-12-09 at 10.25.13 AM

SWT was developed for the needs of the Eclipse project. In contrast to Swing, it went with a different approach: it used Java wrappers around natively rendered widgets. Performance was way better, but SWT had to implement the least common denominator widget set. It did however have its own extensive widget set which was developed by composing Java widget wrappers – a good compromise with still excellent performance. The downside was that you had to extensively test your applications looks and behavior on all supported platforms. SWT is still with us today powering the Eclipse IDE, but not much else.

Speaking of Eclipse, another great byproduct of the IDE was the Eclipse Rich Client Platform (RCP). This made it possible to create elegantly designed cross-platform desktop apps. Its limited popularity is due to addressing only the desktop use case and its heavy reliance on OSGi which still didn’t yet get its tooling sorted out (good luck with doing a command line build or integrating with a build system like Maven or Gradle).

My ideal solution

The characteristics of my ideal solution for cross-platform mobile development are:

  1. A uniform execution model across all platforms. I want to have the same runtime and debugging experience on all platforms. Ideally I’d like a virtual machine based execution model but if that’s not feasible then a cross compiled solution might work.
  2. Cross-platform UI option. I want the ability to build a UI as fast as possible.
  3. Platform-specific APIs and UIs. I want the ability to use platform specific features to refine my UI and code. I should have the option to make the UI fully native, should I have more time to spend on the app.
  4. Android as a first class citizen. Android is the dominant mobile OS and has a great potential for displacing Windows to become the dominant desktop OS. It is thus my expectation that the framework shines on Android. This pretty much narrows down the language to Java.
  5. Everything open source. I want to debug as deep as I can inside the code which powers the app. I want to be able to make code contributions to the framework.
  6. (nice to have) Diverse developer community. I want the people behind the project to be engineers from multiple companies, educational institutions and independent engineers. I don’t want a single company to monopolize the project. This excludes a project owned by Google (vested interest in Android), Apple (iOS owner) and Microsoft (Windows proponent).

Elevator pitch

When next time in an elevator and somebody wants to know, I’ll have this project description ready: An open-source Java framework for developing Android apps that are customizable for and executed on both iOS and Windows.

A roundup of current cross-platform mobile development solutions

Mobile development is a rapidly changing area of software engineering. The mobile industry is growing so fast that everybody’s just rushing out apps to the market using any means possible. We have reached a point though where there’s an appetite for cross-platform development as mobile apps grow larger and more complex and thus accurately replicating the features in parallel code bases is becoming increasingly hard.

I’m writing this post as a reference sheet and I’ll add more info on each language and framework as I find out more about them. As an overall structure I classify the solutions around the programming languages and discuss the shortcomings and advantages of each.


Apache Cordova and friends

There are several frameworks which aim to leverage established web technologies to build cross-platform mobile apps. Apache Cordova (formerly PhoneGap) is probably the most popular and more recently there’s Facebook’s React Native as well.

There are many reasons why this is a bad idea: performance, memory usage, battery usage, UI platform fidelity, debugging in native bindings – just to name a few.

I want to emphasize how big a problem performance is. The solution relies on the JavaScript interpreter. JavaScript is an extremely permissive language with many corner case constructs. Yes, there are ways to do JIT compilation and other runtime optimizations but JavaScript is the nightmare language for these techniques so the effectiveness of optimizations will be limited.

Objective C

This language is dying with Apple having committed to make Swift the primary language for iOS and OSX development.


It’s a new language with an interesting blend of features. It’s biggest problem is that it’s been created at Apple. Consequently any non-Apple developed operating system will be supported as a second class citizen. Put it plainly, it’s against Apple’s business interest for Swift to run best on anything but iOS and OSX. The language, compiler and certain tools have been recently open sourced but Linux is the only other OS supported at this time and there’s no other OS in plans.

As with Mono as the .NET implementation on Linux I’m sure the Linux developer community will embrace Swift just as warmly – not.


These languages are only popular for cross-platform game development. No GC, no memory bounds safety checks and the simplicity and limitations of C plus the complexity of C++ make them a scary proposal for modern software development.


Xamarin and Visual Studio

Seems technically sound but Microsoft has a lot more work to do to convince developers that they are no longer the evil empire of the 90s. C# has been around for almost as long as Java yet it’s still a niche language yet arguably being better designed and more feature rich.

Update: As announced at Build 2016, Microsoft is now including Xamarin into Visual Studio for free. This is coupled with two important changes: making the Xamarin SDK open source and donating the Mono code base (with some extra improvements) to the Mono foundation under an MIT license. My comment on Microsoft’s image stands, but these are all moves in the right direction to start fixing that image.


JVM on iOS


Does not have ahead of time compilation tech and no JIT VMs are allowed on neither the Apple AppStore nor on Google Play. The reasons are sound because both companies want to disallow self modifying binaries which represent an increased security risk.

As a result the Oracle JVM on ARM is slow. Additionally, the JVM is linked to the app and adds an approximately 16 MB overhead to each and every app. Both of these prevent it to become a contender in mobile.


Intel has a the Multi-OS engine tech preview: a port of ART to iOS which is linked to the app. I detailed this solution in my post on AnDevCon 2015 Santa Clara.

Java cross-compiled to iOS


I first heard of j2objc while reading the ArsTechnica article on the internals of Google Inbox.

It generates Objective C source code to be compiled on iOS. It has no bindings for the UI as the project’s philosophy is that native UIs are of the highest quality.

Google also integrated j2objc into a toolchain which can support Web apps too.

Google’s motivation to open source the associated toolchain: the perfectly round number (0). They have no incentive to make it easier to develop apps for iOS or any other future competing OS.


I also touched on RoboVM in my post on AnDevCon 2015 Santa Clara.


It’s a Java to iOS binary compiler. There doesn’t seem to be any active development of the project.

Codename One

Java to Objective C with a cross-platform UI. Think of the Swing UI toolkit. The biggest drawback is the common denominator pattern: the experience of developing for it is identically limited on all platforms. You can’t just use any Java library, there’s no package manager and there’s a subscription model for getting all the features and power of the framework (and all the source code).

Just recently the Codename team did release the iOS cross-compiler as a separate project: ParPar.

Skeleton native UI with business logic running on the server

I just remembered about this option and I’m aware of only one entry in this category: Tabris. It’s the Eclipse Remote Application Platform (RAP) port to mobile. It has two downsides: 1. offline mode is highly problematic and 2. it’s not open source.


So far it’s suffice to say that any framework whose development is driven by a company with a mobile OS is at a disadvantage. The reason is simple: it’s really hard to justify spending money on a technology that disadvantages your own OS and its revenue stream.

Having a paywall around the technology isn’t helping its adoption either. It would be nice to see the RedHat and Spring driven open-source with business grade support reach mobile tooling as well.

Is there a perfect solution? I’ll outline my analysis in a subsequent post.

AnDevCon 2015 Santa Clara – Day 2

Today I had the pleasure of attending the second day of AnDevCon Santa Clara. It’s my second time at this conference and it was just as interesting and intense as before.



Google keynote

Although advertised as a secret, the topic turned out to be obvious: the new Nexus phones (5x and 5p), the features of Android M and the features of the Android Studio 2.0 preview.

But first, a glance at the magnitude of the Android phenomenon: 1.4 billion active devices. In a world of 7.3 billion people that’s impressive.


The M features I didn’t know about are

  1. the data binding framework – available in the support library for all relevant Android versions (down to Android 2.1 / API 7)
  2. app linking allowing browser URLs to trigger app deep-linking. Now I know why when I browse Amazon on my Nexus 6p it gives me the option to open the item inside the Amazon app instead of the browser.
  3. the removal of the ApacheHttp client from the public API (but not the JARs, to maintain binary backward compatibility) and its replacement with the standard

The presenters started out by saying that there won’t be a better time to switch to Android Studio: the ADT plugins for Eclipse has been deprecated and won’t receive any new features. Google now funnels all its IDE efforts into making Android Studio better. Android Studio is no longer experimental; it’s mainstream.

The 2.0 release (based on IntelliJ IDEA 1.5 Community Edition) is primarily a performance release to speed up development time significantly while not sacrificing its architectural values. One of the selling points of Android Studio 1.0 was the switch to a modern IDE independent build system: Gradle. This was in stark contrast with the more complicated Eclipse build that is tedious to run in a headless mode and isn’t capable of using a dependency repository like Nexus (Maven’s Nexus repos, not the Android phones 🙂 ).

The performance optimizations gravitate around instant run. There is now a method hotswap. As with any hotswap implementation, no data initialization is performed (e.g. singletons can be problematic). The way hotswap is implemented is by sending delta classes to the Android VM which are called by the using prebuilt method hooks of the first method version.

For resources, any of them which was modified is sent to the running app in full. An optimization to send only resource deltas is being worked on. Android manifest changes require an app restart.

The emulator is still based on qemu but apparently has improved speed. I’ll compare that to the gold standard (Genymotion) shortly.

A sad note is that even in the age of 1 billion+ Android devices, the screen casting of an Android device to a computer is a rare feat. It’s telling that even the Google team used a camera although the device was one of their own (Nexus 9):


Exhibits hall

As I entered the exhibits hall the first thing to notice was the fundamental shift in Android hardware: Qualcomm area to the left and the Intel area to the right. Both had the largest floor-plan and Intel was there to tell everybody that they mean business. Indeed, in an Android hardware landscape dominated by ARM and Qualcomm more and more Android phones and tablets are now powered by Intel Atom x86 chipsets. Hardware vendor and architecture diversity are a great thing for any ecosystem.


I noticed two app development frameworks: Magnet and moBack. Both are open source mobile backends directly competing with commercial offerings like Parse.

Sony showed a cool demo of Android TV. It was nice to see the typically annoying and out of place TV menu be merged into the settings section of the Android TV OS. Obviously the hardware running Android isn’t upgradeable as all TV manufacturers want is people to upgrade their TVs as often as their phones (every couple of years). I guess the market will decide if this strategy will be sustainable or whether Android hardware upgradeability will be demanded by customers.

I saw a demo of Intel XDK which is an integration effort of Apache Cordova and other open source projects to create a development environment for hybrid apps.

Finally it was cool to see Thales there. It’s an Android powered flight entertainment system of which I’ve heard before. This shows the true power of Android: third parties are free and empowered to explore new use cases for Android without neither depending on nor needing the blessing of its creator.


Obviously there were some more exhibitors, but these stood out to me.

Intel Multi-OS Engine

This is an early access technology from Intel so they didn’t even bother giving it a proper name. So we’ll use what we have: Intel Multi-OS Engine.

It’s a port of ART to iOS linked to the app which adds 9-40 MB to the app’s disk footprint, depending on how much of the API is used by the app. Remember that ART was introduced in Android 5 as an ahead-of-time DEX compiler replacing Dalvik (which uses JIT) as the default Android VM.

I know that Both the Apple AppStore and the Android PlayStore forbid any apps with self-modifying binary code at runtime. Since this is exactly what JIT does, no VM with JIT is allowed on these app stores. That’s also the reason why Oracle’s ARM JVM for Android and iOS does not have JIT and consequently is hopelessly (as in Java 1.0 level) slow.

Thinking of this approach, there’s a problem with linking the JVM to the app though. An average user can easily have 100+ third party apps installed. Let’s say each has a 20 MB overhead for the linked VM. This will effectively use 2 GB of storage just for the runtime. This is a problem. Then the initial download will require around 2 GB of data just for the 100+ VMs linked to the app. Then each new app version will download the VM again and again. Thinking of this a bit more, it’s actually a huge problem.

Some technical details are that the Android Studio project has a companion Xcode project. The framework exposes Java bindings to the iOS API. It uses retrolambda to offer Java 8 language features in Android since the native language support there is still at the Java 7 language level.

Two questions come to my mind.

1. What’s Apple’s incentive of shipping this with iOS and helping the Android ecosystem? It’s the perfectly round number (0).

2. What’s Intel’s motivation behind this investment? Fair, they want to increase Android’s market share and increase the market share of their x86 Atom chipsets in the world currently dominated by ARM licensees. I still don’t get why having such a VM would help them in that direction.


Java bytecode compiler to iOS native code. They ship a plugin for Android Studio which then creates an Xcode project linked to the current Android project. RoboVM has a Java API for the iOS API with a 100% coverage (their claim) and they commit to shipping the same day Java APIs for any new public iOS APIs.

The development model for iOS is to create the UI in Xcode which link to the controllers with outlets and actions. As soon as you write your Java controller with iOS API it becomes visible in Xcode’s interface builder.

It’s a commercial product with a subscription model. The source code is available only for enterprise licensors.

In a Bind? Android’s binder in depth

Another highly technical session by Jonathan Levin. At the 2014 AnDevCon SF I attended his session on the Dalvik and ART internals. Both were really enlightening and stimulating my curiosity to study more the internals of Android. It’s another benefit of Android: the most important parts are fully open source, they run on the by far the most popular OS kernel (Linux) and so you can dig as deep as you desire. Compared to the closed ecosystem of iOS, this is heaven on Earth for any engineer.

Binder is Android’s interprocess communication system. Compared to plain sockets based IPC it offers discovery, authorization, message structure (defined as an AIDL) and parcels as the serialization mechanism.

It is not intended for sending large amounts of data between processes. It’s way too slow and inefficient for that. Thus the default data size upper limit is a conservative 800 KB. For anything larger than that the recommended data sharing strategy is via anonymous shared memory: allocate a memory segment in ashmem, create a file descriptor (fd) to it and then send the fd to the other process via binder. That other process will then be able to read the data directly. It’s pointer passing vs. data copying.

Binder has graduated into the mainline Linux kernel starting with version 3.19: So it no longer is an Android exclusive IPC technology and this brings Android’s architecture closer to that of Linux.

As a side note, Binder was initially developed as part of BeOS and as the developers moved on to Palm, HP and then Google, it followed them. Once at Google, Binder found its way into Android.

Jonathan frequently calls Android slow compared to iOS (JavaScript hybrid app fans take note of this). This time he criticized Binder’s unnecessary complexity with a lot of layers which makes it considerably slower than the functionally equivalent iOS IPC with Mach messages. To understand his point, just take a look at this slide with all the layers, from the Android app and down to the Linux Kernel:

Screen Shot 2015-12-02 at 4.12.56 PM

Those are quite a few layers. Jonathan then went on showing us the code for all the layers.

Back to base

This was another good AnDevCon day. It’s always interesting to see the completely different dynamics of a technology in full growth. It’s a dire contrast to the typical Java conference.

Looking forward to dig deeper into these learnings and in particular I’m preparing a post on cross-platform mobile development.


The Tanenbaum-Torvalds debate’s relevance in mobile

A healthy debate from more than two decades ago shows how we should approach the Android vs iOS vs others debate.

Reading about the famous Tanenbaum-Torvalds debate regarding the micro (Minix) vs. monolithic (Linux) operating system kernel architectures reminded me of the Apple/iOS and Android supporters of today. In my experience Windows Phone users tend to get along with their life instead, but it’s also fair to say that the sub 4% global market share leads to a less representative sample.

A very relevant quote from the Wikipedia page:

Despite this debate, Torvalds and Tanenbaum appear to be on good speaking terms; Torvalds wants it understood that he holds no animosity towards Tanenbaum, and Tanenbaum underlines that disagreements about ideas or technical issues should not be interpreted as personal feuds.

While the less technical mobile users’ sometimes borderline fanatic following of the iDevices or Android ecosystems is easier to digest (a variation of “my team/tribe is better than yours”), I find it more annoying amongst software engineers.

In my view, even if you aren’t a mobile engineer, nowadays mobile is a major player in the software industry. Just as each software engineer should have a clear understanding of the pros and cons of the major software execution environments, mobile should be part of that too.

We all know what a particular desktop or server operating system is good for. The same goes for web browsers. But from what I’ve usually seen, when we get to mobile, things get personal. Quotes like “Apple does it best” or “Android dominates” should ring a bell for anybody.

I also used to be on one of the extremes, but then I started learning about and coding for all the 3 major mobile operating systems of today (in order of global market share): Android, iOS and Windows Phone. Guess what? Nobody does it best, each of the approaches have their shortcomings 🙂


Buy devices. The cheaper the better.

Nothing compares to the day when I could play with my first Windows Phone. I bought a second hand Lumia 521 from ebay and I couldn’t believe how much power and features it had for such a low price. Same goes for a significantly more expensive iPhone 5. And when I bought a used 2013 MotoG I was yet again amazed by how snappy it was. Smartwatches seemed also very mysterious until I got my LG G watch quite a while back. Now I’m better at separating the hype vs value in the AppleWatch news feeds.

You can go one step further if your personal phone is already on a GSM network (that’s only AT&T and T-Mobile in the US while most of the world is on GSM). You should buy unlocked GSM versions of the phones. That way you can easily move the SIM card to your other phones and use them as your primary phone for a while. Nothing beats the first hand experience with an otherwise unfamiliar platform. Those unlocked devices will also have a higher resale value should you decide to swap any of them (like I did to a Lumia 635 and will keep doing for my others).

Read mobile programming books. There is a vast amount of material online about how to develop mobile apps. Yet it’s the depth that’s usually lacking (why am I supposed to do it that way?!). Like with any complex topic, it’s best to learn the core concepts from books. Don’t repeat my mistake thinking that because an operating system is running on a small and low power device it isn’t complex. All mobile OSs are feature packed and there’s a lot to learn.

Follow news, articles, blogs. Needless to say that this is how you keep up-to-date.

My standpoint on mobile – today

Having extensively used Android, iOS and Windows phones and tablets for the past year by now I should have a more informed and less biased opinion. You might still be able to spot which my platform of choice is for my primary devices, but that’s irrelevant in the bigger scheme of things. I’m not actively looking at the other mobile OSs because I feel that it’s not yet worth the investment given that their combined global market share is about 1%, Blackberry included.

iOS – I like: the hardware, including the quality, size and battery life, snappy apps with a truly native feel
iOS – I dislike: the ecosystem (why can’t I use my iTunes account on Android and Windows Phone? Why am I forced to carry a Macbook to be able to develop for iOS?), the OS is closed source.

Android – I like: it almost fully open source (Google Play Services is the notable exception) and I can dig into it as deep as I want to (and I want to, because it’s Linux), the UX of Android 5 is yet unmatched
Android – I dislike: the intrusive OS customizations by some vendors, the less snappier apps

Windows Phone – I like: the hardware (some really good cheap phones), the OS (it has some really interesting UI concepts), the unified app development model (same app binary code runs on both desktop and phone)
Windows Phone – I dislike: the lack of apps, the fact that I need a Windows 8 machine to develop for it, the OS is closed source

This is my standpoint today. Ask me tomorrow and it might change – I’m open to that. It’s also OK if somebody else has a different opinion – I respect that.

In conclusion

The Tanenbaum-Torvalds debate should remind us all that it is indeed a good thing to have different points of view. That is actually how the world moves forward: we do things, we make mistakes, we learn and we improve. The only way not to make mistakes is to not do anything.

Embrace the good parts of each mobile ecosystem and be aware of their limitations. Be knowledgeable to objectively debate the merits and shortcomings of mobile operating systems, ecosystems and hardware. Finally, if you’re an engineer, have software development knowledge on them all. Mobile still evolves very rapidly and don’t wait for your favorite OS and hardware vendor to roll out a feature or concept that the others had for years.

Interesting data points from the first ever Yahoo Mobile Developer Conference

Last Thursday I went up to San Francisco to attend the one day of the 2015 Mobile Developer Conference organized by Yahoo. I was one of the lucky ones who got in (a free event with ~1000 attendees), I guess because I published an app to the Play Store.

The point of the conference was to announce their mobile developer suite heavily based on Flurry, a recent acquisition of theirs; integration with Yahoo search is also there. Another reason must have been to show their commitment to mobile apps and third party developers. Obviously a third reason was hiring developers.

The event took place on Nob Hill. I managed to make the climb on foot from the Powell BART station!

15 - 1

It was a well run conference, despite of an unplanned 30 mins break due to a malfunctioning fire alarm.

During the event I made note of a few slides where the data was either a reinforcement of previous data but occasionally new and surprising. I will work to connect these to other data sources, but for now I’ll just take them for granted. It is important to understand that most of this data comes from apps using Flurry for analytics – still, that’s about 41% of the apps.

I snapped some pictures but in the meantime some of the slides surfaced online.

Time spent in online retail is shifting to mobile & apps

Screen Shot 2015-02-23 at 1.51.03 PM

66% of retail online is spent on mobile, of which 63% in apps. So the desktop lost 14% in one year!

M-commerce sales are growing fast

Screen Shot 2015-02-23 at 1.51.42 PM

M-commerce sales by leading 500 m-commerce retailers grew in 2014 by ~78% compared to 2013. Still, 58% of the revenue was generated from a browser and not an app.

This is comScore data that should be more accurate than Flurry’s own.

Annual growth in app usage

annual growth in app usage

(image courtesy of Bloomberg)

On average app sessions increased by 76% and by far the biggest increase was in lifestyle and shopping apps by 171%. But that’s only for apps which use Flurry for analytics!

Phablets – fastest growing device type

Screen Shot 2015-02-23 at 1.53.32 PM

Wikipedia says that a phone is a phablet when the screen size is between 5.3 and 6.9 inches. These numbers keep changing though. Still, today the Nexus 6, iPhone 6 plus, Galaxy Note 4, Oneplus One and the likes are phablets. The iPhone 6, Nexus 5, Galaxy S5 are not.

Since screen sizes keep increasing I can easily believe this data.

Both mediums [TV and mobile apps] are peaking at prime time

Screen Shot 2015-02-23 at 1.54.19 PM

The chart tells that TV screens are almost never the prime content suppliers. Easily not during the day and only barely above apps at prime time.

iOS mobile games overtook Hollywood in revenues

Screen Shot 2015-02-23 at 1.55.21 PM

Fully says that revenue by the US box office matched the revenue from iOS games alone back in 2013. By now it’s clearly above and rising whereas the box office revenue started to decline. This number (if it’s really true) is impressive especially given that iOS has ~19% global market share.

The global economical impact

Screen Shot 2015-02-23 at 1.56.57 PM

The $3.3 trillion generated in 2014 by mobile is certainly impressive. That sits between the GDP of France and Germany.

The global economical impact in jobs created

Screen Shot 2015-02-23 at 1.56.10 PM

In 2014, the mobile industry created 11 million jobs wordwide. That’s almost at the level of China, the fastest growing economy.

Apps are propelling mobile’s growth


By now, mobile users interact with their devices using apps 86% of the time. That number I’ve seen before and my gut tells me it’s right. Nobody in their sane mind wants to interact with a web site on a tiny screen (10″ tablets are better, but not by much). Users don’t even like hybrid apps.

Mobile internet has a 5x growth ahead


This data is coming from comScore, an analytics company covering many industries. They say that today there are are 2 billion mobile internet users in the world. By 2020 that number will reach 10 billion.

I’m taking this with a pinch of salt. According to Wikipedia, the United Nation says that we’ll reach a global population of 10B by 2083. Even if by some miracle every last human would have mobile internet access (6 month old babies and people in a coma are my two favorite segments), that’s still in 70 years or so and NOT 6. But then again, comScore might count the actual devices.


These are good data points and they showed up unexpectedly at the event. I’ll work to cross-reference them with other data sources but the preliminary conclusion is: mobile is here to stay, it will continue to grow fast for the foreseeable future and users want apps.