Support inside a mobile app has to fit into the app's navigation. A customer may leave the chat to check an order, then return with a half-written message still in the composer.
A support button can open a modal. A help tab can keep the conversation inside a normal screen. Both are useful, but they behave differently when someone changes tabs, opens another screen or brings the app back from the background.
DobroDesk Mobile SDK 0.2.0 adds inline support screens and explicit controls for their lifetime. Here is how that affects navigation, drafts and pending messages.
Give the app control of the screen
An inline support view belongs to the screen that contains it. If the app already has a back button or tab navigation, another close button inside the chat can be confusing. Which one ends the conversation? Which one only leaves the screen?
We let the host app control navigation for the embedded view. A modal keeps its own presentation controls. The conversation can be presented in either place.
This also affects layout. The composer needs room when the keyboard opens, the send action needs to stay reachable and a loading or recovery message needs to fit inside the space the app actually gives the widget.
These previews use example support messages in the native iOS and Android interfaces:
Leaving a screen should preserve useful work
Imagine typing a support message, switching to the Orders tab to check a number and coming back. Losing the draft would make a normal action feel like a mistake.
We treat a visibility change separately from ending the account session. Hiding the widget pauses its view work and releases keyboard focus. It preserves the signed session, draft and pending delivery state. Unmounting an inline view releases its surface reservation and view-scoped work while preserving the signed session and pending outbox.
Logout has a different meaning. A shared device may be about to switch to another person, so the old account's state must be cleared through the account-session lifecycle.
Keeping these transitions separate avoids putting every kind of cleanup into the same close handler.
Delayed callbacks need the same care. They should not reopen a screen after navigation or clean up its replacement. The NativeScript fixes in 0.2.0 cover that ownership problem.
Keep pending delivery visible
Mobile connections disappear at awkward times. A user may press Send just before losing connectivity.
The interface needs to distinguish a message waiting locally from one accepted by the service. Otherwise a user has to guess whether to send it again.
The SDK keeps pending delivery state and can queue messages while offline. The important design question is where acknowledgement happens. A local timeout does not, by itself, tell the app that the service never received the message.
A useful integration check is to leave and reopen the support screen while a message is pending, then restore the connection. Check the draft, delivery state and what the conversation actually contains. A successful first-send test does not cover that sequence.
Carry the action into the handoff
For a configured booking with a connected provider, the conversation collects the details, gets the available choices and asks the customer to confirm. If the action cannot finish or needs a teammate's decision, a person can continue it.
That person needs the details already collected and the action's result. Keeping them in the conversation helps the teammate continue without making the customer start again.
AI drafts follow the workspace's approved knowledge and human review is the default. Automatic actions and replies depend on the configured rules.
What shipped
Mobile SDK 0.2.0 adds inline presentation for React Native, Flutter and NativeScript, plus a native widget attached to a bounded Capacitor container. The iOS and Android renderers supply the native conversation interface. The host backend issues a short-lived customer token, keeping the signing secret out of the app bundle.
The release also includes framework fixes around presentation, retries and cleanup. The release notes list the platform-specific changes.
These examples come from DobroDesk, a product by CoMStudio OÜ. If you're adding support to an app, the SDK guides cover integration and the public demo shows the conversation flow.
Which behaviour has caused the most trouble in your embedded support UI: keyboard layout, pending messages or keeping state when a screen closes?
Top comments (1)
Your point about where acknowledgement happens is the part we had to design for. On an offline-first inspection app I worked on, an inspection started with a temporary local ID; when the device reconnected, the server assigned the real one, and every answer, photo and queue entry was remapped to it. Retries reused the server ID, so a flaky connection couldn't create duplicate inspections. That's the case your integration check describes: press Send just before the signal drops, and the client can't tell a lost request from a lost response. Does the SDK attach a client-generated message ID so the service can drop a resent duplicate?