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.

Yes I did compile CRFSuite in Xcode. After compiling it myself I noticed after that Apple actually includes libCRFSuite in the SDK. If you open your Xcode project and choose link framework you can search for CRFSuite and you can link libcrfsuite.tbd in your project. I haven't tried linking against Apple's version myself though (still linking against my own from source). Quickly taking a look though I don't see the header file for libcrfsuite. I imagine crfsuite.h would be in usr/include somewhere. Not sure what's up with that. I was hoping to convert a model to CoreML and use it with NLTagger because I imagine it would use a lot less memory though the CRFSuite model I'm using isn't too big so I'm going to use it as is for now rather than trying to retrain the entire thing with CoreML because I got a million other things to do. As a sidetone, I haven't really been able to do much with CoreML. All the models I'm interested in using in my app don't work with it. Overall I've had a much easier time using ONNX. But for this model I'm sticking with CRFSuite for now.

coremltools doesn't appear to support this. Looks like the answer is no.

I think what I need is to call -playerTimeForNodeTime: in the tap block to get the time relative to the buffer scheduled on the player node.

if (platform.noUIKitOnlySwiftUIAvailable) { abort(); }

Here is a workaround: // In a NSTextField subclass. -(BOOL)sendAction:(SEL)action to:(id)target { if (action == @selector(performClose:)) { return NO; } else { return [super sendAction:action to:target]; } }