The Current State of Mobile Application Development
This is the second of three blog posts based on a talk I gave at BCS in December. The first post was called A History of Mobile Application Development and the second dealt with the Current State of Mobile Application Development.
In this post I’d like to pick up where I left off – with the demise of Symbian and the rise of the current generation of mobile operating systems.
I’ll run through the native and non-native frameworks that are currently available to developers, outlining their pros and cons and generally setting the scene for my speculations about the future of mobile apps in part 3.
Based on the Linux kernel, Android started life as a proposed advanced operating system for digital cameras until the company realised that the market was limited compared to that for mobile phones.
The Open Handset Alliance unveiled the Android operating system in 2007, nearly two years after Google’s acquisition of Android. (The launch of Google’s foray into the mobile world was delayed by the launch of the iPhone which radically changed consumers’ expectations of what a smartphone should do.)
Google faced down a copyright infringement suit from Oracle over the Java-compatible nature of the Androids APIs. Rather than straight up Java APIs Android uses Apache Harmony and the Dalvik virtual machine which translates Java bytecode into Dalvik executable.
- Android has a dominant share of the mobile market – 81% of all devices shipped in Q3 2013 were Android.
- While developers have previously generated much more revenue from iOS devices (perhaps because iOS users have more disposable income?) that gap narrowed significantly in 2013.
- You can develop on any platform.
- The environment is more open: call history is available to all apps; notifications between apps are possible as well as the sharing of content; apps can be installed from any source.
- Apps can be self-signed.
- You can publish to Google Play for a one-off fee of $25.
- Fragmentation between different versions of the OS, which are often significantly different, are a major problem.
- Upgrades are passed through manufacturers and carriers who add their own customisations, delaying the process.
- App developers are forced to try to accommodate users whose OS versions are years apart (as opposed to iOS where most users upgrade to the new version within weeks of the release).
- The Android process is often more manual than the iOS one.
- Graphics are often slower.
Apple’s iPhone set the standard for the new generation of smartphones when it was first released in June 2007 with its touchscreen and direct manipulation interface. There was no native SDK until February of 2008 (Apple initially planned to provide no support for third-party apps).
The iOS lineage started with NeXTSTEP, an object-oriented multitasking OS from the late eighties developed by NeXT Computer (acquired by Apple in 1996). The world’s first web browser was developed on NeXTSTEP and proved hugely influential in the formative years of HTML.
The main programming language for iOS is Objective C. Development is done through Xcode IDE which has an in-built iOS simulator.
- Less fragmentation arising from upgrades – 80% of users are on the latest version.
- New features are usually available very quickly.
- The OpenGL API is standard for graphics across the platform.
- Navigation is non-prescriptive – you can decide how users will navigate within your app.
- iOS is a more closed platform – there are limited possibilities for inter-app communication and private APIs are automatically rejected by the App Store.
- Development can only be done on a Mac.
- Duplicating core iPhone features is prohibited.
- You need to subscribe to the iOS developer programme (annual fee) to publish apps and App Store guidelines can be difficult to understand.
- The process of signing apps is non-trivial.
- You need an Apple certificate to install to your own device.
Windows Phone 8
The second generation of the Windows Phone operating system uses the same Metro interface but has an updated architecture based on the Windows NT kernel (like Windows 8) rather than Windows CE (which was used as the basis for Windows Phone 7).
You can develop for Windows Phone 8 only on a system running Windows 8 – using Visual Studio 2012 as an IDE. You’re allowed to choose between XAML, Direct3D or a mixture for building UIs; you can write C#, Visual Basic apps on top of .Net; and you can use C++ for native code.
Publication is less flexible. Apps need to be put through a review process before being allowed into the store similar to iOS.
The low take up of Windows Phone makes this process seem rather onerous.
Originally named BBX, BlackBerry 10 is based on the QNX microkernel operating system whose parent company RIM acquired in 2010.
BlackBerry 10 uses a system of gestures and touches which is supposed to make physical buttons unnecessary for core functions (e.g. a ‘back’ or ‘home’ button).
The OS also has an Android runtime layer so that Android apps can be packaged and distributed on the BlackBerry platform. (The latest versions even allow the direct download of apps via Google Play.)
Native application development utilises an API library in C and a Native API in C/C++ though you can eschew C++ coding through the WebWorks framework (HTML5 and JS), Adobe AIR or Java itself.
Again the publishing process is rather onerous: 10 business days are required to approve your app.
Non-native Application Environments
It is of course possible to sidestep the issues that come with developing native apps by instead developing web apps for use on mobile devices.
Some frameworks allow you to build ‘hybrid’ apps which are not truly native (since their layout rendering is done via web views) or totally web-based (since they’re packaged for distribution and have access to native APIs).
The disadvantages of hybrid apps are that you only get limited access to the native functionality of the phone on which the app runs and that such apps are usually slower than ‘pure’ native apps.
PhoneGap supports most major platforms (iOS, Android, BlackBerry, Windows Phone, Palm WebOS, Bada and Symbian) and allows developers to make use of native hardware features like accelerometers, compasses and cameras.
A cloud based compilation engine – PhoneGap Build – generates compatible apps for all supported platforms but rejection of PhoneGap-built apps by the Apple App Store is still a frequent issue.
It’s based on Apache Cordova which also underpins the aforementioned WebWorks.
iOS, Android, BlackBerry and Windows Phone apps can all now be created via Appcelerator’s Titanium framework.
Titanium provides fast results, making it a popular prototyping tool but (as with PhoneGap) performance issues abound and code forking is often required (e.g. if iOS then…).
App to the future
That’s pretty much where we’re at with app development at the beginning of 2014. Come back next week and I’ll share my thoughts on where mobile apps (and devices) are headed in the next few years in the Future of Mobile Application Development.