There is no verified Threetone Expo package or working mobile conversation walkthrough. Public session initiation remains gated. This cookbook covers mobile preparation and supported server-side configuration reads.
Before you begin
Use an Expo project with recorded Expo and React Native versions, a physical test device, and an authenticated application backend. Decide which data the mobile user may access and whether the application needs microphone input at all.1
Keep workspace credentials on the backend
Follow the server-side quickstart to read permitted agent configuration. Return only the application data the user is allowed to see. Expo’s environment guide explains that
EXPO_PUBLIC_ values are bundled into the application; they must not contain workspace API keys.2
Prepare permission and capture states
Follow the version-matched Expo Audio documentation for native configuration and recording permissions. Test denied permission, a later permission change, and explicit stop. Show when capture is active. A local recording test does not prove agent streaming support.
3
Handle app and network transitions
Use React Native’s AppState to observe foreground and background changes. Define whether capture stops or a future session ends when the app leaves the foreground. After a network interruption, recheck authentication and session state before reconnecting. Do not replay buffered audio or tool actions without a released replay contract.
4
Review logout and recovery
Release local audio resources, clear pending work, and remove application session material on logout. SecureStore can protect suitable local values, but it is not a reason to distribute a shared workspace key. Handle unavailable stored credentials by requiring sign-in again.
Frequently asked questions
Does a successful microphone test mean live voice works?
Does a successful microphone test mean live voice works?
No. Device capture, network transport, session authorization, and agent execution are separate checks.
Should the app retry every connection error?
Should the app retry every connection error?
Use bounded retries only for recoverable failures. Stop on denied permission, expired access, user cancellation, or an unavailable runtime.