Additionally, if I use my custom type instead of .json when exporting, the "Save to Files" doesn't even show up, even if I did set the export type in the info.plist file. extension UTType {     static var car: UTType = UTType(exportedAs: "com.acme.cararchive") } extension Car: Transferable {     static var transferRepresentation: some TransferRepresentation {         DataRepresentation(contentType: .car) { archive in             try JSONEncoder().encode(archive)         } importing: { data in             try JSONDecoder().decode(Car.self, from: data)         }     } } fefe

Would like to know as well!

My I add that using FileRepresentation instead of DataRepresentation has the same effect: extension FuelUpsArchive: Transferable {     static var transferRepresentation: some TransferRepresentation {         FileRepresentation(contentType: .commaSeparatedText) {             SentTransferredFile($0.file)         } importing: { received in             try! self.init(csvData: Data())         }     } }

I'd like to know how to share a file as well!

I have this issue as well. Not greyed-out screenshots. Fun times.

Duped radar FB9959325

Still occurs in 13.3 :(

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

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.

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.

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

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.

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.

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!

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