iOS
UIButton
AutoLayout
Swift
FontSizing

Adjust UIButton font size to width

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

Button labels that truncate or overflow hurt usability and polish, especially across localization and dynamic type settings. UIKit provides built-in options to scale button title text, but getting consistent behavior requires combining title-label settings, constraints, and content insets.

This article shows practical patterns for adjusting UIButton font size to available width.

Core Sections

1) Enable automatic title shrink

swift
1let button = UIButton(type: .system)
2button.setTitle("Continue to checkout", for: .normal)
3button.titleLabel?.adjustsFontSizeToFitWidth = true
4button.titleLabel?.minimumScaleFactor = 0.7
5button.titleLabel?.lineBreakMode = .byClipping

This is the simplest approach when one line is required.

2) Control layout with Auto Layout

swift
1button.translatesAutoresizingMaskIntoConstraints = false
2NSLayoutConstraint.activate([
3    button.widthAnchor.constraint(equalToConstant: 160),
4    button.heightAnchor.constraint(equalToConstant: 44)
5])

Without stable constraints, font scaling results can appear inconsistent.

3) Respect Dynamic Type

swift
button.titleLabel?.font = UIFont.preferredFont(forTextStyle: .headline)
button.titleLabel?.adjustsFontForContentSizeCategory = true

If accessibility sizes are enabled, verify scaled text still remains legible after shrink rules.

4) Alternative strategy: multiline titles

If shrinking makes text unreadable, prefer two lines:

swift
button.titleLabel?.numberOfLines = 2
button.titleLabel?.textAlignment = .center

Multiline often improves localization support for long strings.

5) Test across states and locales

Validate title behavior for normal, highlighted, and disabled states, plus translated strings (German/French can be significantly longer).

6) Production checklist for UIButton adaptive typography

To move this pattern from tutorial code into dependable production behavior, define a repeatable validation workflow before rollout. Start with three explicit acceptance metrics: correctness, reliability, and latency. Correctness should be measured against known fixtures or golden outputs, reliability should include error-rate and retry outcomes, and latency should use tail metrics such as p95 or p99 rather than simple averages. Running these checks once locally is not enough; they should execute in CI and, when possible, in a staging environment that resembles production data volumes and dependency behavior.

Next, capture environmental assumptions where maintainers can see them. Document runtime version, library versions, required environment variables, and external service dependencies. Many regressions happen because one assumption changes silently: a runtime upgrade, a minor package update, or a different default configuration in a deployment environment. Add at least one negative test that simulates a realistic failure mode, such as timeout, malformed input, permission issue, or missing artifact. These tests verify that failure handling is explicit and observable rather than hidden.

Operational readiness also requires ownership and rollback clarity. Define who responds when this component fails, what threshold triggers investigation, and what rollback path can be executed quickly. If the feature can be gated, prefer a flag-driven rollout so you can disable behavior without emergency code changes. Even for small utilities, this discipline prevents long incident timelines.

bash
1# Example pre-release validation sequence
2make lint
3make test
4./scripts/smoke_check.sh

Finally, keep a brief limitations note. State clearly what this implementation handles and what it intentionally does not optimize. That helps future contributors avoid accidental misuse and keeps design decisions grounded in explicit tradeoffs. Revisit this checklist after major framework or infrastructure upgrades, because behavior that was safe under one runtime may degrade under another if assumptions are no longer valid.

Common Pitfalls

  • Enabling shrink but forgetting to set a sensible minimumScaleFactor.
  • Forcing one-line text for long localized labels and reducing readability.
  • Ignoring Auto Layout constraints, producing unpredictable scaling.
  • Overriding title font repeatedly in state updates and breaking dynamic type.
  • Testing only English strings and missing overflow in other locales.

Summary

For width-constrained buttons, combine adjustsFontSizeToFitWidth with proper constraints and accessibility-aware typography. When text still becomes unreadable, switch to multiline titles instead of aggressive shrinking. Validate across states, devices, and localization early.

For long-term maintainability, add one regression test and one smoke-check script that exercises the most failure-prone path for this topic. Keep those checks in CI and run them after dependency upgrades so behavioral drift is caught early. Also record expected operating assumptions in project docs, including runtime version, required configuration, and known limitations, so contributors can debug environment-specific failures quickly without rediscovering the same constraints during incident response.


Course illustration
Course illustration

All Rights Reserved.