macOS 12.4 problem is still there.

I opened a ticket with Apple and they told me that the problem was indeed in the Safari engine and this problem is OS level, it has nothing to do with our app. I did as they told me and opened another ticket on somewhere else. I explained the crash in details with multiple crash dump. The problem has appeared in macOS Monterey, it was not there previously. macOS 12.4 does not solve the problem. If you want to see my problem look for : "Mac Catalyst WKWebview random crash since Monterey"

Problem         //Warning : 'contentEdgeInsets' was deprecated in iOS 15.0:         //           This property is ignored when using UIButtonConfiguration         /*uiButton.contentEdgeInsets = UIEdgeInsets(top:    8.0, left:   8.0, bottom: 8.0,right:  8.0 ) Solution uiButton.configuration!.contentInsets = NSDirectionalEdgeInsets(top: 8.0, leading: 8.0, bottom: 8.0, trailing: 8.0) Apple has finally given access to "uiButton.configuration!.contentInsets" in their latest Xcode update. It now woks on iOS and macCatalyst.

Ignore my comment above, it does not work at all. Can't delete and cannot edit my previous post.

MacOS 12.5 problem is still there. Some of our customers cannot use our app because webview will crash for them all the time. WKWebview on macCatalyst is broken and Apple are not fixing it.

There should be a function to set the WKWebview in focus. Because if the javascript set the focus to an input box, it will only work if you click first on the webview to make it the current focus.

This is not working.

Your solution is not a real solution (at best it is part of a possible solution). It does not work anyways. Probably your code is incomplete or the useful information is not there. No idea where to put your code, do I need to set a compiler flag? But swizzling may be the path to a solution. It is really scary that Apple knows about the problem and are too lazy to fix it. Our customers are suffering from that problem. They have to use our iOS version or return to Windows version of our app. If I look a real swift swizzling, it does not look like what you are doing. https://www.guardsquare.com/blog/swift-native-method-swizzling I will investigate a working solution out of the idea of replacing a function to override the UITextInputTraits. Thanks for the tip.

In your solution, you made the call as a static function, but your function is not static. Is this function supposed to be called often as we navigate the webpages or only once? This function is only called once on my side and it is from my own call in didFinishLaunchingWithOptions. Thanks for your time, I really appreciate.

I juste received a confirmation directly from Apple that the problem is fixed in macOS 13 beta and that the fix will be in the final macOS 13 releasing this October. Response from Apple : <<Thank you for the feedback. As mentioned we've identified the issue and have addressed it. This fix is in the current beta. However, if don't want to install the current beta, which we understand, you can wait until the official release of macOS 13. (Which will also include the fix).>> PS : I never had the problem myself (almost all my customers had the problem at some point) that is why I did not want to install the beta version.

We require our customers to always use the latest version of our app to access our cloud and the latest version of our app always requires the latest version of iOS and macOS (latest os version is always the minimum). We imposed that from day one so our customers are used to it. It is irresponsible for a person to use a computer that is not updated (then expect to have a perfectly working app). Apple users are already 90% up to date all the time anyways. If people don't want to update their computer and stay 15 years behind, they can always return to Windows. We release an update every 2 weeks. As a developper that is always on the latest version, I can't support an OS version that I don't have myself. Everyone can have the latest version, but no one can return on an older version. Already on our windows version, it is difficult to support all those different version and flavour of Windows. So the Windows version is always lagging 5 years behind the Apple version of our app. I guess if you use Windows, you know you are on an abandoned legacy platform. So Windows users have low expectations. I guess if your customers don't want to update, it is their problem and not yours. This is 2022 (2023 soon), the computer world is now walk or die. We don't have an Android version because Android people can't have the latest Android. The most expensive Samsung phone is 1 year behind the Google Android version, next year they will get another update, but it will still be 1 year behind, then they will never get any update. That is why companies makes app for iOS first, then if they have time to loose, they port to Android. Because we make feature packed app, we need the latest SDK features and on Android you need to target 5 years old Android and use 5 years old Android SDK. We go even further by telling our users, if you can't update your OS, you need to buy a new Mac, iPad or iPhone. Everyone should only support the latest OS version, so people would stop complaining.

Same problem came out of nowhere, the app still work great. After I updated macOS to Ventura 13.0 and Xcode I get this warning. "This method should not be called on the main thread as it may lead to UI unresponsiveness." Weird that Xcode does not propose a solution. I suspect it is just an Xcode bug.

I just use the stock Apple iOS and macOS Catalyst libraries and I got this message after updating to macOS Ventura 13.0 and Xcode. My project was fine for 3 years and now I get this weird Security issue. Security This method should not be called on the main thread as it may lead to UI unresponsiveness. (purple warning)

I have a similar message, yet everything is working fine. [aqme]            AQMEIO_HAL.cpp:1211  Error 2003332927('who?')  getting headset info or AQMEIO_HAL.cpp:736 kAudioDevicePropertyMute returned err 2003332927 depending if I chose my headphones or the monitor sound on macOS.

I found another problem that is caused by the lack on onKeyDown working on Mac Intel. Tab key is not working, so you can't jump to next input box by pressing Tab key. You can test with this page. Put the cursor in the first input box and press tab. It works everywhere on the planet, but it won't work on a WKWebview on a MacOS Ventura running on Intel. https://www.w3schools.com/html/html_forms.asp