Reverse Engineering iOS to Fix SDK Crashes
Article Summary
Phil Niedertscheider from Sentry reverse-engineered Apple's private frameworks after iPadOS 26 broke a fundamental assumption: that successful type casts guarantee the object is actually that type.
The Sentry team discovered their iOS SDK was crashing on iPadOS 26 when users tried to print. The culprit? Apple's UIPrintPanelViewController was overriding isKindOfClass to return true for UISplitViewController checks, despite not being a subclass. This violated basic Swift type safety assumptions.
Key Takeaways
- iPadOS 26's UIPrintPanelViewController lies about its type, passing UISplitViewController checks
- Swift's 'as?' operator relies on Objective-C's isKindOfClass, which can be overridden
- Used Hopper decompiler to prove Apple's implementation returns true for usingSplitView
- Fixed with respondsToSelector runtime check before accessing methods
- Google Mobile Ads SDK hit the same crash from Apple's change
Apple's internal framework changes in iPadOS 26 broke type casting assumptions, requiring runtime selector checks as a defensive measure.
About This Article
Sentry's SDK kept crashing with 'unrecognized selector sent to instance' errors on iPadOS 26. The crashes happened when users opened the standard UIPrintInteractionController while User Interaction Tracing was enabled, which broke print functionality in apps.
Sentry's team used Hopper decompiler to reverse-engineer Apple's private PrintKitUI framework. They found that UIPrintPanelViewController overrides isKindOfClass to return true for UISplitViewController even though it's not actually a subclass. The team added respondsToSelector runtime checks as a safeguard against this behavior.
Sentry released hotfix v8.57.3 that validates selectors at runtime before accessing viewControllers. This stops the crashes while keeping the SDK working normally, and customers don't need to change anything in their applications.