process.waitUntilExit never exits in tahoe 26.3

I have this code in my Virutalization application

              let process = Process()
              process.executableURL = URL(fileURLWithPath: "/usr/sbin/diskutil")
              process.arguments = ["image", "create", "blank",
                                   "--fs", "none", "--format",
                                   "ASIF", "--size", "2GiB",
                                   url.path
                                  ]
              try process.run()
              process.waitUntilExit()
                            
              if process.terminationStatus == 0 {
                  print("✅ Disk image creation succeeded.")
              } else {
                  print("❌ Disk image creation failed with exit code \(process.terminationStatus)")
              }
              
          } catch {
              print("Process failed to launch: \(error.localizedDescription)")
              return
          }

this code was working fine until Tahoe 26.2. with the update of 26.3 the system freezes at process.waitUntilExit()

The code never exits and i get beech balls. This is working fine with intel macs. i am getting the problem in apple silicon m4 mac mini.

Any help would be appreciated.

Answered by DTS Engineer in 876261022

Well, that’s annoying. We have a bug to track this internally (r. 170381800). We’re hoping to fix it sooner rather than later but, as always, I can’t offer a concrete timeline. If you want to be notified when the fix starts seeding, file your own bug in Feedback Assistant and ask that it be marked as a duplicate of the above-mentioned bug.

Share and Enjoy

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

Well, that’s annoying. We have a bug to track this internally (r. 170381800). We’re hoping to fix it sooner rather than later but, as always, I can’t offer a concrete timeline. If you want to be notified when the fix starts seeding, file your own bug in Feedback Assistant and ask that it be marked as a duplicate of the above-mentioned bug.

Share and Enjoy

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

indeed it is very annoying. I have a live app on the mac appstore and customers are returning the product for refund because of this problme. what a disappointment.

Hmmm, that’s not good.

While I don’t want to engage in ‘blame the victim’ here, there is something you can do to reduce the risk of problems like this occurring in the future, namely, testing with beta seeds as they’re released. The beta seed programme exists to help us find and fixing regressions like this.

Anyway, let’s see if we can find you a workaround. If you add this to your app’s entitlement, does it prevent the failure:

  • A key of com.apple.security.temporary-exception.mach-lookup.global-name
  • With the value being an array
  • With a single string element
  • Whose value is com.apple.storagekitd

If that works, we can then talk about the App Review implications |-:

Note Temporary exception entitlements have an interesting history. I have a couple of links in App Sandbox Resources that explain more about them.

Share and Enjoy

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

Thank you for your reply.

A key of com.apple.security.temporary-exception.mach-lookup.global-name

I tried this and it works. It does not hang anymore. If i make this changes whether the app will pass the app review? Thanks

I tried this and it works.

Yay!

If i make this changes whether the app will pass the app review?

I don’t work for App Review and thus can’t make definitive statements about their policy. However, my experience is that App Review is very skeptical about any use of temporary exception entitlements. However, one valid use case is working around bugs, and so I think it’s worthwhile you attempting this here.

You can improve your chances by limiting this entitlement claim to specific OS versions. You do that with the :before:MAJOR.MINOR clause, as illustrated by this page.

Now, the question is, what to use for MAJOR.MINOR? The obvious choice here is 26.4, on the assumption that the bug in question will be fixed in some later seed of macOS 26.4 beta. However, I can’t guarantee that that will happen. And, if it doesn’t, your workaround will come unstuck as your customers start upgrading to the final release of 26.4.

So, it’s a trade-off:

  • You could use 26.4, which is more specific, and thus easier to explain to App Review, but will cause problems if the bug fix missing that bus.
  • You could use 27.0, because that’ll give you plenty of time to assess your options.
  • You could leave off the :before:MAJOR.MINOR clause entirely, with a promise to ship an update once you know the OS release that’s carrying the bug fix.

This is a choice you’ll have to make yourself.

Regardless of what you choose, I recommend that you specifically call out this temporary exception entitlement in the reviewer notes, and mention:

  • This forums thread
  • Your goal to work around Radar ID 170381800
  • The rationale behind your :before:MAJOR.MINOR clause choice

This will likely require careful consideration by App Review, and that might take some time. So it’s probably best to include it in a simple bug fix release, and not bundle this workaround with a bunch of new features.

Good luck!

Share and Enjoy

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

Thank you very much for detailed info about the entitlement key. I have made the changes to app and submitted for app review with the radar info in review notes and appsandbox info. Fingers crossed till the review complete. I will come back once i have some info from app review team.

process.waitUntilExit never exits in tahoe 26.3
 
 
Q