Overview › Performance

Performance

Heavy viewDidLoad work, unbounded image loading in cells, no instrumented dashboard.

2 findings in this category · iOS
62
SCORE

Summary

Several concerns: heavy synchronous work in viewDidLoad across multiple controllers, repeated UIImage(named:) in cell configuration, polling timers (cookie listener every 5s), and no Instruments-based dashboard published for the team.

Findings

HIGH

Heavy work in viewDidLoad

StoreListTableViewController, GenericWebBrowserViewController, GridMenuController all do data initialization in viewDidLoad. Cold-launch perception suffers.
Recommendation: Move to Task { … } or defer to viewDidAppear; show a skeleton state while loading.
HIGH

Repeated UIImage(named:) in cellForRowAt

Each scroll cycle re-decodes the same asset. Visible scrolling jank on dense lists (Savings, Tab bar).
Recommendation: Cache UIImage references at class scope; precompute in a static let. Asset catalog images cache automatically but dispatch to the right thread.
HIGH

5-second polling timer in CookiesManager

Repeating timer drains battery and CPU. If never invalidated, it runs for the full app lifetime.
Recommendation: Replace polling with WKHTTPCookieStore observer; if polling is unavoidable, throttle to 30s and back-off.
MEDIUM

No Instruments-based perf dashboard

Without periodic profiling runs, regressions go unnoticed.
Recommendation: Add a quarterly Instruments review (Time Profiler, Allocations, Leaks). Track cold start with os_signpost in application(_:didFinishLaunchingWithOptions:).
LOW

Lazy initialization opportunities

Properties built in init that are only used after first interaction can be lazy var.
Recommendation: Convert eager initializations on hot ViewControllers to lazy; measure with Instruments.

Findings in this category

2 shown
Costco iOS · Code Review Report · Generated 2026-05-07 · 88 machine-curated findings