Case study · Native iOS app

Every sideline app wanted my data and an account, so I built a native one that keeps everything on the phone.

A native iOS app for coaches to track games: fast to set up, minimal during play, and with data the coach controls.

Role: Designer and developer
Stack: SwiftUI
Status: Work in progress, in active use this season

NativeSwift with local storage and no network dependency
SoloDesign and implementation by one person
In useTested on a real sideline, in real game conditions

Step 1 · Context

Pen and paper is fast but leaves nothing useful, and third-party apps own your data.

Coaching a youth soccer team generates a surprising amount of data: scores, substitutions, player minutes, goals, assists, saves, and cards. Capturing it is not the hard part. Every existing option forced a tradeoff I was not willing to make. Third-party apps are convenient, but they require accounts and are built for organizations, not individual coaches.

Opportunity
How might a coach track a whole game with one thumb, and keep the data?

New game roster screen — Set the roster: starters and substitutes

New game setup screen — Add game info: team size, location, date, and time

Step 2 · Key decisions

I chose Swift and local storage because a sideline app has a performance contract: launch instantly, respond without lag, never drop data.

A PWA or React Native wrapper would have been faster to build, and I have shipped both. Native with local storage satisfies all three requirements, with no sync, no account to authenticate, and no API that might be down at kickoff.

Every decision went through one person: me.

The constraint clarified scope. Without a backend, multi-device sync and shared rosters are off the table, and knowing what the app is not made it easier to build what it is.

The core design problem is attention. During a live game a coach is watching players, calling substitutions, and talking to parents, so the app gets a glance and a thumb tap.

Pregame

Setup handles the overhead up front: opposition, date, location, half duration, and roster selection. A Game or Scrimmage toggle keeps the history honest.

Scoreboard and quick actions

The two largest tap targets are Team Goal and Opponent Goal. Correction actions are present but smaller and lighter, so they are harder to hit by accident.

Players and activity

Tapping a player logs goals, assists, saves, shots, and cards. Each action is timestamped and tied to the half, so the post-game summary reads as a timeline.

Step 3 · Final design

A live game screen built for a glance, and substitutions that match how they really work.

Live Game screen showing scoreboard, timer, Quick Actions, and player list

Mid-game substitutions have a distinct “substituted out” state, separate from bench status, because a player who comes off is not the same as a player who never started. That distinction keeps per-player stats accurate.

View a player's stats and position before substituting — View stats and position before substituting

Substitutes cannot accidentally have statistics assigned — Substitutes cannot accidentally have stats assigned

Who subbed in and out by half — See who subbed in and out by half

Step 4 · Impact

In use this season, with per-player stats informing lineups and substitution planning between games.

As a coach, historical information shapes how I plan practices, set lineups, and choose strategy.

Historical game data — History, with key info front and center

Player-by-player stats for a game — Zoom into any game for player-by-player stats

Real use has mostly surfaced sequencing. The move from pregame setup into the live view needs less friction, and the post-game summary is still being refined. Those are the next iterations, and an App Store release is planned once the rough edges are resolved.

Previous Case Study All Case Studies