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...