Frame for "Round Style Text Field" will be different at runt


I have repeated the steps in the first few pages several times and I keep getting the warning:

Frame for “Round Style Text Field” will be different at run time.

The text label has orange along the top and sides, and there is an orange vertical line through the background view with orange +1’s right below the text and right below “degrees Celsius”. First of all, how do I post an image of the screenshot I took on my computer?

Can anybody explain these particular orange indicators? What can I do to fix the problem? I am pretty sure I followed the steps correctly. I am selecting “All frames in Container”.


I observed somethings and found a way to fix it. But I am not sure why these things are happening.

In the last chapter, we horizontally aligned the 212 label in the container. We then selected all five labels and under the pin menu, we selected align horizontal centers. So then under the constraints I see that 212.centerX = centerX and 212.centerX = degrees Fahrenheit.centerX

The label degrees Fahrenheit.centerX is not determined and the other labels all have their .centerX constrained to degrees Fahrenheit.centerX. Why not have them all set to 212.centerX?

I don’t get a warning there, but I don’t understand how the degrees Fahrenheit.centerX knows what its horizontal alignment should be (and 212’s is listed twice – so which one prevails?).

Moving along in the beginning of chapter 4, a similar thing was going on (but 212 has now been replaced by the text) and I do get a warning.

In an attempt to fix this, I reset the label degrees Fahrenheit to be centered in container and updated all frames, and then the warning went away.

So when we select the text and the label degrees Fahrenheit and select horizontal centers as a constraint, why isn’t the label degrees Fahrenheit having its .centerX set to the value of the text’s centerX (since it has been centered in the container already). Do we have control of which one becomes the default for the horizontal alignment?

And if nobody else is having this issue, are there any suggestions for what I am initially doing wrong?



As you get more experience with constraints, you will come to realize that orange constraints mean !success! An orange constraint just means that the current position of the label is different than the position determined by the constraints. In a storyboard, Xcode does not automatically move the label into the position determined by the constraints. For instance, suppose you have a single label in the middle of a window, and you constrain the top of the label to be 10 from the top of the window, and you constrain the left of the label to be 5 from the left of the window. Those two constraints perfectly determine the position of the label–but the label will remain in the middle of the window, and the constraints will be orange because you have not told Xcode to move the label into the position determined by the constraints. That is a convenience for you.

The orange constraints mean that you have added enough constraints to perfectly determine the position of the label, but that you have not yet told Xcode to move the label into the position determined by the constraints–therefore at runtime when the app uses the constraints to position the label, the label will be in a different position than that shown in the storyboard. At run time, the storyboard doesn’t exist–all that exists are the constraints. In order to turn the orange constraints into blue constraints, all you have to do is Update Frames, which will instruct Xcode to move the label into the position determined by the constraints.

Another example: you move a label to the guide line indicating the center of the window. Then you constrain the center of the label to the center of the window. Next, you constrain the top of the label 50 from the top of the window. Those two constraints perfectly determine the position of the label–but the center constraint is orange. Why? It’s not easy to move a label and release it so that it exactly lines up with one of the guide lines. Often, you will be off by one pixel, which means the label needs to be moved by 1 pixel to be in the position determined by the centerX constraint, hence the orange constraint. An orange constraint will indicate how many pixels the actual position of the label is from the position determined by the constraint.

The idea is not to have move the labels into their pixel perfect positions and then try to come up with constraints to anchor them there. Rather, you only have to get things into their approximate positions, then pick the constraints you want, then click on Update Frames to move everything into their pixel perfect positions.

Well, if you say x = 2, and then you say y = x, how is it that y knows its value is 2? It’s the same principle with constraints. If you constrain the “212” label so that it is horizontally centered with relation to the window, and then you constrain the “degrees Fahrenheit” label so that its horizontal center lines up with the “212” label’s horizontal center, then the “degrees Fahrenheit” label will be centered in the window as well.

They both prevail. If they are different and they are in conflict, e.g. one constraint says the label should be 10 from the top and the other constraint says the label should be 20 from the top, then you will get red constraints. Xcode does not arbitrarily ignore one of your constraints.

Huh? If you align the horizontal centers of two labels, then their .centerX’s will be equal.

I don’t understand what that means, but one thing I always forget is that you are always lining things up with the “nearest neighbor”. For instance, if I select a Label and in the Pin menu, and I select the top bar, and I set it to 10, I always think to myself, "I’m pinning the label 10 from the top of the window–but that’s incorrect. What you are really are doing is pinning the label 10 from the nearest neighbor–that may be the top of the window, or it may be something else, like a button or a text field.

One reason you might constrain a group of labels to each other, then constrain the top label to the window is so that the group moves as a whole: if you constrain the top label to a different horizontal position, then the other labels will move with it. But there’s nothing preventing you from constraining each label independently, so that they won’t move as a group.

Edit: I think I understand what you mean now. The situation: you have three labels lined up vertically, and you want to constrain the middle label to the center of the window, then you want to constrain the other labels’ centerX to the middle labels centerX. Can you do that? The best way to find out is to start a new project, drag three labels onto the storyboard, give them the text:




and have at it. Post your results.


Thanks for the reply. I am still experimenting overall.

As for this part:

I don’t think this analogy applies. In that example, x is given a value and then y is given a value in terms of x. What I have going on is that the centerX of one label (degrees Fahrenheit) is not assigned at all. However, the label 212 has its centerX defined twice (one has centerX and one as the centerX of the label degrees Fahrenheit).

Furthermore, I don’t get a warning in chapter 3. But when I change the label to a text field (chapter 4), I do get a warning. When I set explicitly the centerX value of the label degrees Fahrenheit, the warning goes away. So I think the label not having its centerX set is important, but I don’t understand why I don’t get a warning in chapter 3 (when we had a label instead of a text field).

Based on your suggestion of taking three labels, I have come up with a conjecture. If you select all three labels and align their horizontal centers, their centerX values are based on one of the top two.

If you have say


then the centerX values of BBB and CCC become AAA.centerX.

But if you have say

_AAA (where _ represents a space)

then the centerX of AAA and CCC become BBB.centerX.

So it seems that which of top 2’s frame is the most to the left dictates the horizontal alignment. This is consistent with my observations about the label degrees Fahrenheit. Thanks for the suggestion.


@7stud7stud, I think you were right.

I looked at the size inspector for each of the labels. Under the label degrees Fahrenheit, it has Align Center X to: and it lists all of the other labels.

What threw me off is that under the constraints, it doesn’t say degrees Fahrenheit.centerX = … . I am used a = b in programming meaning that we set the value of a to be b (as oppose the the mathematical meaning of a = b). But it seems like the mathematical meaning might be intended here.


[quote]If you have say


But if you have say

AAA BBB CCC[/quote]
There’s no difference that I can discern between your two examples.

Ah. I think I know what you are talking about, something like this:

AAA.centerX = centerX AAA.centerX = BBB.centerX

Yeah, that’s not a Swift assignment statement, rather it’s just a shorthand note telling you that the constraints are equal. I was confused by that as well the first time I looked at a list of constraints: I couldn’t find some of the items when I looked down the left hand side of the equals signs, i.e. I was subconsciously treating them like Swift assignment statements, and I couldn’t figure out why the item I was looking for didn’t have its constraint listed. I searched the list too many times before I realized that the constraint I was looking for was on the right hand side of the equals sign.

Coincidentally, a few days ago I was looking through one of the menus, and you can actually switch the items on either side of the equals sign. Select the constraint–it’s easiest if you select the constraint in the storyboard’s table of contents–then look in the Attributes inspector. Under First item, choose Reverse First Item and Second Item. That will change the “notes” about the constraints to this:

AAA.centerX = centerX BBB.centerX = AAA.centerX

…which is easier to read in my opinion. As far as I can tell, switching the names like that has no affect on anything in the storyboard.


Sorry. I didn’t realize that spaces at the beginning of a sentence are ignored. I edited the two examples to make it clear. Essentially, out of the top two labels, the one most to the left is the label that all of the other labels have their centerX values set to. You can see that in the size inspector. Interesting, if the third one is more to the left, it does not matter. It seems that only the top two labels matter.

Yeah, you understand what I was confused about.


There is something to the left/right thing–but I don’t think it has any real effect. In any case, you can select any label, click on the Align icon, and select Horizontally in Container, and that label will be the reference label.

Update: my tests show that there’s no such thing as a reference label–the whole group moves together if you change any label’s horizontal position. After you add the Align/Horizontal Centers constraints, then for the horizontal positions AAA = BBB = CCC, and it’s irrelevant what combination of those equalities that the constraints specify. You can unhook whichever label is constrained to the centerX of the container, then you can pin any label to the left side of the container, and all the labels will move to the left side of the container. Previously, I had thought that the labels only followed the label that was constrained to the centerX of the container (I wonder where I got that notion middle of p. 14!). In other words, you aren’t constraining the horizontal position of the other labels with respect to the first label, as the book says, rather the labels are all constrained with respect to each other–they are a group of equals.