Introduction

There is no single global iOS switch that forces every text element in an app to use one font. The right approach depends on whether the app is built with UIKit, SwiftUI, or a mix of both. In practice, you create a typography layer and apply it consistently through appearance APIs, styles, or custom components.

Register the Font First

If you are using a custom font, the app has to bundle it correctly before any global styling will work.

Add the font file to the project and list it in Info.plist under UIAppFonts.

Example entry:

1<key>UIAppFonts</key>
2<array>
3    <string>Inter-Regular.ttf</string>
4    <string>Inter-Bold.ttf</string>
5</array>

Then verify the runtime name:

1for family in UIFont.familyNames.sorted() {
2    print("Family: \(family)")
3    for name in UIFont.fontNames(forFamilyName: family) {
4        print("  \(name)")
5    }
6}

Use the printed font name in code, not the filename guessed from Finder.

UIKit: Use Appearance Where It Actually Works

UIKit UIAppearance can help with some controls, but it is not a universal typography switch. It works well for classes that expose customizable text attributes.

1import UIKit
2
3@main
4class AppDelegate: UIResponder, UIApplicationDelegate {
5    func application(
6        _ application: UIApplication,
7        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
8    ) -> Bool {
9        let titleFont = UIFont(name: "Inter-Bold", size: 18)!
10        let bodyFont = UIFont(name: "Inter-Regular", size: 16)!
11
12        UINavigationBar.appearance().titleTextAttributes = [
13            .font: titleFont
14        ]
15
16        UIBarButtonItem.appearance().setTitleTextAttributes(
17            [.font: bodyFont],
18            for: .normal
19        )
20
21        return true
22    }
23}

This helps with navigation bars and bar button items, but it does not automatically restyle every UILabel in the app.

UIKit: Centralize Fonts in a Typography Helper

For UIKit apps, a font helper is usually the maintainable solution.

1import UIKit
2
3enum AppFont {
4    static func body(size: CGFloat = 16) -> UIFont {
5        UIFont(name: "Inter-Regular", size: size)!
6    }
7
8    static func title(size: CGFloat = 20) -> UIFont {
9        UIFont(name: "Inter-Bold", size: size)!
10    }
11}

Then apply it explicitly:

titleLabel.font = AppFont.title(size: 24)
subtitleLabel.font = AppFont.body(size: 14)

This is more honest than pretending UIKit has a universal default-font hook that it does not actually provide.

SwiftUI: Apply a Root Font in the View Tree

SwiftUI makes global-style typography easier because environment modifiers can flow down the tree.

1import SwiftUI
2
3@main
4struct DemoApp: App {
5    var body: some Scene {
6        WindowGroup {
7            ContentView()
8                .font(.custom("Inter-Regular", size: 16))
9        }
10    }
11}

For specific roles, define a font palette:

1import SwiftUI
2
3enum AppTextStyle {
4    static let body = Font.custom("Inter-Regular", size: 16)
5    static let title = Font.custom("Inter-Bold", size: 24)
6}

Usage:

1Text("Welcome")
2    .font(AppTextStyle.title)
3
4Text("Body copy")
5    .font(AppTextStyle.body)

This gives consistency without hardcoding font names everywhere.

Support Dynamic Type and Accessibility

A good default font strategy should still respect content-size changes where possible. If you are using UIKit, prefer scaling through UIFontMetrics.

1import UIKit
2
3let baseFont = UIFont(name: "Inter-Regular", size: 16)!
4let scaled = UIFontMetrics(forTextStyle: .body).scaledFont(for: baseFont)
5label.font = scaled
6label.adjustsFontForContentSizeCategory = true

If you ignore scaling, the app may look branded but behave poorly for accessibility.

Mixed UIKit and SwiftUI Apps

Many apps use both frameworks. In that case:

• use a shared naming and sizing system
• expose UIKit and SwiftUI helpers from one typography layer
• do not assume a SwiftUI root .font affects UIKit views

Consistency comes from a shared design system, not from one magic API call.

What Usually Fails

Developers often try to set a font once and expect every UILabel, UITextField, UIButton, and navigation title to inherit it automatically. iOS does not work that way across the board.

Another common issue is using the wrong font name in code. The PostScript font name may differ from the file name.

Teams also skip accessibility scaling when switching to custom fonts, which creates regressions for larger text sizes.

Finally, view-specific overrides can silently undo your intended global style if there is no centralized typography policy.

Common Pitfalls

One common pitfall is treating UIAppearance as a universal default-font mechanism. It is useful, but not comprehensive.

Another is registering the font file correctly but using the wrong runtime font name in code.

Developers also forget that SwiftUI and UIKit do not share typography automatically in mixed apps.

Accessibility is often left out of the first implementation, which makes the font system brittle and user-hostile.

Summary

• iOS does not offer one true global default-font switch for every text element.
• Register custom fonts correctly before styling anything.
• In UIKit, combine appearance APIs with a centralized typography helper.
• In SwiftUI, use root .font modifiers and shared style constants.
• Build the font system around consistency and accessibility, not one-off view settings.