"UI unresponsiveness" warning on @main

  • ">

  • Sama here, Xcode 14.2.

Add a Comment

Apple Recommended

  • I've replied back below. please note

  • I updated to OS 13.0.1 and Xcode to 14.1. My app now reports this same error "This method can cause UI unresponsiveness if invoked on the main thread. Instead, consider waiting for the -locationManagerDidChangeAuthorization: callback and checking authorizationStatus first." and traces it to this bit of code:

    if CLLocationManager.locationServicesEnabled(). So, I implemented the suggested fix, but the complier says that authorizationStatus was deprecated in iOS 14.0

  • this is not helpful at all

Add a Comment

Replies

Same here after update to Xcode 14.0 today

Same issue is there any Fix for this?

In my case, I spotted the error on line 2, in viewDidLoad (but same issue if put elsewhere like viewDidAppear):

1.         guard let url = URL(string: "https://google.com") else {return}
2.         myWebView.load(URLRequest(url: url))

Problem: load MUST run on main thread (dispatching to another queue causes run time crash) WKWebView.load(_:) must be used from main thread only

Dispatching to main.async, logically does not change anything. That occurs in Xcode 14 / iOS 16 simulator. Also occurs with Xcode 13.4.1 / iOS 16. No such error message in Xcode 13.4.1 / iOS 15.5 So that's a new warning in iOS 16. I read there is a solution by prelaoding, but did not test yet. https://coderwall.com/p/trjkcg/preloading-uiwebview-or-wkwebview-in-swift

It is just a warning, if it works OK on real app, I think we should just ignore it.

Same for me with WKWebView

Same issue. What is going on with Xcode?

  • Same issue...Xcode 14.0 - on code that has been working for years. No clue how to solve it.

Add a Comment

Same issue. How to fix it ?

I am seeing the problem with the simulator..but not when running on a real iPad..

Simulator Version 14.0 (986.3) SimulatorKit 624 CoreSimulator 857.7

I have a SwiftUI App that displays an animated gif from a weather api, using UIViewRepresentable and WKWebView. I also get this warning. I'm using the Xcode RC. I've checked the preloading solution, but not sure how I can apply this to an App with SwiftUI lifecycle.

Same purple security warning in Xcode 14 (latest release) here. "This method should not be called on the main thread as it may lead to UI unresponsiveness."

In my case I've traced it to a WKWebView -> loadRequest:, i.e. called from my main ViewController's -> viewDidLoad:

i.e. I load a web view at app startup, as after launch/splash screen it's the first view user will see. I'm careful about accounting for network issues and will timeout (or not even try loading), display an alternative screen, etc. if there are network issues.

I'm going to assume someone on the Xcode team chose to add this warning in the event a developer doesn't account for slow loading or not loading at all an initial wkwebview when the app first launches?

Any other theories? Is it safe to ignore the warning?

same issue here

In my case, the app works fine (even with this warnings), but image are loaded but a bit slow than before, just the other places where this warning is shown :(.

purple warning:

This method can cause UI unresponsiveness if invoked on the main thread. Instead, consider waiting for the -locationManagerDidChangeAuthorization: callback and checking authorizationStatus first.   

code:

    if(CLLocationManager.locationServicesEnabled())     {       locationManager.requestLocation()     }

     

however!

did not happen until xcode 14 upgrade,

i now have auto update off, Murphy's law got me :0)      

  • I'm seeing this same warning in a UIKit app, but not with similar code in a SwiftUI app...

Add a Comment

I want to resolve purple warning. I use WkWebView. Anyone have a solution?

purple warning: This method should not be called on the main thread as it may lead to UI unresponsiveness.

same issue

Same here! Happened after upgrading iOS and Xcode.

"This method can cause UI unresponsiveness if invoked on the main thread. Instead, consider waiting for the -locationManagerDidChangeAuthorization: callback and checking authorizationStatus first."