Skip to main content
PraisonAI Mobile runs the agent loop on the phone, dispatches routes to real screens, and keeps your conversation exactly where you left it — wrapped in a native Tauri shell that provides the platform integration a browser cannot. Run PraisonAI agents natively on iOS and Android — no server, no Python, no subprocess.
praisonai-mobile is a Tauri 2 shell around a webview that runs the agent loop in-process. The whole conversation happens on the device.
Assistant messages and tool results render as plain text by construction — every row’s content is set through textContent, never innerHTML. Model output, tool results, and summarised web pages cannot inject markup into the transcript. An untrusted string can appear on screen; it cannot become a script.

​
Quick Start

1

Clone and install

2

Open a conversation

Tap a chat and the app dispatches the chat route to a live screen — the transcript streams the agent’s reply token by token.
3

Move around, then come back

Open Settings, scroll, tap About, then return. The chat screen is retained, so you land back where you were — same scroll position, same in-flight streaming.
4

Verify everything passes

check runs typecheck, boundaries, and test — the three gates that keep the two seams honest.
The app ships on iOS 16+ and Android API 26+ via Tauri. The native shell handles safe-area insets, keyboard height, lifecycle, and the back gesture — see Native Shell.
The app dispatches four screens. Only the chat screen survives navigation; the rest rebuild fresh on return.
When you scroll up in a conversation, open Settings, and come back, you land where you left off — the transcript keeps its scroll position and any in-flight streaming.
Destroying the other screens on exit is deliberate: they re-read fresh state on return instead of showing stale data.

​
Why It Matters

Every selling point is one line.

​
How It Works

The app is six layers with two enforced seams: one for the agent framework, one for the UI shell.

​
Best Practices

The chat screen is the only screen kept in the DOM when you navigate away. Its nodes stay, so scroll position and any streaming reply survive a trip to Settings and back.
The next screen mounts before the current one hides, so navigation never flashes an empty page.
When the on-device engine answers, the completed turn is written to the same session the chat list reads — so a conversation you had is there the next time you open the app.
The in-process praisonai-ts engine executes tools but does not announce them, so capabilities.tools is false. Use remote-http when you need tool rows, approvals, or reasoning in the UI.
Read events through the 11-event protocol rather than parsing prose. A tool call that silently failed still looks like a normal answer if you infer from text.
end.userIndex comes from the engine. A cancelled or errored turn is never persisted, so any index you compute from screen position drifts.

Architecture

How routes become screens, and where the session join lives.

Engines

The in-process engine, and how it persists a turn.

Native Shell

The Tauri shell — safe-area, keyboard, lifecycle, and back-gesture arbitration.

Getting Started

Clone, run in the webview, and swap engines.

Protocol

The 11 events every engine speaks.