Unless you’ve been living under a rock for the last five or so years, or are just too obtuse to notice, the smartphone has become the most rapidly adopted technological device in human history. Immediately on the heels of the smartphone, is the mobile tablet PC. And combined, these devices are making the “all things mobile” a literal technology revolution!
On average, each of the approximately 2.5 billion smartphone owners worldwide, engage with their device more than two hours per day. The average male “checks in” with Facebook 14 times per day, the average woman 25. In fact, mobile usage is growing so fast worldwide, that bandwidth will one day be a “currency” all its own, traded like mutual funds and stocks are now.
We could also talk about the “Most Pricey Real Estate” on the planet, that being the home screens on a persons mobile device. It’s a very finite space, and mobile device owners are beginning to get really picky over what application icons they keep on those screens. If you do the math, were talking digital real estate prices per square centimeter that are so high, that it would make prices in Monaco comparable to barren wasteland. (prices in Monaco are $1m per 15 sq. mtrs.)
But let’s turn our attention to what I believe is the future of mobile, and why software developers should centralize their development knowledge around native programming. We’ll pick up the scent of the trail here, where hardware manufacturers are literally hiding the future of mobile in plain sight, embedded in their devices: Native Device Sensors.
For the sake of this article, and to prevent inevitable scope creep, I’ll focus our attention on the Android development environment (which is 85% of the current global smartphone marketplace). As I write this, the current Android OS is code named Lollipop, running version 5.0.2. So we’ll start here, and look at what’s available today.
A quick inspection of the current Android Manifest File Permissions, show us “native” sensor permissions for the following:
- Magnetic Field – Magnetometer
- Light Sensor (RGB)
- Rotation Vector
- Step Counter
- Geo-Magnetic Rotation
- Heart Rate
- Tilt Detection
- Eye Movement Tracking
Now the main debate I see circulating among the impassioned development crowd (both web based developers & native mobile software architects), is which development path yields the best results for the users. Or rather, which development choice is likely the future of mobile. Web developers say the future is HTML5, software architects say the future will stay Native, and there’s a growing debate over Hybrid development, which is grabbing folks from both camps.
LETS GO DEEPER
In a world that’s digitally fed through the major artery we call the internet, it makes a lot of sense for those that prescribe HTML5 as the end all be all for mobile. They feel they have a pretty compelling argument. And we do see HTML5 getting closer every year to a more, “standardized” level of performance across all web browsers, and there is hope that one day the markup will play a major role in native mobile device browsers as well. But there remains two glaring issues that I see for the markup, which could actually keep it from “arriving” at that hoped for point in time, where everything is standardized across the web.
The first concern I have of putting all my eggs in this basket, lies right in the name itself: HTML(5). The 5, signifying that the first 4 versions of the markup language weren’t able to reach full standardized stability across the myriad of browsers. The hope of its professors is, certainly “this time” it will be different. That is, until the idea of HTML6 starts getting floated around, and all hell breaks loose on the “debate plane” again.
The other issue I have with HTML5, is that it’s 100% dependent on a web connection (via cell service or Wi-Fi), in order to provide full working value to the user. And an HTML5 app cannot work within a native Android, Apple, or Windows mobile environment without that connection…no matter how well it’s written. So without a web connection via cell service or Wi-Fi, good luck trying to access any of the native sensors on a mobile device.
Now I can hear people screaming, “yeah…but who do you know with a smartphone, that doesn’t have cell service or access to Wi-Fi?” And they would be right, most people do have service. But that’s not the point. The point is very simple, HTML5 is still predicated on and dependent to, the idea that nothing valuable exists outside of the WWW and a browser, so it’s silly to even talk about it. I happen to disagree.
But in all fairness, and if you have full access to service or a Wi-Fi connection on your mobile device, just how many sensors can you access with the HTML5 markup currently? (and reliably)
- Geo-Location Sensor
Now this is a far cry from the 18 available native sensors, but you can still do a ton of cool things with just these four sensors, and believe me…I do. It’s also pretty exciting to push the boundaries of what HTML5 can do right now, and I can easily see why so many folks are into the markup.
To summarize how I feel about HTML5, I think the markup has many great attributes within the browser, and maybe a decade from now, we’ll all be surprised at what it can do.
Precisely the point, native is not an “alternative route” or “next on-ramp” to the world of mobile development…IT IS THE HIGHWAY ITSELF! More to the point, native development is not some technology we, “pick from a hat” and make work for mobile, but it’s the embedded platform that got this whole game started in the first place. Programming on the OS baby!
With native development, you have full access to all the sensors in a mobile device, and speed, performance, and user experience is completely unbeatable by any other realm. Working within the native environment, your application will also avoid the “errors & crashes” so commonly associated with other development environments, and the user will ultimately have the best experience with a native app.
Now, with that being said, it is true that writing native code for both Android and Apple is more difficult, because you will be dealing with two different programming languages (Java for Android & Objective-C for Apple). And although most programming languages share a fairly common syntax arrangement, learning the nuances of each language can be very time consuming and difficult…especially if you intend on mastering each language like an artist. So it’s easy to see why so many people choose the easier route, and gravitate towards the latest “no-coding required” authoring tools. Let’s face it, the world has turned great software developers and architects into rock stars…and everyone wants a piece of that action. Even if they have to usurp the real sacrifice that it takes to learn a native programming language, of those who stay true to the sovereignty of the craft.
So for me, the roadmap for the future of mobile development (done right), is clearly laid out before us. Device manufacturers keep implementing new native sensors in mobile devices for a reason, and astute native software programmers are keenly aware of what’s going on. In fact, if you are as “hyper-aware” of the mobile development space as most native programmers are, you’ll see that there is a global resurgence towards programming purity. The honeymoon is over folks, now it’s time to make the real mobile device/programming marriage strong!
BUT WHAT ABOUT HYBRID?
However, I am still not completely convinced that I can build enterprise quality applications that remain 100% error-free across multiple devices. Yet every year brings new surprises that I admit are refreshing.
I guess I would have to confess, that I am maturing to the idea of keeping an open mind for using the best current technologies when it’s logical to do so, even while I remain dogmatic in my assertion for programming purity. Call it “being a true student of the craft” I suppose.
But until that future date, if and when it ever happens, that an extensive technology amalgam actually equals a 100% stable and error-free mobile experience for users and companies…I’ll choose to stand firmly in my programming dogma.
But that’s just me!