For the past 10 years, a fierce battle has raged on: mobile versus Web.
Each side has its champions, with voices of opposition who are just as loud. Now, a decade into the divide, we face a fundamental problem: We're collectively failing as an industry to properly frame the debate to consumers, who may not even understand the distinction between the two options.
First, the fundamental differences: Web apps (built using HTML5, CSS and JavaScript) require a browser and Internet connectivity to run. But mobile apps are typically written in a language that's specific to an operating system, such as SWIFT for iOS and C# for Windows. Mobile apps also require a native, or on-device distribution mechanism (think, Apple's AppStore) to load to the device. These "native apps" can run without connectivity, but dynamic functionality requires data exchange via an Internet connection.
These definitive distinctions aside, there are only three things that really matter in the mobile versus Web showdown. Before you start developing your own app, give careful thought to these key differences.
Web apps have been built on the assumption that they'll be used on a computer plugged into a wall, with abundant resources like power, storage, memory, CPU and bandwidth at its fingertips. The scaled-down footprint of mobile devices, on the other hand, requires smaller computing components.
What does this mean? Mobile apps need to be optimized for power consumption.
The more computing resources constantly used, the more power is required - and constant usage quickly drains the battery. Radio communication to a cell tower also sucks up a lot of energy. And consumers have low tolerance and little patience for a device with a perpetually dead battery. Research shows poor battery life is the biggest shortcoming for smartphone users. Along those same lines, other recent studies have explored which apps are most guilty of killing a phone's battery life.
Connectivity is also a key point of difference between Web and mobile, as it can impact how and when resources can be used. Wireless networks can be fragile. And historically, they offer less bandwidth than wireline broadband networks. This can be an issue for mobile apps that need to be carefully tuned to use a cellular connection. Plus, mobile devices are sometimes forced to go "offline," making them unavailable (for example, on an airplane, or in a zone without network coverage), a scenario that Web app users will never encounter.
Supporting the same app across multiple browsers can be a major challenge, because Chrome, Firefox, Internet Explorer and Safari all have slightly different configurations.
A Web app runs on pretty much any combination of chipset, device, OS and browser without any problems. Mobile, unfortunately, is different. There's so many phones and tablets available in different shapes and sizes, screen resolutions, chipsets and OS versions. Even within iOS, the arguably most homogeneous ecosystem, there are many different types and generations of devices running who-knows-what-version of iOS on one of Apple's Ax family of chipsets.
On the other side of the fence, it's not much better: device fragmentation for Android has been a well known fact for a long time. But for mobile, there is fragmentation both within and across ecosystems.
Mobile apps need to be written for iOS, Android and Windows - and three different code bases are needed so the app can run natively on all three platforms. To complicate matters further, what works for one specific version of an operating system desn't necessarily work for subsequent versions. For example, Apple deprecated some classes with iOS 9, requiring developers to alter their code to have their apps run on iOS 9.
In a nutshell? Mobile requires development and ongoing management of one code base per supported native platform.
And for any app to be relevant and reach a wider audience, it needs to support at least iOS and Android, which according to IDC had a combined market share of over 90 percent of smartphone shipments in Q2 2015.
One of the strongest arguments for mobile app development is that it gives developers the ability to tap into the rich ecosystem of mobile SDKs. These SDKs provide very mobile-centric or even mobile-only functionality and pieces of information to a developer - he most obvious ones being device name, device type, carrier network and app store metrics, which all only apply to mobile apps.
This instrumentation means mobile apps can do things that Web apps just can't - like, securing an app or an entire device to prevent theft of personal and business information, or providing tools to edit, compile, test and debug application code, and connect an app to back-end services such as user authentication, data storage, computing and asset hosting.
Unlike Web apps, mobile apps can also scale for reach and audience size, drive up user engagement and retention and measure the ROI on customer acquisition spend. Taking it one step further, these apps can even monetize, generating income from the app and its audience via commerce, payments, subscriptions, ads or usage data.
Legacy Web tools can't provide these features because they lack the capability to instrument a mobile app to capture the relevant metrics and telemetry from the device.
Web apps can't leverage the richness of the mobile SDKs, limiting developers' choice to secure, build, grow, monetize and support their apps.