watchOS 26.2/26.3: watch app killed by dyld before main() — getNameSelRefVMAddr assertion (FB25270892)

Our App Store watch app is being terminated by dyld before any app code runs, only on watchOS 26.2 (23S303) and 26.3 (23S620). Only the arm64 slice is affected (Series 9/10, Ultra 2), and almost always on background launches.

Termination Reason: DYLD 9
Assertion failed: (0), function getNameSelRefVMAddr, file ObjCVisitor.cpp, line 1319.

objc_visitor::Method::getNameSelRefVMAddr (ObjCVisitor.cpp:1319)
dyld4::optimizeObjCSelectors (PrebuiltObjC.cpp:530)
dyld4::PrebuiltObjC::make (PrebuiltObjC.cpp:1372)
dyld4::PrebuiltLoaderSet::makeLaunchSet (PrebuiltLoader.cpp:2309)
dyld4::prepare (dyldMain.cpp:960)

Our previous app version crashes in the same function with SIGSEGV instead (same frame offsets on the same dyld build). The fault address lies just past a mapped-file region.

What we checked:

  • The crashing binary UUID matches our archive.
  • Every ObjC method list in every image is a standard relative list (0x80000000). None has the selector-offset flag (0x40000000), which is what that assertion branch expects according to the open-source dyld.
  • dyld_info -objc parses all images cleanly.
  • Build settings and linker flags are defaults (Xcode 27.1).

So it looks like dyld is reading the wrong data while building the launch closure, rather than our binary being malformed.

This seems related to https://developer.apple.com/forums/thread/810471: same OS range, same "dyld before main(), ObjC metadata" symptom. That report involves VPP installs, while ours is App Store distribution.

Full crash logs, binaries and analysis are in FB25270892.

Has anyone else seen this? Is it fixed in watchOS 26.4 or later, and is there any workaround on the app side?

Answered by DTS Engineer in 911382022
Written by blacksun in 911063022

All of the crash reports with these signatures come from watchOS 26.2 (23S303), 26.2.1 (23S314) and 26.3 (23S620). We have not seen either signature on any other watchOS version, including watchOS 27.

OK.

I used some internal tooling to check whether your experience is typical, and that seems to be the case. That is:

  • This bug affected a lot of watchOS apps…
  • … in the the 26.2 and 2.6.3 timeframe.
  • After which the occurrences dropped off to almost nothing.

Given that, I’m not sure it’s worth pushing harder on this. If you have users reporting this, you can advise them to update to either watchOS 26.x, x > 3, or watchOS 27.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I’d like to get a better understanding of how reproducible this is. In the other thread you referenced, the developer only saw it during VPP installs. Is that the case for you too? Or are you seeing it in other circumstances? Specifically, do you see it with developer builds? What about with TestFlight installations?

Also, you specifically call out watchOS 26.2 and 26.3. Those are old, even by watchOS 26 standards. Are you seeing it on later versions of watchOS 26? Or on watchOS 27?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

@DTS Engineer
Thanks for following up. Here is what we know, sticking to what the data shows.

Reproducibility
We have not been able to reproduce this ourselves. None of our own Apple Watch devices are running watchOS 26.2 or 26.3, so we haven't been able to test developer, TestFlight, or App Store builds on an affected OS version. Every report we have comes from the crash reports Xcode Organizer collects.

Distribution channel

  • None of the reports contain a Beta Identifier field.
  • The reports don't contain a distributor field either, so we can't tell whether any of the affected installs came through VPP/MDM.

OS versions
All of the crash reports with these signatures come from watchOS 26.2 (23S303), 26.2.1 (23S314) and 26.3 (23S620). We have not seen either signature on any other watchOS version, including watchOS 27. We can only speak to what the crash reports show, though, so we can't say for sure that later versions are unaffected.

Other details from the reports:

  • Only devices running the arm64 slice are affected.
  • Nearly all of the crashes happen during background / non-UI launches.
  • The crashes keep recurring on the same device. One Watch7,5 has crashed every day since October 12.

Build environment
For the affected builds we have archives from Xcode Cloud:

  • Xcode 27.0 (27A266a) and Xcode 27.1 (27A9275)
  • watchOS 27.0 SDK (24R360)
  • Deployment target watchOS 10.0
  • Default linker, with no custom linker flags
  • Build machines on macOS 26A428, 26A434 and 26B5091g

The archives and dSYMs for these builds are attached to FB25270892, along with the crash reports.

Happy to provide anything else that would help.

Accepted Answer
Written by blacksun in 911063022

All of the crash reports with these signatures come from watchOS 26.2 (23S303), 26.2.1 (23S314) and 26.3 (23S620). We have not seen either signature on any other watchOS version, including watchOS 27.

OK.

I used some internal tooling to check whether your experience is typical, and that seems to be the case. That is:

  • This bug affected a lot of watchOS apps…
  • … in the the 26.2 and 2.6.3 timeframe.
  • After which the occurrences dropped off to almost nothing.

Given that, I’m not sure it’s worth pushing harder on this. If you have users reporting this, you can advise them to update to either watchOS 26.x, x > 3, or watchOS 27.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

@DTS Engineer

Thanks for checking. One data point that may be useful: on our side, the crashes only appeared after we started building with Xcode 27 (watchOS 27 SDK). Builds made with Xcode 26 did not show this signature on watchOS 26.2–26.3, even during the period when most of our users were on those releases. We'll advise affected users to update to watchOS 26.4 or later.