Mochi Trip
Last updated 20 August 2026
The short version. There is no account and no sign-in, and we run no server of our own. To write your itinerary, the trip details you enter — including anything you type in the notes box — are sent to Google, whose model writes it. The app also reports anonymous usage measurement: how the app is used, never your destination or the words you type — and a crash report if it crashes.
Mochi Trip is made by PTK Studio. This policy covers the Mochi Trip iOS app and this page. If anything here is unclear, write to hello@ptk-studio.com and we'll answer plainly.
To write a plan, Trip asks for a destination, how many days, what the trip is for, who is travelling, a budget, and an optional notes field you can type anything into. That is the whole of what it asks for. There is no name, no email, no account.
By Google's Gemini model, reached through Firebase AI Logic. Everything listed above — the destination, the length, the purposes, who is travelling, the budget and anything you wrote in the notes box — is sent there in order to write your itinerary. Google's handling of that request is governed by their terms; we do not receive a copy of it and we keep no record of it.
This needs a working network connection, and it is how every plan is written. Settings names the model in use, so you can always see what is answering.
Earlier versions wrote plans on the device itself where the iPhone supported it. That is no longer how the app works: the hosted model writes noticeably better itineraries, and running one engine rather than two is the reason. The trade is stated here rather than buried — you get a better plan, and your trip details leave the phone to get it.
These live in the app's own storage. We have no copy of them and cannot read them. Deleting the app deletes them. You can also delete saved trips individually, or all at once, in Settings.
Trip measures how the app is used, so we can tell whether it works. This is done through Statsig, an analytics service. It is the only thing the app reports on its own, and it is deliberately narrow.
What an event carries: the shape of a request and what happened to it — how many days, which kind of traveller and budget you picked, which of the trip purposes, whether the notes box had anything in it, whether the plan was written on the device or in the cloud, and whether it succeeded, failed or came from the cache. Also which buttons get used: a plan saved, a day rewritten, a place opened in Maps.
What an event never carries: your destination, the words you typed in the notes box, or the name of any place in your itinerary. Those are either written by you or describe where you are going, and they are left out on purpose. A failure is reported as a category — "network", "refused", "decoding" — never as the underlying message, because a model's error text can quote your prompt back.
Who you are in that data: a random identifier the app generates on first launch and keeps, so events from one phone can be counted as one phone over time. It is not your name, your email or your Apple Account, it is not shared with anyone else, and deleting the app ends it. As with any service reached over the internet, Statsig also sees the technical details of the connection itself, including your device model, OS version, app version and IP address.
We still run no server of our own, and there is no advertising measurement of any kind.
When the app crashes, it sends a report through Firebase Crashlytics, so the fault can be found and fixed. This happens whether or not you have accepted anything else — a crash is the app failing, and we would rather know.
What a report contains: where in the code it stopped, your device model and iOS version, the version of the app, how long it had been running, and whether Apple Intelligence is available on the device — because that decides which part of the app was doing the work. It also carries an identifier Crashlytics generates for the install, so two reports from the same phone can be recognised as the same phone.
What it does not contain: your destination, the words you typed, any plan you have written or saved, your name or your email. A crash report describes the app, not the trip.
If any of this changes, this page will be updated before the version that changes it is released.
Statsig, for the measurement described above, on every device.
Firebase Crashlytics, part of Google, for crash reports.
Google, for the reason described above: their model writes your itinerary. The request is made through Firebase AI Logic, which also runs a check that it came from a genuine copy of the app rather than something impersonating it.
Two more are worth naming because they are yours, not ours. Tapping Maps next to a place hands Apple Maps a search for that name — Trip sends no location and learns nothing about what you do there. Tapping Share hands the plan's text to whichever app or person you pick, and their privacy policy takes over at that point.
Settings → Support → Feedback opens a form, shown inside the app. The form is a Google Form, so what you write is submitted to Google as the host of it, and reaches us from there.
It asks for two things: an optional name, and the feedback itself. That is all. There is no sign-in, no account and no email address collected — not by the form and not by us — so a report is anonymous unless you choose to name yourself in it.
The one thing worth saying plainly: a free text box is a free text box. Whatever you type is sent, so please leave out anything you would not want to share. Telling us the destination and what the plan got wrong is the useful part, and none of that identifies you.
Writing to hello@ptk-studio.com instead is always fine. That reaches us by email, which does carry your address.
Trip is not directed at children and collects nothing that would identify anyone.
If this policy changes, the date at the top changes with it, and the page is updated before the version of the app that made the change is released — not after.