Xcode 14 & iOS 16 purple warnings starting with "[Security] This method should not .. "

The warning is displayed there, but problem could originate elsewhere.

Could you provide more details, possibly a screenshot ?

Same purple warning in Xcode 14 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 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?

Please see the information provided in another thread.

I have this problem also. I develop Ionic apps that use WKWebView and the problem did not materialize until iOS 16.

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)

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

I want to make sure we’re all on the same page here, so I created a tiny test project with a WKWebView and reproduced the problem. Here’s what I see when using Xcode 14.1 running on macOS 13.0 with the iOS 16.1 simulator:

When I click the disclosure triangle associated with the issue, I see this backtrace:

#0	… SecTrustEvaluateIfNecessary ()
#1	… SecTrustCopyCertificateChain ()
#2	… WebCore::CertificateInfo::containsNonRootSHA1SignedCertificate() const ()
#3	… WebKit::WebPageProxy::didCommitLoadForFrame(***::ObjectIdentifier<WebCore::FrameIdentifierType>, WebKit::FrameInfoData&&, WebCore::ResourceRequest&&, unsigned long long, ***::String const&, bool, WebCore::FrameLoadType, WebCore::CertificateInfo const&, bool, bool, std::__1::optional<WebCore::HasInsecureContent>, WebCore::MouseEventPolicy, WebKit::UserData const&) ()
#4	… WebKit::WebPageProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) ()
#5	… IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) ()
#6	… WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) ()
#7	… IPC::Connection::dispatchMessage(std::__1::unique_ptr<IPC::Decoder, std::__1::default_delete<IPC::Decoder> >) ()
#8	… IPC::Connection::dispatchIncomingMessages() ()
#9	… ***::RunLoop::performWork() ()
#10	… ***::RunLoop::performWork(void*) ()
#11	… __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ ()
#12	… __CFRunLoopDoSource0 ()
#13	… __CFRunLoopDoSources0 ()
#14	… __CFRunLoopRun ()
#15	… CFRunLoopRunSpecific ()
#16	… GSEventRunModal ()
#17	… -[UIApplication _run] ()
#18	… UIApplicationMain ()
#19	… UIApplicationMain(_:_:_:_:) ()
#20	… static UIApplicationDelegate.main() ()
#21	… static AppDelegate.$main() at /Users/quinn/Desktop/Test714467/Test714467/AppDelegate.swift:10
#22	… main ()

So, let’s break this down:

• Modern versions of Xcode have a diagnostic feature that checks for potential hangs. Specifically, it looks for folks calling APIs on the main thread that might block waiting for a network request. That makes sense because, if the network is slow, such calls can cause your app to be unresponsive. In the worst case, it may even cause your app to be killed by the watchdog. See QA1693 Addressing watchdog terminations for more on that.

• SecTrustCopyCertificateChain is one such API. In order to build the chain of trust, the trust object may hit the network for various reasons.

• WKWebView calls SecTrustCopyCertificateChain on the main thread (see frames 2 through 1 in the backtrace) and that raises this issue.

• If you look deeper in the backtrace you’ll see that none of your code appears there, which is a strong indication that you’ve done nothing to trigger this.

• This issue may or may not be a real problem depending on how the trust object is configured. You can configure the trust object to prevent any networking (SecTrustSetNetworkFetchAllowed).

• You can also use SecTrustEvaluateAsync to avoid blocking.

• And if you evaluate the trust object asynchronously or on a secondary thread beforehand, your call to SecTrustCopyCertificateChain will never hit the network.

• But none of these are relevant here because it’s not your code doing the evaluation.

• The Security tag on this issue doesn’t mean that it’s a security problem, but rather a problem associated with the Security framework.

• The poor interaction between WKWebView, Security framework, and this Xcode feature is a known issue (r. 94019453). We plan to address it at some point but I don’t have any info to share as to when that’ll happen.

• In the meantime, if you see an issue like this, look at its associate backtrace. If it’s made up entirely of system code (except for main) it’s likely that this isn’t your problem and you should feel free to ignore the issue.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you Quinn! Your note is the only reply from Apple that explains the issue and why you can safely ignore the warning when our code is not involved. Thank you! Other Apple folks have addressed this in other threads but provide only a robotic answer to file a feedback report. You da man!

Here's another datum. I propose to follow the "it’s likely that this isn’t your problem and you should feel free to ignore the issue" advice but this is an occurrence not involving WKWebView.

I get no less that 8 occurrences of the warning from a use of UIContext. Though I may agree it would be better not to use it on the main thread, 8 warnings seems a little excessive. I did try obtaining the NSURL separately into a variable fed into this statement but (unsurprisingly) that made no difference.

Xcode 14.2, macOS Ventura 13.2, targeting macOS 10.14.

As I’ve discussed above, a screen shot of the issue doesn’t reveal the whole story. What’s the full backtrace you get when you click the disclosure triangle associated with the issue?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

@eskimo

Is this issue resolved in Xcode 14.2?

Nope, still getting a bunch of these in 14.2...

Using a WKWebView and not much else. Ignoring for now after the post by @eskimo above.

In reply to The Eskimo, 6 days ago:

Sorry for the delay in replying, I've been away.

OK, I thought I had pressed the disclosure triangle to show the 8 identical errors but I've found it now (below). Note that I have changed my CIImage code and am now using CGImage but with the same issue. Xcode is 14.2, I have no earlier reference as it's new code. As you can probably see, the code is in a method run from a block invoked by a Save panel when the user clicked on 'Save'.

Since the backtrace does include my code, Perhaps I can't just ignore it; it seems to be CGImageDestinationFinalize causing the issue. Odd that I get 8 copies of the report though.

@eskimo - this also happens in a SwiftUI app that I've made responsive to AppleScript commands (using NSScriptCommand). Whenever I issue it an AppleScript command it will complain abut UI responsiveness (which isn't wrong per se - as AppleScript is running on the main thread, but is there any other option?)

frustrating issue from Apple Xcode 14.