FaultOrdering

Why it's ranked here

The approach targets a specific source of startup overhead with direct runtime observations rather than guesses. Its narrow focus is valuable, but adoption requires linker configuration, a dedicated UI test, an extra build, and careful matching of production compiler settings.

What's good

It supports simulator and physical-device collection, which matters when startup follows device-specific code paths. The setup closure can establish a representative signed-in state before measurement. Duplicate symbol names receive special handling, and unobserved symbols remain in the generated output after the measured set.

Tradeoffs

This is an invasive optimization workflow, not a drop-in profiler. The app needs a generated link map, the test target needs bundled access to it, and physical-device runs require embedding the dynamic framework. Collection also uses fixed waiting periods and several forced failures, making errors potentially slow and abrupt.

How to use it well

Use it when an iOS team already has reliable XCUITests and wants launch-sensitive linker ordering based on a representative production build. Run setup through the common signed-in journey and collect on hardware when device-only frameworks change startup. It does not measure broader performance problems or replace startup profiling.

Observed

License

MIT License

Primary language

Swift, with Objective-C++ and Objective-C runtime instrumentation

Installation

Swift Package Manager package added directly to an Xcode project

Interface

XCTest library API that emits an XCTAttachment

Platform

iOS 16 or later; setup documentation requires Xcode 16.2 or later

Package products

FaultOrdering dynamic library and FaultOrderingTests library

Dependencies

SimpleDebugger 1.0.0 and FlyingFox 0.16.0 are pinned Swift package dependencies

Included example

Repository contains a SwiftUI demo app and an XCUITest integration example