Just re-tested as of iOS 15.3.1 and this issue doesn't appear to be there anymore for iOS.

One of my end users is seeing this issue (seen via sysdiagnose logs from that user). It's causing things to break only for that user. Two things I noticed about this user: It only seems to happen for them connecting to a school network where they have to use their login credentials to gain access to the network. Even after successfully connecting to the school wifi network, the NWPath still has the preferred (first) network as pdp_ip0. In my testing after connecting to WiFi, the preferred network becomes en0. This user is on AT&T. I don't have a test device with AT&T LTE to test this. Are either of these true for your case?

Still going back and forth on this issue. This does work perfectly fine as long as Private Relay isn't enabled. For now, our alternate plan if we can't get this resolved is to tell our customers to turn off Private Relay. We'll add it to our help articles, customer service troubleshooting steps, chatbot, etc.

Through beta 5 now, same result.

It looks like it's an issue with the extension not activating. I removed the extension target, which also removed the embedded .appex from my main app target, and I get the exact same result. It seems like it can't find the extension.

Having to close and open Xcode with or without Rosetta if you want to modify a view or compile the project is not a valid solution, especially when there's no alternative IDE. After my nightmarish experience with the transition kit I was actually pleasantly surprised that this is all I had to do to get my M1 to work, but yeah I agree this is not anything close to a solution. I did submit a bug report to Apple, but I suspect I'll be seeing it linked with existing reports.

Same problem here, only seems to affect one of my storyboards (that I've found so far). I haven't found a solution, but here's how I work around it for now: I have two copies of Xcode installed, one opens with Rosetta, one opens without. The one that opens with Rosetta can build to Simulator, the one that doesn't can't (but I can still build to physical devices with that one). I normally use the Xcode that opens with Rosetta, but when I need to edit this storyboard I close that version of Xcode and open the other version. I finish my editing than go back to the Xcode that opens with Rosetta. It's not ideal, but it works until Apple irons out these issues. I would really like to just use Xcode without Rosetta, but I run into brick walls everywhere between third party libraries, pods, SPM, etc.

It works for me now! I installed Xcode 12.3 beta and it builds to "My Mac (Designed for iPad)" without error. I have macOS 11.0.1 beta installed.

I've had this same issue. I've tried building a few of my apps with manual signing and with automatic signing. They build and run in iOS simulators, physical iOS devices, and "My Mac (Rosetta)", but not for "My Mac (Designed for iPad)". Edit: Since I believe this is the exact same issue, I'll post some more of my error details in case this looks familiar to anyone. If it turns out to be a different issue, I'll start a separate thread. This app could not be installed at this time. Could not install at this time. Failed to verify code signature of /var/db/appinstalld/Library/Caches/com.apple.mobile.installd.staging/temp.NrLsa7/extracted/appname.app : 0xe8008015 (A valid provisioning profile for this executable was not found.) Additional Details: This app could not be installed at this time. Domain: IDEInstallLocalMacService Code: 1 Failure Reason: Could not install at this time. Recovery Suggestion: Failed to verify code signature of /var/db/appinstalld/Library/Caches/com.apple.mobile.installd.staging/temp.NrLsa7/extracted/appname.app : 0xe8008015 (A valid provisioning profile for this executable was not found.) System Information macOS Version 11.0 (Build 20A5299w) Xcode 12.1 (17222)

Got it. We don't use NEHotspotHelper....just packet-tunnel-provider, content-filter-provider, app-proxy-provider. It looks like we've had NetworkExtension set in the App ID and as the additional entitlement. So we can just set the additional entitlement to Multicast instead. Thanks!

Thanks for the prompt reply. I'm a little confused because the app behaves the exact same without the entitlement (the UDP broadcast works fine in TestFlight builds as long as the user accepts the permissions prompt). I was hoping this entitlement would allow us to be able to discover the hardware device. The issue I'm trying to solve is that if our users don't hit the right button at that prompt, we can't detect this and tell them how to fix it. I just want our users to be able to setup their hardware device without having to contact a support line for help.

The team ID was the issue. I replied to the email from Networking and asked for the team to be changed so that it matches the App ID prefix. The new entitlement is now showing up when I create a new profile.

Additional Info: I just learned that the team ID submitted with the entitlement request was not the organization team (and doesn't match the App ID prefix). Maybe this makes a difference when being granted an entitlement?

Responding to the comments from Apple Frameworks Engineer: If you have a case where you'd like to know if your app doesn't have permission, can you describe it? Is this for using Bonjour, or a direct connection use case? I have an app that controls a hardware device that we manufacture and sell. In order to find the hardware on the network, we send a UDP broadcast with a message for our hardware, and the hardware responds with a message back so that we can get an endpoint to send calls directly to the hardware. The UDP broadcast triggers the request for Local Network permissions, and if the user chooses not to accept it, we will never find their hardware device, and we do not have any tools for diagnosing the issue for them. We're going to have to have a generic error message anytime the hardware is not found telling users to make sure the hardware is connected AND go into Settings on their iOS device and ensure that Local Permissions is turned on for the app. We will warn the user ahead of seeing the request that they need to accept it, but there's always ones that don't, and once that gets off the rails there's no good way to help the user back on the rails. It ends up in a terrible experience for the user.