Case studies
Three performance programs
These three programs come from full-time iOS platform roles held between 2020 and
2026. They are employment track record, not paid consulting engagements. Each one is
written as problem → what I did → measured result, with the metric definition and
measurement method kept in the text.
What is anonymized: client and product names, internal codenames,
exact business metrics, absolute OOM baselines and sample sizes, and exact project
dates. What is not anonymized: the problem, the measurement
definition, the tooling category, the role, and the relative change. No client
testimonial is published on this page.
01
OOM and memory on a top short-video platform
iOS · short-video and live app · consumer scale
Context: iOS architect · 30+ iOS engineers platform-wide · employed role 2021–present. Measurement: in-house per-screen footprint sampler; the last run's scene stack, footprint, and thread count persisted and reported on the next launch; OOM exits per session on low-tier devices. Time span: multiple releases; exact measurement window withheld.
Problem
Out-of-memory exits were rising faster than crash reports suggested. The team could
see that a session had died, but not which screen was open, how much memory it held,
or which asset pushed it over the limit. Image caches, player buffers, and editor
retain cycles all competed for the same budget.
What I did
-
Made memory attributable: sampled footprint per screen, persisted the last run's
scene stack, footprint, and thread count, and reported it on the next launch, so
every OOM had a scene and a number attached.
-
Replaced guesses with budgets: per-device image resolution tiers, thumbnail
decoding before full decode, and a hard image-cache cap tied to physical memory.
Bounded the player buffer and released it on pause and exit.
-
Worked the leak list: editor controllers held after dismissal, gift assets never
released, rounded-corner image leaks. Each fix shipped behind a switch and was
verified against a fixed replay.
Result
−3.18% relative OOM rate on low-tier devices
87.9 MB decoded images removed from one startup path
18 → 1.7 MB gift image memory
What this does and does not say: −3.18% is a relative change in OOM exits per session on low-tier devices, not a 3.18-point drop. The absolute baseline, sample size, and exact measurement window are withheld under client confidentiality.
Takeaway: OOM is usually a budget problem, not a single bug — make it attributable
first, then set limits.
02
First screen for a live-streaming platform
iOS · live streaming · viewer path
Context: iOS architect · platform iOS team · full-time platform roles 2020–2026. Measurement: segmented first-screen instrumentation (app preparation, player pre-render, stream pull, surface wait); the same definition used in lab and production; click-to-first-frame from a fixed replay on a mid-tier device. Time span: multiple releases; exact measurement window withheld.
Problem
Entering a live room felt slow even when the dashboard said it was fine. First
screen was measured as one number, so app preparation, player pre-render, and the
stream pull were mixed together. No one could tell which segment to cut, and
business setup competed with playback for the same main thread.
What I did
-
Split the path into segments — app preparation, player pre-render, stream pull,
and surface wait — and instrumented each one, so lab runs and production used the
same definition.
-
Decoupled stream pull and rendering from business UI: started the player before
the transition, reused player instances between rooms, lazy-loaded comments,
gifts, and rank panels, and staged playback separately from business content.
-
Kept the critical path short on low-tier devices by deferring non-critical SDKs
and preloading until after first frame, with extras gated by device class.
Result
−166 ms total first-screen time (−18%)
−162 ms pre-render time (−73%)
732 → 126 ms click-to-first-frame in the lab (−82%)
Metric definition: first screen runs from room entry to the first rendered frame. The lab figure is from a fixed replay on a mid-tier device; production figures use the same segment definitions. Absolute production baselines are withheld.
Takeaway: users feel the critical path, not the average — break the first screen into
segments, then move work off it.
03
720p at 30fps on a live-streaming platform
iOS · live streaming · playback and overlays
Context: iOS architect · platform iOS team · employed role 2021–present. Measurement: release build, fixed 720p30 room replay, one variable toggled per run, ten runs per case, percentiles instead of averages; GPU cost measured against a 12% baseline. Time span: multiple releases; exact measurement window withheld.
Problem
Moving live rooms to 720p at 30fps raised GPU and CPU pressure. Overlays —
comments, gifts, floating hearts, gift slots, comment aggregation — shipped feature
by feature, and nobody knew which one was eating the frame budget. On low-tier
devices the result was dropped frames at the exact moment a room got busy.
What I did
-
Built a repeatable 720p30 harness: release build, fixed room replay, clean
background, one variable toggled at a time, ten runs per case, and percentiles
instead of averages.
-
Measured each overlay's GPU cost against a 12% baseline, with and without gift
rendering, to isolate cost rather than estimate it.
-
Turned the measurements into a per-feature budget and a degradation ladder: cap
animation frequency, lower asset resolution, and disable the heaviest effects on
low-tier devices, with an independent switch per feature.
Result
+21 points GPU cost with all overlays on, against a 12% baseline
+10 / +8 / +7 points for gift slots, comments, floating hearts
+15 points for the four overlays measured together
What this does and does not say: this is a cost measurement, not a claim that GPU use fell. The deliverable was a per-overlay budget and a device-tier degradation ladder. Per-device frame-rate outcomes are withheld under client confidentiality, so I do not claim that 30fps was held on every low-tier device.
Takeaway: at 30fps, overlays are part of the performance budget, not decoration.