AppProxyProvider cannot receives new flows on macOS 15

I just encounter this issue on macOS 15 beta (24A5309e)

I’m confused. The released build of macOS 15.0 was 24A335, and you’re testing on a version older than that. I recommend that you re-test on either a released version of macOS 15 or the macOS 15.2 beta seed (currently that’s 15.2b1, or 24C5057p).

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I tested and found this error appears on macOS 15.0.1 (24A348)

OK.

Before we start debugging this, I have some high-level thoughts:

• You really need to set up a more comprehensive testing programme. NE providers work deep within the system, so it’s not uncommon for them to fail in mysterious ways. If you’re building a product that relies on them, you need to test that product with every beta release of macOS as soon as we start seeding it.

• In this case, we started seeding macOS 15 back in June, and if you’d tested your product back then you would’ve saved your customers a bunch of inconvenience.

• It’s easy to test a wide range of macOS versions using virtual machines.

• Right now, I suggest you set up VMs for the latest public release of macOS (macOS 15.0.1) and all the currently seeded betas (macOS 15.1rc2 and macOS 15.2b1). That way you can a) ensure that this is still a problem on the latest betas, and b) verify any fixes that you make.

• And then maintain those VMs as new releases ship and new betas are seeded.

As to your current problem, it’s hard to offer concrete advice without more details. See tip 7 in Quinn’s Top Ten DevForums Tips for general advice on the sort of info I look for in a new post. In this case:

• What type of NE provider are you building. Is it actually an app proxy provider? Or a transparent proxy?

• How is it packaged? As mentioned in TN3134 Network Extension provider deployment, both of those provider types can be packaged as either an appex or a sysex.

• Are you sure that the provider starts? Do you see your ‘first light’ log point? See Debugging a Network Extension Provider for more about that concept.

• Does you provider see no flows? Or is it just that specific flows are missing?

• And, in general, how are you testing this?

For context, there are a lot of third-party NE providers for macOS and I’m not aware of a general problem with them. So, if this is a bug in the system itself, there’s something specific about your provider that’s triggering it.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

OK. I'll answer each question:

• I'm using NEAppProxyProvider combined with NEPacketTunnelProvider and NEDNSProxyProvider. However, I have just encountered the issue with NEAppProxyProvider.
• All of them are packaged as a sysex.
• I added some logs to debug and found that the function startProxy was called. Setting setTunnelNetworkSettings also didn't return any errors. Therefore, I think it had started successfully but I didn't see the function handleNewFlow was called. As a result, I see no flows.
• My app worked stably on older versions but from Sequoia, I have encountered this issue when restarting NEAppProxyProvider. It's an intermittent issue.