To workaround the issue, if I iterate over the pixel data of the CMYK image I'm able to manually convert to RGB and write it into another buffer and create a CGImage with that RGB data. Then I can use CGBitmapContextCreate with the RGB buffer to generate a new image. So there appears to be an issue with how CMYK color space is being handled. Had to take a peek back in the Quartz 2D Programming Guide in the "Documentation Archive" for a refresh on some of these APIs I haven't used in a long time...

So if I put a breakpoint right after CGImageCreateWithJPEGDataProvider and Quicklook preview sourceCGImage, the CGimageRef rendered in the Quicklook preview in the Xcode debugger is correct. But once I try to pass sourceCGImage to any higher level API it goes black. That includes NSBitmapImageRep, NSImage, CIImage, etc. I also tried creating a bitmap context and drawing the sourceCGImage in the bitmap context, but haven't been able to get that to work. Previewing the sourceCGImage right after CGImageCreateWithJPEGDataProvider from Xcode's debugger when I hit that breakpoint is the only time the image is rendered correctly. I wonder what API is being used to render the CGImage from the Xcode debugger?

I filed FB15114920

Yes. Everything in the source image format struct is derived from the sourceCGImage. Color space is retrieved using CGImageGetColorSpace, width is retrieved using CGImageGetWidth, etc.

I hear you but sometimes developers gotta do what they gotta do for their users and themselves. So I was just offering a workaround that should help the developer release an update without having to drastically change the codebase. I don't know about the OP but depending on the complexity of the app it may not be feasible to just throw the whole thing out because of a bug like this and "just wait, maybe we'll fix it" and then play a commercial for SwiftUI. Always appreciate your answers though. They have often been very helpful!

That must've been a nasty surprise. I don't know about you but I got way too much code and time invested to just throw it all in the trash and start using SwiftUI anytime soon. As a workaround you should be able to embed an "AppKit aware" bundle in your Catalyst app? This bundle can call all the public methods an AppKit app can. Load the bundle from the Catalyst app and call whatever public API you want... Something like this... NSURL *appKitAwareBundleURL = [[NSBundle.mainBundle.builtInPlugInsURL URLByAppendingPathComponent:@"NameOfBundle"] URLByAppendingPathExtension:@"bundle"]; NSBundle *appKitBundle = [NSBundle bundleWithURL:appKitAwareBundleURL]; NSError *errorLoadingBundle = nil; if (![appKitBundle loadAndReturnError:&errorLoadingBundle]) { // whoops check error.. return; } Class appKitWorldClass = appKitBundle.principalClass; id <YourProtocolNameHereWrappingAPIsYouNeed>myAppKitWorld = [[appKitWorldClass alloc]init]; self.appKitWrapper = myAppKitWorld; Your principalClass conforms to your protocol you define that wraps whatever API calls you need.

Thanks for the reply. So every Objective-C developer has to write a Swift wrapper around StoreKit2?

FB14382408

Where is DispatchQueue.main.async being called from? What object is self (a view controller or some other object)? And the controller has deallocated before it. Are you saying that the view controller has been deallocated before the table view it displays? Sounds like you might have a memory leak. You can use the memory graph debugger to try to reproduce and/or Instruments. I'd check for unintentional strong references to the table view. References in blocks is a place I'd look for first but it could be something else. It's easy to create a retain cycle using blocked based APIs. Swipe gesture action blocks, context menu action blocks, diffable datasource provider blocks, or your own blocks.

It’s hard to explain exactly what’s failing without knowing more about how Python is expecting to work within your app Thanks for the reply Quinn. I'm using the released version from the repository Python-Apple-support. I needed to set DEAD_CODE_STRIPPING to NO to get this to work in release mode.

So running in release mode I discover I get this error: symbol not found in flat namespace '__PyFloat_Pack2' Are there linker flags I need to add to get this to work in release mode? Thanks

I removed _tkinter.cpython-39-darwin.so from the app, which links to Tcl.framework and resubmitted to the App Store. My app doesn't need _tkinter.cpython-39-darwin.so to function so I'm able to simply remove it. Hopefully that resolves the issue. I will report back with the results.

Thanks a lot for replying. I've never had luck filing an appeal to the review board. As previously mentioned, I wrote this app a long time ago and forgot about it and it only has a handful of users. I didn't realize the app stopped functioning on newer versions of macOS and I'm submitting this update to fix it (because doing otherwise hurts my pride). With that said I also don't want to spend a tremendous amount of time on this going back and forth with app review. It seems like the issue is related to the fact that one or more of the .so files provided by Python links to Tcl.framework (which is where all these symbols are coming from). I don't think the Python code is using any of these private APIs directly.

Can you show what formatStr is set to?

I didn't manage to get it running so far, I suspect that libcrfsuite is for private Apple only use If it's for private API use only it shouldn't appear in the list under Apple SDKs. Maybe someone from Apple could clarify? If you want to try a lazy approach, you could just grab the header files from Github and link against the Apple provided version. I think you are better off building CRFSuite yourself though (to protect your app from crashing if Apple decides to remove it from the SDK in the future). You might be able to get crfsuite to compile from the command line with make but I didn't do it that way. I made an Xcode framework project (you could also do a static library project as well if static linking works better for you) and added all the source code. There are a lot of warnings but they aren't too difficult to resolve. I think I had to make a couple of other changes to get the crfsuite models to work on Apple Silicon. Then I wrote a couple of Objective-C classes that wraps the functionality I need.