Ahh, hooked up console and I think I found the problem: error 09:51:01.071909-0800 appstored [BUY347258D/com.apple.TestFlight:899247664] Failing installation after receiving error: Error Domain=IXUserPresentableErrorDomain Code=1 "Unable to Install “TestFlight”" UserInfo={NSLocalizedDescription=Unable to Install “TestFlight”, NSLocalizedFailureReason=Please try again later., NSLocalizedRecoverySuggestion=Failed to get CFBundleVersion from Info.plist for incoming OS app upgrade for bundle ID com.apple.TestFlight, NSUnderlyingError=0xc98a5a300 {Error Domain=MIInstallerErrorDomain Code=33 "Failed to get CFBundleVersion from Info.plist for incoming OS app upgrade for bundle ID com.apple.TestFlight" UserInfo={SourceFileLine=315, NSLocalizedDescription=Failed to get CFBundleVersion from Info.plist for incoming OS app upgrade for bundle ID com.apple.TestFlight, FunctionName=-[MIInstallableBundle _checkCanInstallWithError:]}}} Seems like a TestFlight.app bug... Opening a FB... 13601901

What kind of VPN are you using? If not using Network Extensions, probably going to have a bad time. FWIW, the VPN I am using does not have this problem, so likely a configuration or implementation detail specific to your VPN software.

AFAIK, Apple will only be supporting Account Driven enrollments and will not be supporting profile-driven MDM enrollments on the platform.

Thanks Matt! One detail: we are deploying agentlessly and not using an app with a bundled dns extension. Specifically we are deploying a DoH configuration via an MDM mobile configuration profile: https://developer.apple.com/documentation/devicemanagement/dnssettings Therefore we don’t have an app available to modify these settings. That being said… could a macOS app (that we would have to build to solve this use case) modify the behavior of an MDM deployed DNS settings configuration?

Possibly old news but for the record. According to AppLayer VPN MDM spec MailDomains has been deprecated in 13.4. The suggestion is to "use the VPNUUIDproperty of the Mail or ExchangeActiveSync payload instead."

Hi Matt, I've observed similar issues when using a Global HTTP Proxy profile on a supervised iOS device. We rely on iOS's proxy capability to block adult material on managed devices so that we don't have to force users to use a 3rd party browser app and disable Safari. The above note from Rachel illustrates that developers/vendors have rolled their own strategies for blocking content from loading via a proxy server. Now it seems a change in Safari in iOS 15 has broken or otherwise compromised at least some of those strategies. Rather than trying to reverse-engineer the iOS network stack and WebKit, could you shine some light on how Apple engineering expects proxy servers to block traffic? AFAIK there isn't a well adopted RFC defining this behavior, however the server-side strategy of opening the TCP socket, accepting the initial HTTP request (e.g. GET/CONNECT), then sending a RST in response (if the content is to be blocked) seems to be a well adopted and accepted method across many enterprise proxies and firewalls. Of course in iOS 15 the new behavior in Safari is to detect that the TLS handshake was interrupted pre-maturely for HTTPS connections, and force a direct connection attempt around the proxy server. This obviously renders the content filter worthless... Anything you can share I'm sure would be vey helpful to me and the broader Apple enterprise ecosystem.

I was having the issue with rvictl refer responding, but now I am getting the FAILED error. Updated to latest Xcode 12.3 (12C33) and macOS 11.1 (20C69) and iOS 14.3 (18C66): sudo rvictl -s 00008101-<REDACTED> Starting device 00008101-<REDACTED> [FAILED] Same happens with and without sudo...

Seeing as of iOS 14.1 as well. Filed Feedback ID FB8070710 with no response from Apple Engineering. Found the same thing: no problem with TestFlight upgrade paths. However production app upgrades in the App Store get intermittently "bricked". We are having trouble supporting this extension in production environments as it currently stands.

FYI: This problem is still happening painfully intermittently as of iOS 14.1. We are about to abandon our implementation of NEFilterDataProvider as a result and see alternative options as it bricks our customers' devices when it occurs (until they Cancel Download of our parent app). Feedback ID FB8070710 filed back in July and there has been no response from engineering. It does beg the question: is anyone using NEFilterDataProvider in production? I've found quite a few bugs and I can't seem to find anyone reporting them, let alone claiming to be using Content Filter Plugins on iOS...

Submitted! FB8401363 Will update this thread with any relevant updates towards resolution or workarounds we may find.

Ahh, actually, looking at the system logs when the user is trying to upgrade the app, it looks like sysextd is crashing... Logs filtered by sysextd during an installation: 2291 default 2020-08-10 09:09:50.760221 +0100 sysextd Restoring state from extensions DB Previous boot UUID: 4585FFFD-6D28-42A4-B7F4-4CD7F09253BD, current boot UUID: 4585FFFD-6D28-42A4-B7F4-4CD7F09253BD; rebooted = false 2291 default 2020-08-10 09:09:50.761023 +0100 sysextd Extension com.company.NE/teamID("&lt;redacted&gt;") version 6 is in state activated_waiting_to_upgrade 2291 default 2020-08-10 09:09:50.761116 +0100 sysextd Extension com.company.NE/teamID("&lt;redacted&gt;") version 6 now in state activated_waiting_to_upgrade 2291 default 2020-08-10 09:09:50.761137 +0100 sysextd Extension com.company.NE/teamID("&lt;redacted&gt;") version 7 is in state terminating_for_uninstall 2291 default 2020-08-10 09:09:50.761157 +0100 sysextd Extension com.company.NE/teamID("&lt;redacted&gt;") version 7 now in state terminating_for_uninstall 2291 default 2020-08-10 09:09:50.761161 +0100 sysextd State restoration from extensions DB completed 2291 default 2020-08-10 09:09:50.783536 +0100 sysextd attempting to realize extension with identifier com.company.NE 2291 default 2020-08-10 09:09:50.790281 +0100 sysextd Realizing target path: &lt;private&gt; 2291 default 2020-08-10 09:09:50.790872 +0100 sysextd Bundle class: UncachedBundle 2291 default 2020-08-10 09:09:50.814968 +0100 sysextd Fatal error: Activate found 2 extensions in active state, ID: com.company.NE,&#9;teamID("&lt;redacted&gt;"): file /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/SystemExtensions_executables/SystemExtensions-35.140.3/core/extension_manager.swift, line 1324 335 default 2020-08-10 09:09:50.838167 +0100 ReportCrash Parsing corpse data for process sysextd [pid 2291] 335 default 2020-08-10 09:09:52.797288 +0100 ReportCrash Sending event: com.apple.stability.crash {"appVersion":"???","exceptionType":2,"process":"sysextd","responsibleApp":"sysextd"} 335 default 2020-08-10 09:09:52.824914 +0100 ReportCrash Saved crash report for sysextd[2291] version 35.140.3 to sysextd_2020-08-10-090952_&lt;redacted&gt;.crash This looks to explain why the extensions are stuck in their state: sysextd crashes before it can put them into a healthy state. Time to submit a feedback ticket?

Yes, we are doing exactly that (always returning replace) with only a single line of additional code for logging. We captured a sysdiagnose on the device and the above system extension state is shown in the systemextensionsctl_list.txt file, but there isn't anything really apparent in the big systems_logs file. Anything else to check?

Thanks for the great answer, this saved me a ton of time. I'll add a few details from my experience for the benefit of the thread: I was able to make this work for my distribution via a DMG instead of ZIP. I use appdmg - https://github.com/LinusU/node-appdmg to build the DMG that contains my .saver file. It is a very handy tool that does the Developer ID signing. It doesn't do the notarization, but the steps provided above against the DMG file works a treat. I added the app-specific password by logging in to https://appleid.apple.com with my developer account After notarizing, I simply ran the staple command on the DMG and it was notarized. There is a lot of auto-magic going on there. I was able to validate that "source" is "Notarize Developer ID" using: spctl --assess -vvv --type install &lt;fileName&gt;.dmg. You should see something like: screensaver.dmg accepted source=Notarized Developer ID origin=Developer ID Application: &lt;your developer account name&gt; (&lt;your team identifier&gt;) Note the Notarized part. Otherwise you would just see source = Developer ID

OK great, that makes sense.And what about storing secrets in NETunnelProviderProtocol.providerConfiguration dictionary? Are those KVPs persisted to the root system keychain in a secure way? I found documentation indicating credentials pushed within a VPN MDM profile are stored in the keychain, but the security guarantees for provider configuration isn't documented one way or the other that I could find... I assume it is not safe, encrpyted, or recommended to store secrets there, but I wanted to validate with you.Thanks agian!

@eskimo ah, well that would certainly explain it. Does this mean there is no way to employ a shared keychain with System Extensions without making the application run as root, which doesn't seem like the right solution. Or is it possible to make the system extension run at the user level (I doubt it)?If neither of those are possible, what is the advised way to securely storing exchange credentials derived by the host app to be used by the NE provider for authentiation? Perhaps using IPC from app to provider and having the provider write to keychain?