The closest you can get is to use the `tmutil` tool to make a snapshot. You can't control the aging of that snap though and Time Machine will delete it after 24 hours or so.In order to have full control you need to be invited to have the entitlement.

As you found you can't revoke a VPP code as it's essentially a gift card code for a particular app. As the name would indicate though, using managed apps requires managed devices, thus the MDM requirement.While it is possible to assign licenses directly to Apple IDs, I've not checked to see if you can do the same for devices. In either case I don't know of any shipping management products that will let you assign VPP without also using MDM.Most cases where I've seen code-based distribution work because they don't care if the app is out there. In those deployments access to any information is gated by user authorization, not just having the app.

You would need to sign the app with an enterprise distribution certificate for your organization. Then you can use your MDM to distribute it to as many internal users as you like.

You can simply create a custom configuration profile for any app preference domain and distribute it via MDM. You can either use the app domain directly or the older MCX domain when targeting the Mac with settings.Currently an app on the Mac will read the settings in its preference domain and apply them. It's up to the app to mark if they came from a managed domain or not. The introduction of the managed app payload makes me think that store apps might need to declare what can be managed in the future, like iOS does now, but that hasn't happened yet.

Just to be clear, Shared iPad is an education-only feature.

It seems to be saying that you are missing some libs, possibly the Swift runtime. That could happen if you are targeting the current OS and SDK, but specifying an older deployment target on the store.If you look in your app archive you should be able to figure out what is missing or the wrong version. Failing that I would reach out to dev support.

Is there any chance you are working with a macOS app here? Testflight is only for iOS and tvOS.

Apple hsa started to spend a lot of time on the validation because of the rampant fraud and piracy that came from illictly obtained enterprise certificates.It's good to secure the platform but, as usual, the actions of bad actors mostly causes headaches for legitimate ones.

When you are using a Custom/B2B app it is very much just a App Store app that is not published in the store search index.You are correct that in this case Apple takes over the signing and provisioning of the apps. If you download a B2B app and inspect the signing you will see that it has no provisioning profile in it. It's simply signed with the Apple iPhone distribution certificates.For example...B2B signed app certificates:Authority=Apple iPhone OS Application Signing Authority=Apple iPhone Certification Authority Authority=Apple Root CAEnterprise signed app certificates:Authority=iPhone Distribution: JAMF Software, LLC Authority=Apple Worldwide Developer Relations Certification Authority Authority=Apple Root CAMy B2B app was uploaded on March 1st, two years ago but it still gets signed fresh by Apple with their certificates and no provisioning profiles in it.

I think it's just them gathering info as to how the program is being used. It's probably in response to the public outing of companies that were using enterprise distribution to avoid the App Store terms of service and restrictions.

The simplest path is just to update the app with the new profile.You can also push out the new provisioning profile with MDM if your organization has a server that supports the operation.

I would take a look at the troubleshooting documentation from Apple. It will walk you through the process to verify the signing and the notarization steps.

You can't force enable a Safari extension. The best you can do is check to see if it is enabled with:getStateOfSafariExtension(withIdentifier:compeltionHandler:) when your container app is launched.Then you can prompt the user to enable it if they need to.

Typically I see apps like this using Sparkle, or something similar, to handle updates.

In the post at least, your AppGroups identifier has a typo in the second one where it is missing a dot between the team ID and the bundle ID. The first one actually has two dots between them.That would keep them from matching and from being able to access the shared space, which is what the logs are complaining about.