> Fixing "-[OS_dispatch_mach_msg _setContext:]: unrecognized selector" on iOS 27

You update one of your test phones to iOS 27, hit Run in Xcode, and an app that has worked perfectly from iOS 18 through 26.5 freezes on the splash screen. The console fills with a message like this:

objc[1953]: -[OS_dispatch_mach_msg _setContext:]: unrecognized selector sent to instance 0x103fc8ba0 (no message forward handler is installed)
-[OS_dispatch_mach_msg _setContext:]: unrecognized selector sent to instance 0x103fc8ba0 (no message forward handler is installed)

If you grab a backtrace, the abort lands inside libsystem_kernel.dylib at __abort_with_payload. The really confusing part is that it only happens under the debugger. Quit the debug session, tap the app icon on the phone directly, and it launches and runs exactly as intended. Older devices don't show it either, so an iPhone on iOS 18 or 26.5 builds and runs clean while the iOS 27 device hangs every time.

What's Actually Going On

This isn't a bug in your code, and it isn't tied to a specific Xcode version. People hit it on Xcode 26.5 and on the Xcode 27 beta alike, which is the first clue that the trigger is the runtime environment rather than the compiler.

The selector in the message, _setContext: on an OS_dispatch_mach_msg object, is internal Dispatch plumbing. Xcode's debugger has a feature called backtrace recording that hooks into libdispatch so it can show you the queue a block was originally enqueued from when you're stepping through asynchronous code. To do that it has to instrument dispatch objects as they pass through the system. On iOS 27 the internals of those objects changed, and the instrumentation tries to send a message the object no longer responds to. The result is an unrecognized selector, an abort deep in the kernel layer, and your app appearing to wedge on launch.

Because the whole mechanism only exists to support the debugger, none of this happens when the app runs on its own. That's exactly why launching from the home screen works while launching from Xcode does not.

The Fix: Turn Off Queue Backtrace Recording

The fastest way back to a working debug session is to disable the feature that's doing the instrumenting:

1. In Xcode, open Product > Scheme > Edit Scheme (or Command + Shift + comma).
2. Select the Run action in the sidebar, then open the Options tab.
3. Find Queue Debugging and uncheck Enable backtrace recording.

Close the editor and run again. The hang is gone and you can debug on the iOS 27 device normally. You lose the enriched async backtraces that show the originating queue, but ordinary breakpoints, stepping, and the regular call stack all keep working. For most day-to-day debugging you won't miss it, and you can flip it back on later once the underlying issue is resolved in a future Xcode update.

A Couple of Sanity Checks

If toggling that option doesn't clear it, make sure you're editing the scheme you actually run, since a workspace can hold several. It's also worth confirming the symptom matches: this specific failure is the _setContext: selector on a dispatch object aborting under the debugger only. A crash that also reproduces when you launch from the home screen is a different problem and won't be fixed by this setting.

This is the kind of rough edge that tends to show up early in a major OS cycle, where the debugger tooling hasn't fully caught up to changes in the system frameworks. Apple's Edit Scheme documentation covers the scheme options if you want to see what else lives under the Run action. Until a toolchain update lines the instrumentation back up with the iOS 27 runtime, unchecking backtrace recording is the clean workaround, and it costs you almost nothing in practice.