One URL in a WebView, and your customers can reach you from inside your app — no package to install, none to keep updated.
In-app chat support lets people message your support team from inside your mobile app instead of leaving it. inrelay serves your chat widget as a hosted full-screen page on your own help-centre address, so any iOS, Android or React Native app can open it in a WebView and get the same conversation, bot and inbox as your website.
What it prevents is the exit. A customer stuck in your app who has to find your website, then your contact page, then an email client, is a customer who mostly gives up — and the ones who do write arrive with no idea which screen they were on or which account they are using.
Your workspace gets a chat page at your help-centre address. Point a WebView at it and you are done — that is the entire integration.

This is the part most vendors are vague about, so plainly: when your customer has closed the app, your reply reaches them by email. If the conversation has an email address — passed in from your app, or asked for in the chat — the answer is delivered there, and their reply comes back into the same thread.
There are no push notifications in this version. No APNs certificates, no FCM keys, no device tokens to store. That is a genuine limitation and we would rather you read it here than discover it in week two: if silent, instant re-engagement inside your app is the point of the exercise, this is not yet the tool for it.
What it is very good at is the common case — someone with a question while they are using your product, who wants an answer without leaving it, and does not mind hearing back by email if they have moved on.
Each integration is about a screen of code, and the same one works for every platform because the thing being embedded is a page.
It is on the Help Widget page in desktop settings, with a copy button, alongside the verification toggle.
WKWebView on iOS, WebView on Android, react-native-webview for React Native. A support button in your app opens the screen; that is the whole surface.
Signed-in app? Append the customer’s email, name and a random opaque token so their history follows them. Skip this and everything still works, anonymously.
Have your server sign the identity before it reaches the WebView. Copy-paste recipes for all three platforms live on the in-app chat setup page.
No plan gate on this one. In-app chat is on every plan — it is the same widget, in a page.
The reason small app teams ship without in-app support is not that they do not want it — and the same is true of every business with an app in front of its customers. It is that the well-known way to get it costs a per-seat platform plus a native SDK per platform, and then keeps costing: every SDK is a dependency you upgrade, a build you re-cut, an App Store review you wait through when the vendor fixes something on their side.
A hosted page removes all of that from your release cycle. Improvements to the chat, the bot and the help centre reach your app the next time somebody opens the screen, because there is no version of us baked into your binary.
We are not claiming a native SDK. This is a hosted chat page you put in a WebView, and it is worth knowing that several of the vendors who do ship SDKs started exactly here — the first Android SDK from at least one well-known chat product was a WebView around their hosted chatbox.
What we have done instead of writing the wrapper is take the identity model seriously from day one. Signed identity exists before anyone needs it, because retrofitting verification after your customers have embedded an unverified URL is the documented pain of doing this the other way round. The token that restores a conversation is opaque and random by instruction, and with verification switched on a signature covering one customer’s details will not validate for another’s.
And when a signature is wrong or missing, the chat still opens. It just treats the visitor as anonymous rather than failing — because a support button that errors is worse than a support button that has forgotten who you are.
In-app chat is one piece of the inrelay feature family — these are its closest neighbours.
Web and in-app chats are one channel, one queue and one history — not two products to staff.
See live chat → MOBILE APPThe other side of mobile: the companion app your teammates use to answer from anywhere.
See the mobile app → HELP CENTREPoint the crawler at your docs and the same widget can answer from them before anyone types.
Generate a help centre →Free to start with your own inbox — every feature, no card, never per seat.
Give your customers faster answers and your team their evenings back.
Desktop and mobile. Free for solo.