appearanceWhenContainedIn in Swift
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
appearanceWhenContainedIn refers to an older UIKit style customization pattern where a control receives appearance settings only when it appears inside a specific container. The concept still matters, but in modern Swift the API you usually use is appearance(whenContainedInInstancesOf:).
This is part of the UIAppearance system. It is useful when you want a consistent theme inside one container type, such as a navigation bar or search bar, without affecting the same control everywhere else in the app.
Understand Container-Scoped Appearance
UIAppearance can style a class globally, but sometimes global styling is too broad. You may want all UIBarButtonItem instances inside a UINavigationBar to look one way, while leaving other bar button items alone.
That is the job of container-scoped appearance. Instead of saying "all instances of this class should look like this," you say "instances of this class should look like this when they are contained inside one of these parent classes."
In modern Swift, the code looks like this:
This applies the title attributes only to bar button items inside navigation bars.
Apply Appearance Rules Early
Appearance configuration usually works best when it happens before the relevant views are created. A common place is app startup, such as a central theme configuration method.
If you apply appearance changes after controls are already on screen, you may not get the result you expect. That is one reason these rules can feel inconsistent when they are scattered throughout the codebase.
Know When UIAppearance Is the Wrong Tool
UIAppearance is powerful, but it is still global configuration. Even container-scoped rules affect every matching control in that containment hierarchy across the app.
That means it is a good tool for:
- stable theme rules
- app-wide branding decisions
- consistent styling in a repeated container pattern
It is usually a poor tool for:
- a one-off visual tweak on a single screen
- stateful styling that changes frequently at runtime
- highly specific view hierarchies that are hard to reason about
If only one controller needs custom colors, direct property assignment in that controller is often clearer than adding another appearance rule.
Understand the Older Name
You will still see older discussions mention appearanceWhenContainedIn because UIKit originally exposed a more Objective-C-flavored variadic API. Modern Swift renamed and reshaped it into appearance(whenContainedInInstancesOf:), which is easier to read and type-check.
So if you are reading old examples, translate the concept rather than copying the syntax literally. The idea is unchanged:
- choose the view class you want to style
- specify the container classes that scope the rule
- set appearance properties on the proxy object
Common Pitfalls
The biggest mistake is forgetting that appearance rules are effectively global within their scope. Once configured, they can influence matching views far away from the code that set them.
Another common issue is applying the rule too late. If the relevant controls already exist, the new appearance configuration may not fully take effect.
It is also easy to misread the containment hierarchy. The rule only applies when UIKit actually sees the control inside the specified container chain.
Finally, developers often use UIAppearance for local customization that would be clearer as direct view configuration. Appearance proxies are best for themes, not one-off exceptions.
Summary
- '
appearanceWhenContainedInis the older idea behind container-scopedUIAppearance.' - In modern Swift, use
appearance(whenContainedInInstancesOf:). - Apply these rules early, before the views are created.
- Use them for stable thematic styling, not isolated screen-specific tweaks.
- Check the real containment hierarchy when a rule does not seem to apply.

