Our app uses a Distribution.xml-based installer. Within the postinstall script, we attempt to untar a signed and notarized .app to the /Applications directory. On macOS 27 (tested up to Developer Beta 4), the tar command randomly fails to write random unpacked files with an I/O error; in the console there is "spolicyd[721] revoked access to "/Applications/XXX.app/file/within". It can be reproduced approximately every 4th install.
Is this happening for anyone else? Any known workaround?
You should definitely file a bug about this. Regardless of what I’m talking about below, I presume that this worked on macOS 26 and thus it should either work on macOS 27 beta or we should have some sort of explanation for why it shouldn’t work.
Make sure to include a sysdiagnose log taken immediately after reproducing the problem.
Please post your bug number, just for the record.
But…
Why are you installing the app from the post-install script? Most installer packages have the content in the package itself, and one presumes that such packages never hit this problem.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
I have already filed FB23871124. The design of the installer is a historical artifact due to the way how we structure our installer and updater, and changing it would be complicated...
I have already filed FB23871124.
Thanks.
Note If you’ve already filed a bug then it speeds things up if you include the bug number in your post. For this and other hints, see Quinn’s Top Ten DevForums Tips.
I’ve no concrete news to share on that front, other than to confirm that your bug has made it to the right folks.
The design of the installer is a historical artifact
OK.
The problem you’re hitting is most likely related to app bundle protection. That feature isn’t new — in Trusted Execution Resources I link to the WWDC talk that introduced it, back in 2022 — but it’s a complex feature and it’s easy to see how something might’ve changed to trigger this specific issue.
The easiest way around this is to have the installer do the installation. That way this becomes Apple’s problem to resolve.
If you can’t do that — for example, you’re doing an incremental updater — then my general advice is:
renamex_np is your friend).It might be worthwhile for you to experiment with these techniques now, just in case FB23871124 doen’t catch the macOS 27 bus.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"