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

Question

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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         - gt  Void in         self tableView reloadData

User · Answer

Had the same problem  because I was using performSelectorInBackground

User · Answer

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

User · Answer

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

User · Answer

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         - gt  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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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  lt redacted gt    96     1   Foundation                          0x00000001c5501868  lt redacted gt    32     2   Foundation                          0x00000001c5544370  lt redacted gt    540     3   Foundation                          0x00000001c5543840  lt redacted gt    396     4   Foundation                          0x00000001c554358c  lt redacted gt    272     5   Foundation                          0x00000001c5542e10  lt redacted gt    264     6   UIKitCore                           0x00000001f20d62e4  lt redacted gt    488     7   UIKitCore                           0x00000001f20d67b0  lt redacted gt    36     8   UIKitCore                           0x00000001f20d6eb0  lt redacted gt    84     9   Foundation                          0x00000001c571d124  lt redacted gt    76     10  Foundation                          0x00000001c54ff30c  lt redacted gt    108     11  Foundation                          0x00000001c54fe304  lt redacted gt    328     12  UIKitCore                           0x00000001f151dc0c  lt redacted gt    156     13  UIKitCore                           0x00000001f151e0c0  lt redacted gt    152     14  UIKitCore                           0x00000001f1514834  lt redacted gt    868     15  UIKitCore                           0x00000001f1518760  lt redacted gt    104     16  UIKitCore                           0x00000001f1543370  lt redacted gt    1772     17  UIKitCore                           0x00000001f1546598  lt redacted gt    120     18  UIKitCore                           0x00000001f14fc850  lt redacted gt    1452     19  UIKitCore                           0x00000001f168f318  lt redacted gt    196     20  UIKitCore                           0x00000001f168d330  lt redacted gt    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  lt redacted gt    32     25  CFNetwork                           0x00000001c514f1a0  lt redacted gt    176     26  Foundation                          0x00000001c55ed8bc  lt redacted gt    16     27  Foundation                          0x00000001c54f5ab8  lt redacted gt    72     28  Foundation                          0x00000001c54f4f8c  lt redacted gt    740     29  Foundation                          0x00000001c55ef790  lt redacted gt    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

User · Answer

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

User · Answer

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

User · Answer

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

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

Examples related to swift

Examples related to macos

Examples related to autolayout

Examples related to background-thread