Xcode may finish building and installing an app but then stall with “Launching … is taking longer than expected” or “LLDB could not find the on-disk shared cache for this device.” This usually points to the debugger preparing or resolving symbols for the device, rather than to a compile failure in the app itself.
The messages
Launching "App Name" is taking longer than expected.
LLDB is likely reading from device memory to resolve symbols.
warning: libobjc.A.dylib is being read from process memory.
This indicates that LLDB could not find the on-disk shared cache for this device.
This will likely reduce debugging performance.What causes it
Apple operating systems place many system libraries in the dyld shared cache. If LLDB cannot use the matching local cache or symbols, it may fall back to reading from device memory. Launching, attaching, stepping, and inspecting values can then become extremely slow.
- The Xcode and device OS versions are not a supported match, especially with beta software.
- Device preparation or symbol retrieval did not complete.
- A wireless connection interrupted the transfer.
- The selected Xcode or LLDB release has a version-specific issue.
An Apple Developer Forums report documents Xcode 26 successfully building for a device on a tvOS 26 beta while LLDB alone failed to attach; stopping the debugger allowed the app to launch. That pattern should be treated as a debugging-environment problem before changing unrelated app code.
Confirm that this is a debugger problem
- Run the same scheme on the physical device.
- Stop Xcode and launch the installed app manually.
- Temporarily clear Run → Info → “Debug executable” in the scheme and run again.
If the app starts promptly without the debugger, LLDB attachment is a stronger suspect than signing or installation. Disabling “Debug executable” is a diagnostic or temporary workaround; it does not restore breakpoint debugging.
Recommended steps
1. Check Xcode and device OS compatibility
Record the exact Xcode, macOS, and device OS builds. A device running a new beta generally requires the corresponding Xcode generation. For normal development, update both sides to compatible stable releases when possible.
xcodebuild -version
sw_vers
xcode-select -pIf command-line tools point to a different Xcode, select the intended installation:
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer2. Complete device preparation over a cable
- Restart Xcode and the device.
- Temporarily disable VPN and connect the device by USB when the platform supports it.
- Open Window → Devices and Simulators, or Device Hub in newer Xcode versions.
- Wait for preparation and symbol work to finish.
- Confirm trust and Developer Mode on the device.
If only wireless debugging fails, complete preparation over a cable before trying wireless operation again.
3. Recreate the pairing
Unpair the device in Devices and Simulators, restart the Mac and device, and pair again. For Apple TV, re-pair on the same network and avoid guest networks or client isolation that can block host-to-device traffic.
4. Clear caches gradually
Start with Product → Clean Build Folder. If necessary, quit Xcode and remove only the affected project’s DerivedData:
rm -rf ~/Library/Developer/Xcode/DerivedData/YourProject-*Do not begin by deleting the entire DeviceSupport or Developer directory. That removes known-good data for other Xcode versions and devices and forces expensive downloads. Only regenerate a specific OS-version cache after narrower steps fail, and move or back it up first.
5. Compare environments
- Another physical device with the same Xcode
- The same device with another compatible Xcode
- A Simulator destination
- Wired versus wireless debugging
If only one Xcode and OS build pair fails, treat it as a likely version-specific issue. Update to a newer compatible beta or maintenance release, or use a known-good stable combination while investigating.
Alternatives
- Launch without the debugger and inspect logs in Console.
- Temporarily use a compatible Xcode/OS pair that attaches correctly.
- Debug reproducible logic in Simulator.
These options keep development moving but do not replace a working LLDB session when breakpoints and variable inspection are required.
How to verify the fix
- The app launches without the extended-wait alert.
- The shared-cache warning no longer repeats in the console.
- Breakpoints, Step Over, and variable inspection respond normally.
- Debug → Attach to Process connects successfully.
Important notes
The warning means LLDB is falling back from an on-disk shared cache to device memory; by itself, it does not prove an app defect. As of September 16, 2026, the public Apple forum report for the tvOS 26/Xcode 26 case does not identify a specific maintenance release as the universal fix. Check current Xcode and platform release notes rather than assuming one version resolves every occurrence.
If the problem remains, file Feedback with the Xcode diagnostic log, exact macOS/Xcode/device OS versions and build numbers, connection type, and wired-versus-wireless results.
Summary
First prove that the app launches without LLDB. Then check the Xcode/device OS pairing, complete device preparation over a reliable connection, recreate pairing, and clear only narrowly scoped caches. A failure limited to one Xcode and OS build should be handled as a probable version-specific debugger issue.
References
