Cherry Studio App: the mobile client for Cherry Studio, and what its build actually requires
🍒 This is the mobile version of Cherry Studio.
At a glance
- What is it?
- Cherry Studio App is the Expo React Native mobile counterpart to the Cherry Studio desktop client, aimed at iOS and Android. The README is honest about its state: multi-provider support is described as gradually integrating, and the build path expects a prebuild step, a local database generation, and a native toolchain rather than a managed workflow.
- Who is it for?
- Adopt Cherry Studio App if you already use Cherry Studio on desktop and want the same assistant and conversation model on a phone, or if you are willing to work inside an Expo prebuild workflow to get it. Do not adopt it if you need a stable multi-provider mobile client today, since the README describes provider integration as still in progress, or if you cannot accept AGPL-3.0 obligations for a distributed build.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Cherry Studio App is, and who the mobile build is actually for
Cherry Studio App is the official mobile version of Cherry Studio, published under CherryHQ and written in TypeScript. The README frames it as bringing LLM interaction to iOS and Android devices, with preset assistants, multi-model conversations, conversation management, history search, and data migration listed as the core surface. The repository topics (agent, android, assistant, chat-bot, expo, ios) match that framing rather than suggesting a library or an SDK.
The audience is narrower than the feature list implies. This is a client, not a server, and the README points at the desktop project's sponsor documentation for support, which tells you the maintainers treat the desktop client as the primary product. If you are evaluating this as infrastructure to embed, it is the wrong shape. If you already run Cherry Studio on a desktop and want the same assistant and conversation model on a phone, that is the case this repository exists to serve. Note also that the README asks for a star, which is a request, not a signal about maturity.
Expo React Native, Tamagui, Redux Toolkit, and a local Drizzle database
The stack is stated plainly in the README: Expo React Native for the framework, pnpm as the package manager, Tamagui for UI, React Navigation for routing, and Redux Toolkit for state. That combination implies a conventional React Native application with a component library layered on top of the platform primitives, and Redux Toolkit holding conversation and assistant state in a single store rather than scattering it across context providers.
The more interesting piece is the database. The development steps include npx drizzle-kit generate, which means the app carries a typed local schema generated ahead of build time rather than defining tables ad hoc at runtime. For a chat client, that is the mechanism behind history search and data migration: conversations live in a local store the app owns, and migration between versions is a schema concern rather than a serialization concern. The README does not describe the schema contents, so the exact table layout is not something I can state.
There is also a separate workspace package, packages/react-native-streamable-http, built with npm install and npm run build inside that directory. The name points at streamable HTTP transport for MCP, which is how the app would talk to MCP servers. That package is built independently of the pnpm install at the root, which is a real detail: the root workflow and the transport package use different package managers, and a clean checkout needs both steps before the app will run.
Getting it running: prebuild, certificates, and the Android SDK path
The README gives an ordered sequence. Clone the repository, cd into it, then pnpm install at the root. Next, npx drizzle-kit generate to produce the database. Then the transport package: cd packages/react-native-streamable-http, npm install, npm run build. Only after that does the app start.
For iOS the steps are npx expo prebuild -p ios, then cd ios to add a self-signed certificate, then npx expo run:ios -d. For Android it is npx expo prebuild -p android, then cd android to add the Android SDK path to local.properties, then npx expo run:android -d. The prebuild calls are the load-bearing part. This is a bare workflow, not a managed one, and the README states the constraint directly: use physical devices or simulators for development, do not use Expo Go.
The local.properties content differs by platform. On Windows it is sdk.dir=C:\\Users\\UserName\\AppData\\Local\\Android\\sdk, with a note that newer Android Studio or IntelliJ versions may need the escaped form sdk.dir=C\:\\Users\\USERNAME\\AppData\\Local\\Android\\sdk, and a warning that the folder must be named sdk or Sdk. On Mac it is sdk.dir = /Users/USERNAME/Library/Android/sdk. On Linux it is sdk.dir = /home/USERNAME/Android/Sdk. The README also offers the environment variable route, exporting ANDROID_HOME and appending platform-tools and tools to PATH. The self-signed certificate step on iOS has no further explanation in the material, so what that certificate is used for is not something I can confirm.
Where the mobile client is thinner than the desktop one
The README labels multi-LLM provider support as gradually integrating, naming OpenAI, Gemini, and Anthropic. That phrasing is a limitation stated by the maintainers themselves, not an inference. If your workflow depends on a provider that has not landed yet, the mobile app is not a substitute for the desktop client, and the desktop client remains the reference implementation.
The release history reinforces the point. Three releases are listed: v0.1.5 in late December 2025, v0.1.6 in early January 2026, and v0.1.7 in late February 2026. All are 0.1.x. Nothing in the material indicates a stable API surface, and the repository's last push timestamp is later than the most recent release, which is consistent with ongoing work between releases rather than a frozen artifact.
The build requirements are the second limitation. A prebuild step, a self-signed certificate on iOS, a correctly cased SDK directory on Windows, and a separately built workspace package add up to a setup that assumes some native toolchain familiarity. The README's own warning against Expo Go removes the easiest escape hatch. If you want to evaluate the app quickly without touching Xcode or the Android SDK, this repository does not offer that path.
How this differs from running Cherry Studio on desktop
The obvious alternative is the desktop Cherry Studio client, which this repository explicitly calls the mobile version of. The difference is not only form factor. The desktop project is where the sponsor documentation lives and where the README directs supporters, so it is the centre of the project. The mobile app is a client that consumes the same assistant and conversation concepts but carries its own local database schema, its own transport package for MCP streamable HTTP, and its own release cadence on the 0.1.x line.
That means the two are not interchangeable in operation. A desktop user evaluating the mobile app is evaluating a second codebase with a separate schema and a separate build pipeline, and data migration is listed as a mobile feature, which suggests moving state between environments is a supported concern rather than an afterthought. The README does not describe a sync protocol, so whether desktop and mobile share state over a network or only through migration is not something the material answers.
The second alternative is building your own thin client against the provider APIs directly. That gives you control over which providers exist and when, at the cost of reimplementing assistant presets, conversation storage, history search, and migration. Cherry Studio App is worth its build complexity only if those pieces are what you want and the provider gap does not block you.
Licence, maintenance, and what AGPL-3.0 means for a mobile build
The repository is AGPL-3.0. For a mobile application this is a meaningful choice rather than a formality, because the licence's network clause applies to software users interact with over a network, and a client that talks to a service you operate can fall inside that boundary depending on how the service is structured. If you fork the app, ship it under your own name, or run a modified version as part of a hosted offering, the obligations attach. I am not a lawyer and this is not legal advice; the point is that the licence is a factor to evaluate before you build on the code, not after.
Maintenance cost is visible in the workflow itself. Every contributor needs the Android SDK configured with the correct directory casing, a self-signed iOS certificate, and a working build of packages/react-native-streamable-http, which uses npm while the root uses pnpm. That is two package managers and two build systems in one repository. Upgrades to Expo or React Native will need to be reconciled with the prebuild output, and the Drizzle schema has to be regenerated whenever the database changes.
The release spacing of roughly six to seven weeks between v0.1.5 and v0.1.7, based on the tagged dates, suggests active but not high-frequency shipping. There is no changelog content in the supplied material, so what changed between those versions is not something I can describe.
Editorial conclusion
Adopt Cherry Studio App if you already use Cherry Studio on desktop and want the same assistant and conversation model on a phone, or if you are willing to work inside an Expo prebuild workflow to get it. Do not adopt it if you need a stable multi-provider mobile client today, since the README describes provider integration as still in progress, or if you cannot accept AGPL-3.0 obligations for a distributed build. Before committing, verify that the packages/react-native-streamable-http build succeeds on your machine, that npx drizzle-kit generate produces the schema you expect, and whether the release cadence since v0.1.5 matches the stability you need.
Community notes