Archive. This is an archive of the Apple Support Community. Discussions are being restored and soon you will be able to read and post here again.

Apple Watch Series 6 stuck on watchOS 7.5 due to DYLD crash

Hello,


I am opening a new thread because this issue has now been independently reproduced on a second Apple Watch Series 6, and the crash evidence strongly suggests a reproducible software-update failure rather than an issue with one particular Watch or iPhone.


We now have at least two independent Apple Watch Series 6 devices affected:

• Watch6,3

• Watch6,4

• Both running watchOS 7.5 (18T567)

• Different owners and different Watches

• Multiple iPhone/iOS versions tested

• Multiple target watchOS versions tested


In both cases, the Watch works normally and can successfully discover and download an update. The failure occurs during the preparation/verification stage.

Reproduced with multiple target watchOS versions

Between the two devices, the problem has been reproduced while attempting to update from watchOS 7.5 to:

• watchOS 8.8.2

• watchOS 11.6.2

• watchOS 26.6


Changing the target version does not change the underlying failure.

The crash signature is essentially identical

Immediately after the failed update attempt, both Watches generate a crash report for:

com.apple.MobileSoftwareUpdate.UpdateBrainService

with:

Termination Description: DYLD, missing lazy symbol called

More importantly, both crash reports show the same UpdateBrain binaries:

UpdateBrainService UUID:
2CB8AF1F-A1D0-31DC-86B9-009C942505A4

UpdateBrainLibrary.dylib UUID:
70C3EDEB-3C20-3F33-A3EC-40CC484F4785


Both reports also contain the same UpdateBrainLibrary crash offsets, including:

UpdateBrainLibrary.dylib + 441312
UpdateBrainLibrary.dylib + 441184


The library is executed from the dynamically staged XPC bundle under:

/private/var/db/com.apple.xpc.roleaccountd.staging/

Why I believe this is significant

We now have:

Different Watches
Different Series 6 hardware identifiers (Watch6,3 and Watch6,4)
Different owners
Different iPhones
Different iOS versions
Different target watchOS versions

but:

The same starting watchOS 7.5 (18T567)
The same UpdateBrainLibrary binary UUID
The same DYLD missing-symbol failure
The same crash location

This makes an individual Watch hardware failure, Wi-Fi issue, download problem, or a problem with one specific target watchOS version much less likely.

The common factor appears to be watchOS 7.5 executing the currently supplied UpdateBrain code.

My current hypothesis is that the UpdateBrain component being delivered by Apple’s software-update infrastructure may no longer be binary-compatible with the watchOS 7.5 userspace. It appears to reach a lazy-linked symbol that is unavailable on 7.5, causing dyld to terminate UpdateBrainService before the actual OS installation can begin.

I want to emphasize that this is a hypothesis based on the crash reports, not something I can prove without access to Apple’s binaries/symbols or internal update infrastructure.

Question for Apple/watchOS engineering

Could someone from Apple Software Update/watchOS engineering please verify whether the UpdateBrain component currently served to Series 6 devices is still binary-compatible with:

watchOS 7.5 (18T567)

on Watch6,3 / Watch6,4?

If this analysis is correct, Apple Watch Series 6 devices that remained unused for several years and are still running their original watchOS 7.5 installation may currently have no functioning OTA upgrade path out of 7.5, even though newer compatible updates are detected and downloaded successfully.

The Watches themselves are fully functional. The failure occurs when Apple’s software-update component executes during update preparation.

Crash reports available

We have complete .ips crash reports from both independently affected Watches, including:

• exception/termination information

• complete thread backtraces

• binary image UUIDs

• UpdateBrainService information

• UpdateBrainLibrary information


I can provide the complete reports for comparison if someone from Apple engineering is able to investigate this.

At this point I believe this warrants investigation beyond the usual erase/unpair/re-pair troubleshooting, because those procedures cannot reasonably explain two independent devices producing the same deterministic DYLD failure inside the same UpdateBrain binary.

If anyone else has a Series 6 still running watchOS 7.5 (18T567), I would be very interested to know whether you can successfully update it.

If your update fails, please check:

Watch app → Privacy/Analytics → Analytics Data

for a crash report beginning with:

com.apple.MobileSoftwareUpdate.UpdateBrainService

and please keep the complete .ips file.


Thank you,

Vasyl

2 replies

Hi there


Please try this


Because OTA updates fail inside the verification/preparation stage, standard user-side workarounds focus on clearing staged caches or forcing a different distribution route:


  • Clear Staged Update Files: Open the settings  app on your paired iPhone, go to General → Storage, and delete any downloaded watchOS update file before attempting a fresh download. 
  • Apple Store / Authorized Service Provider: If an Apple Watch Series 6 is completely locked out of OTA updates due to a server-side UpdateBrain compatibility gap on legacy watchOS 7.5, Apple Support or an Apple Authorized Service Provider may need to inspect the device or apply an out-of-band firmware flash using specialized diagnostic tools, as end-users cannot manually flash watchOS firmware at home.


Hi WheelieNick,


Thank you for the suggestions.

I have already removed downloaded update files and repeated the update process from a clean state several times, including after erasing/unpairing the Watch. Unfortunately, the result is identical.

The important part here is that the update itself downloads successfully. The failure happens afterwards, when com.apple.MobileSoftwareUpdate.UpdateBrainService is launched during update preparation.

At that exact point, UpdateBrainService crashes with:

DYLD, missing lazy symbol called

What makes this case unusual is that we now have two completely independent Series 6 Watches, Watch6,3 and Watch6,4, both on watchOS 7.5 (18T567), producing the same failure with the same UpdateBrainLibrary.dylib UUID and the same crash offsets.

We have also reproduced it with three different target versions: watchOS 8.8.2, 11.6.2 and 26.6.

So I agree that an Apple service/depot restore may ultimately be the only practical workaround available to the user.

However, I am particularly interested in determining why the OTA path itself is failing, because the evidence currently points to the dynamically staged UpdateBrain component crashing before the OS installation even begins.

If Apple has an out-of-band restore method that bypasses UpdateBrain entirely, that would also be a very useful test: if the same Watch can be successfully restored that way, it would further separate the problem from the Watch hardware itself.

I would therefore still very much like this specific UpdateBrainService crash signature to reach Apple/watchOS engineering rather than being treated only as a generic “unable to update” case.


Thanks again.