Repository navigation
Mobile entry suite: iOS, HarmonyOS, and Android #363
Description
Why
#362 covers mobile as PWA-then-native. We also need an explicit three-platform entry suite: iOS, HarmonyOS (鸿蒙), and Android. Daily life and work in our user base spans all three; shipping only one store leaves a large slice without a first-class entry for approvals, Agent inbox (#349) and reminders (#353–#355). Parent tracking: #361.
Suite shape
One program, three storefronts, shared product contract:
| Platform | Store / channel | Client form (proposed) | Notes |
|---|---|---|---|
| iOS | App Store | Native or wrapped (Phase B of #362) | Push via APNs; biometric for sensitive approve |
| Android | Play (and optional side load for self-host) | Native or wrapped | Push via FCM; biometric / device credential |
| HarmonyOS | App Gallery / 鸿蒙分发 | Native Harmony or compatible Android build where allowed | Confirm push and background limits on current HarmonyOS; do not assume Play services |
Phase A of #362 (responsive web / PWA) remains the shared bootstrap so all three can use the product before store apps land.
Shared requirements (all three)
- Same account and personal instance (Deployment step 1: official image and one isolated instance per person #352); phone is a client, not a second source of truth.
- Core loops first: chat skim, approve / reject, Agent inbox cards, reminder deep links.
- Sign-in that works against self-hosted instances (open question under Mobile: PWA first, then native — approvals and reminders on the phone #362).
- No secrets in logs; revoke auth removes access immediately.
- UI guidelines from [Feature RFC] Agent inbox board: one place for tasks, approvals and failures (personal first, team second) #349 apply on small screens.
Suggested child issues (open when starting work)
mobile-ios: App Store pipeline, APNs, TestFlight.mobile-android: Play pipeline, FCM, internal testing track.mobile-harmony: HarmonyOS target, push path, App Gallery or alternative distribution.- Keep Mobile: PWA first, then native — approvals and reminders on the phone #362 as the product/PWA umbrella; this issue is the platform suite umbrella.
Acceptance for the suite (not a single app)
- Documented build and release path for each of the three platforms.
- At least one internal test build per platform that can approve a held reply against a Deployment step 1: official image and one isolated instance per person #352 instance.
- Push (or platform-best-effort notification) works for approval-waiting on each platform where the OS allows.
- A short matrix in this issue: platform × (install / sign-in / approve / push) with pass/fail.
Open questions
- One codebase (e.g. Flutter / RN / Kotlin Multiplatform) vs three native stacks?
- HarmonyOS: pure Harmony next vs Android-compatible package first?
- Do we require store listing for v1, or is sideload / enterprise enough for the team pilot ([Team] Verify the real two-human team pilot end to end #58)?
- Who owns certificates and store accounts?
Related
#361 (gap parent), #362 (PWA / native phases), #352, #349, #353–#355.
Process
RFC and tracking here; per-platform implementation via OpenCode + Codex review.
Activity
Birfy commentedon Oct 19, 2026
Closing as a duplicate of #362. The iOS / HarmonyOS / Android platform table, shared requirements, suggested child issues, suite acceptance and extra open questions were copied into a comment on #362. Please continue there.