First – Why Mobile Should Be On Your Mind
Ever since Luke Wroblewkski coined the phase “mobile first” in 2011, the zeitgeist of software development (at least the vast portions of it that touch mobile devices in some way) has been building towards a critical mass of not only “mobile first”, but – as the CEO of Twitter said – “all-in on mobile.”
When I travelled to Africa in 1998, my luggage was stolen. I spent several hours in an airline office in Nairobi, Kenya – where it took thirty minutes just to get a landline connection to the airline’s office in Uganda. It was busy. Thirty minutes just to get a busy signal! I travelled again to the same areas in 2003 and then 2005 – and I noticed something: the use of mobile phones had exploded. It was fascinating to observe the region skip the period of wired infrastructure (which we’d had for numerous decades where I live) and jump straight to wireless.
Why is this important? In a great piece by Toby Shapshak, he notes some interesting facts about Africa:
- More people have access to a mobile phone than electricity (i.e. – no home electrical power)
- “Mobile money” – payment systems that allows you to transfer money to another phone user – is expected “to become a $617 billion industry by 2016”.
- “80% of the world’s mobile money transactions are happening in East Africa…” (with half of Kenya’s GDP moving through mobile payment services!)
- In 2012, Google reported that 25% of its weekday searches in South Africa occur on mobile devices – and that figure jumps to 65% on the weekends
Perhaps the most bellweather-like point from Tony’s article is that the Economist noted, in 2011, that “six of the 10 fastest growing economies in the last decade were in Africa”.
“Simply put, Africa is not just a mobile-first continent”, Tony concluded. “It is mobile-only.”
“Great – but I write line of business applications for my company in Europe. I’m not writing payment, radio or apps like Farmerline. How is this relevant?”
The mobile tsunami is already underway – the question is, what will you do when it reaches you? What are your options, when the time comes that your next project is a mobile application? What does this mean for your team? Will you need to hire new talent? Which mobile platforms should you focus on supporting?
Understanding Your Options
A little learning is a dangerous thing –– Alexander Pope
Knowing is half the battle –– GI Joe
Would it surprise you to learn that there’s more than one way to write an application for an iOS or Android device (not to mention other mobile platforms)? To create an application for a mobile device, you generally have three choices:
- Write the app in the native platform/language for the device. For iOS, this means writing it in Objective C using a Mac + XCode, etc. For Android, this means writing it in Java using Eclipse/Or-Insert-favorite-IDE + the Android SDK on Windows/Mac/Linux/BeOS (just kidding about BeOS). For Windows Phone 8, this means writing it in C#/XAML on a Windows 8 machine + Visual Studio 2012, etc.
- Write a mobile web site. Your application is a web app – hosted on the web and accessed by the device’s browser.
As you might already suspect, there are a host of trade-offs you will confront in choosing any one of the above options. These trade-offs are critical for the decision makers in your organization to understand. My goal in this article is to help jumpstart the discussion around these trade-offs, and help you begin to form the rails on which to guide and direct your energies as you assess which approach makes sense for you and your team. We can’t possibly cover every aspect of how these options compare, nor can we anticipate the widely-varying needs of each team, application, company, etc. – all very important drivers in a decision. But I can tell you now that – no matter what the “native-only-or-you’re-doing-it-wrong” or the “hybrid-is-just-as-good-as-mobile-all-the-time” pundits say – there is no single right answer in this debate.
Let’s start with a high-level view of pros and cons:
Why Not Just Go Native?
Let’s be honest – as I oversimplify for a moment – if money isn’t an issue and your company can afford to venture into multiple native platforms (i.e. – hiring talent experienced in each platform, etc.) and you need app-store discoverability, then native might be the ideal option for you. Developing a native application means you will not be constrained by any “lowest common denominator” forced on you by a hybrid/cross-compiled approach. It also means that you won’t be sacrificing performance and you’ll have access to device-differentiating features that may not be readily accessible to hybrid containers.
Then why do the other options exist? It turns out the developing native applications comes at a price. Literally.
Native App Means Native Cost
This is just a peek into the economic factors of writing mobile applications, but it already paints a clear picture: the margins are razor-thin, a large portion of companies don’t break even, and your chances improve if you can target mutliple platforms. That is why the other options exist, and why their siren call – the reach of multiple platforms without the expense of multiple teams – appeals to many. The question of “when should I go native?” is often best answered with “When you can afford to support each target platform – including hiring developers, designers, QA & analysts as well as purchasing/maintaining any infrastructure required to build for the native target”.
When Native Isn’t an Option
How will I know when it’s love? –– Van Halen
Now what?! –– Bloat, Finding Nemo
If going native is off the table as an option, how do you know which alternative to choose?There’s no silver bullet, but there are questions you can ask that will help determine your options:
- Do you need to have an app store presence? If yes, then mobile web is out. If “no” or “not necessarily”, then mobile web is an option.
- Are you OK with no app store presence, you need the ability to frequently update the application and you’re not nessarily concerned with heavy monetization of the app? (Believe it or not, this happens – particularly when an established company is expanding its reach to mobile to establish presence before other mobile initiatives.) If yes to all 3, then mobile web could be your answer (assuming you don’t need heavy device API availability).
- Do you need to be able to access device APIs (accelerometer, camera, GPS, key chain, use push notifications, etc.)? Then mobile-web is out.
What’s the fuss about app store presence? Many companies may not already have existing customer accounts. Being in an app store provides the ability to reach & bill customers, as well as a means of distribution and discoverability for lesser-known companies/apps. If monetizing your app is critical, and you don’t already have solid channels via which you can reach your customers, then having an app store presence is something you shouldn’t ignore!
From the above questions, you can begin to see the logic behind answering “When should I go mobile web?”. In many cases, this is best answered with: “When you don’t need an app store presence, aren’t really using device APIs, aren’t as concerned about app monetization, and want to potentially take advantage of re-using a responsively-designed desktop site”. Don’t underestimate what’s possible here. Both Time.com and darksky.net are good examples of what’s possible with this approach. (It’s worth noting that some device-level APIs are available to mobile web applications – good examples being geolocation, media capture, contacts and others.)
Cross Platform Tools – Democratizing Mobile Development
Since hybrid mobile applications utilize many of the exact same skills necessary to create a mobile web site, this can be an attractive option – especially given the likelihood that you may already have a web development team and can leverage those skills immediately. Developers that had previously been kept out of a platform due to the walled-garden nature of developing for it can now create applications that usually look and feel like native apps. However, it’s not as simple as writing your web application and hosting it inside the native container app provided by, for example, Apache Cordova. You can (and probably will) run into road blocks – and it’s important to be aware of where that might happen.
|Notification – Alert||Notification – Sound||Notification -Vibration||Storage|
As far as devices, Apache Cordova/PhoneGap supports, to some degree or another, the following platforms:
|Symbian||Tizen||webOS||Windows Phone 7|
|Windows Phone 8||Windows 8|
If you decide to go the Cordova/PhoneGap route, three of the biggest challeneges you need to prepare for are:
1.) UI Performance
Not all mobile devices support remote debugging like iOS 6 (for shame). Weinre is the next best option (currently) for remote debugging, but it can be a painful, buggy experience. You will find that running your hybrid app in a dekstop browser simulator (Telerik’s Icenium and Apache Ripple both provide simulators like this) will help a great deal – given the maturity of debugging tools in browsers like Chrome. Of course, if you write Cordova plugins, you will need to become familiar with each platform/SDK’s debugging toolsets as well.
3.) Platform Requirements & Maturity
In 2012, Vision Mobile’s Cross Platform Developer Tools report indicated that while PhoneGap had a high adoption rate, 27% were abandoning it – likely due to frustrations with the development & debugging experience, coupled with lack of desired native APIs. (Appcelerator Titanium had a slightly higher abandonment rate of 33%.) As predicted, vendors have improved their tooling quite a bit in the last year, though it still has a long way to go. Both Adobe and Telerik are making headway in this area by providing cloud-based build tools alonside other differentiating features. Removing the burden of locally-installed SDKs, improving the debugging experience and reducing the pain of including custom Cordova plugins will likely go a long way towards retaining developers.
There Can’t Be Only One
So – this begs the question: “When do I go with a cross-platform tool?”
- Do you need to support multiple platforms but don’t have the skills or budget in-house to go native?
- Is an app store presence a must-have?
- Do you have existing web skills (or C#, in the case of CPTs like Xamarin) that you want/need to leverage for your mobile application?
- Is maintaining one code base (and thus synchronizing releases across platforms) a goal?
Answering yes to the questions above (especially the first one) is a good indicator that using a CPT might be your best bet. As to the question of which CPT to use, it depends so heavily on details unique to your circumstance that it’s not easily predictable. Obviously, a heavy .NET shop might favor Xamarin. Companies with available web talent may favor Cordova. The tools provided by vendors can drive things as well. If you target iOS and Android primarily and want to sidestep SDK requirements, easier testing & simulation and a simpler publishing-to-app-store experience, using Icenium is a good option. If you have a custom build tool chain, need to support multiple platforms, want to use Cordova and graft it into your build setup, then PhoneGap Build might be an option. The different alternatives exist because the needs of different apps and companies can vary widely!
Where To Go From Here
In 2011, Marc Andreessen said that “software is eating the world”. It’s clear from current trends that a vast portion of the software to which he refers will be on mobile devices. If you are evaluating alteratives currently, I recommend a small pilot project in 2 or 3 of your top choices to get in-the-trenches experience with them. Once you set a course, find and follow the top voices for that platform or CPT – and become a voice as well.