Monitoring Performance of Screens in Your iOS App
Article Summary
Revolut's iOS team was drowning in vague performance reports. "This screen is laggy" became a detective hunt through Xcode Profiler with no clear starting point.
Arsen Gasparyan, an iOS developer on Revolut's trading product, built an automated performance monitoring system that measures every screen's lifecycle without manual instrumentation. The solution uses method swizzling and runtime magic to track viewDidLoad, viewWillAppear, and viewDidAppear execution times.
Key Takeaways
- os_signpost integrates with Instruments to pinpoint exact performance bottlenecks in viewDidLoad
- Method swizzling UIViewController.loadView enables automatic measurement across all screen subclasses
- Dynamic function creation at runtime prevents swizzling conflicts between different ViewControllers
- System filters out private controllers and SDK classes to avoid crashes
- Always-on monitoring catches performance regressions before they reach production
The team now has continuous, automated performance tracking for every iOS screen without writing a single line of measurement code per controller.
About This Article
Arsen Gasparyan got vague complaints about performance issues like 'some screen is laggy' without any clear direction on where to look. This forced him to manually analyze everything in Xcode Profiler, which felt like searching for a needle in a haystack.
Gasparyan used os_signpost with Apple's pointsOfInterest category to automatically send execution timing data to the system. He then applied method swizzling on UIViewController.loadView to measure viewDidLoad performance across all screen subclasses at runtime without manual setup.
The automated system removed the need to write instrumentation code for each controller. Now the team gets continuous performance tracking that catches regressions before they hit production, and developers don't have to add measurement code to every screen.