iOS 12 wrong navigation bar height
I'm working on an iPad app in landscape orientation. There is a navigation bar at the top without a status bar, and I want to line up a UITableView
such that the top of the table is at the same y coordinate as the bottom of the navigation bar. Naturally, I do the following in viewDidLoad
:
MyTableView* table = [[MyTableView alloc] init];
table.frame = CGRectMake(someX, navBar.frame.size.height, someWidth, someHeight);
[self.view addSubview:table];
At this point, navBar.frame.size.height
returns 44. This is strange, because when I run the app, I see that my table overlaps the bottom of the navigation bar by a few points. I do some investigation, and find out that the navigation bar is actually drawing with a height of 50 points.
I try to think what could be wrong, and realize that perhaps I'm doing this too early in the view controller's lifecycle and the views haven't yet been laid out, so I override viewWillAppear
, viewDidAppear
, and viewDidLayoutSubviews
, all of which report that the navigation bar's height is 44, even when it is clearly drawing with a height of 50.
I thought perhaps there's something I simply don't know, so I setup a timer to run a block of code that would repeatedly print out the height of the navigation bar every second after viewDidLoad
was called, which allows for any view controller behind-the-scenes setup to finish. Still, every time the timer triggers the print, the height is only 44.
I took a look at interface builder, and even there, in the dimensions property window (second tab from right), it says the navigation bar has a height of 44. Yet on the screen in the view controller in interface builder, it is clearly drawing with a height of 50.
My question is: why does the reported height not match the height the navigation bar draws at? I need the correct height to place my table in the right location.
At this point I'm at a loss for what could possibly be the issue, save for the API simply being completely broken. The only solution I can think of is to just position the navigation bar at -3 and hardcode in a y value for my table view of 44, resulting in 3 points on the top and bottom of the navigation bar being covered up, which is super janky and I want to avoid it if at all possible.
Now, I understand that autolayout is a thing and constraints exist, but I like to manually compute the frames of my views in code and never use constraints, and that is the realm that this question is in. Please don't give answers like "you're supposed to use constraints".
Although I doubt it matters, I'm running iOS 12.0.1 on an iPad Air 2.
My debugging:
Below is an image of the top center portion of my screen. Each of the rectangles is simply a UIView
with a background color set, a y coordinate of 0, a width of 50 points, and are spaced 50 points apart from each other (each starts where the previous one ends). The heights of each rectangle from left to right are: 44, 50, and 51. You can tell the navigation bar is drawing at a height of 50 points since the right rectangle is just barely taller than the navigation bar.
EDIT:
I should probably mention that this navigation bar is added to the view controller via being dragged and dropped into a view controller in the storyboard. I still do some frame shenanigans in viewDidLoad
, but it's not being dynamically added to the view there.
Another interesting thing of note: In interface builder, you know the dashed blue lines that help you line things up? Apparently, those align with the 44 point height instead of the 50 point height:
ios uinavigationbar
add a comment |
I'm working on an iPad app in landscape orientation. There is a navigation bar at the top without a status bar, and I want to line up a UITableView
such that the top of the table is at the same y coordinate as the bottom of the navigation bar. Naturally, I do the following in viewDidLoad
:
MyTableView* table = [[MyTableView alloc] init];
table.frame = CGRectMake(someX, navBar.frame.size.height, someWidth, someHeight);
[self.view addSubview:table];
At this point, navBar.frame.size.height
returns 44. This is strange, because when I run the app, I see that my table overlaps the bottom of the navigation bar by a few points. I do some investigation, and find out that the navigation bar is actually drawing with a height of 50 points.
I try to think what could be wrong, and realize that perhaps I'm doing this too early in the view controller's lifecycle and the views haven't yet been laid out, so I override viewWillAppear
, viewDidAppear
, and viewDidLayoutSubviews
, all of which report that the navigation bar's height is 44, even when it is clearly drawing with a height of 50.
I thought perhaps there's something I simply don't know, so I setup a timer to run a block of code that would repeatedly print out the height of the navigation bar every second after viewDidLoad
was called, which allows for any view controller behind-the-scenes setup to finish. Still, every time the timer triggers the print, the height is only 44.
I took a look at interface builder, and even there, in the dimensions property window (second tab from right), it says the navigation bar has a height of 44. Yet on the screen in the view controller in interface builder, it is clearly drawing with a height of 50.
My question is: why does the reported height not match the height the navigation bar draws at? I need the correct height to place my table in the right location.
At this point I'm at a loss for what could possibly be the issue, save for the API simply being completely broken. The only solution I can think of is to just position the navigation bar at -3 and hardcode in a y value for my table view of 44, resulting in 3 points on the top and bottom of the navigation bar being covered up, which is super janky and I want to avoid it if at all possible.
Now, I understand that autolayout is a thing and constraints exist, but I like to manually compute the frames of my views in code and never use constraints, and that is the realm that this question is in. Please don't give answers like "you're supposed to use constraints".
Although I doubt it matters, I'm running iOS 12.0.1 on an iPad Air 2.
My debugging:
Below is an image of the top center portion of my screen. Each of the rectangles is simply a UIView
with a background color set, a y coordinate of 0, a width of 50 points, and are spaced 50 points apart from each other (each starts where the previous one ends). The heights of each rectangle from left to right are: 44, 50, and 51. You can tell the navigation bar is drawing at a height of 50 points since the right rectangle is just barely taller than the navigation bar.
EDIT:
I should probably mention that this navigation bar is added to the view controller via being dragged and dropped into a view controller in the storyboard. I still do some frame shenanigans in viewDidLoad
, but it's not being dynamically added to the view there.
Another interesting thing of note: In interface builder, you know the dashed blue lines that help you line things up? Apparently, those align with the 44 point height instead of the 50 point height:
ios uinavigationbar
there is always something desperately derailed when the dev's starting worry about the system navigation-bar's / tab-bar's height – I really like your expectation about what kinda answer you do not wanna see, but aside your eagle-eyed observation of44 != 50 != 51
, I don't see why this height is relevant to you, or what your question really is, or why you'd think the height is wrong in any respect.
– holex
Nov 23 '18 at 11:25
@holex My question is why does the height returned fromnavBar.frame.size.height
(44) not match the height that it draws with on screen (50)? The height is relevant so that I can place my table at the right y coordinate. If thenavBar
tells me a height any different from what it draws with, the placement of my table will be wrong - either too high or too low. I think the height is wrong because it doesn't match the displayed height. The only other option is that it is drawing with the wrong height, but that seems more unlikely than simply returning the wrong height.
– Aderis
Nov 24 '18 at 0:22
I know you said that you don't want to see "you're supposed to use constraints", but you're supposed to use constraints. You'd have to have a hell of a use case not to, and nothing you've outlined here indicates that you have such a use case. How many times does Apple have to tell you not to lay things out manually?
– NRitH
Nov 24 '18 at 0:53
add a comment |
I'm working on an iPad app in landscape orientation. There is a navigation bar at the top without a status bar, and I want to line up a UITableView
such that the top of the table is at the same y coordinate as the bottom of the navigation bar. Naturally, I do the following in viewDidLoad
:
MyTableView* table = [[MyTableView alloc] init];
table.frame = CGRectMake(someX, navBar.frame.size.height, someWidth, someHeight);
[self.view addSubview:table];
At this point, navBar.frame.size.height
returns 44. This is strange, because when I run the app, I see that my table overlaps the bottom of the navigation bar by a few points. I do some investigation, and find out that the navigation bar is actually drawing with a height of 50 points.
I try to think what could be wrong, and realize that perhaps I'm doing this too early in the view controller's lifecycle and the views haven't yet been laid out, so I override viewWillAppear
, viewDidAppear
, and viewDidLayoutSubviews
, all of which report that the navigation bar's height is 44, even when it is clearly drawing with a height of 50.
I thought perhaps there's something I simply don't know, so I setup a timer to run a block of code that would repeatedly print out the height of the navigation bar every second after viewDidLoad
was called, which allows for any view controller behind-the-scenes setup to finish. Still, every time the timer triggers the print, the height is only 44.
I took a look at interface builder, and even there, in the dimensions property window (second tab from right), it says the navigation bar has a height of 44. Yet on the screen in the view controller in interface builder, it is clearly drawing with a height of 50.
My question is: why does the reported height not match the height the navigation bar draws at? I need the correct height to place my table in the right location.
At this point I'm at a loss for what could possibly be the issue, save for the API simply being completely broken. The only solution I can think of is to just position the navigation bar at -3 and hardcode in a y value for my table view of 44, resulting in 3 points on the top and bottom of the navigation bar being covered up, which is super janky and I want to avoid it if at all possible.
Now, I understand that autolayout is a thing and constraints exist, but I like to manually compute the frames of my views in code and never use constraints, and that is the realm that this question is in. Please don't give answers like "you're supposed to use constraints".
Although I doubt it matters, I'm running iOS 12.0.1 on an iPad Air 2.
My debugging:
Below is an image of the top center portion of my screen. Each of the rectangles is simply a UIView
with a background color set, a y coordinate of 0, a width of 50 points, and are spaced 50 points apart from each other (each starts where the previous one ends). The heights of each rectangle from left to right are: 44, 50, and 51. You can tell the navigation bar is drawing at a height of 50 points since the right rectangle is just barely taller than the navigation bar.
EDIT:
I should probably mention that this navigation bar is added to the view controller via being dragged and dropped into a view controller in the storyboard. I still do some frame shenanigans in viewDidLoad
, but it's not being dynamically added to the view there.
Another interesting thing of note: In interface builder, you know the dashed blue lines that help you line things up? Apparently, those align with the 44 point height instead of the 50 point height:
ios uinavigationbar
I'm working on an iPad app in landscape orientation. There is a navigation bar at the top without a status bar, and I want to line up a UITableView
such that the top of the table is at the same y coordinate as the bottom of the navigation bar. Naturally, I do the following in viewDidLoad
:
MyTableView* table = [[MyTableView alloc] init];
table.frame = CGRectMake(someX, navBar.frame.size.height, someWidth, someHeight);
[self.view addSubview:table];
At this point, navBar.frame.size.height
returns 44. This is strange, because when I run the app, I see that my table overlaps the bottom of the navigation bar by a few points. I do some investigation, and find out that the navigation bar is actually drawing with a height of 50 points.
I try to think what could be wrong, and realize that perhaps I'm doing this too early in the view controller's lifecycle and the views haven't yet been laid out, so I override viewWillAppear
, viewDidAppear
, and viewDidLayoutSubviews
, all of which report that the navigation bar's height is 44, even when it is clearly drawing with a height of 50.
I thought perhaps there's something I simply don't know, so I setup a timer to run a block of code that would repeatedly print out the height of the navigation bar every second after viewDidLoad
was called, which allows for any view controller behind-the-scenes setup to finish. Still, every time the timer triggers the print, the height is only 44.
I took a look at interface builder, and even there, in the dimensions property window (second tab from right), it says the navigation bar has a height of 44. Yet on the screen in the view controller in interface builder, it is clearly drawing with a height of 50.
My question is: why does the reported height not match the height the navigation bar draws at? I need the correct height to place my table in the right location.
At this point I'm at a loss for what could possibly be the issue, save for the API simply being completely broken. The only solution I can think of is to just position the navigation bar at -3 and hardcode in a y value for my table view of 44, resulting in 3 points on the top and bottom of the navigation bar being covered up, which is super janky and I want to avoid it if at all possible.
Now, I understand that autolayout is a thing and constraints exist, but I like to manually compute the frames of my views in code and never use constraints, and that is the realm that this question is in. Please don't give answers like "you're supposed to use constraints".
Although I doubt it matters, I'm running iOS 12.0.1 on an iPad Air 2.
My debugging:
Below is an image of the top center portion of my screen. Each of the rectangles is simply a UIView
with a background color set, a y coordinate of 0, a width of 50 points, and are spaced 50 points apart from each other (each starts where the previous one ends). The heights of each rectangle from left to right are: 44, 50, and 51. You can tell the navigation bar is drawing at a height of 50 points since the right rectangle is just barely taller than the navigation bar.
EDIT:
I should probably mention that this navigation bar is added to the view controller via being dragged and dropped into a view controller in the storyboard. I still do some frame shenanigans in viewDidLoad
, but it's not being dynamically added to the view there.
Another interesting thing of note: In interface builder, you know the dashed blue lines that help you line things up? Apparently, those align with the 44 point height instead of the 50 point height:
ios uinavigationbar
ios uinavigationbar
edited Nov 24 '18 at 0:37
Aderis
asked Nov 21 '18 at 3:05
AderisAderis
1,6391222
1,6391222
there is always something desperately derailed when the dev's starting worry about the system navigation-bar's / tab-bar's height – I really like your expectation about what kinda answer you do not wanna see, but aside your eagle-eyed observation of44 != 50 != 51
, I don't see why this height is relevant to you, or what your question really is, or why you'd think the height is wrong in any respect.
– holex
Nov 23 '18 at 11:25
@holex My question is why does the height returned fromnavBar.frame.size.height
(44) not match the height that it draws with on screen (50)? The height is relevant so that I can place my table at the right y coordinate. If thenavBar
tells me a height any different from what it draws with, the placement of my table will be wrong - either too high or too low. I think the height is wrong because it doesn't match the displayed height. The only other option is that it is drawing with the wrong height, but that seems more unlikely than simply returning the wrong height.
– Aderis
Nov 24 '18 at 0:22
I know you said that you don't want to see "you're supposed to use constraints", but you're supposed to use constraints. You'd have to have a hell of a use case not to, and nothing you've outlined here indicates that you have such a use case. How many times does Apple have to tell you not to lay things out manually?
– NRitH
Nov 24 '18 at 0:53
add a comment |
there is always something desperately derailed when the dev's starting worry about the system navigation-bar's / tab-bar's height – I really like your expectation about what kinda answer you do not wanna see, but aside your eagle-eyed observation of44 != 50 != 51
, I don't see why this height is relevant to you, or what your question really is, or why you'd think the height is wrong in any respect.
– holex
Nov 23 '18 at 11:25
@holex My question is why does the height returned fromnavBar.frame.size.height
(44) not match the height that it draws with on screen (50)? The height is relevant so that I can place my table at the right y coordinate. If thenavBar
tells me a height any different from what it draws with, the placement of my table will be wrong - either too high or too low. I think the height is wrong because it doesn't match the displayed height. The only other option is that it is drawing with the wrong height, but that seems more unlikely than simply returning the wrong height.
– Aderis
Nov 24 '18 at 0:22
I know you said that you don't want to see "you're supposed to use constraints", but you're supposed to use constraints. You'd have to have a hell of a use case not to, and nothing you've outlined here indicates that you have such a use case. How many times does Apple have to tell you not to lay things out manually?
– NRitH
Nov 24 '18 at 0:53
there is always something desperately derailed when the dev's starting worry about the system navigation-bar's / tab-bar's height – I really like your expectation about what kinda answer you do not wanna see, but aside your eagle-eyed observation of
44 != 50 != 51
, I don't see why this height is relevant to you, or what your question really is, or why you'd think the height is wrong in any respect.– holex
Nov 23 '18 at 11:25
there is always something desperately derailed when the dev's starting worry about the system navigation-bar's / tab-bar's height – I really like your expectation about what kinda answer you do not wanna see, but aside your eagle-eyed observation of
44 != 50 != 51
, I don't see why this height is relevant to you, or what your question really is, or why you'd think the height is wrong in any respect.– holex
Nov 23 '18 at 11:25
@holex My question is why does the height returned from
navBar.frame.size.height
(44) not match the height that it draws with on screen (50)? The height is relevant so that I can place my table at the right y coordinate. If the navBar
tells me a height any different from what it draws with, the placement of my table will be wrong - either too high or too low. I think the height is wrong because it doesn't match the displayed height. The only other option is that it is drawing with the wrong height, but that seems more unlikely than simply returning the wrong height.– Aderis
Nov 24 '18 at 0:22
@holex My question is why does the height returned from
navBar.frame.size.height
(44) not match the height that it draws with on screen (50)? The height is relevant so that I can place my table at the right y coordinate. If the navBar
tells me a height any different from what it draws with, the placement of my table will be wrong - either too high or too low. I think the height is wrong because it doesn't match the displayed height. The only other option is that it is drawing with the wrong height, but that seems more unlikely than simply returning the wrong height.– Aderis
Nov 24 '18 at 0:22
I know you said that you don't want to see "you're supposed to use constraints", but you're supposed to use constraints. You'd have to have a hell of a use case not to, and nothing you've outlined here indicates that you have such a use case. How many times does Apple have to tell you not to lay things out manually?
– NRitH
Nov 24 '18 at 0:53
I know you said that you don't want to see "you're supposed to use constraints", but you're supposed to use constraints. You'd have to have a hell of a use case not to, and nothing you've outlined here indicates that you have such a use case. How many times does Apple have to tell you not to lay things out manually?
– NRitH
Nov 24 '18 at 0:53
add a comment |
1 Answer
1
active
oldest
votes
After too much time spent with no progress, I decided to finally bite the bullet and transition to constraints. After I spent far too much time trying to get them to do what I wanted (and failing), it turns out that manually laying out my views wasn't the issue. During the conversion process, I deleted my navigation bar and re-added it to the view controller, which caused everything to start working perfectly. The dashed blue alignment guides lined up with the 50 point height and the height field now always returns 50.
My guess is that the logic in Xcode to upgrade storyboards from pre iOS 12 navigation bars (44 points high) to the new iOS 12 navigation bars (50 points high) is broken, which put my storyboard into a bad state where it thought the height was 44 in some places and 50 in others. Deleting and re-adding it looks to have cleared any record of 44-ness so everything is now properly 50 points high.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53404721%2fios-12-wrong-navigation-bar-height%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
After too much time spent with no progress, I decided to finally bite the bullet and transition to constraints. After I spent far too much time trying to get them to do what I wanted (and failing), it turns out that manually laying out my views wasn't the issue. During the conversion process, I deleted my navigation bar and re-added it to the view controller, which caused everything to start working perfectly. The dashed blue alignment guides lined up with the 50 point height and the height field now always returns 50.
My guess is that the logic in Xcode to upgrade storyboards from pre iOS 12 navigation bars (44 points high) to the new iOS 12 navigation bars (50 points high) is broken, which put my storyboard into a bad state where it thought the height was 44 in some places and 50 in others. Deleting and re-adding it looks to have cleared any record of 44-ness so everything is now properly 50 points high.
add a comment |
After too much time spent with no progress, I decided to finally bite the bullet and transition to constraints. After I spent far too much time trying to get them to do what I wanted (and failing), it turns out that manually laying out my views wasn't the issue. During the conversion process, I deleted my navigation bar and re-added it to the view controller, which caused everything to start working perfectly. The dashed blue alignment guides lined up with the 50 point height and the height field now always returns 50.
My guess is that the logic in Xcode to upgrade storyboards from pre iOS 12 navigation bars (44 points high) to the new iOS 12 navigation bars (50 points high) is broken, which put my storyboard into a bad state where it thought the height was 44 in some places and 50 in others. Deleting and re-adding it looks to have cleared any record of 44-ness so everything is now properly 50 points high.
add a comment |
After too much time spent with no progress, I decided to finally bite the bullet and transition to constraints. After I spent far too much time trying to get them to do what I wanted (and failing), it turns out that manually laying out my views wasn't the issue. During the conversion process, I deleted my navigation bar and re-added it to the view controller, which caused everything to start working perfectly. The dashed blue alignment guides lined up with the 50 point height and the height field now always returns 50.
My guess is that the logic in Xcode to upgrade storyboards from pre iOS 12 navigation bars (44 points high) to the new iOS 12 navigation bars (50 points high) is broken, which put my storyboard into a bad state where it thought the height was 44 in some places and 50 in others. Deleting and re-adding it looks to have cleared any record of 44-ness so everything is now properly 50 points high.
After too much time spent with no progress, I decided to finally bite the bullet and transition to constraints. After I spent far too much time trying to get them to do what I wanted (and failing), it turns out that manually laying out my views wasn't the issue. During the conversion process, I deleted my navigation bar and re-added it to the view controller, which caused everything to start working perfectly. The dashed blue alignment guides lined up with the 50 point height and the height field now always returns 50.
My guess is that the logic in Xcode to upgrade storyboards from pre iOS 12 navigation bars (44 points high) to the new iOS 12 navigation bars (50 points high) is broken, which put my storyboard into a bad state where it thought the height was 44 in some places and 50 in others. Deleting and re-adding it looks to have cleared any record of 44-ness so everything is now properly 50 points high.
answered Dec 30 '18 at 1:49
AderisAderis
1,6391222
1,6391222
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53404721%2fios-12-wrong-navigation-bar-height%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
there is always something desperately derailed when the dev's starting worry about the system navigation-bar's / tab-bar's height – I really like your expectation about what kinda answer you do not wanna see, but aside your eagle-eyed observation of
44 != 50 != 51
, I don't see why this height is relevant to you, or what your question really is, or why you'd think the height is wrong in any respect.– holex
Nov 23 '18 at 11:25
@holex My question is why does the height returned from
navBar.frame.size.height
(44) not match the height that it draws with on screen (50)? The height is relevant so that I can place my table at the right y coordinate. If thenavBar
tells me a height any different from what it draws with, the placement of my table will be wrong - either too high or too low. I think the height is wrong because it doesn't match the displayed height. The only other option is that it is drawing with the wrong height, but that seems more unlikely than simply returning the wrong height.– Aderis
Nov 24 '18 at 0:22
I know you said that you don't want to see "you're supposed to use constraints", but you're supposed to use constraints. You'd have to have a hell of a use case not to, and nothing you've outlined here indicates that you have such a use case. How many times does Apple have to tell you not to lay things out manually?
– NRitH
Nov 24 '18 at 0:53