Leading and Line Spacing: What It Is and Configuration in iOS and Android

What Is Leading and Line Spacing

Leading (pronounced “led-ing”) — the vertical distance between the baselines of adjacent lines in typography. The baseline is the invisible line on which text characters rest. The larger the leading, the more freely the lines are positioned relative to each other. In digital typography, leading is more commonly called line spacing or line height.

Historically, the term originated in the era of metal typography: typesetters inserted thin lead strips between lines to increase spacing. In modern fonts, leading is defined as a ratio to the font size. The system default is 1.2 (120% of font size), but for long texts and mobile interfaces, a larger value is recommended. According to Material Design Typography Guidelines, the optimal line height for web and mobile interfaces is 1.4–1.5 for body text.

Difference between leading and line spacing: leading is the full distance from baseline to baseline, while line spacing is the distance between the bottom edge of one line and the top edge of the next. In most mobile APIs (iOS NSParagraphStyle, Android TextView), line spacing is used as an additional offset on top of the natural line height. This is important to consider when calculating the overall line spacing.

Optimal Leading Values for Mobile Interfaces

Choosing the optimal leading depends on several factors: font size, line length, usage context, and audience. For mobile interfaces with a typical line width of 40–60 characters, a leading of 1.4 to 1.6 of the font size is recommended. Short lines (labels, buttons) can use smaller leading — 1.0–1.2. Long texts (articles, descriptions) — larger leading, up to 1.8 for maximum readability.

Experimental data: a study by the Wichita State University Software Usability Laboratory showed that a leading of 1.5 increases reading speed by 7.5% compared to a leading of 1.0 with the same line width. For users with dyslexia, the optimal leading is even higher — up to 1.8. These data are confirmed by WCAG 2.2 recommendations, which require the ability to increase line spacing to 1.5 without losing content.

Effect of typeface: fonts with a high x-height require more leading than fonts with a low x-height. For example, Helvetica (high x-height) recommends a leading of 1.5 for body text, while Didot (low x-height) — 1.3. This is because with a high x-height, lines visually merge faster with the same line spacing.

Leading Implementation in iOS via NSParagraphStyle

On iOS, line spacing is managed through the NSMutableParagraphStyle class, which has two key properties: lineSpacing (additional space between lines in points) and lineHeightMultiple (line height multiplier). These properties work together: the final line height is computed as the natural font height multiplied by lineHeightMultiple, plus lineSpacing.

let paragraphStyle = NSMutableParagraphStyle()

// Method 1: line height multiplier
paragraphStyle.lineHeightMultiple = 1.5

// Method 2: extra spacing between lines
paragraphStyle.lineSpacing = 4.0

// Apply via NSAttributedString
let attributedText = NSAttributedString(
    string: "Text with custom line spacing",
    attributes: [
        .paragraphStyle: paragraphStyle
    ]
)

lineHeightMultiple is the preferred approach because it automatically scales when the font size changes. lineSpacing is specified in absolute points and does not scale, which can cause inconsistencies when using Dynamic Type. According to the Apple Text Programming Guide, for accessibility-compatible interfaces use lineHeightMultiple in combination with UIFontMetrics.

SwiftUI provides the .lineSpacing() modifier for Text and VStack. Unlike UIKit, in SwiftUI line spacing is specified in points and has no built-in multiplier. To implement a multiplier, the developer needs to calculate the line spacing manually based on the font size. Limitation: SwiftUI does not support lineHeightMultiple directly — use .lineSpacing(CGFloat) with a calculated value.

struct LeadingTextView: View {
    let fontSize: CGFloat = 17

    var lineSpacing: CGFloat {
        fontSize * 0.5 // 50% of font size
    }

    var body: some View {
        Text("Line spacing")
        Text("1.5 multiplier")
            .lineSpacing(lineSpacing)
            .font(.system(size: fontSize))
    }
}

Configuring Line Spacing on Android

On Android, line spacing is set through two TextView attributes: lineSpacingExtra (additional spacing in px) and lineSpacingMultiplier (line height multiplier, default 1.0). Similar to iOS, the multiplier scales when the font size changes, while extra is an absolute value. For accessibility-compatible interfaces, using the multiplier is preferred.

// In XML layout
<TextView
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:text="Text with line spacing"
    android:lineSpacingExtra="4dp"
    android:lineSpacingMultiplier="1.5"
    android:textSize="16sp" />

// Programmatically in Kotlin
val textView = findViewById<TextView>(R.id.contentText)
textView.setLineSpacing(
    TypedValue.applyDimension(
        TypedValue.COMPLEX_UNIT_DIP,
        4f,
        resources.displayMetrics
    ),
    1.5f
)

Compose — the modern Android UI framework — uses the lineHeight parameter in the TextStyle modifier. Unlike the XML approach, in Compose lineHeight is specified as the full line height in sp (default = fontSize * 1.2). To set a multiplier, the developer specifies lineHeight as a percentage of fontSize: Example: TextStyle(fontSize = 16.sp, lineHeight = 24.sp) gives a multiplier of 1.5.

Limitation: on Android before API 28, lineSpacingExtra and lineSpacingMultiplier work incorrectly with some fonts, especially custom ones (TTF/OTF). It is recommended to test on real devices and note that systemTextView by default uses lineSpacingMultiplier 1.0 — without additional spacing. For long texts in ScrollView, always explicitly set the line spacing.

Line Spacing in Web Development via CSS line-height

On the web, line spacing is set by the CSS property line-height, which can be a number (multiplier), a percentage, length units (px, em), or the keyword normal. The numeric multiplier is the preferred method because it inherits and scales relative to the font size of child elements. The value normal corresponds to approximately 1.2 for most fonts.

/* Numerical multiplier (recommended) */
body {
    font-size: 16px;
    line-height: 1.5;
}

/* Percentage value */
.article-content {
    line-height: 150%;
}

/* Fixed value (does not scale) */
.small-text {
    font-size: 12px;
    line-height: 18px;
}

Numeric multiplier vs em: line-height: 1.5 and line-height: 1.5em are different things. A numeric multiplier is inherited as a computed value and is recalculated for each child element based on its font-size. em is inherited as a fixed computed value based on the parent’s font-size. This is a critical difference: when nesting font-size: 20px inside font-size: 16px, line-height: 1.5 gives 30px, while line-height: 1.5em gives 24px (from the parent). Recommendation: always use a numeric multiplier.

Comparison of Leading Settings on iOS, Android, and Web

Despite different APIs, the principle of configuring line spacing is the same on all platforms. Multiplier scales when the font size changes and is accessibility-friendly. Absolute value (spacing) does not scale and can cause issues when using Dynamic Type or large text settings.

Cross-platform strategy: define lineHeight in the design system as a multiplier of fontSize. For example, in design tokens: line-height-body = 1.5, line-height-heading = 1.1. Each platform implements this multiplier with its own API: iOS — lineHeightMultiple, Android — lineSpacingMultiplier, Web — line-height: 1.5. This ensures consistent visual results across all platforms.

Important nuance: on iOS, lineHeightMultiple is applied to the full line height (including font ascender + descender), while on Android, lineSpacingMultiplier is applied to the line height calculated by the Minikin render engine. In practice, this leads to slight differences in visual leading with the same multiplier value. For pixel-perfect consistency, use absolute values adjusted per platform.