[NSSavePanel savePanel] can return NULL in sandboxed apps, causing panic

[SuchAFuriousDeath]

Contrary to Apple documentation, [NSSavePanel savePanel] seems like it can return nil when called from a sandboxed macOS app that lacks the com.apple.security.files.user-selected.read-write entitlement. This causes a panic in objc2-app-kit:

unexpected NULL returned from +[NSSavePanel savePanel]

While Apple's documentation doesn't mention this, NSSavePanel.savePanel silently returns nil when the app is sandboxed but only has read-only file access entitlement instead of read-write. This has been discovered in the Apple Developer Forums:
https://developer.apple.com/forums/thread/104913

Here are examples of the panic happening in Ruffle:
https://github.com/ruffle-rs/ruffle/issues?q=is%3Aissue%20state%3Aopen%20%22unexpected%20NULL%20returned%20from%22

[madsmtm]

Thanks for the report! The header happens because the header has:

NS_HEADER_AUDIT_BEGIN(nullability, sendability)
// ...
@interface NSSavePanel : NSPanel
+ (NSSavePanel *)savePanel;
// ...
@end
NS_HEADER_AUDIT_END(nullability, sendability)

Which makes savePanel be non-null. Could I get you to file a Feedback Request with Apple, and post the ID here? We can fix it locally, but it's less maintenance for me if Apple adds the missing null-ability annotation instead.

---

In the meantime, Ruffle can do:

pub fn save_panel(mtm: MainThreadMarker) -> Option<Retained<NSSavePanel>> {
    unsafe { msg_send![NSSavePanel::class(), savePanel] }
}

[SuchAFuriousDeath]

Well, Ruffle can fix the entitlements in the meantime, which is the proper fix and bypasses this whole conundrum 😅 : ruffle-rs/ruffle#22776

I filed this just for the sake of objc2.

I'll look into filing the Apple thing.