Mobile: PWA first, then native — approvals and reminders on the phone

Why

FlyBot has no phone entry point today (Desktop / web only). Approvals, Agent inbox (#349) and proactive reminders (#353–#355) are weak if the user is away from the laptop. Tracked under the capability-gap parent: #361.

Phased scope

Phase A — mobile web / PWA (first)

Responsive layouts for chat, approvals and Agent inbox.
Installable PWA with web push for: approval waiting, task failed, task finished (Proactive reminders 1/3: event reminders (approval waiting, failed, finished) in app and desktop #353).
Deep links into the card that needs action.
Works against a personal deployed instance (Deployment step 1: official image and one isolated instance per person #352); local-only Desktop is out of scope for push.

Phase B — native or wrapped app

iOS / Android (or a shared wrapper) with reliable push and background delivery.
Biometric (or OS) confirm for sensitive approvals.
Same account and instance as Desktop; no second data store.

Non-goals for now

Full Desktop feature parity on day one (Timeline, face-to-face can come later).
Replacing Deployment step 1: official image and one isolated instance per person #352: the phone is a client of the personal instance.

Acceptance (Phase A)

On a phone browser: approve or reject a held reply without a desktop.
A push (or at least a lock-screen-capable notification where the platform allows) arrives for an approval-waiting event while the app is backgrounded.
UI meets the guidelines in [Feature RFC] Agent inbox board: one place for tasks, approvals and failures (personal first, team second) #349 (truncation, one primary status, no native confirm dialogs where we control the UI).

Open questions

PWA only for Phase A, or also store listing later?
One codebase (responsive web) vs separate native from the start?
How does sign-in work on a phone against a self-hosted instance (Deployment step 1: official image and one isolated instance per person #352)?

Process

Implementation via OpenCode + Codex review; bots do not hand-write code.

Platform suite (iOS / HarmonyOS / Android) tracked in #363.

Folding #363 (Mobile entry suite: iOS, HarmonyOS, Android) into this issue as a duplicate. Its unique content, so nothing is lost:

Three-platform entry suite. One program, three storefronts, shared product contract. Phase A (responsive web / PWA) stays the shared bootstrap so all three can use the product before store apps land.

Platform	Store / channel	Client form (proposed)	Notes
iOS	App Store	Native or wrapped (Phase B)	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 a compatible Android build where allowed	Confirm push and background limits on current HarmonyOS; do not assume Play services

Shared requirements (all three)

Same account and personal instance (Deployment step 1: official image and one isolated instance per person #352); the 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 above).
No secrets in logs; revoking 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).

Acceptance for the suite

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 of platform × (install / sign-in / approve / push) with pass/fail.

Extra open questions

One codebase (Flutter / RN / Kotlin Multiplatform) vs three native stacks?
HarmonyOS: pure Harmony next vs an Android-compatible package first?
Do we require a 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, #352, #349, #353–#355.

Triage on main 7b9e90b, 2026-10-19 ~12:10 Asia/Shanghai: needs-human, not agent-ready. Question for the owner: start Phase A (responsive web / PWA with push)? Push needs a deployed instance (#352), so the order matters.

Triage (maintenance, 2026-10-20 08:59 Asia/Shanghai)

On main bae4128: no PWA manifest, service worker or push. The client CSS has no phone-width layout (its only @media rules are for reduced motion). The web page shell belongs to DSH (dsh web); FlyBot only adds plugins to it. #363's three-platform suite is folded in here (comment above). #352 (deployment) is still open.

Expected behavior: on a phone browser you can skim a chat, press Approve / Reject on a held reply, and open Agent inbox (#349) cards.

Smallest first slice: a phone-width layout (about 400px) for the chat, held-reply Approve/Reject buttons and the Agent inbox. No PWA install, no push and no native app yet. It can be tested now against the running dsh web page.

Details I decided (say if you disagree)

A push or notification never approves anything. It only opens the card in the app, where you press the button. This follows the rule that approvals are explicit UI buttons only.
Push needs an always-on instance, so it waits for Deployment step 1: official image and one isolated instance per person #352. Native apps (iOS / Android / HarmonyOS from Mobile entry suite: iOS, HarmonyOS, and Android #363) get their own issue later.
English UI and the same layout rules as [Feature RFC] Agent inbox board: one place for tasks, approvals and failures (personal first, team second) #349.

Question for the owner
(a) Start the phone-width layout now. Do PWA install and push after #352 step 1, and native later.
(b) Wait for #352, then do layout, PWA and push together.
(c) PWA and push now, against the desktop instance (only works while it runs).
Recommendation: (a).

Owner decision (2026-10-20): Confirmed option (a): first step is mobile-width layout only for chat, approve/reject buttons and the Agent inbox. PWA and push come after #352; native later. Push can never approve directly; it only opens the card, and approval stays on the in-app buttons.

Claimed by maintenance run (2026-10-20 09:54 Asia/Shanghai). Working on branch feat/362-mobile-layout (fork Birfy/FlyBot), developed in parallel with sibling issues; first slice per the Owner decision only.

Minor details decided for step 1 (PR #481, 2026-10-20 11:01 Asia/Shanghai):

Breakpoint 640px, the same one the inbox/memory dialog already uses to go full-screen; wider screens are unchanged.
Held-reply and floating approval cards: Reject / Approve split the card width as 40px buttons, Approve filled with the accent (same look as the app's other primary buttons). Social's hold card gets 40px buttons at that width too.
The floating approval stack and the chat pointers keep clear of DSH's 56px icon rail (DSH collapses the sidebar below 1024px on its own), so the top + and the account stay reachable.
Inbox cards put their buttons on their own row under the text; title and reason wrap to two lines instead of truncating.
Not touched: the shell's own sidebar/rail (DSH owns it), PWA, push, native apps (later steps per the Owner decision).

Fit chat approvals and the Agent inbox to a phone-width screen (Think…

Cleanup: issue closed. Removing stale agent-working and assignee.

Navigation Menu

Repository navigation

Mobile: PWA first, then native — approvals and reminders on the phone #362

Why

Phased scope

Phase A — mobile web / PWA (first)

Phase B — native or wrapped app

Non-goals for now

Acceptance (Phase A)

Open questions

Related

Process

Triage (maintenance, 2026-10-20 08:59 Asia/Shanghai)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Mobile: PWA first, then native — approvals and reminders on the phone #362

Description

Why

Phased scope

Phase A — mobile web / PWA (first)

Phase B — native or wrapped app

Non-goals for now

Acceptance (Phase A)

Open questions

Related

Process

Activity

hsliuustc0106 commented on Oct 18, 2026

Birfy commented on Oct 19, 2026

Birfy commented on Oct 19, 2026

Birfy commented on Oct 20, 2026

Triage (maintenance, 2026-10-20 08:59 Asia/Shanghai)

Birfy commented on Oct 20, 2026

Birfy commented on Oct 20, 2026

Birfy commented on Oct 20, 2026

Birfy commented on Oct 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions