Keeping drafts and pending messages in a mobile support SDK

Dmytro Shevchenko — Wed, 14 Oct 2026 06:22:15 +0000

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?

Why we build DobroDesk on Cloudflare Workers

Dmytro Shevchenko — Tue, 13 Oct 2026 13:02:37 +0000

DobroDesk puts email, website chat and in-app support in shared inboxes. A teammate can read the history, see the customer details and take over from AI when needed.

We build it on Cloudflare. Here is how that works when a customer asks for a booking and then needs help from the team.

A booking request in chat

A customer asks to book a consultation. With a booking provider connected and the action configured, DobroDesk can collect the service, date and time, check availability and show a proposed slot. The customer confirms before the booking is completed.

Sometimes the request changes halfway through. The customer may need a different service, or the provider may fail to return an answer. A teammate can then take over with the details already collected in the conversation.

That handoff matters. The customer should not have to explain the request again, and the teammate needs to know what was tried and what still needs attention.

Where the messages go

A booking request has more than a few chat messages. There is a customer, a conversation history and the result of the action. We keep that support data in the workspace's Durable Object, using SQLite.

D1 holds shared account and routing information. R2 stores files, including email attachments. This keeps the conversation data together without putting large files in the same database.

Some work continues after a message arrives. An email needs parsing, a reply needs sending and a failed delivery may need another attempt. We use Cloudflare Queues for those jobs. A customer can send a message while the service handles the next steps in the background.

Retries need care too. Receiving a provider event twice should not create two conversations, and retrying a reply should not send it twice. Those are the kinds of cases we check when changing the flow.

AI and the team share the conversation

AI can prepare a reply for review or answer routine questions automatically when the workspace enables that mode. It uses the knowledge and rules the team has configured.

Sensitive or uncertain requests go to a person. The booking action follows the same approach: it can complete the configured steps after confirmation, while a teammate handles the cases that need a decision.

For the support team, the useful part is seeing the messages, customer details and action results together. They can continue the conversation from that point.

Updating the product while chats are open

A customer may leave a chat open while we release an update. We keep versioned widget files and support the previous running version so an active conversation can continue. We also check restored sessions and conversation history during releases.

The Mobile SDK brings native support screens to iOS and Android, with packages for Flutter, React Native, Capacitor and NativeScript. Version 0.2.0 is published. Teams can add support to their app and handle the incoming conversations in DobroDesk.

We have also been improving conversation loading and switching in the inbox. We focus on everyday steps, such as opening a conversation and moving to the next one.

You can try the interactive demo. The SDK guides cover installation and configuration when you are ready to add support to an app.

DEV Community: Dmytro Shevchenko