Customize UITableView header section
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
Custom section headers in UITableView are useful when the default plain-text header is too limited for your design or interaction needs. They let you add typography, icons, buttons, and expand-collapse behavior while preserving table-view structure. The stable way to build them is with reusable UITableViewHeaderFooterView subclasses and a clear sizing strategy.
Start with the Simplest Option
If you only need plain text, the built-in header title API is enough.
That is lightweight and perfectly valid for simple settings screens. Move to a custom header only when you need richer layout or interaction.
Return a Custom Header View
For custom visuals, implement viewForHeaderInSection.
This works, but for production code you usually want reuse and encapsulation.
Prefer UITableViewHeaderFooterView Reuse
Repeatedly creating ad hoc header views is less maintainable. A reusable header subclass is cleaner and scales better.
Register it and dequeue it:
Sizing the Header Correctly
You need either fixed height or automatic sizing.
Fixed-height example:
Automatic sizing example:
If you use automatic sizing, your constraints must fully define the header’s vertical layout. Most clipped-header bugs come from incomplete constraints.
Add Buttons or Collapse Behavior
Headers often act as expand-collapse triggers. The important rule is to keep section state in the controller or view model, not inside the reusable header view.
Then in the table-view controller, update the model and reload the affected section.
Accessibility and Appearance
Custom headers should behave like real headers, not just decorative views.
Useful settings:
Also check:
- Dynamic Type support.
- Dark-mode contrast.
- Enough tap target size for interactive headers.
If the header contains controls, make sure those controls are discoverable and not hidden behind a gesture-only interaction.
Common Pitfalls
- Building header views from scratch every time instead of using reusable header-footer views. Fix by subclassing
UITableViewHeaderFooterView. - Storing section-expanded state inside the header view. Fix by keeping state in the controller or view model.
- Mixing manual frames with Auto Layout in the same header. Fix by choosing one layout system and completing all constraints.
- Using automatic height without vertical constraints. Fix by constraining top and bottom edges of header content.
- Forgetting accessibility semantics on custom headers. Fix by setting header traits and validating with VoiceOver.
Summary
- Use simple built-in titles when plain text is enough.
- For richer UI, prefer reusable
UITableViewHeaderFooterViewsubclasses. - Keep sizing strategy explicit with either fixed heights or complete Auto Layout constraints.
- Put interactive state in the controller, not in the reusable header view.
- Treat custom headers as real UI components with proper accessibility and reuse behavior.

