Skip to content

Native iOS app #113

Description

@karngyan

Why

Three things the PWA cannot do, in rising order of importance:

  1. Push without the add-to-home-screen ceremony, and richer notification actions.
  2. Live Activities and the Dynamic Island. Cursor tracks up to eight agents there and it is the best notification story in the field. A glanceable "agent still running / agent needs you" on the lock screen is exactly flue's shape.
  3. Pairing trust that does not depend on JavaScript served by the relay. docs/FOLLOW-UPS.md item 11 names a native client as one of the two real fixes: keys live in the app, the relay is back to carrying ciphertext it cannot read or influence, and a hostile relay origin loses its one good move.

Rough scope

  • Open source Swift app, same wire protocol and Noise IK handshake, QR pairing against the daemon key.
  • Sessions list, terminal view (SwiftTerm to start, ghostty if iOS embedding ever lands), the needs-you queue, and the composer.
  • APNs push.

The honest problem

APNs requires the app publisher's key on a server, so fully self-hosted push for a store-distributed app is not possible. Options: a tiny stateless push bridge run by the project (content-free pings only, documented plainly), or store distribution without push and sideload/TestFlight variants with the user's own key. This is the one place the no-hosted-service line gets genuinely hard, and the issue should not pretend otherwise.

Sequencing

Biggest lift on the roadmap. Decide after the web push arc (push notifications, needs-you queue) ships, because that covers a large share of the value and will teach us which notifications matter.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestepicLarge feature. Decide and break down before building.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions