Product Delivery

TL;DR

I helped ship Copilot agent sessions in GitHub Mobile as a cross-platform workflow people could actually use away from their desk. The public surface was the refreshed Copilot tab, session list, native session logs, and in-app follow-up actions. My part lived in the production stretch, in implementation review, cross-platform coherence, scope calls, and the details that make an agent workflow trustworthy on mobile. After launch, metrics increased significantly.

GitHub Mobile: Agent sessions without leaving the app

Publicly, this shipped as a refreshed Copilot tab and native session logs in GitHub Mobile. The problem was simple to say out loud, and really hard to get right. People needed to track agentic work, inspect what happened, and take the next action without leaving the app.

Another designer (Hi @oriolson) led the initial direction, and took it on again after. I came in where shipped work usually gets harder, around cross-platform coherence, production behavior, edge cases, and the question of whether the experience still made sense once it was real. I also covered the work end-to-end for a while, kept the quality bar across iOS and Android, and made the scope calls that decided what had to ship for the Staff build vs. what could wait for beta, or the public.

The hard part was the handoff

The work is starting somewhere else, but the user still needs to understand progress, state, output, and what to do next… across multiple surfaces, and platforms.

On mobile that means the product needs to be clear, even with interruption. A session might be running, completed, blocked, or ready for review, and the user might only have a minute. The interface has to answer what changed, whether it's still running, and whether you can act on it right now.

Designing across iOS and Android

iOS and Android shouldn't feel identical, but they should feel like the same product. A lot of my cross-platform design work lives in that gap… for any initiative, feature, or product.

The Copilot tab, session list, logs, and follow-up actions had to share the same mental model across both apps, while the interaction details still behaved like native UI.

Working inside production details

Much of my contribution happened close to implementation. I shipped several production Android, and iOS PRs myself, which established the visual hierarchy for the Copilot tab, agent messages, tool calls, file paths, and inline code. I reviewed production changes, caught issues that only show up once the experience is running, and made focused code changes where that helped unblock the work.

I care most about this part of the work. Once the feature exists in code, you can see whether it actually make sense, whether streamed session logs stay consistent across surfaces, whether loading and empty states explain enough, and whether the product still communicates the right thing under pressure, while Copilot is still evolving around us.

A few smaller calls also shaped what the app felt like every day: I pushed for a cross-platform naming fix so iOS and Android stopped using slightly different vocabulary for the same concepts. Naming drift sounds like a polish issue but it's a product surface: agent tasks reading as different things on the two apps was a trust problem, and internally it made it harder to talk about the work without adding "on iOS" and "on Android" to every sentence. I replaced a hidden nav bar menu with two contextual creation actions, one for chats and one for agent tasks, that respected the current Copilot tier. The menu was a polite way of telling people "we couldn't decide", and contextual actions made the user's next move visible, and easier to reach.

What had to hold up

My focus wasn't adding more surface area, it was protecting the value of the workflow as it moved towards, and through the path to production.

The experience needed clear hierarchy, sensible defaults, resilient states, and enough platform detail to feel like part of GitHub Mobile instead of a feature placed on top of it.

It also helped clarify what GitHub Mobile can own in an agentic workflow. The app doesn't need to become the full development environment, but it can help people track progress, review outcomes, and take the next step from wherever they are.

A demo environment that unblocked the team

I built a dedicated SwiftUI demo environment as a sub-module in our Xcode workspace which the lead designer for this project (hi again @oriolson) picked up to advance other SwiftUI prototypes. The demo wasn't the deliverable, it was infrastructure for the next decision, and more prototype with real data shipped faster because of it.

What changed after launch

Phase one shipped on schedule. In the weeks after launch, daily task creation actions and unique creators both increased drastically across iOS and Android. That tracks with where the additional design-engineering collaboration, polish, and implementation review went, which was the part of the work I was most directly responsible for.

Closing

For agent workflows on GitHub Mobile, the workflow only holds if the next step stays legible while the agent is still running.

My part was making the workflow trustworthy on a phone, without turning the phone into a smaller version of github.com.