I just updated to Version 13.0 Beta (22A5286j) running in a virtual machine on an M1 Mini. It too said there was an update after updating but then after it checked it said everything was up-to-date.
(note: It doesn't explicitly say "Beta 2" but rather it gives the build in this case (22A5286j))
Post
Replies
Boosts
Views
Activity
[Buzz wearing his "dog-waiting-for-a-bone-from-Apple-developer face whist shelving his ultra-cool VM app]
Thank you
Ben, I'm sorry and I don't mean to be a nudge but I need some level of detail.
For instance, is it even possible for Apple's cloud services to recognize requests coming from a virtual machine instance and authenticate with those services, or are inherent security features built into those services that would prevent a virtual machine from connecting?
Or, are we waiting for those methods to be built into Virtualization Framework?
Or is it something else?
If this is not the forum to go into those detail, perhaps we can take this offline or you could direct me to where I can begin to get such questions answered?
Thank you
I recall sessions during WWDC19 and WWDC20 that addressed this feature. It was referred to then as "Ad Hoc". Here is a link to the presentation slides...
https://devstreaming-cdn.apple.com/videos/wwdc/2019/304uxy73xvmgt37/304/304_app_distribution__from_adhoc_to_enterprise.pdf
I haven't followed closely how those initiatives nor terminology have evolved but here is a link to what I think is more current...
https://developer.apple.com/support/unlisted-app-distribution/
Good luck
I understand from threads here and elsewhere that it is not supported. Perhaps you can offer some insight into exactly where the shortfall is.
Is it that of the project, lacking an implementation of a restricted entitlement perhaps, or simply lacking an existing method?
Or is it that the Virtualization framework lacks a method to implement, one that is required but still in development?
Are we looking at the same instructions? It reads: "In your project’s “Signing & Capabilities” panel, turn on the App Sandbox. This creates a new entitlement file in your project with the same name as the app target." Confusing, since the project already has an entitlement file that includes that entitlement.
In any case, your help was instrumental in my getting VMs built and running both Monterey and Ventura betas on an M1 running 12.4, simultaneously.
Now, to get authentication with Apple services to work. Has there been any progress on that front?
Thanks again
The App Sandbox WAS very definitely enabled, as per "Step 1" of Apple's documentation found here:
https://developer.apple.com/documentation/virtualization/adding_the_virtualization_entitlement_to_your_project
...and that WAS the problem. After setting App Sandbox entitlement to "NO", "macOSVirtualMachineSampIeApp" runs and the Virtual machine boots from the VM.bundle located at "vmBundlePath". Thank you
Now the question: why are we instructed to add App Sandbox entitlement, in light of the above?
I came across this whilst search how to request another entitlement...
https://developer.apple.com/forums/thread/656411
I have not yet had a response as to whether there exists a new process or we are still using the TSI route.
Good luck. I'll be watching this thread :)
You are not alone. I am getting the same message running Apple's own sample code:
2022-06-15 10:19:14.882785-0400 macOSVirtualMachineSampleApp-Swift[4265:108949] [default] Failed to get state for list identifier com.apple.LSSharedFileList.ApplicationRecentDocuments Error: Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted" (Access to list denied) UserInfo={NSDebugDescription=Access to list denied}
Though this is not a fatal error as the Virtual machine successfully starts, I would like to understand what pram in the project config is causing it.