Chatbot Mobile SDK: Adding Chat to Flutter and React Native Apps

Your web chat widget is answering questions all day. Then you look at where support email actually comes from and roughly half of it is people using your mobile app, who never see that widget at all. So you go looking for a chatbot mobile SDK, and every vendor has one on the pricing page.

Read the installation docs and a pattern shows up fast. Most of those SDKs are the web widget in a WebView with a nicer install command wrapped around it. That is not a scandal — it is a reasonable engineering decision — but it changes what you should test before you ship, and it changes what you should ask a vendor before you buy.

What a Chatbot Mobile SDK Actually Ships

There are only two ways to put a chat conversation on a phone screen.

Native rendering draws the bubbles, input field and typing indicator with the platform's own components — Flutter widgets, or UIView and View under React Native. The SDK talks to the chat API over plain HTTP and owns the interface.

WebView rendering loads the existing web widget inside an embedded browser and passes messages in and out. One codebase, instant parity with whatever the web team ships, and no design work.

	Native	WebView
Extra dependency	HTTP client only	WebView runtime
Approx. install size added	Under 100 KB of Dart/JS	Uses the system WebView; the binding package is small, the runtime is not free on Android
Matches your app's theme	Yes, by construction	Only if the widget is themeable
Keyboard and safe-area behaviour	Platform default	Needs manual handling
Survives being backgrounded	Yes, if state is held outside	Often reloads empty on iOS
Parity with web widget updates	Needs a package update	Automatic
Offline behaviour	You control the failure state	Blank page or browser error

Neither is wrong. Native is better when chat is a core surface people use weekly. WebView is better when chat is a rarely-opened help screen and you would rather not maintain a second UI. What matters is knowing which one you bought.

The questions to ask a vendor

1. Is the mobile package native, or a WebView wrapper? A direct answer here tells you a lot about the rest of the documentation.
2. Which endpoints does it call, and are they public — so you can rebuild the UI yourself if the package stalls?
3. Is the mobile package gated behind a higher plan than the web widget?
4. What happens on a dropped connection mid-answer?

Adding a Chatbot to a Flutter App

Flutter is the easier of the two, because a native chat UI in Dart is a few hundred lines and several vendors have written them. SahayBot's Flutter package ships both modes in one dependency — AgentFaqNativeWidget for pure Flutter UI, AgentFaqWebViewWidget when you want pixel parity with the web widget. The full walkthrough lives in the Flutter integration docs; the shape of it is:

1. Download and drop in the package. It installs as a path dependency rather than from pub.dev, so it sits in your repo next to lib/.
2. Add it to pubspec.yaml under dependencies with path: ./agentfaq_widget, then run flutter pub get.
3. Add the Android internet permission. <uses-permission android:name="android.permission.INTERNET"/> in AndroidManifest.xml. iOS needs nothing for the native mode.
4. Wrap your Scaffold in a Stack and drop AgentFaqNativeWidget(baseUrl: ..., widgetKey: ...) in as the second child. That produces a floating bubble at the bottom right.
5. Paste your widget key — the same data-widget-id value the web embed uses, from the agent's detail page.

The package targets Flutter 3.10+ and Dart 3, which is comfortably behind the 3.44 stable line, so it drops into a current project without a version fight. If you pick the WebView mode instead, it pulls in webview_flutter and iOS wants an App Transport Security entry in Info.plist.

One deployment note that is easy to miss: the Flutter package is a paid-plan feature. On a free trial the guide works but the API returns 403, which looks like a broken integration rather than a billing state. Check your plan before you spend an afternoon debugging a network error.

React Native: The Honest Answer Is a WebView

There is no native React Native package for SahayBot, and we would rather write that sentence than dress a WebView up as an SDK. The route is react-native-webview pointing at the same widget your website loads — which is also what Chatwoot, Chative and LiveChat publish as their React Native integration, and what Botpress documents for Expo apps. When four vendors independently arrive at the same answer, it is the answer.

Two constraints matter in 2026:

• react-native-webview 14.x dropped the legacy Paper architecture entirely. You need React Native 0.76 or newer with the New Architecture enabled, and iOS 15.1+. An older app is a migration project before it is a chat project.
• Communication runs through postMessage and injectJavaScript. If you want the app to tell the widget who the logged-in user is, that is the channel.

What actually breaks in a mobile WebView

Not the answers. The answers are fine — they come from the same retrieval pipeline as the web widget. What breaks is everything around them:

• The keyboard covers the input field. Set keyboardDisplayRequiresUserAction={false} and give the WebView a container that resizes, or users type blind.
• The safe area. An unpadded WebView puts the send button under the home indicator on every notched iPhone.
• Session loss. iOS can evict a backgrounded WebView's process; it reloads with an empty conversation. Persist the session ID on the native side and replay it on resume.
• Links inside answers. By default they open in the WebView and your user is now browsing your website inside your support window with no back button. Intercept navigation and hand external URLs to the system browser.
• Offline. A WebView with no network shows a browser error page. Check connectivity before rendering and show your own retry state instead.

Budget half a day for that list. It is not hard work, but skipping it is how a working integration ships feeling broken.

When Not to Put a Chatbot in Your App

Three cases where the answer is no.

Your app has almost no support volume. If mobile generates a handful of tickets a month, a "Contact us" mail link costs nothing to maintain and never hallucinates. Chat is worth building when volume is boring and repetitive — the signs it is time are about repetition, not headcount.

Your questions are account-specific. "Where is my order", "why was I charged twice", "reset my 2FA" — none of those are answerable from published content. A bot without an integration into your own backend will politely fail at all three, and users will conclude the feature is useless. Wire up the lookups first, or keep chat on the marketing site where the questions are generic.

Your app is already mostly a WebView. Adding another WebView screen pushes you further into the territory Apple's guideline 4.2 is written for. Chat is not what gets that app rejected, but it is not the thing to add while you are on thin ice either.

What to Measure After You Ship

Mobile deflection is usually a little lower than web, for a mechanical reason: people open chat in an app when they are already stuck, whereas on a website they often open it while browsing. Published 2026 benchmarks put self-service and AI deflection in the 40–60% band overall, with true deflection — resolved, not just answered, and not reopened within seven days — sitting materially lower than the headline figures vendors quote.

Track three things for the first month:

Metric	What it tells you	Watch for
Open rate of the chat bubble	Whether anyone found it	Under 2% of sessions means placement, not content
Conversations per resolved ticket	Real deflection	Rising while tickets stay flat = the bot is an extra step
Unanswered question log	Content gaps	The same phrasing appearing weekly is a missing article

That third one is where the work is. A chatbot reduces tickets in proportion to how honestly you read the questions it could not answer, and mobile users phrase things differently from desktop users — shorter, more fragmented, more typos.

If you are weighing whether to build the native path yourself against installing a package, that is a build-versus-buy call, and the team at NoCubical writes about how those decisions age. For most teams the honest sequence is: ship the web widget first, watch what mobile users ask, and put it in the app once you know the answers are worth the screen space.

Frequently Asked Questions