Also, I've noticed that the callback returns a different internal port than the initial one. Somehow internalPort is always set to 3095 in my case. I guess it's radar time.

For those who'd like to dupe this and for Apple folks: FB9137313

I have the same problem. Works fine on macOS but crashes on iOS. Have you filed a radar?

I ran some tests and oddly enough in my case the issue is only occurring on my iPad, not my iPhone. Anyone else?

Here's my radar for the issue: FB9188075 I managed to reproduce the crash in a sample project, attached to the radar.

Additionally, it seems like supportsSecureCoding isn't called either on macOS 12 but it on macOS 11.

Apple folks: FB9276356 for a sample project to reproduce the issue.

I wish this was available for UITextView as well and quite frankly I have no idea why it's not. However, it seems you had to do this on the Mac side before usesAdaptiveColorMappingForDarkAppearance was introduced. Do you have any hints as to what needs to be done to accomplish this? Thanks!

Is DNSServiceNATPortMappingCreate now only available for sandboxed apps? If I enable Sandbox in the test project I included with the radar, DNSServiceNATPortMappingCreate returns kDNSServiceErr_NoError. Port mapping still fails of course but if I disable Sandbox, I get this error: DNSCreate[30499:361087] dnssd_clientstub ConnectToServer: connect() failed path:/var/run/mDNSResponder Socket:3 Err:-1 Errno:1 Operation not permitted Unfortunately since it seems like this won't be addressed until GM ships (still not fixed in macOS 12 Beta 7), I have no way to know for sure if this is just a bug or a new requirement. And because of that, I have no way to prepare for this and it may be too late when GM ships. That is if this issue is resolved then. Not cool. Not cool at all.

DNSServiceNATPortMappingCreate is still broken on macOS 12.0.1, which shows that either Apple doesn't care or lied about fixing this while they just wanted to remove that API. Luckily I was able to find an alternative so my users (which are Apple's as well to an extent) don't end up with a broken service. If you want to retire the API, just say so.

For those affected by this regression, check out monkeydom/TCMPortMapper on GitHub. TCMPortMapper is pretty ancient but still works pretty well.

I don't remember their name, sorry. I spoke to an engineer during a WWDC lab and they told me that. But the real issue here is why such a serious regression never got fixed? Do you understand that this bug may render some apps useless? This may impact tens of thousands of users. What do we tell our users when their app stops working when they upgrade to Monterey? In my case I was able to go around the problem but this may not be the case for others.

Still not fixed in macOS 12.1 beta 1. I guess it's now unofficially deprecated. Can't wait for macOS 13 and see which other APIs get the same treatment.

Received an email from an Apple engineer and apparently this has been fixed in the latest macOS 12.1 beta.

Still occurs in 13.3 :(