In-App Support Has Three Doors. Only One Opens Into Your App.

One tap, three very different journeys

Imagine a delivery app, a crushed parcel and a customer standing in the rain. She taps Help. The next screen looks reassuringly familiar. Same colours. Same friendly invitation to chat. Then the agent asks her to identify herself, find the order number and explain the damage. The app knew two of those things a moment ago. The camera could settle the third.

That is the expensive little trick hidden inside “in-app support”. It describes where the customer starts, while saying remarkably little about where she finishes. A native SDK adds support components to the application. A webview displays a web experience inside it. An external support link opens a destination in a browser. The costumes may match; the plumbing does not.

For a mobile product team, the useful question is what happens after the first tap: who knows the customer, who can see the problem, and who remembers either when chat becomes a call?

The native door carries its own luggage

A native support SDK becomes a dependency in the iOS or Android app. It can work with platform navigation, permissions and device APIs, subject to what the vendor actually implements. That makes camera capture, notifications and device authentication practical parts of a support flow. It also means integration work, release testing and another dependency to maintain.

UJET belongs in this column. Its Mobile SDK supports iOS and Android, with in-app media capture and app/device context. Its published size estimate is about 8 MB added to the app-store download. That is a vendor estimate, not a measurement of your build. [1]

The distinguishing moment comes when the agent needs proof. UJET SmartActions can request verification through the phone’s existing Face ID, fingerprint or passcode, before a call connects. Photos, screenshots and video can be requested before or during a call and saved to the CRM. Identity becomes a glance; a dent becomes evidence. [3]

This is a capability of the configured service, not a magical property bestowed on every SDK. A native interface still needs the right account association, permissions and backend integration. Buying the door does not furnish the house.

A webview has perfectly good manners

The webview’s bargain is attractive: reuse a web support experience, keep the customer visually inside the app, and publish much of the interface or content without waiting for a new app release. For a help centre or a straightforward contact form, that can be excellent engineering.

Android describes WebView as a way to display a web page within an app and provides mechanisms for JavaScript to communicate with native code. Its browser engine also has runtime memory costs. A smaller app download does not automatically mean a lighter running process. [9]

Nor is the camera forbidden territory. Android exposes file chooser and permission callbacks for web content; a host app can implement the necessary handling. Apple documents passkey authentication in WKWebView browser applications. A blanket claim that web content cannot use device-backed authentication would be wrong. Those mechanisms do not, by themselves, establish a support vendor’s caller-verification workflow. [10][11]

What the webview cannot do automatically is inherit every useful fact from the surrounding app. Identity, order details and diagnostics must be passed deliberately through supported interfaces. The honest trade is less duplicated presentation work in exchange for careful work at the boundary.

The browser door travels light

A link to a hosted support page asks very little of the app binary. It can be the quickest route to a searchable help centre, a fallback when an integration fails, or support that also works for people who have never installed the app. Web content remains easy to update. Those are real virtues.

The price is the change of environment. Android explicitly notes that the browser does not share its application data with the host app. Leaving an authenticated app therefore does not automatically create an authenticated support browser session. [9]

But leaving the app does not inevitably erase the conversation. Zendesk documents authenticated messaging identities across domains, devices and browsers. A properly implemented sign-in or handoff can reconnect the customer to server-held history. A bare URL cannot be assumed to carry the current order or screen state. [6]

“Deep link” also needs care. A deep link can target a screen inside an app. Here, the third door means an outbound link to browser-hosted support. The destination and authentication design decide what survives, not the fashionable name given to the link.

Three vendors, not three assigned seats

UJET, Zendesk and Intercom are a useful cohort precisely because the labels overlap. Zendesk offers mobile Messaging SDKs for both platforms; its iOS integration documents camera, microphone and photo-library permission keys. Intercom describes its mobile integrations as native SDKs and also acknowledges WKWebView use in its iOS SDK. Native packaging can contain web-rendered surfaces. [4][5][8]

The size figures resist a neat horse race. Zendesk lists approximately 7.5 MB for the Android AAR and iOS XCFramework downloads, with final app impact dependent on build settings and dependencies. Intercom’s FAQ gives rough mobile SDK sizes of 9 MB for iOS and 7 MB for Android, varying by configuration. Neither is an exact equivalent of UJET’s app-store download increment. [4][5][7]

Treat these as planning clues. Build the same release app with and without each candidate, then compare delivered download size, installed size, startup time and memory. Measure the webview and link versions too. A table of incompatible megabytes is a very handsome way to make a poor decision.

The handoff is where the promise gets tested

UJET describes collecting information in chat before moving to a phone call without losing context, alongside CRM information presented when a call connects. Its omnichannel proposition is continuity between voice and digital engagement, rather than merely offering several buttons. [1][2]

Authentication deserves its own test. Zendesk documents server-signed JWT authentication for its widget and mobile SDKs. Intercom’s installation guidance describes backend-generated HMAC identity verification. These establish trusted messaging identity; they are not the same feature as an agent requesting UJET’s device verification during support. [6][8]

Return to the parcel. Ask each vendor to demonstrate the same sequence: a signed-in customer opens Help from an order, shares a picture, starts chat and escalates to voice. Inspect the receiving agent’s screen. Are the order reference, transcript, attachment and verification status present? Which came from the app, which from the CRM, and which required custom work?

Choose native when device interaction and an uninterrupted support journey justify the release burden. Choose a webview when a reusable web experience meets the job and the identity bridge is sound. Choose a browser link when reach and simplicity matter most, then design the return path. The customer has already explained the problem once. A second recital should never be the admission price.