Xcode 26 beta 4 and iOS 26 beta 4 unable to build: facing issues in sideloading using Xcode

Can you please post the output of running devicectl list preferredDDI?

— Ed Ford,  DTS Engineer

Please find attached document

Thanks for posting that. Before going too deep, can you run the following commands to make sure there are no surprises?

% sudo xcode-select -s /Applications/Xcode-beta.app
% sudo xcodebuild -runFirstLaunch

Once that's done, does running devicectl list preferredDDI output anything different?

— Ed Ford,  DTS Engineer

please find attached screenshot

No, there is no difference in output

What is the output of devicectl manage ddis update?

Please find attached screenshot for given ask

Ok, so now we're getting somewhere...

You could possibly manually install the content from CandidateDDIs directory into the DeveloperDiskImages directory, but I want to understand why you're hitting that error in the first place.

Do you have any type of Endpoint Security software installed which might be causing errors mounting disk images?

Please capture a devicectl diagnose tarball right after you run that devicectl manage ddis update and send it over via Feedback Assistant. Please include the FB# here (and ideally reference this thread in the report), so we can tie the two together. Thanks!

Files have been uploadend to below FB FB : FB19276507

Do you have any type of Endpoint Security software installed which might be causing errors mounting disk images? -- SIA have Sentinal one end point security software

Ed asked me to look into this and, after a bit of digging, I was able to figure out what's going on.

So, the direct issue here is that the disk image is actually ejecting before it's even able to start mounting:

2025-08-01 10:00:58.691154+0800 SystemUIServer: [com.apple.systemuiserver:digihub] received premount disk13 <private> returned: 0xC
2025-08-01 10:00:58.691157+0800 SystemUIServer: [com.apple.systemuiserver:digihub] ack values for _generateNewAckFromOldAck &requireAuth=8 =eject=0 =eject&deny=0 &eject=4 &readOnly=0 =readOnly=0
2025-08-01 10:00:58.691157+0800 SystemUIServer: [com.apple.systemuiserver:digihub] request eject due to MCX settings
2025-08-01 10:00:58.699190+0800 SystemUIServer: [com.apple.systemuiserver:digihub] request auth and eject due to MCX settings
2025-08-01 10:00:58.710259+0800 SystemUIServer: [com.apple.systemuiserver:digihub] received eject pre-notification for <private>, returned 0
...
2025-08-01 10:00:58.756557+0800 diskarbitrationd: [com.apple.DiskArbitration.diskarbitrationd:default] ejected disk, id = /dev/disk13, success.
2025-08-01 10:00:58.756616+0800 diskarbitrationd: [com.apple.DiskArbitration.diskarbitrationd:default]   dispatched callback, id = 0000000000000008:0000000000000008, kind = disk eject, disk = /dev/disk13, success.
2025-08-01 10:00:58.759084+0800 diskarbitrationd: [com.apple.DiskArbitration.diskarbitrationd:default] unable to copy disk description, id = /dev/disk13 (status code 0xF8DA0003).
2025-08-01 10:00:58.759754+0800 diskimagesiod: [com.apple.DiskImages2:Default] -[DIIODaemonDelegate exitDaemon]: IO daemon of disk13 is shutting down, stopping IO channels

In other words, the reason the volume isn't mounting is because SystemUIServer told the device to eject before anything could mount:

2025-08-01 10:00:58.691157+0800 SystemUIServer: [com.apple.systemuiserver:digihub] request eject due to MCX settings

The terms "MCX settings" would normally refer to the Device Management system and, I believe, the profile setting "MediaManagementAllowedMedia" could actually cause exactly the same failure you're seeing. However, that's not the cause in your case.

In your case, you can find the cause by opening up System Information.app (/Applications/Utilities/System Information.app) and looking through the "Profiles" section. One of the profiles in the list is named "Dev***********eet/V_9:" and one of its sub properties is "com.apple.systemuiserver:" with this payload:

{
...
        "disk-image" =         (
            eject,
            authenticate
        );
...
}

I have no idea how that payload was generated or what the intention was, but the net result is that the preferences configuration above causes SystemUIServer to eject devices on attach so that it can present an authentication dialog. However, in the case of DiskImages, that eject causes the entire DiskImage driver to unload, destroying the object before it can do anything useful.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

To zoom from Kevin's analysis above and to go back to Xcode-level details, Xcode needs to be utilize disk images, and can't because of the managed system policy Kevin details above. I presume this mangement policy is set by your IT department, so the action item here for you is to take this information back to them and get their help in creating a system configuration that is usable with Xcode (including the ability to mount disk images) for you.

— Ed Ford,  DTS Engineer