Creating Unanticipated Complexity Through Excessive Utilization of Webviews within a Mobile App

Mobile app developers use webviews primarily to embed web content (HTML/JS) into a native mobile app (iOS or Android). There are three main applications of webviews that conform to mobile app development best practices:

1. Showing Web Content: If your app has embedded web links (URLs) that require rendering web pages within your app, then this takes place within a webview container.
2. Displaying Advertising: If the mobile app displays advertising banners, web view containers are embedded with native views to render the advertising content from remote sources.
3. Mobile App Enabling a Web Application: When you are distributing a web application within a mobile app container, the webview serves as the medium where the web application resides and executes its functionality.

The first two applications of webviews are the original intent of availing webviews within a native mobile app, and developers utilize webviews for these purposes without any significant complications. The third application, where webviews execute an entire web app within a native mobile app, has the potential to create very complicated and convoluted problems.

A simple web application with half a dozen to a dozen features/functions will probably have a minimum of issues running within a webview inside of a mobile app. Even if some minor problems, such as proper page rendering or device-specific functionality access (such as push notifications) arise, a webview provides the facility to resolve these problems effectively and efficiently.

The problem arises when the web app complexity grows over time or the volume of web pages increases significantly beyond the original manageable few. Even though it may be tempting to continue with this pattern as the app functionality grows to manage costs, the long-term implications of continuously adding webviews may render both the mobile app and the web app useless due to the at-scale complexity introduced.

A more realistic scenario is that when a web app grows within a webview container, portions of the web app are converted into the native implementation to improve the user experience on the mobile device. In this case, we have created a hybrid app with entry and exit points from the web app into the mobile app and vice versa. The complexity of this architecture creates issues that may consume an inordinate level of resources to resolve.

The hybrid webview/native app model creates severe and contentious problems for the app. In the long run, it introduces inefficiencies at scale and jeopardizes the app's future viability. Here is an overview of these untenable issues:

• Webviews need to be embedded both into iOS and Android platforms. Each platform utilizes a different approach to rendering web pages within a webview. So, issues can manifest differently within each platform due to these variances in code execution within the webview engine. This complication requires triangulation of debugging efforts involving web, Android, and iOS dev teams which is resource intensive and challenging to manage.
• Consuming platforms of webviews react differently to webview's attempts to access native mobile functionality. This variance is particularly true where security matters are concerned, as remote web interaction is frequently scrutinized for security vulnerabilities by the native app to ensure that the app will not be compromised. Where switching views within a native app may not be of any concern for the containing platform, switching back and forth between a native app and the webviews containing web content may provide an appearance of a security violation.
• Continued vendor support for extensive and sophisticated utilization of webviews within a mobile app is uncertain at best. If, for example, at some point, Apple decides that flowing in and out of webviews within a native mobile app creates complications for new device-level features, then it can easily block the anomalous application of webviews within an app to streamline the implementation of upcoming versions of iOS. Apple will be quick to severely limit webview support if it is contrary to its iOS development roadmap.

Extensive and unorthodox utilization of webviews will complicate the mobile app architecture and create undue risks where the intended cost saving becomes counterproductive in the long run. What is the solution to embedding webviews where there is a need to do so? Utilizing cross-platform native tooling, such as React Native, to develop a mobile app allows one to create Android, iOS, and web apps from a single JavaScript-based source code. It is a streamlined methodology that does away with using webviews as a stopgap measure to support web app functionality within a native app context. 

The complex solutions that mix web and native app development through extensive utilization of webviews will unquestionably approach the law of diminishing returns at some point during the app lifecycle. The added complication is the direct result of Kotlin/Java (Android) and Swift/Objective C (iOS) intersecting with the JavaScript/HTML (Web App), where native views are intermingled with embedded webviews to support end-to-end app functionality.