Advantages, Disadvantages & Common Misconceptions Addressed
A decade ago, blogging was still on the rise, Facebook was barely a year old, and the vast majority of new software development projects focused on their traditional target, the desktop computer. Half a decade ago, smartphones had come into their own, the iPhone 3 had just been released, and native applications (or “apps”) for iOS or the nascent Android were a key part of the strategies of every consumer-facing company.
For those embarking on a new or renewed software development project today, however, the platform of choice will almost certainly be, in some fashion, the web. Whether the application in question is a consumer-facing product, a line-of-business tools, or anything in-between, taking advantage of the opportunities offered by our increasingly connected technology makes perfect sense.
Half a decade ago, this would have been the obvious purview of a native app; but with the ever-improving performance and capabilities of 100% web-based applications (or “web apps”), the question of the benefits and costs of each approach now needs to be considered to determine the best value proposition for your application’s use case. The following represents a breakdown in brief of the advantages, disadvantages and common misconceptions regarding web vs. native applications.
Web Apps
Shared Codebase
One of the greatest advantages of a web app is the promise of ‘write once, run anywhere’. A web app enables your application to utilize a single code-base shared among all platforms, which can greatly reduce project cost by obviating the need for platform-specific code, especially view (GUI) code. This can allow your application to support far more platforms than if you had to write platform-specific versions for each. In addition to capturing the mainstream devices, your application will be able to appeal to users on less common platforms (Blackberry or Windows Phone, for example).
Additionally, the increased capabilities that are part of the ongoing evolution of web standards (which many are familiar with under the banner of ‘HTML5’), can allow a web app access to device hardware – the camera, the GPS, the gyroscope and accelerometer, etc., in a cross-platform compatible way. This enables your app to have access to whatever hardware the device might have, again without needing to write different code for each platform.
This advantage extends throughout the lifetime of your application – not only does it expedite initial development, it can also keep future code-maintenance costs low. A single shared codebase generally proves simpler to update with new features and is more straightforward to fix when bugs are encountered.
Caveats
Of course, the promise of ‘write once, run anywhere’ has been made before, most famously by Sun Microsystems for its Java language and Java Virtual Machine. Developers familiar with the language have an old joke based on the slogan: ‘write once, debug everywhere’, and the joke works just as well for web apps.
While all major browsers follow the W3C standards, their implementations are unique, and the same challenges that faced developers working with the JVM on differing operating systems and/or hardware are faced by web developers today. Each browser should be considered a separate platform, and major versions of said browsers may also qualify for this careful treatment.
Behavior and available feature-set differs between desktop and mobile versions of browsers, and between major versions of the same browser – there is, for example, a large number of feature support differences between Internet Explorer 10 and 11, not to mention earlier versions, and major differences in a variety of areas between iOS Safari and Mac OS X Safari. Extensive testing across all supported platforms is a necessity, as subtle bugs or unexpected behavior can arise in surprising places.
The net effect is that, once the cost of testing and supporting multiple browser platforms is considered, the benefits of a shared codebase are somewhat reduced relative to native apps. In all likelihood, it will still be faster and less expensive to create a web app compared to a native application equivalent, but it should not be expected that the difference will be drastic, especially if support of cutting-edge features is desired.
Conclusion
If your application is destined only for iPhones, then a native iOS app is a better choice. If your application should be usable by desktop and mobile users alike, or needs to be available to users across multiple mobile platforms, a web app may be the optimal solution.
Shared Architecture
Applications targeting the web typically have a server component to them – a machine, or set of machines, that hosts a database, performs business logic, and communicates details to and from client applications.
Typically speaking, the architecture needed to support the server component of an application can often be extended trivially to support serving the client portion of an application as well (that is, the portion of the application that’s often meant when speaking about a ‘web app’). Being a part of the server code-base, or closely related to it, allows for simpler web app code, as some of the ‘heavy-lifting’ can be done by the server component of the application. By comparison, a native application often needs to duplicate some of the effort and logic of the server component.
Caveat
A close coupling between the server and the web app typically means that a user needs continual internet access to use the web app; a native application, by virtue of having duplicated some of the logic of the server, can often work independently of the server for at least some of its functions.
Conclusion
That said, there is support for ‘offline’ web applications in the body of specifications that compose HTML5, so this issue can be mitigated against if the web app is designed appropriately from the start, offering all the advantages of both a native app and a web app in this regard.
Responsive Design
Another well-known concept in web application development is the term ‘responsive design’. This refers to advances in the CSS (Cascading Style Sheet) technology, and the careful employment of these advances to allow for a flexible design that can accommodate a variety of form factors – that is, different screen and/or device sizes, pixel densities and resolutions.
This allows the web app to share the bulk of its graphical user interface between various devices – whether viewed on a desktop, a tablet, a smartphone or any other device, it will have a coherent design that works for the screen it’s being used on, and remains familiar to the user even when they use your application on a completely different kind of device.
Caveat
This sort of flexibility does not come for free, however. The key considerations are ‘native look and feel’ and ‘pixel-perfect layouts’.
A web application can very closely mimic the appearance of a native application, if so desired, but a native application – using the interface elements provided by the OS, rather than needing to build them from more basic shapes and colors, as in a web app – will always have the edge in this regard. Moreover, matching the look and feel of multiple different platforms will require creating the necessary layouts for each platform – defeating the purpose of having a single interface for all platforms.
Additionally, due to the way responsive design works, pixel-perfect matches to Photoshop mock-ups are often time-consuming even if they are not impossible. Web apps can be expected to look beautiful, modern, sleek, and in line with design-oriented images; they should not be expected to have elements spaced exactly to the pixel or millimeter, as the exigencies of designing for the massive variety of screen sizes and resolutions across all the internet-connected devices the web app is intended to support requires design flexibility and, often, some measure of compromise.
Conclusion
While a web app can very closely mimic the host environments, effort typically increases more than linearly with the number of desired platforms to support. For applications with their own brand and identity, or for applications targeting desktops and mobile platforms, web apps are an excellent choice.
For applications that must look exactly like a native application, and desire to target multiple platforms, native applications for those platforms are a better choice.
Neither option is a good choice for matching mock-ups with pixel perfection – once, when iOS was young, this could be expected there, but with Apple devices now ranging in screen size and resolution, even native applications must deal with flexible layouts (more on that in the Native Application section, below). Pixel-perfect layouts are a thing of the past in both the mobile and web space.
Native Mobile Apps
Performance
Native apps for iOS and Android are built using languages such as Objective-C, Swift, Go, or Java and are compiled into native applications. They have direct access to the underlying hardware on the mobile device and gain a significant performance advantage because they’re not limited by the performance and features of a mobile browser. Apps that need fluid animations, require multi-touch interaction, perform complex calculations, rely on large data sets, or that work with sound, video, or image data are great candidates for implementing as native applications.
As mobile devices evolve into wearables and smartwatches such as the Apple Watch or Android Wear, native apps and performance become crucial on these smaller devices with less processing power, memory, and battery life than smartphones or tablets. Some technology from mobile web apps will most certainly make this transition as well, but won’t have an impact in the near term.
Caveat
If you want iOS and Android versions of your application, know that there will be little to no code shared between them. To gain the performance advantages of a native app you essentially need to develop two separate apps, relying on iOS and Android best practices.
There are frameworks and platforms designed to minimize this duplication of effort, but they introduce their own concerns, compromises, and risks. There’s not a single “one size fits all” solution here and these need to be evaluated on a per-application basis.
However, the development time of native apps can often be minimized by developing for both platforms at the same time.
Conclusion
Many types of applications are still at their best when implemented as a native app, but this performance advantage isn’t easily shared between versions of the same app for different mobile platforms.
Exclusive Mobile Features
Apple and Google have developed a number of popular hardware and software features for iOS and Android devices such as contactless payments, in-app purchases, fingerprint readers, inter-app communication, and interactive push notifications. These are features that customers have come to rely on and often take for granted. Many of these features simply aren’t possible to support in a mobile web app, and taking advantage of them would require a native app.
For example, on its latest iOS devices, Apple includes a Touch ID fingerprint sensor that can be used to secure sensitive data within your app or to authorize payments within your app that are processed with Apple Pay. It’s simple to use, secure, and provides a much nicer experience to entering usernames, passwords, or credit card numbers. However, the Touch ID frameworks are only available for native apps.
Caveat
While many features are common to both iOS and Android, there are unique features on each platform and even differences between similar features. Something that is possible in iOS may not be in Android, or vice versa. Depending on your app, understanding these differences is important.
Some of these exclusive features may eventually be available to web apps, but for the time being they are native only.
Conclusion
Developing a native mobile app that integrates with iOS or Android exclusive hardware and software features can provide a better experience for your customers and set your app apart from competitors.
Design, Development, and Distribution
Just as with mobile web apps, the increasing number of screen sizes and resolutions of mobile devices has forced designers of native apps to take into account many of the same design decisions to provide the best experience from devices with screens ranging from 4” to 10” with a range of resolutions from watch sized to high-dpi “retina” quality ones. Apps are no longer designed to be pixel perfect, but instead to deliver the same great experience across the variety of mobile devices we rely on in modern life. There are tools to help with this transition, but it definitely requires a different approach to the design and development of apps, and can complicate the development and testing processes.
Furthermore, just as code needs to be written differently for iOS and Android, the platforms rely on different design languages, conventions, and styles. What works in an Android app may likely feel alien to a customer using your app on iOS. There’s definitely some overlap between the two platforms with common gestures, concepts, and ways of interacting with a touch screen device, but there are enough differences that they’re important to consider.
Finally, where mobile web apps can be deployed on a variety of hosting solutions and made available directly to your customers, native mobile apps are published and available only in mobile app stores. The publishing process can require developer accounts, contracts, testing services, and legal requirements or limitations that may affect your business model or the design of your app. Jumping over these hurdles can be frustrating at times, but the app stores do command a large audience of customers looking for new and interesting apps.
Summary
In conjunction with the details above, the following points can offer some guidance when considering the needs of your application.
In Favor of Web Apps
- Want/Need to support multiple platforms (multiple mobile devices, or desktop and mobile);
- High level of integration with web services (Google Maps, Facebook, Twitter, etc.);
- A server component exists/is planned for the project (tight integration with existing functionality);
- Want/Need to bypass the potentially lengthy approval process of the app stores for your platforms of choice for any reason;
- Want the opportunity to capture smaller markets without much additional cost expended on supporting them.
In Favor of Native Apps
- Only need to support a single, specific mobile device or OS (e.g. only iOS);
- Need access to specialized hardware on the device (Bluetooth radio, Touch ID, vibration motor);
- Need access to other apps on the device (inter-app communication);
- Need the highest performance possible from a device, where every microsecond counts.
Conclusion
When considering the question of whether to pursue a web app or a native app, there can be no ‘one size fits all’ answer. Ultimately, the best fit for your application depends on your project’s targeted audience, goals, and requirements.
