Mobile In-App Browsing
Mobile In-App browsing is a special case of handling browser-based requests from within mobile apps. Let's understand this in a bit more detail.
tl;dr
Due to a lot of variability and limitations on in-app browsing experience, we are unable to support the popup flow of web SDK via in-app browsing. If this forms a large part of your use case or customer experience, you may want to switch to redirect flow or use a smart combination of popup and redirect as fallback. We recommend using popup flow (or our dedicated mobile SDKs in case of native apps) as much as possible given its clear advantages over redirect. Detailed comparison and advantages can be found on the choosing a flow for Web SDK page. Read on to know more about what is in-app browsing and why these problems occur.
What is in-app browsing
In-app browsing refers to the viewing of web-based content from within a native mobile app, without leaving the app or switching to a browser like Chrome or Safari. The most common implementations of this are seen on most social media apps, like Instagram, Facebook, LinkedIn, and Twitter. Other than this, a few communication apps like Gmail and Telegram have also started providing this functionality. This is great for the host apps since the user stays within their app while viewing web links shared by other users, either as a post or as a form of direct communication.
Common use cases for in-app browsing
A native mobile app which is just your web app wrapped in a WebView
A link shared via an app (such as social media apps or Gmail app) that defaults to in-app browsing behavior
JS-based hybrid mobile frameworks, such as React Native, Flutter and Ionic (Cordova), trying to reuse JS integration techniques instead of dedicated, framework-specific plugins
How this affects you
While in-app browsing may look eerily similar to using a browser, they are not the same. The factors that make it different from a browser are:
Parent app's choice of in-app browsing method - whether it is a WebView or it is browser based (ChromeTab or SafariViewController)
OS limitations imposed on each of the in-app browsing methods
Parent app developer's configurations and customizations on their in-app browsing
This means that all features that are available to a browser may or may not be available with an in-app browsing experience. This mostly hampers with a lot of JS working and window/tab management.
Since web SDK's popup flow depends on these features, it doesn't work well with in-app browsing. If your use case or your customers' behavior is expected to give rise to in-app browsing scenarios, we suggest falling back to the redirect flow in such cases. Both of these flows, popup and redirect, are detailed in depth on the browser integration page.
A brief history of in-app browsing (in-case you are interested!)
Without going much into detail about how browsers are built and how they work, let's just say that they are basically JavaScript-processing-and-HTML-rendering engines with a UI and buttons slapped on top of it to make it usable (and trust me, I'm glossing over a lot of details and nuances when I say this).
So now with the advent of mobiles and programmable mobile apps, developers needed a way to show web content within their apps if they so desired. On Android and iOS, the two leading mobile OSs, this is usually done using something called a WebView. A WebView is the barebones form of the rendering engine that makes up a browser.
Since the developers are now directly interacting with the browsing engine, they can manage all the interactions a user can have with the WebView. This is both a pro and a con. Great, because developers have a lot of control over how things are processed. Not so great, because developers have to manage many aspects of the user's browsing and browser controls, even if they don't want to - browsing is pretty common user behavior and users know their way around. Plus a lot of this control makes it easy for developers (and malicious actors) to build insecure stuff. For this reason, many platforms don't allow secure operations such as login (which is the crux of the experience) via WebViews.
To solve this, the OS providers have recently started providing browser-based implementations for developers to be able to provide similar experiences with more security and less code. It's called a Chrome Tab on Android and Safari View Controller on iOS. These implementations provide limited control to the developers and come with their own, limited-customizations-available UI, on behalf of providing a low overhead, more secure and more natively familiar alternative to the WebViews.
In case you want to discuss this more, feel free to drop a line to [email protected] or on our Discord community, and we'll get in touch with you.