Agent runtimes for mobile apps: an honest comparison (2026)

Comparison posts in this category usually line up word error rates, and word error rate is rarely the thing that decides the project. A mobile team picking a runtime is deciding how much of a five-layer stack arrives already built, how many of their client platforms are covered by a first-party SDK, and what happens the first time the agent is asked to do something that writes.

Everything below comes from published documentation read in September 2026, with the pages linked. Where we are the weaker option, that is stated rather than styled around.

The four categories, and what each one leaves you#

A raw speech API returns text. Deepgram, AssemblyAI, Soniox and the open models all sit here, and they are good at it. Everything past the transcript is yours: deciding what the user meant, calling your own services, and putting something on screen.

A voice runtime returns a turn. It handles the microphone, endpointing, interruption and the audio round trip, and it hands your code a conversation rather than a string. OpenAI’s Realtime API is the reference example, working “directly with audio”, maintaining conversation state and calling tools, over WebRTC or WebSocket.

An agent platform adds the loop: tool schemas, a prompt, evaluation, and usually a dashboard. Vapi and Retell live here, both with telephony at the centre. Retell describes itself as “a platform to build, test, deploy, and monitor AI voice and chat agents with telephony, prompts, tools, and analytics built in.”

The fourth category returns a description of what the client should draw. That is where we sit, and it is the smallest category on this chart.

Client platform coverage, from the docs#

This is the row most teams should check first, because it is verifiable and it is where several vendors quietly do not reach.

LiveKit states it “includes open source SDKs for every major platform including JavaScript, Swift, Android, React Native, Flutter, and Unity”, and on raw platform count nobody beats that. Vapi’s SDK index lists Web, Flutter, React Native, iOS, Python and vanilla, with no Android entry. ElevenLabs publishes a first-party Swift library with SwiftUI integration and client-side tool execution, and a React Native library whose API is identical to their web React SDK, with the caveat that it “requires development builds and cannot be used with Expo Go”.

That ElevenLabs pairing is genuinely strong. If you are building a voice-only agent for iOS and React Native and nothing needs to appear on screen beyond a transcript, their documentation is a shorter path than ours and we would tell you so.

Flutter is the exception to this whole table, because it has a first-party answer that nobody else’s platform does. Flutter’s GenUI SDK and what it covers is worth reading before you evaluate anyone here.

Where the categories diverge: the write path#

Everything above is a reading feature. The divergence starts when the agent can change something.

A voice runtime will happily call a tool that moves money, because from its point of view a write tool and a read tool are the same JSON. The gate has to exist somewhere, and if the runtime does not provide one, it is yours to build: a turn that stops short of executing, a description of the pending action returned to the client, a UI that shows the user exactly what they are agreeing to, and a second call that runs it. The gate between a tool call and a write covers how to tier it by risk.

This is the single biggest difference between the demo you show internally and the feature you ship. It is also the part of the comparison that no vendor page makes easy to check, so ask the question directly when you evaluate.

What the interface layer is worth#

Everything in that sheet is a shape an answer can take. A runtime that returns only text forces every one of those into a sentence, or forces you to write a screen per answer type and a router that guesses which to show. Hard-coding a screen per answer type stops scaling at about the fourth one. An agent answering in the app’s own components is the longer argument for keeping the set closed rather than letting the model emit markup.

When the language is the constraint#

Vendor language lists are a marketing artefact. A model that scores well on the standard variety of a language can fall apart on how people in a given city actually speak, and no published list tells you where that line falls for your users.

The measurable version of this is worth citing. At the NADI 2025 shared task, Salhab and colleagues took first place in multi-dialectal Arabic recognition by pretraining on 15,000 hours of weakly labelled speech covering both the standard variety and regional ones. The reason that result is notable is that general-purpose models, trained on far more total audio, do not reach it on the same dialects. Scale on English does not transfer.

Our own answer is that we run this in production in Arabic, replying in Modern Standard Arabic with the interface flipped right to left, and that we arrived there by evaluating per variety rather than trusting a language list. The method is the same in any language with meaningful regional variation. Evaluating dialect coverage is the post that sets it out.

Choosing, by constraint#

Three constraints do most of the work.

If the agent answers a phone, this whole comparison is the wrong one and you want a telephony platform. If the answer only ever needs to be spoken, a voice runtime is sufficient and cheaper. If the answer needs to appear on screen, or the agent can write, or you ship on more than two client platforms, the interface and safety layers stop being weekend work and start being a team.

Two further reads if you are deciding rather than browsing: what the whole stack is made of covers the five pieces this table is measuring coverage against, and what owning the runtime actually costs prices the version where you own all five.

How to run the evaluation yourself#

A week is enough to answer this properly, and the exercise is the same for every vendor on the list.

Write twenty questions your users would actually ask, with the correct operation and arguments written down beside each one. Wire the same set of tools to each candidate. Run all twenty through each, three times, and record which operation was called rather than how the answer read.

Then add the write path to the same test. Ask each candidate to do something that changes state, and watch what happens between the request and the change. If nothing stops to ask the user, you have found the piece you will be building.

Finally, run it on a device in a real room rather than at a desk. Endpointing behaviour, which is the model deciding you have finished speaking, is where the biggest experience differences between these vendors show up, and it looks uniformly good in quiet conditions.

What this comparison deliberately does not do#

It does not rank accuracy. Every vendor publishes numbers measured on their own evaluation set, and comparing two such numbers tells you about the sets rather than the models.

Per-minute pricing is left out too. Published rates change often enough that any figure here would be wrong within a quarter, and the rate is rarely what decides a build of this size.

No latency figure appears for anyone, us included. Our own warm turns land at roughly 2.5 to 3 seconds end to end against a live tenant, dominated by the round trip to that tenant’s own services. Numbers below a second in this category usually measure first audio out rather than a completed action, which is a different quantity.

Sources#

• OpenAI, Realtime API guide. Accessed 12 September 2026.
• LiveKit, Connecting to LiveKit: client SDKs. Accessed 12 September 2026.
• ElevenLabs, Swift SDK and React Native SDK. Accessed 12 September 2026.
• Vapi, SDKs. Accessed 12 September 2026.
• Retell AI, Introduction. Accessed 12 September 2026.
• Mahmoud Salhab and others, Munsit at NADI 2025 Shared Task 2, 12 August 2025. Accessed 12 September 2026.