At CodeStax.Ai one of the platforms we regularly deploy applications to is the KBZPay app. While the west has been a bit lukewarm to the idea of a super app, it’s extremely popular in China and Southeast Asia. Tencent’s WeChat, Grab(from Malaysia) and Gojek(Indonesia) are few names that spring to mind where the user uses a single app for a whole host of services. Old geezers such as me will be reminded of webportals when the internet was first gathering steam. Each of these services it turns out is just a web app which depends on the super app for authentication, identity and customer context. The web application is rendered using Webview.

Whats a webview?

So a webview is fundamentally a browser’s rendering engine loaded inside the app. Think of it as a browser within your app which occupies maximum available screen real estate that is capable of loading any url. For a long time webview for both Android and Ios was based on webkit — apple’s open-sourced rendering engine. Only recently has android forked webkit to create Blink which is going to be the rendering engine for its webviews going forward. (On a side note, all browsers on IOS are required to use webkit for their rendering engine).

‍

‍

One of CodeStax.Ai’s flagship product MyMedicine is indeed a mini app inside KBZPay. But developing a web application as a stand alone product with a responsive design is one thing. Getting it to work under the super app and inside the webview is a whole other story.

The first thing we need to realize is that if you are not the app developer then you are already at a huge disadvantage as you do not have any knowledge of how the webview is implemented. It could just be a blanket webview invocation without any restrictions or it could be a very specific fine tune webview that will force stringent restrictions on your application. Android requires very granular permissions to its webview where each web application needs to be whitelisted to be given access to any of the mobile’s available hardware, whereas IOS is much more permissive. Whatever permissions the app has is immediately transferred to its webview irrespective of the url being called.

Then there is the whole gamut as to how the webview is implemented. One of the biggest challenges we faced in IOS was that our video conferencing solution implemented in webrtc was crashing. The same solution worked fine on Safari but just crashed inside the webview. The issue, it turned out, was that the webview being used was a slightly deprecated version and was not supporting mutli-threading.

‍

Also responsive design will pose its own challenges as the app implementing the webview gets to decide the screen real estate you can use. It will also have its navigation bar which need to be taken into account when calculating for screen height. This is especially tricky if you webapp can also be accessed directly via a browser. We need to keep track of user agents to hide and show components, allow or disallow certain actions etc.

‍

Authentication for a mini app via webview is usually straightforward and will require interfacing with the super app according to the specs. However, the validity of cookies, local storage etc are all opaque to you and are decided by the superapp. Your design must assume that as soon as the webview is closed all local storage and cookies are deleted. Also if and when you need the user to return to a screen on the super app you will need to load their library(written in javascript) in your application. Again, using inforation from the user-agent the code must be able to differentiate the context and not call these functions when in the browser.

Webview in and of itself is a quite a nifty little application but it definitely helps to understand all the gotchas around it especially if the super app is developed by a different entity.

‍