Patterns
Permission States
Every permission is absent-but-invited. The app is fully usable without Google, Drive, or a wearable — each denied permission simply leaves its features in an invited state with a contextual route to grant it.
Rules
- 01No sign-in: full app works locally; auth banner offers sync; toasts say “Saved locally ✓”.
- 02Drive denied: sync dot error; data persists in localStorage.
- 03No wearable / Health Connect: wearable features appear as “Sync” assumption actions — no nagging, no locked screens.
- 04Demo mode: read-only overlay — FAB inert, edits no-op, persistent DEMO banner.
Examples
Wearable invitation
The Cycle Overview drawer lists “Sync wearable” as an assumption action — the permission ask appears exactly where its value is visible.
Anti-patterns
What breaks this pattern
- Permission walls at launch
- Re-prompting on every session
- Locked-feature padlocks
Do
- ·Ask in context, at the moment of value
- ·Keep denied features visible and useful-adjacent
Don't
- ·Gate the dashboard on any permission
- ·Use system-style scare dialogs