I took over a 50,000–60,000-line React Native codebase with no documentation and a storage bucket that exposed every user's photos. I fixed the exposure in my first week, shipped a new measurement tool inside the existing code, then led the native iOS rebuild: 581 Swift files, about 104,000 lines, and 303 SwiftUI views.
- 01Took over a 50,000–60,000-line React Native app with no documentation.
- 02Found every user's photos publicly readable and fixed it in the first week, before any feature work.
- 03Shipped a new measurement tool inside the legacy app to show the codebase could still move, which earned the rebuild.
- 04Led the native iOS rebuild: 581 Swift files, about 104,000 lines, 87 screens on one design system.
- 05Wrote the scoring engine to Boone and Crockett rules for a dozen species. 5,000+ hunters use it.
Timeline
Aug 2025 → present · Native rebuild Nov 2025
Role
Lead Engineer & Designer
Technology
Swift, SwiftUI, Firebase, Cloud Functions
Platform
iOS native
5,000+
Production users
104K LOC
Native Swift codebase
15× zoom
Coordinate-locked precision
The Redesign
The same screen, before and after the rebuild
The legacy React Native app on the left, the native SwiftUI rewrite on the right.
BeforeLegacy · React Native
AfterNative · SwiftUI
The Product
The Product
HornScore is a hunting app for serious hunters. Users photograph trail-cam footage, field-judge antler measurements using anatomical references, calculate official scores adapted from Boone & Crockett methodology, share scores with a community, and access species-specific guides.
The audience invests in premium equipment and expects the software to match. This is a production app with 5,000+ users.
The App
87 screens built from one design system
Every flow in the production app (feed, scoring, field judging, guides, and community) uses the same design tokens. The steps below follow the three scoring tools, recorded in the app, and the scoresheet they produce.
01 · HornMatch
HornMatch estimates a score by comparison.
You compare your animal with already-scored animals and mark it bigger, smaller, or similar. Each answer narrows the range. In this recording, five swipes take the estimate from 103–271 inches to 189–198.
Live · HornMatch
- Start103–271″
- Swipe 1185–271″
- Swipe 2185–229″
- Swipe 3185–209″
- Swipe 4189–201″
- Estimate189–198″
Live
- Start–
- Swipe 1–
- Swipe 2–
- Swipe 3–
- Swipe 4–
- Estimate–
02 · HornTrace
HornTrace measures directly on the photo.
You set a known reference, then draw along the tine. The app measures the line against the reference as you draw and enters the result in the scoresheet.
Recorded · HornTrace
- Reference3⅜″
- Tracing2⅞″
- Line5⅞″
- P1 · Right5⅞″
Recorded
- Reference–
- Tracing–
- Line–
- P1 · Right–
03 · HornCalc
HornCalc completes the scoresheet.
Each part is measured against reference photos of scored animals. One tap copies a side's measurement to the other side, and the total updates with every entry.
Recorded · HornCalc
- Total72⅞″
- Prong · Left—
- Entered4⅞″
- Same L/R4⅞″
- Total82⅝″
Recorded
- Total–
- Prong · Left–
- Entered–
- Same L/R–
- Total–
04 · Harvest breakdown
The full scoresheet sits behind every score.
Mass, length, and point measurements, in a simple or advanced view, so anyone can see how a score was reached.
Six onboarding screens
New users see these before signing up. Scroll sideways to see all six, or tap one to enlarge it.
Where It Started
Where the codebase stood when I joined
In my first week, before building any features, I audited the repository and wrote up the findings for the founders. These were the main ones.
Codebase audit · week one
50–60K
Lines of undocumented React Native
3
Half-built versions of the app, in parallel
0
Tests, docs, or versioning
2–5K
Lines in a typical file
The security finding
Every user's photos were public.
The Firebase storage bucket was publicly readable: trail-cam photos, hunting locations, and personal images, open to anyone with the URL. I documented the exposure, wrote proper access rules, and verified the fix before touching anything else.
BeforeStorage accessPublic, open to anyone with the URL
AfterStorage accessOwner-only rules, verified
Fixed in week one, before any feature work.
Phase 1
Phase 1: a new tool inside the legacy app
Before proposing a rebuild, I shipped the Line Reference Tool inside the legacy React Native codebase. I wanted to show that substantial features could still ship in the existing code, on schedule, without breaking anything.
That first version measured straight lines only: you calibrate against an anatomical reference, then draw. Delivering it is what earned the trust to propose the rebuild.
The original Line Reference Tool in the legacy app (straight lines only).
Phase 2
Phase 2: the native rebuild
I started the rebuild on November 6, 2025, in native Swift and SwiftUI. Today it is a ports-and-adapters architecture: MVVM screens, a core of use cases and repositories with no vendor code in it, one place where every dependency is wired, and a design system meant to scale. I was the only engineer on it.
581
Swift files
across the repo
104K
Lines of Swift
production code
303
SwiftUI views
156 feature-specific
39
Domain entities
modeled and validated
87
User-facing screens
across 12 feature modules
5
Backend integrations
Firebase, RC, Amplitude, Sentry, FB
The shareholder progress report rated technical risk as low. The remaining work is feature development, with no further re-architecture planned.
Architecture
A core that doesn't know what it's plugged into
The app is built as ports and adapters. Scoring rules, feed logic, and every use case live in a core package that imports nothing from Firebase, RevenueCat, or Sentry. The core talks to the outside through 82 small protocols, the ports, and an adapter on the other side of each one does the real work.
Pick an action and follow it through. Then take the phone offline, or switch to the test doubles, and see what changes.
HomeScreenV2The home screen asks for the feed.
- 0
- Vendor imports in the core
- 276
- Swift files in the core
- 82
- Ports
- 48
- Use cases
- 1,575
- Core tests, no simulator
Type names, paths, and offline behavior are from the app's source. Subscriptions, error reporting, and analytics plug in through ports of their own in the same way; they're left off the drawing because none of these four actions pass through them. Sign-in, the paywall, and account settings still run on the older wiring and are the last pieces being moved over.
The Unified Tool
Straight and curved measuring, merged into one tool
The legacy app had separate modes for straight and curved measurements, and users had to know which one they needed.
The rebuild replaces both with a single canvas state machine. The first two points calibrate against an anatomical reference, and adding more points turns the line into a curve. There is no mode switch.
In code, it is a seven-state enum with a transition function that advances automatically. The old states remain, marked `// Legacy — should not be entered in unified flow`.
How points stay locked to the photo
Points stay on the antler while the user pans and zooms to 15×. That depends on two transforms between canvas space (image pixels) and screen space (the rendered SwiftUI view). Every touch, drawn point, and hit-test goes through them.
From FieldJudgeScoringViewModel.swift (2,089 lines), which holds the coordinate math.
swift
func screenToCanvas(_ screenPoint: CGPoint, viewSize: CGSize,
totalScale: CGFloat, totalOffset: CGSize) -> CGPoint {
let center = CGPoint(x: viewSize.width / 2, y: viewSize.height / 2)
return CGPoint(
x: (screenPoint.x - center.x - totalOffset.width) / totalScale + center.x,
y: (screenPoint.y - center.y - totalOffset.height) / totalScale + center.y
)
}The curve is a Catmull-Rom spline whose length is summed over 200 intervals per segment, recomputed in real time as points move. The 44pt tap threshold is converted to screen space for hit-testing, and stroke width scales inversely with zoom so lines stay visible without thickening.
Design System
The design system came before the features
I built the design tokens before any feature screens: adaptive light and dark colors, semantic surfaces, a brand color that adjusts to the color scheme, and spring curves that match the native iOS sheet animation. Every screen in the app uses this file.
DesignSystem.swift · 586 lines
01 · Color
50+ tokens
RGB(0.745, 0.518, 0.365)
Brand primary
#065767
Brand accent · Light
#1E92A8
Brand accent · Dark
Adaptive
Surface · Dark
02 · Type
20+ sizes
Display 64HornScore
Title 32Field judge accurately.
Body 18Score trophies the right way.
Caption 12ANTLER POINTS · 0.12EM
03 · Spacing
25 tokens · 4pt grid
4pt
8pt
12pt
16pt
20pt
24pt
32pt
48pt
64pt
50+
Color tokens
25
Spacing tokens
20+
Type sizes
40+
Frame sizes
DesignSystem.swift: 586 lines, dark-mode aware, used in 165 production files.
The Stack
Infrastructure set up before the UI
Authentication, analytics, crash reporting, and subscriptions were integrated and tested before I built any feature screens.
Firebase
Auth, Firestore, Storage
Cloud Functions
TypeScript · FCM, provisioning
RevenueCat
Subscription billing
A
Amplitude
Product analytics
Sentry
Crash & error reporting
Sign in with Apple
Nonce-based OAuth
Google
OAuth · auto-login
Facebook
OAuth · email verification
Working Together
If your business runs on an app like this
The apps businesses depend on usually carry far more than one feature: a feed, photo and video uploads, tools people use out in the field, offline access, subscriptions sold through the App Store and the web, and analytics that show what's working. If your app has that many moving parts, I'd take the same approach I took here. In the first week I audit the codebase for security and architecture risks. While we plan, I ship improvements inside the code you already have. I recommend a rebuild only if the findings support one, and if they do, you get one person who designs the screens, writes the Swift, and owns the backend behind it.