For almost a decade, our industry -- and consumers -- have been struggling with a seemingly simple question: What’s the difference between mobile and web? One would assume the answer to that question would have become clear sometime in the seven years since the AppStore launch changed the game. But in some ways, we’re still trying to even properly frame the question to consumers. For example, should we be arguing the merits of "native vs. web" or "native vs. HTML5?" (And don’t forget about hybrids, which are some combination of the two, just to add to the confusion.)
The good news? Some of the best and brightest have already weighed in on the topic of web vs. native: Mark Zuckerberg talked about the mobile vs. web quandary back in 2012, famously confessing that betting on HTML5 was a mistake for Facebook. On the other hand, Steve Jobs told developers to build for the web along with the launch of iPhone 1, only to launch the AppStore with native apps a year later. As you can imagine, this is a broad topic with many issues worth debating. But the availability of resources is a major sticking point, and often a key part of the conversation.
Differences between web vs. native are most evident in:
- Power, computing and networking
- Sensors and context
- Tools and instrumentation.
Here’s our breakdown of these three major points in the ongoing discussion -- and why they carry so much weight.
#1. Power, computing and networking
Let’s start with a highly simplified definition of mobile and web apps. A web app is typically built using HTML5, CSS and JavaScript. It requires a browser and Internet connectivity to run.
A (native) mobile app is typically written in a language that’s specific for an operating system, such as SWIFT for iOS and C# for Windows. A mobile app requires a native, i.e. on-device distribution mechanism, like Apple’s AppStore, to make it on the device. Native apps can run without connectivity, however, to provide any sort of meaningful functionality, data exchange via an Internet connection is required.
Compared to the web, mobile apps need to be engineered with a world of constrained resources in mind. web apps have been built and architected for a landscape that assumes a computer is plugged into a wall, with abundant resources (such as power, storage, memory, CPU and bandwidth) available for computing.
The smaller footprint of mobile devices requires smaller computing components (though lately there’s been a trend to larger screen sizes). However, battery power remains a key bottleneck -- meaning mobile apps need to be optimized for power consumption. The more computing resources are constantly used, the more power is required -- and constant usage quickly drains the battery. This is especially true when a wireless connection is frequently opened and closed; radio communication to a cell tower sucks up a lot of energy.
Connectivity is another issue. Wireless networks can be fragile, and historically have offered less bandwidth than wireline broadband networks. As a result, mobile apps need to be carefully tuned to use a cellular connection. (Remember, back in "the early days", some apps took down entire networks.)
Mobile devices can also face an "offline" situation (like, on an airplane, or in a zone without network coverage) that can cause challenges -- a concept that doesn’t exist for a web app.
#2. Sensors and context
Next to the computing-related aspects of resources, access to device sensors, such as GPS, microphone, camera, gyro, NFC, haptic screens, fingerprint ID and even barometers (since 2014 for iPhone 6 and 2011 with Android Ice Cream Sandwich) can also be a sticking point. Leveraging the context from these sensors makes mobile apps come alive -- hence, why device sensors need to be instrumented accordingly in the code, again, a concept that doesn’t necessarily exist for a web app.
The ability of using on-device sensors matters for the richness of an app. Consider apps offered by retailers such as Starbucks and Walgreens, or airlines such as United and American Airlines, all of which use Apple’s Passbook feature, i.e., the native PKPass Class Reference. Passes automatically appear at the right time or place because they include time or location-based information; for example, your boarding pass appearing as you arrive at the airport. And coupled with contactless payment services such as Apple Pay and Android Pay (both of which leverage NFC functionality), native mobile apps become a vehicle for in-store commerce.
In summary, compared to web, native mobile apps are better suited to leverage device sensors and the context they provide, which result in richer functionality than web apps.
#3. Tools and instrumentation
One of the strongest arguments for mobile 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 (like device name, device type, carrier network and app store metrics) which all only apply to mobile apps.
Developers tell us at Crittercism that they want to be able to do five core things for their mobile apps -- and it’s for these five categories that the ecosystem is providing mobile-specific tools and SDKs:
- Secure: Securing the app or an entire device to prevent theft of personal and business information
- Build: 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
- Grow: Scale reach and audience size of a mobile app, drive up user engagement and retention and measure the ROI on customer acquisition spend
- Monetize: Generate income from the app and its audience via via commerce, payments, subscriptions, ads or usage data
- Support: Provide customer support via in-app and external channels and measure user satisfaction captured in app store ratings and surveys
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. Vice versa, by definition, a web app can’t leverage any functionality of native mobile SDKs, unless the web app is embedded into a native container.
To make a long story short, web apps can’t leverage the richness of the mobile SDKs, limiting developers’ choice to secure, build, grow, monetize and support their apps. In fact, the rise of mobile apps created a need for new mobile SDKs, which triggered a whole new wave of venture capital investment, e.g. for analytics; so in a way, mobile SDKs are the equivalent of selling pickaxes during a gold rush.
Image Credit: funkyfrogstock / Shutterstock
VP of Business Development, Lars Kamp joined Crittercism after 12 years at Accenture. As the managing director of strategy and corporate development for Accenture Mobility, he led a global team of professionals responsible for corporate strategy, M&A and partnerships for Accenture's enterprise mobility business. Working closely with Accenture's leadership, his team was also responsible for shaping Accenture's overall digital strategy. Lars is also an active angel investor with investments into a number of technology start-ups, such as Mashape, CircleCI, EasyPost, Orderbird and Bay Sensors.