Getting a "This application is modifying the autolayout engine from a background thread" error?

Swift Macos Autolayout Background Thread

Swift Problem Overview

Been encountering this error a lot in my OS X using swift: >"This application is modifying the autolayout engine from a background thread, which can lead to engine corruption and weird crashes. This will cause an exception in a future release."

I have a my NSWindow and I'm swapping in views to the contentView of the window. I get the error when I try and do a NSApp.beginSheet on the window, or when I add a subview to the window. Tried disabling autoresize stuff, and I don't have anything using auto layout. Any thoughts?

Sometimes it's fine and nothing happens, other times it totally breaks my UI and nothing loads

Swift Solutions

Solution 1 - Swift

It needs to be placed inside a different thread that allows the UI to update as soon as execution of thread function completes:

Modern Swift:

DispatchQueue.main.async {
    // Update UI
}

Older versions of Swift, pre Swift 3.

dispatch_async(dispatch_get_main_queue(){
    // code here
})

Objective-C:

dispatch_async(dispatch_get_main_queue(), ^{
    // code here
});

Solution 2 - Swift

You get similar error message while debugging with print statements without using 'dispatch_async' So when you get that error message, its time to use

Swift 4

DispatchQueue.main.async { //code }

Swift 3

DispatchQueue.main.async(){ //code }

Earlier Swift versions

dispatch_async(dispatch_get_main_queue()){ //code }

Solution 3 - Swift

The "this application is modifying the autolayout engine from a background thread" error is logged in the console long after the actual problem occured, so debugging this can be hard without using a breakpoint.

I used @markussvensson's answer to detect my problem and found it using this Symbolic Breakpoint (Debug > Breakpoints > Create Symbolic Breakpoint):

Symbols: [UIView layoutIfNeeded] or [UIView updateConstraintsIfNeeded]
Condition: !(BOOL)[NSThread isMainThread]

Build and run the app on the emulator and replicate the steps that lead to the error message being thrown (the app will be slower than usual!). Xcode will then stop the app and mark the line of code (e.g. the call of a func) that's accessing the UI from a background thread.

Solution 4 - Swift

When you try to update a text field value or adding a subview inside a background thread, you can get this problem. For that reason, you should put this kind of code in the main thread.

You need to wrap methods that call UI updates with dispatch_asynch to get the main queue. For example:

dispatch_async(dispatch_get_main_queue(), { () -> Void in
   self.friendLabel.text = "You are following \(friendCount) accounts"
})

EDITED - SWIFT 3:

Now, we can do that following the next code:

// Move to a background thread to do some long running work
DispatchQueue.global(qos: .userInitiated).async {
   // Do long running task here
   // Bounce back to the main thread to update the UI
   DispatchQueue.main.async {
      self.friendLabel.text = "You are following \(friendCount) accounts"
   }
}

Solution 5 - Swift

For me, this error message originated from a banner from Admob SDK.

I was able to track the origin to "WebThread" by setting a conditional breakpoint.

Then I was able to get rid of the issue by encapsulating the Banner creation with:

dispatch_async(dispatch_get_main_queue(), ^{
   _bannerForTableFooter = [[GADBannerView alloc] initWithAdSize:kGADAdSizeSmartBannerPortrait];
   ...
}

I don't know why this helped as I cannot see how this code was called from a non-main-thread.

Hope it can help anyone.

Solution 6 - Swift

I had this problem since updating to the iOS 9 SDK when I was calling a block that did UI updates within an NSURLConnection async request completion handler. Putting the block call in a dispatch_async using dispatch_main_queue solved the issue.

It worked fine in iOS 8.

Solution 7 - Swift

Had the same problem because I was using performSelectorInBackground.

Solution 8 - Swift

Main problem with "This application is modifying the autolayout engine from a background thread" is that it seem to be logged a long time after the actual problem occurs, this can make it very hard to troubleshoot.

I managed to solve the issue by creating three symbolic breakpoints.

Debug > Breakpoints > Create Symbolic Breakpoint...

Breakpoint 1:

Symbol: -[UIView setNeedsLayout]
Condition: !(BOOL)[NSThread isMainThread]

Breakpoint 2:

Symbol: -[UIView layoutIfNeeded]
Condition: !(BOOL)[NSThread isMainThread]

Breakpoint 3:

Symbol: -[UIView updateConstraintsIfNeeded]
Condition: !(BOOL)[NSThread isMainThread]

With these breakpoints, you can easily get a break on the actual line where you incorrectly call UI methods on non-main thread.

Solution 9 - Swift

You must not change the UI offside the main thread! UIKit is not thread safe, so that above problem and also some other weird problems will arise if you do that. The app can even crash.

So, to do the UIKit operations, you need to define block and let it be executed on the main queue: such as,

NSOperationQueue.mainQueue().addOperationWithBlock {

}

Solution 10 - Swift

Obviously you are doing some UI update on back ground thread. Cant predict exactly where, without seeing your code.

These are some situations it might happen:-

you might be doing something on background thread and not using. Being in the same function this code is easier to spot.

DispatchQueue.main.async { // do UI update here }

calling a func doing web request call on background thread and its completion handler calling other func doing ui update. to solve this try checking code where you have updated the UI after webrequest call.

// Do something on background thread
DispatchQueue.global(qos: .userInitiated).async {
   // update UI on main thread
   DispatchQueue.main.async {
                // Updating whole table view
                self.myTableview.reloadData()
            }
}

Solution 11 - Swift

I had this issue while reloading data in UITableView. Simply dispatching reload as follows fixed the issue for me.

    dispatch_async(dispatch_get_main_queue(), { () -> Void in
        self.tableView.reloadData()
    })

Solution 12 - Swift

I had the same problem. Turns out I was using UIAlerts that needed the main queue. But, they've been deprecated.
When I changed the UIAlerts to the UIAlertController, I no longer had the problem and did not have to use any dispatch_async code. The lesson - pay attention to warnings. They help even when you don't expect it.

Solution 13 - Swift

You already have the correct code answer from @Mark but, just to share my findings: The issue is that you are requesting a change in the view and assuming that it will happen instantly. In reality, the loading of a view depends on the available resources. If everything loads quickly enough and there are no delays then you don't notice anything. In scenarios, where there is any delay due to the process thread being busy etc, the application runs into a situation where it is supposed to display something even though its not ready yet. Hence, it is advisable to dispatch these requests in a asynchronous queues so, they get executed based on the load.

Solution 14 - Swift

I had this issue when I was using TouchID if that helps anyone else, wrap your success logic which likely does something with the UI in the main queue.

Solution 15 - Swift

It could be something as simple as setting a text field / label value or adding a subview inside a background thread, which may cause a field's layout to change. Make sure anything you do with the interface only happens in the main thread.

Check this link: https://forums.developer.apple.com/thread/7399

Solution 16 - Swift

I had the same issue when trying to update error message in UILabel in the same ViewController (it takes a little while to update data when trying to do that with normal coding). I used DispatchQueue in Swift 3 Xcode 8 and it works.

Solution 17 - Swift

If you want to hunt this error, use the main thread checker pause on issues checkbox. Fixing it is easy most of the times, dispatching the problematic line in the main queue.

Solution 18 - Swift

For me the issue was the following. Make sure performSegueWithIdentifier: is performed on the main thread:

dispatch_async (dispatch_get_main_queue(), ^{
  [self performSegueWithIdentifier:@"ViewController" sender:nil];
});

Solution 19 - Swift

Swift 4,

Suppose, if you are calling some method using operation queue

operationQueue.addOperation({
            self.searchFavourites()
        })

And suppose function searchFavourites is like,

func searchFavourites() {
     DispatchQueue.main.async {
                    //Your code
                }
}

if you call, all code inside the method "searchFavourites" on the main thread, it will still give an error if you are updating some UI in it.

> This application is modifying the autolayout engine from a background > thread after the engine was accessed from the main thread.

So use solution,

operationQueue.addOperation({
            DispatchQueue.main.async {
                self.searchFavourites()
            }
        })

For this kind of scenario.

Solution 20 - Swift

Here check out this line from the logs

$S12AppName18ViewControllerC11Func()ySS_S2StF + 4420

you can check that which function calling from the either background thread or where you are calling api method you need to call your function from the main thread like this.

DispatchQueue.main.async { func()}

> func() is that function you want to call in the result of api call > success or else.

Logs Here

This application is modifying the autolayout engine from a background thread after the engine was accessed from the main thread. This can lead to engine corruption and weird crashes.
 Stack:(
	0   Foundation                          0x00000001c570ce50 <redacted> + 96
	1   Foundation                          0x00000001c5501868 <redacted> + 32
	2   Foundation                          0x00000001c5544370 <redacted> + 540
	3   Foundation                          0x00000001c5543840 <redacted> + 396
	4   Foundation                          0x00000001c554358c <redacted> + 272
	5   Foundation                          0x00000001c5542e10 <redacted> + 264
	6   UIKitCore                           0x00000001f20d62e4 <redacted> + 488
	7   UIKitCore                           0x00000001f20d67b0 <redacted> + 36
	8   UIKitCore                           0x00000001f20d6eb0 <redacted> + 84
	9   Foundation                          0x00000001c571d124 <redacted> + 76
	10  Foundation                          0x00000001c54ff30c <redacted> + 108
	11  Foundation                          0x00000001c54fe304 <redacted> + 328
	12  UIKitCore                           0x00000001f151dc0c <redacted> + 156
	13  UIKitCore                           0x00000001f151e0c0 <redacted> + 152
	14  UIKitCore                           0x00000001f1514834 <redacted> + 868
	15  UIKitCore                           0x00000001f1518760 <redacted> + 104
	16  UIKitCore                           0x00000001f1543370 <redacted> + 1772
	17  UIKitCore                           0x00000001f1546598 <redacted> + 120
	18  UIKitCore                           0x00000001f14fc850 <redacted> + 1452
	19  UIKitCore                           0x00000001f168f318 <redacted> + 196
	20  UIKitCore                           0x00000001f168d330 <redacted> + 144
	21  AppName                        0x0000000100b8ed00 $S12AppName18ViewControllerC11Func()ySS_S2StF + 4420
	22  AppName                        0x0000000100b8d9f4 $S12CcfU0_y10Foundation4DataVSg_So13NSURLResponseCSgs5Error_pSgtcfU_ + 2384
	23  App NAme                        0x0000000100a98f3c $S10Foundation4DataVSgSo13NSURLResponseCSgs5Error_pSgIegggg_So6NSDataCSgAGSo7NSErrorCSgIeyByyy_TR + 316
	24  CFNetwork                           0x00000001c513aa00 <redacted> + 32
	25  CFNetwork                           0x00000001c514f1a0 <redacted> + 176
	26  Foundation                          0x00000001c55ed8bc <redacted> + 16
	27  Foundation                          0x00000001c54f5ab8 <redacted> + 72
	28  Foundation                          0x00000001c54f4f8c <redacted> + 740
	29  Foundation                          0x00000001c55ef790 <redacted> + 272
	30  libdispatch.dylib                   0x000000010286f824 _dispatch_call_block_and_release + 24
	31  libdispatch.dylib                   0x0000000102870dc8 _dispatch_client_callout + 16
	32  libdispatch.dylib                   0x00000001028741c4 _dispatch_continuation_pop + 528
	33  libdispatch.dylib                   0x0000000102873604 _dispatch_async_redirect_invoke + 632
	34  libdispatch.dylib                   0x00000001028821dc _dispatch_root_queue_drain + 376
	35  libdispatch.dylib                   0x0000000102882bc8 _dispatch_worker_thread2 + 156
	36  libsystem_pthread.dylib             0x00000001c477917c _pthread_wqthread + 472
	37  libsystem_pthread.dylib             0x00000001c477bcec start_wqthread + 4
)

Solution 21 - Swift

I also encountered this problem, seeing a ton of these messages and stack traces being printed in the output, when I resized the window to a smaller size than its initial value. Spending a long time figuring out the problem, I thought I'd share the rather simple solution. I had once enabled Can Draw Concurrently on an NSTextView through IB. That tells AppKit that it can call the view's draw(_:) method from another thread. After disabling it, I no longer got any error messages. I didn't experience any problems before updating to macOS 10.14 Beta, but at the same time, I also started modifying the code to perform work with the text view.

Content Type	Original Author	Original Content on Stackoverflow
Question	Mark	View Question on Stackoverflow
Solution 1 - Swift	Mark	View Answer on Stackoverflow
Solution 2 - Swift	Naishta	View Answer on Stackoverflow
Solution 3 - Swift	k06a	View Answer on Stackoverflow
Solution 4 - Swift	Jorge Luis Jiménez	View Answer on Stackoverflow
Solution 5 - Swift	markussvensson	View Answer on Stackoverflow
Solution 6 - Swift	spongessuck	View Answer on Stackoverflow
Solution 7 - Swift	Bobby	View Answer on Stackoverflow
Solution 8 - Swift	www.jensolsson.se	View Answer on Stackoverflow
Solution 9 - Swift	Chowdhury Md Rajib Sarwar	View Answer on Stackoverflow
Solution 10 - Swift	Ashish Pisey	View Answer on Stackoverflow
Solution 11 - Swift	ReshDev	View Answer on Stackoverflow
Solution 12 - Swift	epaus	View Answer on Stackoverflow
Solution 13 - Swift	Mukund Agarwal	View Answer on Stackoverflow
Solution 14 - Swift	Stu P.	View Answer on Stackoverflow
Solution 15 - Swift	Kiran P Nair	View Answer on Stackoverflow
Solution 16 - Swift	FN90	View Answer on Stackoverflow
Solution 17 - Swift	rockdaswift	View Answer on Stackoverflow
Solution 18 - Swift	Offek	View Answer on Stackoverflow
Solution 19 - Swift	Pramod More	View Answer on Stackoverflow
Solution 20 - Swift	Govind Wadhwa	View Answer on Stackoverflow
Solution 21 - Swift	Andreas detests censorship	View Answer on Stackoverflow