Mac Catalyst WKWebview random crash since Monterey

The problem is still there on macOS Monterey 12.3.1 Not everyone has that problem, I never had it myself on my 2 Macs. I would say 1 in a 10 or 1 in 100? We have 2 000 people using our app every day and I receive 1-2 call per week.

macOS 12.4 problem is still there.

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.

I have the exact same problem, a TestFlight user reported this problem on his Mac mini (M1, 2020). I can reproduce the problem on my MacBook Pro (13-inch, M1, 2020), both are running macOS Monterey. I open a WKWebview (login page) and as soon as I click inside the email textbox the whole app crashes. Is there at least any workaround available? It's a little bit annoying as it happens in the login page which means the user who purchased the app can't use it at all.

Not sure but it seems the issue is fixed in macOS Monterey 12.5.1 released on August 17? Not sure what changed but the issue doesn't occur anymore on my MacBook Pro. Can someone else confirm this?

@ShaddamIV i just added a workaround for this issue in my maccatalyst app. Please follow this solution [https://stackoverflow.com/a/73772508/4160680) Hopefully this will work for you also. I tried to set the autocorrectiontype to no for my textfield, but still it was crashing due to other properties like issecuretextfield or setting the keyboard type. This workaround fixed all these cases for me. Thanks

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.

@ShaddamIV Thanks for your feedback. I updated the answer.

We can put that function in AppDelegate class and then called it from delegate function like this. func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { AppDelegate.swizzleInputTraits() }

if you still face any issue with this code then I can help.

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.

That's great news. But still we need the hack as we can't force every customer to move to macOS 13.

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.