Cherry Studio App: the mobile client for Cherry Studio's LLM assistants

Who the Cherry Studio mobile app is for

Cherry Studio App is not a standalone product. The README calls it the official mobile version of Cherry Studio, and the desktop repository is where the sponsor link points. That framing matters: the app exists to carry an existing Cherry Studio user onto a phone, not to recruit someone who has never installed the desktop client. The stated features are multi-LLM provider support, preset assistants and multi-model conversations, light and dark themes, conversation management, history search and data migration. Of those, data migration is the one that only makes sense if there is something to migrate from. If you are looking for a first LLM chat client and have no existing setup, the migration feature is dead weight and the value proposition is thinner. If you already keep assistants and conversation history in Cherry Studio on a laptop, the mobile app is the piece that makes that setup usable away from the desk. The topics list on the repository (agent, android, assistant, chat-bot, expo, ios) confirms the intended shape: a chat client with an agent angle, shipped as a native mobile app.

Expo, Tamagui and a local Drizzle database

The stack is Expo React Native with pnpm as the package manager, Tamagui for UI, React Navigation for routing and Redux Toolkit for state. That is a conventional Expo application layout, and it means the app is a JavaScript bundle running against native modules rather than a web view wrapper. Two details in the repository layout are more interesting than the framework list. First, there is a db/ directory, a drizzle/ directory, a drizzle.config.ts and a generate step in the setup instructions, so conversation and assistant data live in a local SQLite-style store managed by Drizzle ORM rather than being fetched from a server on every screen. Second, packages/react-native-streamable-http is a workspace package that the README tells you to build separately, and the EAS build scripts do the same thing in eas-build-post-install. That package name points at Streamable HTTP, the transport used by MCP servers, which lines up with the agent topic and with the assistant feature set. In other words, the app can talk to tool servers over HTTP in addition to talking to model providers over their own APIs. The i18n scripts (check:i18n, sync:i18n, auto:i18n) show the UI strings are maintained as translation files with a check that fails on drift, which is a real cost the project has chosen to carry.

Building Cherry Studio App from source

There is no published install command for end users in the README. Everything under the Development heading assumes you are cloning and building. Start with the clone and the dependency install, which uses pnpm rather than npm or yarn.

git clone https://github.com/CherryHQ/cherry-studio-app.git
cd cherry-studio-app
pnpm install

Next generate the database schema. The README gives this as a bare npx call, so it runs the Drizzle kit that the repository pins.

npx drizzle-kit generate

The app depends on a workspace package that must be built before the native run, otherwise the import resolves to nothing.

cd packages/react-native-streamable-http
npm install
npm run build

Then pick a platform. The iOS path prebuilds the native project, and the README notes you add a self-signed certificate inside the generated ios directory before running on a device.

npx expo prebuild -p ios
cd ios
npx expo run:ios -d

Android follows the same shape, but you must put your SDK location into local.properties inside the generated android directory first. The README gives per-platform examples, including this Mac form.

npx expo prebuild -p android
cd android
# add sdk.dir to local.properties, then:
npx expo run:android -d

What you should see is a native build launched on a connected device or simulator. The README is explicit that you should use physical devices or simulators and not Expo Go, which is a direct consequence of the custom native code and the workspace package. The -d flag in both run commands targets a device, so an emulator or phone must be attached and recognised before the command will do anything useful.

Where the Cherry Studio App falls short

The most honest limitation is written into the feature list: multi-LLM provider support is described as gradually integrating, with OpenAI, Gemini and Anthropic named as the direction. Gradual integration means the provider you care about may not be wired up in the build you produce. That is a different kind of gap from a missing feature, because it is invisible until you try to add a provider and find no entry for it. Second, the README documents no rollback, no uninstall path and no upgrade procedure for the mobile app. Desktop Cherry Studio has its own release cadence and the mobile app versions independently (the latest release in the repository is v0.1.7), so a schema change in the local Drizzle database has no documented migration story for a phone that already holds your conversation history. Third, the build is not trivial. It requires pnpm, a Drizzle generate step, a workspace package build, Xcode or the Android SDK, and a self-signed certificate on iOS. Anyone expecting an app store install will be disappointed by the actual path. Fourth, AGPL-3.0 applies to the code, which is a real constraint if you intend to fork and ship a modified client; that is a licensing question for a lawyer, not something this article can settle. Finally, the README does not describe what happens to local data when you sign out or clear the app, so treat the local database as something you should understand before trusting it with history you care about.

Cherry Studio App compared with running the desktop client

The obvious alternative is the desktop Cherry Studio application, which is the same project and the source of the mobile app's data model. The difference is not features but reach. The desktop client runs on a computer with a full window, a keyboard and a filesystem you control directly; the mobile app runs on a phone, which is where you actually are when a question comes up. The trade is that the mobile client carries a smaller surface: the README lists preset assistants, conversations, history search and migration, while the desktop repository is where the sponsor link and the broader project documentation live. A second alternative is any general-purpose mobile chat client that speaks to one provider directly. Those install from an app store in seconds and require no build toolchain, but they do not carry your Cherry Studio assistants or history, and they do not give you the MCP-over-Streamable-HTTP path that the workspace package implies. If your assistants are the valuable part of your setup, a generic client throws that away. If your setup is one API key and one model, the generic client wins on effort by a wide margin.

Maintenance, releases and the AGPL-3.0 licence

The repository is not archived, and the last push was on 2026-09-10, which is recent enough that the project is being worked on. Releases are a different story: v0.1.7 landed on 2026-02-27, v0.1.6 on 2026-01-08 and v0.1.5 on 2025-12-25. Those are roughly monthly tags early in the year, and the version in package.json matches v0.1.7, so the tagged release line and the source tree are consistent. The gap between the last tag and the last push tells you that commits continue between releases, which is normal for a mobile project where a tag implies a build. Upgrade cost is the thing to plan for: because the app keeps a local Drizzle database and the README documents no migration path between versions, moving from one build to the next means you should assume you may need to redo setup rather than assume state carries over. On licensing, the repository is AGPL-3.0. For personal use that is unremarkable. For anyone who wants to modify the app and run it as a network service, the AGPL's source-availability terms are the part to read, and the README offers no guidance on them.

Editorial conclusion

Adopt it if you already run Cherry Studio on desktop and want the same multi-model assistant workflow on a phone or tablet, and you are willing to build from source. Do not adopt it if you need a one-command install, a stable documented API surface, or a client that is independent of the desktop project's data model. Before you commit, check whether the provider list in your build actually covers the models you use, since the README describes multi-provider support as gradually integrating, and confirm that the Android SDK path in local.properties matches your machine.

Frequently asked questions

Official sources

1. CherryHQ/cherry-studio-app on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases