Selected work
Three programs, one method: measure first, then change one thing.
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 is
written as problem → what I did → measured result, with the metric definition kept
in the text.
Anonymized: client and product names, internal codenames, exact
business metrics, absolute OOM baselines and sample sizes, and exact project dates.
Not anonymized: the problem, the measurement definition, the tooling
category, the role, and the relative change. No client testimonial is published here.
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.
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, a hard image-cache cap tied to physical memory, and
a bounded player buffer released 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 in lab and production; click-to-first-frame from a fixed
replay on a mid-tier device.
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.
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.