Introduction

On iOS 7, many scroll views and table views began extending underneath the status bar because Apple changed the default full-screen layout behavior. The fix is usually to adjust the controller's extended-layout settings or add the right top inset so the table content starts below the status bar.

Why It Happens on iOS 7

Before iOS 7, many interfaces behaved more like they were clipped below bars automatically. In iOS 7, Apple introduced a more immersive full-screen layout style, and views could extend under translucent bars by default.

That means a UITableView starting at the top of the controller can appear visually underneath:

• the status bar
• the navigation bar

The table itself is not broken. The layout rules changed.

A Common Controller-Level Fix

One traditional fix for iOS 7 is to stop the controller from extending under the top bars:

1- (void)viewDidLoad {
2    [super viewDidLoad];
3
4    if ([self respondsToSelector:@selector(edgesForExtendedLayout)]) {
5        self.edgesForExtendedLayout = UIRectEdgeNone;
6    }
7}

That tells the view controller not to place its content in the extended region under the status bar and navigation bar.

For many iOS 7-era table view screens, this was the cleanest fix.

Another Fix: Adjust the Table View Insets

If you want the view to stay extended but the scrollable content to begin lower, set a top content inset:

1- (void)viewDidLoad {
2    [super viewDidLoad];
3
4    self.tableView.contentInset = UIEdgeInsetsMake(20.0, 0.0, 0.0, 0.0);
5    self.tableView.scrollIndicatorInsets = self.tableView.contentInset;
6}

The 20 points correspond to the classic status bar height in that era. If a navigation bar is also involved, you may need a larger effective top spacing depending on the layout.

This approach is useful when you want the controller itself to remain full screen but still need the table content visually below the bar region.

Navigation Controllers Matter

If the table view controller sits inside a navigation controller, the bar translucency and automatic inset behavior affect the result.

For iOS 7-era code, common checks included:

• whether the navigation bar is translucent
• whether scroll-view insets are adjusted automatically
• whether the controller extends under top bars

That is why two table views with similar code can behave differently depending on their container hierarchy.

What This Means in Modern Terms

On current iOS versions, developers think in terms of safe areas and automatic inset adjustment. For an old iOS 7 question, though, the practical answer is still the older set of tools:

• 'edgesForExtendedLayout'
• 'contentInset'
• navigation bar translucency choices

So if you are maintaining legacy code, use the API vocabulary that matches the deployment target rather than forcing a modern safe-area explanation onto an older layout system.

Common Pitfalls

• Assuming the table view is positioned incorrectly when the real issue is extended layout under translucent bars.
• Adding a hard-coded inset without checking whether a navigation bar is also contributing to the overlap.
• Fixing the content inset but forgetting the scroll indicator inset, which makes the scrollbar look wrong.
• Mixing modern safe-area guidance with iOS 7-specific controller layout behavior in a legacy codebase.
• Applying multiple fixes at once and then making the content start too low.

Summary

• On iOS 7, table views often appeared under the status bar because full-screen extended layout became the default behavior.
• A common fix is edgesForExtendedLayout = UIRectEdgeNone.
• Another fix is adding a top contentInset and matching scrollIndicatorInsets.
• Navigation controller translucency can change how the overlap appears.
• For legacy iOS 7 code, use the older layout APIs rather than modern safe-area assumptions.