// the take
LifetimeTracker is a runtime debug overlay for iOS/Objective-C and Swift apps that flags when more instances of a class are alive than expected, catching retain cycles as you use the app instead of after the fact. It's aimed at iOS teams who want leak detection baked into day-to-day QA rather than relying on sporadic Instruments sessions.
Tracks lifetimes by manual counting rather than objc runtime introspection, so unlike FBRetainCycleDetector it actually works on pure Swift types with no bridging tricks. Integration is a single protocol conformance plus one trackLifetime() call, and the optional Danger script enforces that call gets added in every new ViewModel/ViewController PR. Grouping with a separate groupMaxCount lets you cap a family of related subclasses together instead of tuning thresholds per class, which fits polymorphic VC/VM hierarchies well. The accessibility identifier on the summary label makes it scriptable from UI tests, so leak detection can be asserted in CI, not just eyeballed.
Detection only fires for classes you've explicitly annotated with LifetimeTrackable and a trackLifetime() call, so it silently misses leaks anywhere you forgot to instrument - the opposite of the automatic detection the pitch implies. It tells you a count exceeded maxCount, not which reference is holding on, so you still need Instruments or the Memory Graph Debugger to actually find the retain cycle. The whole UI layer (bar/circular dashboard, UIViewController-based list) is UIKit-only with no SwiftUI story, which is a real gap for any codebase that's moved its screens to SwiftUI. maxCount is a static guess per class; in screens with legitimately variable instance counts (e.g. cell reuse, nested navigation) you'll be tuning thresholds by hand or fighting false positives.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →