I came across an interesting article recently where the author argued that we are nearing the end of developing native apps for mobile devices like smartphones and tablets.
He postulated that web technologies are advancing at such an incredible pace that there is literally no reason for software developers to write applications specifically geared for a particular programming platform like iOS or Android.
And he’s got lots of convincing and well thought out arguments that support his thesis.
How Web Application Development Is Different
Web application technology is getting to a point where it’s almost impossible to distinguish a native software application targeted specifically for an Android or iOS mobile device, with a web application running inside a web browser.
I often use Facebook’s messaging app to communicate with my other friends who also have Facebook accounts.
One of the fun little things you can do nowadays with another person who is in your Facebook messenger contacts list, is challenge them to play various two-player video games on your mobile device.
Since we’re talking about games running on your mobile smartphone or tablet device, of course, you won’t be playing the same kind of 4K resolution games you’d need a beefy PC or top of the line gaming console.
But still, I can play lots and lots of fun little arcade games that I remember from my childhood and college days … Dig Dig, Arkanoid, Space Invaders and the absolutely amazing thing about this is all of these games are running directly inside a web browser control!
I know this, because these games don’t require me to manually install them directly to whatever hardware device I’m using. In fact, because they are games that run inside a web browser, they pretty much can run cross-platform on any computer device that has a web browser or web browser control, which is pretty much any modern device on the planet.
Our smartphones and tablets are getting to the point where they have just as much native “horsepower” as traditional desktop and laptop computers, so they have no problems being able to run video games right inside a web browser.
[bctt tweet=”Our mobile devices are getting to the point where they have just as much native “horsepower” as traditional desktop computers” username=”profocustech”]Modern web applications also have the ability to work outside the “sandbox” which they have traditionally been constrained inside of.
Traditionally, a web browser can only operate inside of its own sandbox environment … for instance, you cannot deliberately or accidentally use your web browser to delete native files from your computer or mobile device. Your web browser cannot erase or format your hard drive. It can’t gain “root” access control of your computer and potentially do malicious things like install malware and nasty computer viruses. It couldn’t do things like gain access to any external computer peripherals like your webcam or other external devices plugged into your primary computing device.
Slowly but surely however, these sandbox restrictions have been removed and replaced by new and approved “sanctioned gateways” into these formerly forbidden areas of a computer which could formerly only be accessed by native software applications.
So nowadays, you can write a web application that can take advantage of a mobile device’s GPS and camera capabilities and many other hardware sensors like NFC (Near Field Communications) and Bluetooth connectivity, and do things like mobile payments and wirelessly hooking up to other external devices.
You may be wondering how does a web application know what device it’s running on? After all, if you’re running a web application on your smartphone device, the screen size is obviously going to be much smaller than if you were running the same web application on a big 4K monitor or large projection screen.
Fortunately, there’s lots of technology available that helps software developers write their web applications in a way so that things like screen size and resolution automatically adjust themselves so they are specifically targeted for the actual hardware device they are running on.
This is referred to as progressive web app development. There are ways for a web application to know what kind of general type device you’re using to view that web app … desktop computer, laptop, tablet, smartphone or even big screen projection system, and will adjust the overall size and resolution of the browser window for optimum viewability.
There have been other major technological breakthroughs that have made developing web applications almost indistinguishable from conventional native applications one had to formerly install to their computer device.
One of the first breakthroughs was the introduction of AJAX technology. AJAX is short for Asynchronous Javascript and XML. The way that every web application works, to this day, is under the request/response model.
When you type in a URL address in your address bar and hit ENTER, you’re creating a new HTTP web REQUEST. The web browser takes your URL address, and sends your REQUEST to the destination web server which hosts the website/application you are requesting.
When the remote web server is done retrieving the contents of your REQUEST, it wraps it up in an HTML RESPONSE, which ends up showing up in your web browser window.
This request/response model has been in place since the very first web browser was released all the way back in 1993.
The problem with this request/response model is twofold. First, there is a delay between the time you submit your HTTP request in your web browser, to the time the full response is fully loaded back to your browser. Of course, we have much faster network speeds than we did back in the days when we were still using dial-up modems over landline phone connections, but even with our broadband gigabit speeds we enjoy today, we still can’t get around the fact that there is still a delay.
The second problem is while you’re waiting for the response to come back from your web browser, you see this “flash”, where the web browser appears blank because it’s still busy waiting for the full response to come back.
It’s a very irritating visual reminder that the user experience of a native software application doesn’t suffer. When you run native applications like Microsoft Word or Excel, there is no “flash” or delay, waiting for your application to retrieve information from some remote web server…everything you need is already ready to use.
AJAX came about to address the shortcomings of the request/response model of HTML applications.
You still need to fully load up an initial web address, even with AJAX, there’s no getting around that.
But once the initial contents of a web application have been fully loaded into your browser, AJAX allows you to update a PORTION of your web page, without the need to make a new full round-trip HTTP request back to the web server.
If you’re familiar with Google Maps, or Google’s Gmail applications, you’ll notice that once you initially load them in your web browser, you never notice any sort of “flicker” or significant delay, as you move around on the map or in your mail.
The user experience is buttery smooth, and it’s very hard to tell you’re running a web-based application.
This is thanks to the magic of AJAX, which works hard behind the scenes to update only portions of your screen that need to change.
There are other more recent software libraries and frameworks that have made web applications even smoother and responsive.
ReactJS is a Javascript library developed by Facebook to help web developers create super smooth and responsive user interfaces developed in HTML and Javascript.
One of the most time-consuming activities a web browser must constantly deal with is manipulating the DOM (short for Document Object Model).
Every HTML element you see on the screen, a button, a dropdown control, a radio button, a textbox, etc, are all part of the DOM, that make up all the elements of a web page.
When your web application needs to insert, remove or move any of those DOM elements around in your application, it is very time consuming and causes a web application to feel sluggish and unresponsive.
Writing your web interface in React helps to eliminate the DOM bottleneck by creating what is referred to as a “virtual DOM”. The virtual DOM keeps track of any and all DOM element changes you want to have happen in your web application. Once all necessary changes have been made to the virtual DOM, React updates your real web page with the changes from the virtual DOM, and the end result is you see instant visual changes in your web interface.
Yet another modern technology that has helped speed up web applications is Web Assembly and asm.js.
What they both do is speed up the execution of javascript, which is important because javascript is the primary programming language for modern day web applications.
The faster that you can execute javascript, the faster a web application can run.
All these technologies and many more have made modern day web applications run almost as fast and performant as native applications.
Notice how I continue to use the qualifier, “almost”, however.
Will Native Apps Completely Disappear?
As fast as web applications have become with the help of all these supporting technologies, there are still certain kinds of native software applications that will outperform equivalent web applications.
Take modern day video games for example. When you want to create the fastest performing and best-looking video games on the planet, you absolutely must target a specific hardware platform like a PC or modern console. These machines can be loaded out with the latest and fastest CPU processors, maximum RAM and the top of the line graphics video cards.
You need this kind of hardware in order to run video games at 4K resolution (or more) at a buttery smooth sixty frames a second. And as advanced as web applications have become these days, you simply can’t write the equivalent native machine targeted video game for a web browser, you simply can’t. You have to write your games to the “bare metal” performance of a specific hardware platform and squeeze every ounce of performance out of it.
And there are certain kinds of technology companies that simply can’t or won’t get rid of native targeted applications, Apple probably being the number one example.
Apple is a hardware company. Ever since it’s inception back in the 1970s, they have always made their revenue and profit from the sale of their electronic hardware products.
Sure, they write lots of lots of software. In fact, they have written their own operating system, Mac OS, that competes toe to toe, with Microsoft’s Windows operating system.
But they do that to help sell their hardware products. Apple’s Mac OS operating system ONLY works on Apple computers. Apple’s iOS operating system ONLY works on iPhones and iPad devices.
There are literally millions of native apps available through Apple’s app store. It’s important to understand they are NOT cross-platform web applications. They are applications specifically written and targeted to run on Apple-branded devices ONLY.
Cross-platform HTML applications don’t fit in with Apple’s overall business strategy. It doesn’t matter what kind of device you’re running a cross-platform web application. You can run it on a Windows device, an Android device or on UNIX or Linux, it really doesn’t matter.
Which means cross-platform apps don’t require you to purchase a hardware device manufactured by Apple.
This is one of the reasons why native apps will never completely go away.
Another major pain point which web developers must continue working around, is the stateless nature of the web.
As we previously mentioned, all web applications to this day, work around the request/response model. That means that every new web request you make in your browser, is literally a brand new request. A web browser has no knowledge of any previous request you make.
This poses a problem for many web application scenarios. For example, imagine you’re inside the website of your primary bank. Without some mechanism to remember who you are, there is no way for the bank to know it’s actually YOU, navigating around their website, which means, there is no safe way to allow you to do standard banking operations like checking your bank balance, or transferring or withdrawing funds from your account.
The same goes for e-commerce type websites, like Amazon. Without any way of knowing it’s YOU who’s doing the shopping on their website, there’s no reliable way of ensuring a safe and reliable shopping experience.
Native applications don’t have the problem of statelessness that web applications do. Once you have fully loaded up a native software application, it knows exactly who you are for the lifetime that application runs on your device. Native applications like Microsoft Word and Excel, also don’t require an internet connection, so you can do all of your work locally on your computer and even if no internet connection is available, you have everything you need to continue your work.
So is native mobile app development really on the downslope as the author of that article, makes in his argument?
I’m not convinced it is. Video games will continue to be written specifically for high-end PCs and top of the line consoles, at least for the foreseeable future.
And as long as companies like Apple continue to be in the business of selling you hardware, they will always write software that is specifically geared around their hardware platforms.
Native apps dying? Probably not. Not as long as video gamers and Apple fanboys like myself continue to flock to those platforms.
