Hello there, We currently have a crash in prod when executing the following line: let classificationRequest = try SNClassifySoundRequest(classifierIdentifier: .version1) It appears to only happen on iOS 17+ and only when regaining audio focus after an interruption in a background state. We are aware this call probably fails because it is happening from a background state - however - I would expect then that the SNClassifySoundRequest throws some kind of error since it is already an initializer that throws. If it is possible for the call to fail under certain circumstances, then could SNMLModelFactory throw an error instead of using try! ? Full trace below: SoundAnalysis/SNMLModelFactory.swift:112: Fatal error: 'try!' expression unexpectedly raised an error: Error Domain=com.apple.CoreML Code=0 "Failed to build the model execution plan using a model architecture file '/System/Library/Frameworks/SoundAnalysis.framework/SNSoundClassifierVersion1Model.mlmodelc/model1/model.espresso.net' with error code: -1." UserInfo={NSLocalizedDescription=Failed to build the model execution plan using a model architecture file '/System/Library/Frameworks/SoundAnalysis.framework/SNSoundClassifierVersion1Model.mlmodelc/model1/model.espresso.net' with error code: -1.}

With the release of UIHostingConfiguration for iOS 16 and above, I've seen a few different blog posts and libraries that try to back-port this functionality to older iOS versions. All of the solutions I've come across will have a UIHostingController inside of the cell and will sometimes have some kind of attempt to handle the parent/child relationship of the ViewController. Would this approach be recommended or would it be considered a misuse of the UIHostingController? Is something similar happening under the hood with UIHostingConfiguration? Here is one example of an implementation you can find online: https://gist.github.com/kylebrowning/044b837a9a98135a15ccbb34f664e31f