32

Just like this question: Auto Layout and in-call status bar and this question: Resize for in-call status bar?, I am having issues with the In Call Status Bar screwing up my view layout.

Here is my nested structure. I have a Custom Modal ViewController that is nested within another ViewController. Whenever the In Call Status Bar is shown (and then closed out of), this is what happens:

enter image description here

Here is a picture of what it should look like before the In Call Status Bar is shown:

enter image description here

The background blue color of the status bar after the bug occurs is the background color of the root view controller.

Whenever an In Call Status Bar is shown, the following error is printed out:

Unable to simultaneously satisfy constraints.
    Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints) 
(
    "<NSLayoutConstraint:0x7fdac6192320 V:|-(20)-[UIInputSetContainerView:0x7fdac6190a40]   (Names: '|':UITextEffectsWindow:0x7fdac6061a10 )>",
    "<NSLayoutConstraint:0x7fdac608ebb0 'UIInputWindowController-top' V:|-(0)-[UIInputSetContainerView:0x7fdac6190a40]   (Names: '|':UITextEffectsWindow:0x7fdac6061a10 )>"
)

Will attempt to recover by breaking constraint 
<NSLayoutConstraint:0x7fdac6192320 V:|-(20)-[UIInputSetContainerView:0x7fdac6190a40]   (Names: '|':UITextEffectsWindow:0x7fdac6061a10 )>

Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.

Unable to simultaneously satisfy constraints.
    Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints) 
(
    "<NSLayoutConstraint:0x7fc60b03d230 V:|-(20)-[UIInputSetContainerView:0x7fc608d22020]   (Names: '|':UITextEffectsWindow:0x7fc60b171720 )>",
    "<NSLayoutConstraint:0x7fc60b03d2d0 UIInputSetContainerView:0x7fc608d22020.bottom == UITextEffectsWindow:0x7fc60b171720.bottom>",
    "<NSLayoutConstraint:0x7fc60b17c4b0 'UIInputWindowController-height' UIInputSetContainerView:0x7fc608d22020.height == UITextEffectsWindow:0x7fc60b171720.height>"
)

Will attempt to recover by breaking constraint 
<NSLayoutConstraint:0x7fc60b03d2d0 UIInputSetContainerView:0x7fc608d22020.bottom == UITextEffectsWindow:0x7fc60b171720.bottom>

Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.

Using FLEX debugging tool I can see that

UINavigationBarBackground and UIStatusBarForegroundView overlap before the In Call Status Bar, however afterwards UINavigationBarBackground is below UIStatusBarForegroundView.

This bug only occurs AFTER I present the Modal View Controller. If I show the In Call Status Bar, then the issue does not occur. You cannot go back to the root view controller after the Modal View Controller is shown.

What can I do to fix this?

Will Hua
  • 1,729
  • 2
  • 23
  • 33
  • Just to confirm that you are not alone. Myself, I work quite often with personal hotspot, so I have this auto layout error every time hot spot is on with its blue status bar in portrait orientation. When starting in landscape mode though, when blue bar is only 20px, this error doesn't happen. – Stanislav Dvoychenko Oct 15 '15 at 10:45
  • I have been dealing with this exact same error for a while. Unfortunately I haven't been able to find a fix. The only work around I have been able to come up with is to hide the status bar all together when displaying the custom modal view and then unhiding the status bar when closing the modal view. – denvdancsk Oct 19 '15 at 16:47
  • Great question. Did any of the solutions help you? Please select the correct answer. – serge-k Feb 24 '16 at 19:53
  • No, I wasn't able to fix this issue. It seemed that the issue went away if I didn't use a ModalViewController so I switched up my View hierarchy a bit. – Will Hua Feb 25 '16 at 00:31

4 Answers4

12

iOS 9.2.1, Xcode 7.2.1, ARC enabled

UPDATE 3/25/2016: Conflict still exists in Xcode 7.3, iOS 9.3.

Summary: In the window hierarchy for your application there are various windows that get added onto the application window. In my case, this was the UITextEffectsWindow and the UIRemoteKeyboardWindow. These windows come with preconfigured constraints. It seems there is a bug that updates some vertical layout constraints, but not other related constraints for the same window. This throws the constraints conflict in debugger. This happens when a custom window gets added to the window hierarchy or when the in-call status bar gets toggled in or out, on both the simulator and the actual iOS device.

The constraints are priority 1000, this indicates that they are required constraints.

The solution below will remove the conflicting constraint and add it back once the in-call status bar is toggled out.

EDIT 2/25/2016: Neither solution solves the problem of having the in-call status bar already displayed when opening app. The conflict happens before the change in status bar is registered.

It appears that this constraint conflict happens only the first time the in-call status bar is shown (this is most common), or in other scenarios involving the presentation of an additional custom window that would sit on top of the key window. I also tried just creating a blank single view application and with adding nothing toggling in the in-call status bar, and I got the same constraint conflict.

I think it is a bug and is discussed on the Dev forums. The original article from the Dev forums can be found here (as matty pointed out):

https://forums.developer.apple.com/thread/16375

I wanted to expand a little on matty's answer here. Which I found very helpful. I am not sure what impact removing "all" the constraints would cause, so I removed just the conflicting constraints. My reasoning being that the conflicting constraint will be broken anyway as the debugger informs "Will attempt to recover by breaking constraint"; so the constraint will serve no purpose anyway.

Here are the constraint conflict errors I was receiving:

enter image description here

enter image description here

After interpreting the constraint errors (see this apple document to help with that: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/DebuggingTricksandTips.html) I used the following code to get rid of the conflicting constraints:

Objective-C:

*AppDelegate.h

...

@interface YourAppName : UIResponder <UIApplicationDelegate>
{
    NSMutableDictionary *dictionaryConstraints;
}

...

*AppDelegate.m

...

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    // Override point for customization after application launch.

    dictionaryConstraints = [[NSMutableDictionary alloc] init];

    return true;

}

- (void)application:(UIApplication *)application willChangeStatusBarFrame:(CGRect)newStatusBarFrame
{
   NSLog(@"newStatusBarFrame: %@", NSStringFromCGRect(newStatusBarFrame));

   if (newStatusBarFrame.size.height > 20.0)
   {
        for (UIWindow *window in [[UIApplication sharedApplication] windows])
        {
            if ([window.class.description isEqual:@"UITextEffectsWindow"] || [window.class.description isEqual:@"UIRemoteKeyboardWindow"])
            {
                NSMutableArray *constraints = [[NSMutableArray alloc] initWithCapacity:[window.constraints count]];

                for (NSLayoutConstraint *constraint in window.constraints)
                {
                    if (!([constraint.description rangeOfString:@"V:|-(0)-[UIInputSetContainerView"].location == NSNotFound))
                    {
                        NSLog(@"");
                        NSLog(@"%@: %@, %f, %f", window.class.description, constraint.description, constraint.priority, constraint.constant);
                        NSLog(@"");

                        [constraints addObject:constraint];
                        [window removeConstraint:constraint];
                    }
                    else
                    {
                        nil;
                    }
                }

                if ([constraints count] > 0)
                {
                    [dictionaryConstraints setObject:constraints forKey:[NSString stringWithFormat:@"%p", window]];
                }
                else
                {
                    nil;
                }
            }
            else
            {
                nil;
            }
        }
    }
    else
    {
        nil;
    }
}

- (void)resetConstraints
{
    for (UIWindow *window in [[UIApplication sharedApplication] windows])
    {
        if ([window.class.description isEqual:@"UITextEffectsWindow"] || [window.class.description isEqual:@"UIRemoteKeyboardWindow"])
        {
            if (dictionaryConstraints)
            {
                NSArray *keys = [dictionaryConstraints allKeys];

                for (int i = 0; i < [keys count]; i++)
                {
                    if ([[NSString stringWithFormat:@"%p", window] isEqualToString:keys[i]])
                    {
                        [window addConstraints:[dictionaryConstraints objectForKey:keys[i]]];
                    }
                    else
                    {
                        nil;
                    }
                }
            }
            else
            {
                nil;
            }
        }
        else
        {
            nil;
        }
    }
}

- (void)application:(UIApplication *)application didChangeStatusBarFrame:(CGRect)oldStatusBarFrame
{
    NSLog(@"oldStatusBarFrame: %@", NSStringFromCGRect(oldStatusBarFrame));

    if (oldStatusBarFrame.size.height > 20.0)
    {
        if ([dictionaryConstraints count] > 0)
        {
            [self resetConstraints];
            [dictionaryConstraints removeAllObjects];
        }
        else
        {
            nil;
        }
    }
    else
    {
        nil;
    }

    for (UIWindow *window in [[UIApplication sharedApplication] windows])
    {
        if ([window.class.description isEqual:@"UITextEffectsWindow"] || [window.class.description isEqual:@"UIRemoteKeyboardWindow"])
        {
            for (NSLayoutConstraint *constraint in window.constraints)
            {
                if (!([constraint.description rangeOfString:@"V:|-(0)-[UIInputSetContainerView"].location == NSNotFound))
                {
                    NSLog(@"");
                    NSLog(@"%@: %@, %f, %f", window.class.description, constraint.description, constraint.priority, constraint.constant);
                    NSLog(@"");
                }
                else
                {
                    nil;
                }

            }
        }
        else
        {
            nil;
        }
    }
}

...

Swift:

*AppDelegate.swift

...

var dictionaryConstraints = [NSString : NSArray]();

...

func application(application: UIApplication, willChangeStatusBarFrame newStatusBarFrame: CGRect)
{
    print("newStatusBarFrame: \(newStatusBarFrame)")

    if newStatusBarFrame.size.height > 20.0
    {
        for window in UIApplication.sharedApplication().windows
        {
            if ((window.classForCoder.description() == "UITextEffectsWindow") || (window.classForCoder.description() == "UIRemoteKeyboardWindow"))
            {
                var constraints = [NSLayoutConstraint]()

                for constraint in window.constraints
                {
                    if (constraint.description.containsString("V:|-(0)-[UIInputSetContainerView"))
                    {
                        print("\(window.classForCoder.debugDescription), \(constraint.description), \(constraint.priority), \(constraint.constant)")

                        constraints.append(constraint)
                        window.removeConstraint(constraint)
                    }
                    else
                    {
                        //nil
                    }
                }

                if (constraints.count > 0)
                {
                    dictionaryConstraints[NSString(format: "%p", unsafeAddressOf(window))] = constraints
                }
                else
                {
                    //nil
                }
            }
            else
            {
                //nil
            }
        }
    }
    else
    {
        //nil
    }
}

func resetConstraints()
{
    for window in UIApplication.sharedApplication().windows
    {
        if ((window.classForCoder.description() == "UITextEffectsWindow") || (window.classForCoder.description() == "UIRemoteKeyboardWindow"))
        {
            if (dictionaryConstraints.count > 0)
            {
                let keys = Array(dictionaryConstraints.keys)

                for i in 0 ..< keys.count
                {
                    if (NSString(format: "%p", unsafeAddressOf(window)) == keys[i])
                    {
                        window.addConstraints(dictionaryConstraints[keys[i]] as! [NSLayoutConstraint])
                    }
                    else
                    {
                        //nil
                    }
                }
            }
            else
            {
                //nil
            }
        }
        else
        {
            //nil
        }
    }
}

func application(application: UIApplication, didChangeStatusBarFrame oldStatusBarFrame: CGRect)
{
    print("oldStatusBarFrame: \(oldStatusBarFrame)")

    if (oldStatusBarFrame.size.height > 20.0)
    {
        if (dictionaryConstraints.count > 0)
        {
            self.resetConstraints()
            dictionaryConstraints.removeAll()
        }
        else
        {
            //nil
        }
    }
    else
    {
        //nil
    }

    for window in UIApplication.sharedApplication().windows
    {
        if ((window.classForCoder.description() == "UITextEffectsWindow") || (window.classForCoder.description() == "UIRemoteKeyboardWindow"))
        {
            for constraint in window.constraints
            {
                if (constraint.description.containsString("V:|-(0)-[UIInputSetContainerView"))
                {
                    print("\(window.classForCoder.debugDescription), \(constraint.description), \(constraint.priority), \(constraint.constant)")
                }
                else
                {
                    //nil
                }
            }
        }
        else
        {
            //nil
        }
    }
}

...

Note: This keeps all constraints that are not conflicting. And adds the removed conflicting constraints back in after the conflicting situation is no more, namely the in-call status bar is toggled out.

UPDATE 2/25/2015: Further testing...

I decided to isolate the changing constraints using two methods in the app. delegate *.m file:

...

- (void)application:(UIApplication *)application willChangeStatusBarFrame:(CGRect)newStatusBarFrame
{
    NSLog(@"New status bar frame: %@", NSStringFromCGRect(newStatusBarFrame));

    for (UIWindow *window in [[UIApplication sharedApplication] windows])
    {
        NSLog(@"%@, %@", window.description, window.constraints);
    }
}

- (void)application:(UIApplication *)application didChangeStatusBarFrame:(CGRect)oldStatusBarFrame
{
    NSLog(@"Old status bar frame: %@", NSStringFromCGRect(oldStatusBarFrame));

    for (UIWindow *window in [[UIApplication sharedApplication] windows])
    {
        NSLog(@"%@, %@", window.description, window.constraints);
    }
}

...

When the in-call status bar toggles in, the conflicting constraints change from:

UITextEffectsWindow:

< UITextEffectsWindow: 0x7fbf994cc810; frame = (0 0; 320 568); opaque = NO; autoresize = W+H; layer = < UIWindowLayer: 0x7fbf994c8470> >,

( "< NSLayoutConstraint:0x7fbf99667eb0 V:|-(0)-[UIInputSetContainerView:0x7fbf99668ce0] (Names: '|':UITextEffectsWindow:0x7fbf994cc810 )>",

...omitted

"< NSLayoutConstraint:0x7fbf9966c800 'UIInputWindowController-top' V:|-(0)-[UIInputSetContainerView:0x7fbf99668ce0] (Names: '|':UITextEffectsWindow:0x7fbf994cc810 ) >",

...omitted )

UIRemoteKeyboardWindow:

< UIRemoteKeyboardWindow: 0x7fbf994ceb80; frame = (0 0; 320 568); opaque = NO; autoresize = W+H; layer = < UIWindowLayer: 0x7fbf994cf190> >,

( "< NSLayoutConstraint:0x7fbf994cfb20 V:|-(0)-[UIInputSetContainerView:0x7fbf99744ec0] (Names: '|':UIRemoteKeyboardWindow:0x7fbf994ceb80 ) >",

...omitted

"< NSLayoutConstraint:0x7fbf9966c800 'UIInputWindowController-top' V:|-(0)-[UIInputSetContainerView:0x7fbf99668ce0] (Names: '|':UITextEffectsWindow:0x7fbf994cc810 )>",

...omitted )

...and changes to:

UITextEffectsWindow:

< UITextEffectsWindow: 0x7fbf994cc810; frame = (0 0; 320 568); opaque = NO; autoresize = W+H; layer = < UIWindowLayer: 0x7fbf994c8470> >,

( "< NSLayoutConstraint:0x7fbf99667eb0 V:|-(20)-[UIInputSetContainerView:0x7fbf99668ce0] (Names: '|':UITextEffectsWindow:0x7fbf994cc810 )>",

...omitted

"< NSLayoutConstraint:0x7fbf9966c800 'UIInputWindowController-top' V:|-(0)-[UIInputSetContainerView:0x7fbf99668ce0] (Names: '|':UITextEffectsWindow:0x7fbf994cc810 ) >",

...omitted )

UIRemoteKeyboardWindow:

< UIRemoteKeyboardWindow: 0x7fbf994ceb80; frame = (0 0; 320 568); opaque = NO; autoresize = W+H; layer = < UIWindowLayer: 0x7fbf994cf190> >,

( "< NSLayoutConstraint:0x7fbf994cfb20 V:|-(20)-[UIInputSetContainerView:0x7fbf99744ec0] (Names: '|':UIRemoteKeyboardWindow:0x7fbf994ceb80 ) >",

...omitted

"< NSLayoutConstraint:0x7fbf9966c800 'UIInputWindowController-top' V:|-(0)-[UIInputSetContainerView:0x7fbf99668ce0] (Names: '|':UITextEffectsWindow:0x7fbf994cc810 )>",

...omitted )

To understand the visual formatting language read https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/VisualFormatLanguage.html

It appears that the vertical layout constraints in the format "Vertical Layout V:[topField]-XX-[bottomField]" changes from...

NSLayoutConstraint:0x7fbf99667eb0 V:|-(0)-[UIInputSetContainerView:0x7fbf99668ce0]

to...

NSLayoutConstraint:0x7fbf99667eb0 V:|-(20)-[UIInputSetContainerView:0x7fbf99668ce0]

...for both windows: UITextEffectsWindow and UIRemoteKeyboardWindow; however, ...

NSLayoutConstraint:0x7fbf9966c800 'UIInputWindowController-top' V:|-(0)-[UIInputSetContainerView:0x7fbf99668ce0]

...does not.

So from what I can deduce, the window adjusts its constraint to account for the added in-call status bar, but the UIInputWindowController does not. Therefore, the constraint conflict arrises.

But the plot thickens...

After the initial constraints conflict resulting from the in-calls status bar toggling, the constraints do not change, and the priority is the same, but the constraints conflict does not arise with further toggling of the in-call status bar in or out. But, this just because the initial conflict was already thrown.

Hope this helps! Cheers.

Thanks to all the original contributors.

Community
  • 1
  • 1
serge-k
  • 3,394
  • 2
  • 24
  • 55
  • 3
    Please don't think I am crazy for wasting so much time on troubleshooting a warning that is most likely a bug. I needed to learn about NSLayoutConstraints and the layout formatting language anyway. – serge-k Feb 26 '16 at 01:07
  • @HassanTaleb I do not have any yet. Give me a few days and I will - I am still learning the language. Maybe some one else does? Did you see matty's answer above? It might serve as a clue... http://stackoverflow.com/a/33411423/4018041 – serge-k Mar 24 '16 at 15:41
  • thx bro , but I get this error: Use of Unresolved Identifier 'dictionaryConstraints' – Hassan Taleb Mar 26 '16 at 06:29
  • After adding : `var dictionaryConstraints = NSMutableDictionary()` , I get this error : `Value of type 'NSMutableDictionary' has no member 'keys'` and this : `Value of type 'NSMutableDictionary' has no member 'removeAll'` – Hassan Taleb Mar 26 '16 at 06:33
  • After changing 'key' by 'allKeys' and 'removeAll' by 'removeAllObjects()' , I get an error in : `(NSString(format: "%p", unsafeAddressOf(window)) == keys[i])` , I changed it to `(NSString(format: "%p", unsafeAddressOf(window)) == keys[i] as! NSObject)` , the problem now is in: `window.addConstraints(dictionaryConstraints[keys[i]] as! [NSLayoutConstraint])` , the error message is : cannot subscribe a value of type 'Array' , this is the only error now – Hassan Taleb Mar 26 '16 at 06:40
  • @HassanTaleb Glad to help! I edited the answer, I think the root problem is that I left of that you have to add `var dictionaryConstraints = [NSString : NSArray]();` as an instance variable for the app. delegate. Then `let keys = Array(dictionaryConstraints.keys)` should work, okay. Not sure if this is best practice, but I am trying... Give that a try and let me know. It was a problem for me to play with an array of constraints, had to cast it to make it work. – serge-k Mar 26 '16 at 06:47
  • Please note that some of the print() and NSLog() statements can be omitted from the final solution, those are there just to show that the constraints are removed and then added back. – serge-k Mar 26 '16 at 06:52
  • Yes now the code works fine , but the black bar after toggle out the in-call status bar is still showing , this happens when I toggle In the call in the first VC then toggle it out in another VC , this images show the error: [https://www.dropbox.com/s/acc19mmykmmj2gt/Screen%20Shot%202016-03-26%20at%208.55.53%20AM.png?dl=0 and [https://www.dropbox.com/s/t0220wskphjzz25/Screen%20Shot%202016-03-26%20at%208.55.39%20AM.png?dl=0] – Hassan Taleb Mar 26 '16 at 07:07
  • When I toggle in for the first time I get : `newStatusBarFrame: (0.0, 0.0, 375.0, 40.0) (Function), , 1000.0, 0.0 (Function), , 1000.0, 0.0 oldStatusBarFrame: (0.0, 0.0, 375.0, 20.0)` – Hassan Taleb Mar 26 '16 at 07:14
  • And the toggle Out is : `newStatusBarFrame: (0.0, 0.0, 375.0, 20.0) oldStatusBarFrame: (0.0, 0.0, 375.0, 40.0) (Function), , 1000.0, 0.0 (Function), , 1000.0, 0.0 ` – Hassan Taleb Mar 26 '16 at 07:14
  • Without any toggle , the first launch of app, I get newStatusBarFrame: (0.0, 0.0, 0.0, 20.0) oldStatusBarFrame: (0.0, 0.0, 0.0, 0.0) – Hassan Taleb Mar 26 '16 at 07:16
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/107391/discussion-between-serge-k-and-hassan-taleb). – serge-k Mar 26 '16 at 07:24
  • @serge-k you said "Neither solution solves the problem of having the in-call status bar already displayed when opening app. The conflict happens before the change in status bar is registered." did you find any workaround for this situation? anyway your code works like a charm and I thank you for your work :) – Fabio Mignogna May 02 '16 at 11:47
  • @FabioMignogna Thank you, my pleasure. I have not, I was hoping that the recent updates to iOS and Xcode would solve this issue or at least answer the bug report submitted to apple https://forums.developer.apple.com/thread/16375, but unfortunately I have no good news to report. The key to solving this would be to find a way to detect that the in call status bar is up at app. launch, then implement similar constraint manipulation. But I have not found a way. I am still trying various methods from time to time. I'll update the post if I find a good solution. – serge-k May 02 '16 at 20:42
  • @serge-k Why are you putting `nil` in all your else blocks? I'm curious if it is a style choice, or if you have another reason for it, because I've never seen that before. Thank you. – Ryan Maloney May 12 '17 at 20:15
  • @RyanMaloney Hey Ryan, yeah for me its a style choice. Something I picked up from taking C/C++ classes from the same professor for 3 years. It works for me, as it is easier to identify nested if-else statements. But modern linter tools can help with that. The idea also is that I am not 100% sure what the compiler interprets for an omitted condition. What if during a version upgrade it sticks something funky in there after recompiling, etc. Does it take longer to execute the omitted condition or are they the same, or maybe the omitted case is better? Maybe the compiler ignores it. – serge-k May 12 '17 at 20:59
9

Swift version from @matty answer :

func application(application: UIApplication, willChangeStatusBarFrame newStatusBarFrame: CGRect) {
    for window in UIApplication.sharedApplication().windows {
        if window.dynamicType.self.description().containsString("UITextEffectsWindow") {
            window.removeConstraints(window.constraints)
        }
    }
}
jfgrang
  • 1,148
  • 13
  • 13
  • Quick and dirty, does the job when the in-call status bar is shown while the app is running, but if it's visible before the app launches, the warning will still be raised (as already noted by @serge-k) – lshepstone Mar 04 '16 at 12:49
3

Similar issue can also be found here: https://forums.developer.apple.com/thread/20632

I attempted the suggested workaround from that topic by implementing the snippet below in my AppDelegate. It seems to get rid of the constraint errors but I'm very reluctant to release an app with this as it is most certainly an Apple Bug.

Steps to reproduce:

  1. Create a new single view application in Xcode 7.1
  2. Run the app in an iOS 9.1 simulator
  3. Toggle the in-call bar (CMD+Y)
  4. You'll see 'Unable to simultaneously satisfy constraints.' error.

To get rid of the constraint error:

- (void)application:(UIApplication *)application willChangeStatusBarFrame:(CGRect)newStatusBarFrame {
    for(UIWindow *window in [[UIApplication sharedApplication] windows])
    {
        if([window.class.description isEqual:@"UITextEffectsWindow"])
        {
            [window removeConstraints:window.constraints];
        }  
    }
}

Personally I only used the above snippet to make sure the constraint errors weren't causing other constraint issues that I was having namely: black screens when the app was launched in the background. That turned out not to be the case.

matty
  • 190
  • 1
  • 5
  • +1 depending on what windows and constraints are causing the issue, you might adjust the code to include additional window classes and constraints, e.g UIRemoteKeyboardWindow. Or specify specific constraints to remove. – serge-k Feb 23 '16 at 22:27
  • 2
    I do not recommend doing this. You are removing constraints Apple created. The issue seems to be a bug and you don't know when Apple is going to fix it and when they does you might be removing constraints that is supposed to be there. – ThomasCle Feb 25 '16 at 07:41
0

All above seemed not simple solutions. I ran into the same trouble when I added the subview in viewDidLoad. I got round of it by moving the code into viewDidAppear. FYI.

firebear
  • 774
  • 1
  • 8
  • 19