One Flutter codebase for iOS and Android, talking to the same API as the web app. Sixty-eight screens, every module, and you build it and ship it from your own developer account.
MIT licensed. No store listing to wait on, and no per-seat fee on the phone either.
Not a companion app that shows you what happened. The one that lets you do something about it.
You build it, you sign it, you distribute it. That is the same operational model as the rest of BottleCRM.
Clone the repository, run flutter pub get, run flutter run. One codebase produces both the iOS and the Android build, and there is no paid tier gating any of it.
Set the backend URL for the install. That is the whole configuration step, and it is why the app works against your own deployment rather than ours.
Google Sign-In, or a six-digit code emailed to you that you type into the app. Tokens land in the iOS Keychain or the Android Keystore and refresh themselves.
Tickets, leads, deals, approvals, goals and the timesheet, from the device. Someone in more than one organisation switches tenant without signing in again.
Three of these are deliberate trade-offs with a reason behind them. The fourth is simply not built yet.
Not under our publisher account. The repository ships the Flutter source so you, or whoever hosts for you, build and distribute under your own developer account. One binary that talks to many different self-hosted backends is a review problem we would rather you did not inherit from us.
A live connection is required for everything: list, detail, create, edit. The backend runs the tenant scoping and the field validation on every request, and buffering offline writes would produce merge conflicts that quietly corrupt customer data. Correctness over offline editing, deliberately.
Each install signs in as one user and there is no fast account switch. For a shared device, a tablet on a sales floor for instance, use the web app and let the browser session do the work.
Opening the app does not ask for Face ID or a fingerprint; the tokens are in the platform secure store, but the app itself is not gated behind a biometric check. And there is no kanban board on the phone, though that is not a mobile gap: the web app does not have one either.
Leads, contacts, accounts, deals, tasks, tickets, invoices, estimates, documents, solutions, goals, the timesheet, notifications, team and the whole settings tree. Sixty-eight screens, and creating and editing works on all of them.
Not a stripped view of the queue. SLA panel, public and internal comment tabs, parent and child links, merge and unmerge, time tracking, mentions, macros, the close-with-children dialog and the approvals inbox all ship on the phone.
The JWT pair goes into the iOS Keychain or the Android Keystore through the platform secure store, never into shared preferences. Every request carries the org, and the backend enforces the tenant boundary whatever the app sends.
A widget test renders screens at a 390 by 844 viewport at three times density, fails if Flutter reports a single overflow, asserts tap targets of at least 44 pixels, and runs the whole thing again with the system font scaled up.
Bordered cards with no drop shadow, Material 3 underneath, one type scale across every screen. The design system says so in its own do-not list, which is why the app looks the same on screen forty as on screen one.
Custom fields your org defined render and save on the phone the same as on the web. And because the source is MIT, the app you ship can carry your name rather than ours.
The Flutter source, the design system and the 390px viewport test are all in the open repository.
Not under our publisher account today. The repository ships the Flutter source so you, or your hosting partner, build and distribute it under your own developer account. This avoids the per-customer review friction of submitting one binary that talks to many different self-hosted backends.
No. A live connection is required for every action: list, detail, create, edit. The backend runs tenant scoping and custom-field validation on every request, and we deliberately do not buffer offline writes because the resulting merge conflicts would silently corrupt customer data. The trade-off is intentional: correctness over offline edits.
No. The app is designed for personal use. Each install is signed in as one user. For shared devices, a sales floor tablet for example, use the web app instead and rely on browser sessions.
Nearly all of them, and this page has been checked rather than asserted. The mobile ticket detail carries the SLA panel, public and internal comment tabs, custom fields, parent and child links, time tracking, mentions, merge and unmerge, solutions, the macro picker, the close-with-children dialog and the per-ticket approval panel, alongside a dedicated approvals inbox. Ticket analytics ships too, read-only. What is missing is a board, and the web app does not have one either.
Two passwordless paths: Google Sign-In, or a six-digit code emailed to your address, which you type into the app rather than following a deep link. Tokens land in the iOS Keychain or the Android Keystore through the platform secure store and refresh automatically when the access token expires. There is no biometric unlock on top of that.
Clone the repository, point it at your backend, run it on a device. Nothing to buy and nobody to ask.
