Fitnit · discovery
As of v1.149.0 you can say “Hey Siri, log a workout in Fitnit” and it works — no setup, app closed, answer in about a second. Nothing inside Fitnit says so. This board is about the general problem that sits under that: an app with thirty features and one person who came to do one thing. Three places a tip could go, the mechanism that stops the next ten features fighting over the same moment — and the arithmetic that says none of it is the first thing to do.
The instinct with an undiscovered feature is to find somewhere to put it — a banner, a tour, a “what’s new” sheet. That treats attention as if the constraint were room on the screen. It isn’t. The constraint is how many times you can interrupt someone before dismissing becomes a reflex, and that budget is spent across the whole app, not per feature.
Once the reflex forms it is permanent, and it takes every future message down with it — including the ones that would have mattered, like the paywall, the rating ask, and the push permission. So the question is never “where can this go?” It is “is this worth one of the few interruptions we get?” — and something has to be able to answer no.
A tour shown to someone who opened the app to log a banana is noise. The same sentence shown immediately after they typed that banana in by hand is an offer, because they have just done the slow version of the exact thing. That is the whole rule: teach a feature at the moment it would have saved work, to the person who just did the work.
Which means the trigger is never “on launch” or “on the third session”. It is evidence-based — this person has now logged food by hand three times — and it retires the moment it is acted on or dismissed.
A · recommended — after the save
Fires on the third hand-typed meal, not the first — someone still learning the app has no friction to relieve yet. Dies permanently on dismiss, or the first time they use Siri.
B · Apple’s own tip view
SiriTipView(intent:) — roughly one
line of SwiftUI, and Apple keeps the phrasing correct as the OS changes. Fixed height and
full width, so it is the documented Host exception. You do not control the
copy, and it cannot say why you are seeing it.
C · a place to look it up
Costs zero interruptions and teaches nobody on its own — but it is where someone goes when they half-remember the feature exists, and it is the page a support reply can link to. Cheap. Build it whatever else happens.
If each feature decides for itself whether it deserves a tip, every feature says yes — that is what it is like to be the person who built it. The fix is structural: a single registry where a tip is data, and a scheduler that is allowed to refuse.
The rules that matter are the refusals: one tip per session, one per three days, twice in a lifetime, and never again once dismissed or once the feature has been used. A tip nobody acted on twice is a tip that is wrong, and a third showing does not fix wrong — it just spends the budget.
Everything above is right and almost none of it matters yet. Here is the last 90
days of real logging, straight out of history_entries.
So the tip in mockup A — the best-designed, best-timed message on this page — would be seen by about nineteen people a quarter, and only the fraction of those who reach a third hand-typed meal. Meanwhile:
In-app discovery is eighty times smaller than store discovery right now. That is not an argument against building the tips system — it is an argument about order, and about what you should expect it to do this quarter, which is nothing measurable.
| What was measured | Result | What it means for this feature |
|---|---|---|
| Food entries by source, 90d | 98 manual 64 camera 8 voice |
Typing is still the most common way a meal gets logged, so the trigger moment in mockup A is real — it just does not happen often. |
| Meals logged more than once by the same person | 3 titles 1 person |
The “log my usual breakfast” path — instant, offline, no AI credit — has almost nothing to match against yet. Today the feature leans on the USDA lookup and the AI estimate, which are the slower and costlier halves. |
| Workout entries, 90d | 310 rows 40 people |
Twice the reach of food. If only one tip gets built, the moment after a hand-entered workout is the bigger audience — which is the opposite of what seemed obvious before the query. |
Subtitle, one screenshot, and the what’s-new text. “Log meals and workouts by voice” is a real differentiator against Hevy and Cal AI, and it is the only surface with an audience big enough to notice. Existing users read what’s-new; new ones read the subtitle.
One PostHog event at the drain, tagged by kind, and one when a tip is shown or dismissed. Adoption is currently unmeasurable, which means every future conversation about this is a conversation about opinions.
Build the registry and the refusals now, while there is one tip in it. Retrofitting a budget after ten features have each shipped their own banner is a much worse job, and by then the dismiss reflex has already formed. Ship it with the Siri tip and the Voice & Siri settings row as its first two consumers.
The most expensive item, aimed mostly at people who have not installed, where a screenshot does the same job for a fraction of the effort. Worth revisiting once the numbers in step 2 show that people who find voice logging keep using it. A video for a feature with poor retention just buys churn faster.
v1.149.0 · Siri intents shipped, tips system not builthistory_entries, 90 days to 8 September 2026, deleted rows excluded