Mobile burn book: what we need to ship iOS to 100 externals

This is a brain dump rather than a triaged list. Sections are roughly grouped by theme. Feel free to break items out into their own issues as they get picked up — check them off here as they land.

The big open question

• Uhh, at some point we should probably actually read the code huh
  • What if no tho 🤔

Critical path (on us even if upstream)

• Tasks take a gorillion years to start, and get stuck in failed states frequently. This is a PHAI thing, but we can't drop a broken app and shrug and say "well not our department." On our critical path → our responsibility.
• Connecting to cloud runs also takes a gorillion years.
• Bug: "Local" badge in the upper right corner is wrong on cloud runs — these are cloud, not local.

Observability & resilience

• Add PostHog error tracking and session replay to the mobile app. New project? Probably yes, but feature flags etc. are a complication to sort out.
• Would be cool if we can keep connecting when the app is backgrounded.
• Offline mode (queue tasks).
• Watch app:
  • Actions should wake up the app.
  • Permissions popup (via push when something needs my attention).

Tasks & home view

• Swap default view to "new task"; task list only lives in the left panel.
  • Stretch: dedicated tasks view that supports sorting and searching — probably post-release.
  • Recommended tasks on the home screen (feels like part of this).
• Archived tasks should disappear from the sidebar.
• Archived tasks (the dropdown) should live in the sidebar.
• The "filter & sort" icon on the tasks list page only sorts — I want to be able to filter by project.
• Better filters in the task list (e.g. sliding filters along the top, with a "new task" button up top).
• Render plan as markdown.
• Stop icon when a task is running in dark mode needs a more visible border.

Automations & skills

• Automation repo picker UX: scroll into view, close the dropdown after selecting.
• Move automation config to above the skill — we expect people to mostly manage skills elsewhere, and it's a giant block of text.
• Use the same repo picker as the new-task UI for automations, and add the other choices (model etc.).
• Skill "tagging" / categories, so we can:
  • Pre-create a number of "automation" skills for every team on signup.
  • Not show clearly-interactive skills as templates for automations.

MCP apps (owner: Tom Owers)

• Don't think this actually works on mobile — needs testing.
• We maybe rip our MCP config (hot take: all config should be desktop for now; positioning mobile as clearly a side-car, not the main event — saves us headaches and keeps things simple).

UI / UX polish

• PR UI is ugly AF on iOS. Pills not roundrects is The Way IMO, but broadly it needs a serious pass.
• Love for the login screen.
• Show app version somewhere in settings.
• Drawer needs some gestures.
• Bottom sheets dimmer — could be native sheets?
• Some weird nav in places.
• Too much space at the bottom of the new-task splash screen above the chat box + repo selector.
• Bit better UX for the bottom bits of the chat box.

Visualizations (stretch / sicko mode)

• Visualizations for questions we can answer with pictures (Claude Code native app drawing).
  • Not sure we need this TBQH; sicko mode but a stretch goal.

Post-hackathon follow-ups

• Change the automation/task/taskrun model to display task runs in the UI, not tasks. Right now an automation that runs overrides the existing task instead of creating a new one.
• To the MCP store: add an "automation" concept and only display those on the "new automation" page.

Maybe

• Onboarding + settings: first-run flow (3–4 screens), expanded settings (theme, notification prefs, project switching), offline message queuing, and general quality-of-life.
• Share tasks logic:
  • Share to open in the PostHog Code mobile app.
  • Share to open in the PostHog Code desktop app.
  • Share to open in PostHog Cloud.

The issue names no files, tests, or entry points and is explicitly a brain dump. Start by splitting one checkbox into a focused issue and locating the relevant mobile-app entry point; define a single acceptance criterion and test before implementation. Nothing here establishes what overall completion looks like.