Skip to content
← All apps

SPORTS / VIDEO

Analyze a swing. Know what to practice.

A golf swing analysis app, continuously refined after launch using customer feedback and collected data to improve swing trajectories, analysis and ball tracking.

I independently planned, designed, built and released the app. I am now connecting video review to the next practice session, while continuing to add and refine features. Explore ongoing improvements ↓

SwingForge · iOS · v1.8 · Released

SHIPPED → ITERATING

From reviewing a swing to choosing a drill.

Problem
Video review alone does not tell the user what to practice next. Analysis also needs evidence before its output can be trusted.
Decision
Connect corrections to evidence and drills in development, while evaluating the analysis independently before release.
My implementation
Owned planning, design, development and release of the video-review app; built the development feedback flow and evaluated model candidates.
Delivery and release decision
Video-review app shippedObserve usage through Firebase and customer emails. Keep the new ball-detection candidate in development until real-video and user validation.
Read the experiments ↓

01 / USE

The released video-review flow.

The released version focuses on slow-motion review, visual overlays and side-by-side comparison. Building on that video-review flow, I am developing an experience that connects swing-analysis evidence to the next practice activity.

  1. 01Prepare a swing video
  2. 02Slow down · Step through frames
  3. 03Overlay · Compare side by side
  4. 04Save to the library

Review a swing frame by frame

Slow motion and frame-by-frame playback help inspect a particular moment.

Compare two videos side by side

Add posture and angle overlays and keep comparison videos in a personal swing library.

02 / INTERFACE

Current development: analysis to practice.

A home that leads into practice

Recording, recent swings and weekly practice in one place. Current development build · Korean UI · sample state.

Captured from the current development build on an iPhone simulator, September 2026. Sample video and synthetic test measurements demonstrate the interface, not analysis accuracy or the exact App Store release.

03 / AFTER LAUNCH · IN PROGRESS

Keep learning after release.

After release, I examine Firebase usage patterns for possible friction and receive customer feedback by email. Behavioral data suggests where to investigate; email provides customers’ own descriptions. Separately, the development build includes events for opening analysis and starting or completing practice. Adding these events does not establish real-user conversion through the new drill flow; that validation remains the next step.

Product question: what should the user practice next?

The released app supports reviewing and comparing swing videos. The next product goal is to help users choose what to practice after reviewing a swing.

Implemented: connect feedback to practice

The current development build connects one correction to its measurement, a relevant video segment and a suggested drill. The screens above demonstrate this flow with test data.

Ongoing: refine analysis and add improvements

I continue adding and refining features using customer feedback and collected data, including swing trajectories, swing analysis and ball tracking. Development photo comparisons are detailed below; iPhone video accuracy and increased practice completion remain unverified.

Next validation question

Does connecting a correction to a drill help users start and finish practice? A proposed next step is to compare drill starts among users who viewed feedback, and completions among those who started. Report the period, build version and user counts alongside rates, separating simulator and test activity. Analysis-open events alone do not establish that feedback was viewed. No measured user improvement is claimed yet.

Usage analytics and swing-analysis data serve different purposes. Firebase events help examine product use; they are not evidence of analysis accuracy.

04 / TEST → DECISION

Test the change. Keep what the evidence supports.

As the independent maker, I connect product design, implementation and verification. I used development evidence to select a stronger ball-detection candidate while keeping release gates in place, reject an ineffective crop, and fix skipped input frames.

C / BETTER CANDIDATE · RELEASE HELD

A better development result was not enough to ship.

The baseline missed the ball in half of the 128 development photos. I expanded training and compared the candidate on the same evaluation sample. The checkpoint was selected using validation results, not the development-test score.

Ball localized within 12 pixels · same 128 photos, including misses
BaselineCandidateDecision
64/128104/128Continue research

The candidate still missed 24 photos. The labels had not been independently reviewed, and there were no reviewed ball-absent images to measure false positives. I kept the candidate in a local Debug research path and retained the block on normal distribution.

September 24, 2026 experiment. Saved aggregates, sample manifests, source-code fingerprints and checkpoint identities were audited on 2026-09-27. No model inference or per-photo prediction recount was performed for this portfolio audit. These are development photo results, not iPhone video accuracy or user outcomes.

Sample, selection criteria and separate full evaluation

The two manifests contain the same 128 evaluation records and labels. Filename groups do not overlap between training, validation and evaluation, but independence of golfers and filming sessions has not been established. The detection threshold is 0.5; the comparison uses argmax coordinates and a 12-pixel tolerance. The checkpoint at 6,000 additional updates was chosen by validation localization recall, with fewer incorrect detections breaking ties.

A separate full development evaluation used the final local-centroid decoder: 1317/1637 localized, 319 missed, and 1 detection outside tolerance. It has no baseline result on the same full sample, so no improvement rate is calculated against the 128-photo comparison.

Provider box labels and their XYWH interpretation remain independently unverified. Source: National Information Society Agency / AI Hub, Sports Human Motion (Golf), dataset 65. Raw photos, labels and weights are not published here.

Audit summary and source fingerprints ↗
Earlier experiments: crop rejection and frame-selection fix

A / REJECTED

Cropping the golfer did not improve wrist observations.

The hypothesis was that a tighter golfer crop would improve observations. I compared the full image with a manually selected crop on the same 200 frames.

Frames with both wrist confidences ≥ 0.25
Full imageCropped imageDecision
168 / 200154 / 200Reject crop

2 frames recovered, but 16 regressed. I did not apply the crop to the product. The remaining wrist-observation problem was not resolved by this experiment.

B / FIX IMPLEMENTED

Preserve valid frames at the sampling boundary.

At 30 fps, floating-point rounding made some frame intervals slightly smaller than 1/30 second. A 1-microsecond tolerance, with checks for invalid, duplicate and backward timestamps, preserves the intended input cadence.

Input frames accepted from the same 200 presentation timestamps
Previous ruleCurrent functionDecision
108 / 200200 / 200Keep the fix

Replaying the current Swift function also passed cadence checks at 24–240 fps, a shifted time origin, invalid timestamps and the simulator’s 0.2-second interval. This verifies input selection, not a completed swing analysis.

Test conditions, source records and remaining questions

Verified on 22 September 2026: recorded crop predictions were recounted; the current Swift function was extracted and executed against actual video timestamps. The old comparison rule was reconstructed from the implementation record. Vision inference and the full iOS test suite were not rerun for this portfolio verification.

One development video: shot-tracer-demo.mp4, 1920 × 1080, 30 fps, 200 frames. Crop: normalized bottom-left (0.6, 0.1, 0.35, 0.6). macOS Vision revision 1 on macOS 26.6.2; decoded JPEG input. The source video and each compared record are identified by SHA-256 in the verification file.

These are development results without independent ground truth. Wrist confidence is not position accuracy. Remaining work includes human-reviewed annotations, unseen golfers and sessions, and the iPhone processing path. Processing more frames also requires device performance and thermal checks before drawing release conclusions.

View verification results and source fingerprints ↗
NEXT APP

Mote ↗

A strategy and planning app organizing ideas, goals and tasks as cards.