How to prevent UINavigationBar from covering top of view in iOS 7?
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
In iOS 7, many existing layouts suddenly looked wrong because view controllers started extending underneath translucent bars by default. If a UINavigationBar appears to cover the top of your content, the fix is usually to change how the view controller participates in extended layout, not to hard-code random offsets.
Why the navigation bar overlaps the view
Before iOS 7, many apps assumed the content area started below the navigation bar. iOS 7 introduced a flatter visual style and translucent bars, and UIKit changed the default so a view controller's root view could extend under the status bar and navigation bar.
That behavior comes from edgesForExtendedLayout. Its default value allows the content to reach all screen edges. If your top view starts at y = 0, the navigation bar can visually sit on top of it.
For a legacy screen that should begin below the bar, the simplest fix is to opt out of extended layout.
The standard iOS 7 fix
Set edgesForExtendedLayout to UIRectEdgeNone in the pushed view controller.
This tells UIKit not to place the controller's main view under the top or bottom bars. For many iOS 7 migration issues, this is the correct and sufficient solution.
If you prefer Swift syntax in newer codebases, the idea is the same:
That is usually better than manually adding 64 points of top padding, because hard-coded values break across status bar changes and device variations.
When translucency is the real problem
Sometimes the layout is technically correct, but the translucent navigation bar makes the content hard to read. In that case you can disable translucency instead of changing the controller geometry.
With a non-translucent bar, UIKit adjusts the content area so the visible content begins below the navigation bar. This can be a good option for forms, table views, or older screens that were designed around opaque bars.
Be careful, though: changing bar translucency affects the whole navigation controller stack, not just one screen.
Scroll views and table views need their own adjustment
If the top content is inside a UIScrollView or UITableView, you may also need to review automatic inset behavior. On older UIKit versions, the controller can add insets so the scrollable content starts below the bar.
If you disable inset adjustment while also using extended layout, the first rows of a table view often end up hidden behind the bar. That is why many developers saw the issue even after changing one property but not the related scroll behavior.
What to do in modern projects
The question is about iOS 7, but the modern equivalent is safe area layout. On current iOS versions, pinning controls to the safe area is the preferred solution instead of relying on legacy edge behavior.
If you are maintaining an old app, use edgesForExtendedLayout for the legacy controller and safe area constraints for newer screens.
Common Pitfalls
- Hard-coding a
yoffset instead of letting UIKit manage bar geometry. - Disabling translucency on one screen without realizing it changes the entire navigation controller.
- Forgetting about scroll view insets, which can leave table content hidden under the bar.
- Mixing old autoresizing layouts with new bar behavior and expecting them to adapt automatically.
- Applying modern safe area advice to an iOS 7-only codebase without checking API availability.
Summary
- In iOS 7, views extend under translucent bars by default.
- '
edgesForExtendedLayout = UIRectEdgeNoneis the usual fix for legacy screens.' - Turning off navigation bar translucency can also solve visual overlap.
- Scroll views may still need inset management even after the main layout is corrected.
- In modern code, safe area constraints are the preferred long-term solution.

