DEV Community: nooraja

Text Selection in SwiftUI TextEditor Is Still Harder Than It Should Be

nooraja — Thu, 27 Aug 2026 13:34:25 +0000

TextEditor looks wonderfully simple:

TextEditor(text: $note)

People can type multiple lines, move the caret, long press, select text, and copy or paste. For an ordinary notes field, that is excellent.

The trouble begins when the app itself needs to understand that selection.

What if a Bold toolbar action should activate only when text is selected? What if a template must be inserted at the caret? Or if suggestions depend on the word the user has highlighted?

At that point, SwiftUI's TextEditor can feel more difficult than long-established UIKit controls.

Selection UI is not selection state

First, an important distinction: users can select text directly in TextEditor. iOS supplies the familiar caret, selection handles, and system Copy/Paste menu.

The historical gap was accessing the state of that selection from SwiftUI. The basic TextEditor(text:) API binds only the editor's contents to a String:

@State private var note = "Select part of this text."

TextEditor(text: $note)

We know the value of note, but not whether the user is at character 5 or has selected characters 5 through 20. That small distinction matters enormously to a feature-rich editor.

The good news: `TextSelection` in iOS 18

SwiftUI now has an official answer: TextSelection and the TextEditor(text:selection:) initializer in iOS 18.

import SwiftUI

struct NoteEditor: View {
    @State private var text = "Select part of this text."
    @State private var selection: TextSelection?

    var body: some View {
        TextEditor(text: $text, selection: $selection)
            .frame(minHeight: 180)
    }
}

TextSelection can represent an insertion point (the caret) or a range of text. An app can therefore respond to a user's selection without inspecting the UIKit view behind SwiftUI.

This is meaningful progress, but it has two practical consequences:

The API requires iOS 18 or later.
It does not remove the need for UIKit when an editor is highly customized or must support older iOS versions.

Why UIKit feels more direct

UIKit has had a mature text-input model for a long time through UITextInput. Both UITextField and UITextView expose selectedTextRange; for multiline editing, UITextView also exposes selectedRange as an NSRange.

Here is how to select all text in a UITextField:

let field = UITextField()
field.text = "INV-2026-0817"

if let range = field.textRange(
    from: field.beginningOfDocument,
    to: field.endOfDocument
) {
    field.selectedTextRange = range
}

In UIKit, selection has long been part of the public API surface. You can read the active range, change it, and receive notifications when it changes.

One important note: the correct UIKit counterpart to a multiline TextEditor is UITextView, not UITextField. UITextField is still a useful example because both controls use the same UITextInput model.

Need	SwiftUI `TextEditor`	UIKit
User selection with native iOS UI	Yes	Yes
Bind the text value	`Binding<String>`	`text` plus target/delegate
Read or change selection in code	`TextSelection` on iOS 18+	`selectedTextRange` / `selectedRange`
Multiline editing	Yes	`UITextView`
Support selection state on older iOS	Needs another strategy	Long-standing API support
Highly customized input behavior	More limited	Broader delegate and `UITextInput` control

The fallback: wrap `UITextView`

If your deployment target includes iOS 17 or earlier and selection is a product requirement, the straightforward fallback is a UITextView in UIViewRepresentable.

struct UIKitEditor: UIViewRepresentable {
    @Binding var text: String
    @Binding var selectedRange: NSRange

    func makeUIView(context: Context) -> UITextView {
        let view = UITextView()
        view.delegate = context.coordinator
        return view
    }

    func updateUIView(_ view: UITextView, context: Context) {
        if view.text != text { view.text = text }
        if view.selectedRange != selectedRange {
            view.selectedRange = selectedRange
        }
    }

    func makeCoordinator() -> Coordinator { Coordinator(self) }

    final class Coordinator: NSObject, UITextViewDelegate {
        var parent: UIKitEditor
        init(_ parent: UIKitEditor) { self.parent = parent }

        func textViewDidChange(_ textView: UITextView) {
            parent.text = textView.text
        }

        func textViewDidChangeSelection(_ textView: UITextView) {
            parent.selectedRange = textView.selectedRange
        }
    }
}

The wrapper delivers the required control, but it comes with cost: two-way synchronization, focus management, accessibility, Dynamic Type, and range validation whenever text changes.

One detail is easy to miss: NSRange uses UTF-16 offsets, not Swift Character counts. Emoji and combined characters can make index conversion a source of bugs. Do not assume that NSRange(location: 2, length: 1) simply means “the third character.”

A gap that is still noticeable after SwiftUI's 2019 debut

Apple introduced SwiftUI in 2019 and has clearly continued to invest in it. TextSelection in iOS 18 shows that Apple recognizes modern editor requirements.

Still, the gap is not entirely closed:

The modern selection-state API arrived only in iOS 18, so it does not solve the problem for apps that support older systems.
Developers of feature-rich editors still often need UIKit's deeper capabilities.
Bridging to UITextView increases the size and complexity of a codebase for behavior that has long been fundamental to UIKit text input.

The fair criticism is not “SwiftUI cannot select text.” Users can select text in TextEditor. The more precise criticism is this: observing and controlling selection from SwiftUI arrived late, and it still does not fully replace UIKit's depth.

Practical recommendation

Use TextEditor(text:) for a simple note editor.
Use TextEditor(text:selection:) when iOS 18 is your minimum target and the app needs selection state.
Use a UITextView wrapper when you must support older iOS versions or need a highly customized editor.
Do not use UITextField for multiline content; use UITextView.

SwiftUI makes many things more elegant. For advanced text editing, however, UIKit remains an important escape hatch—which feels a little ironic after years of Apple investment in SwiftUI.

References

SwiftUI Text Selection vs UITextView: the compatibility gap Apple left behind

nooraja — Thu, 27 Aug 2026 06:25:23 +0000

Text selection is a small feature with a large usability impact. Users often need to copy error messages, transaction IDs, URLs, log output, addresses, or a single sentence from a longer block of text.

SwiftUI makes enabling it delightfully small:

Text("Request failed: 401 Unauthorized")
    .textSelection(.enabled)

However, this modifier has a behaviour change that matters a lot for compatibility. The same source code does not deliver the same selection experience on every supported iOS release.

The short version

Platform / version	What `.textSelection(.enabled)` does
macOS 12+	Lets people select a text range with normal pointer and keyboard conventions.
iOS / iPadOS 15 through 26	Long press exposes a system menu that acts on the whole `Text` view. No native range handles for selecting only part of that `Text`.
iOS / iPadOS 27+	Long press shows selection highlight and handles, enabling range selection.

Apple documents this distinction explicitly. The modifier has been available since iOS 15, yet the familiar partial-selection interaction only arrives in iOS 27. That is a frustrating gap for something as basic as selecting two words in a paragraph. Come on, Apple: SwiftUI should not force a UIKit escape hatch for a fundamental text interaction after so many years.

The iOS 27 row reflects Apple’s current documentation. Test it on the target OS and Xcode you are shipping with; do not infer the behaviour just from the modifier compiling.

What SwiftUI gets right

One clear, composable API

VStack(alignment: .leading) {
    Text("Build failed")
        .font(.headline)
    Text(logOutput)
        .font(.system(.body, design: .monospaced))
}
.textSelection(.enabled)

Applying the modifier to a container can enable selection for the contained Text views. That is clean, discoverable SwiftUI code with no subclassing or delegate plumbing.

Great for whole-value copying

On iOS 15–26, the behaviour is still useful when the entire value is what users want: a UUID, an email address, an API key displayed safely, an error message, or an IP address. Apple’s Human Interface Guidelines specifically calls out useful labels such as error messages, locations, and IP addresses as candidates for copyability.

Native accessibility and platform conventions

SwiftUI hands the interaction to the system, which is generally a good default. On macOS in particular, .textSelection(.enabled) feels natural immediately.

Where SwiftUI `Text` falls short

1. Partial selection on iOS was missing until iOS 27

For a paragraph, log, or legal text, users commonly want only a phrase. On iOS 26 and earlier, SwiftUI treats a selectable Text as a whole-value copy target. There are no selection handles to adjust the range.

This is the central limitation. The modifier can make an app look like it supports selection while delivering a less capable experience on most deployed versions.

2. No selection inside `Button`

Apple documents that Button views do not support text selection. If a piece of text needs both a tap action and copyable text, redesign the interaction or use a separate control instead of expecting .textSelection to solve both jobs.

3. Limited control over the interaction

Text exposes an opt-in switch, not a text-engine configuration surface. If the product needs precise selection behaviour, custom menus, programmatic ranges, selection-state observation, or highly custom rich-text interaction, SwiftUI’s simple modifier can become too restrictive.

SwiftUI `Text` versus UIKit `UITextView`

The useful UIKit comparison is UITextView, not UILabel.

UITextView is a full text component. For read-only selectable content, configure it with isEditable = false and isSelectable = true. It has long supplied UIKit’s standard range-selection UI: selection highlight, drag handles, the loupe in long text, and copy actions.

Unlike Text, it is imperative and heavier. In SwiftUI, it needs a UIViewRepresentable bridge; its container, scrolling, sizing, and accessibility need careful integration. But when the requirement is “select part of this text” on iOS 15–26, it is the reliable native answer.

UILabel is worth mentioning only to avoid a common misconception: it is a display view and has no native selectable-text API. Do not use it as the selection fallback.

Capability	SwiftUI `Text`	UIKit `UITextView` (read-only)
Display static text	Excellent	Good, but heavier
Enable copy with a small API	Yes: `.textSelection(.enabled)`	Yes: configure properties
Range selection on iOS 26 and earlier	No, whole `Text` action only	Yes
Rich attributed content	Improving, but intentionally higher-level	Strong interaction + display support
Selection handles / loupe / standard editing mechanics	iOS 27+ for `Text` ranges	Yes
Custom selection interaction	Limited	Broad UIKit control; can go further with `UITextInteraction`
SwiftUI layout ergonomics	Excellent	Requires a wrapper

So the relevant decision is Text vs a read-only UITextView.

The UIKit fallback for older iOS versions

When range selection is a requirement before iOS 27, bridge a non-editable UITextView into SwiftUI:

import SwiftUI
import UIKit

struct SelectableTextView: UIViewRepresentable {
    let attributedText: NSAttributedString

    func makeUIView(context: Context) -> UITextView {
        let textView = UITextView()
        textView.isEditable = false
        textView.isSelectable = true
        textView.isScrollEnabled = false
        textView.backgroundColor = .clear
        textView.textContainerInset = .zero
        textView.textContainer.lineFragmentPadding = 0
        textView.adjustsFontForContentSizeCategory = true
        return textView
    }

    func updateUIView(_ textView: UITextView, context: Context) {
        textView.attributedText = attributedText
    }
}

Usage:

SelectableTextView(
    attributedText: NSAttributedString(
        string: longReleaseNote,
        attributes: [
            .font: UIFont.preferredFont(forTextStyle: .body),
            .foregroundColor: UIColor.label
        ]
    )
)

UITextView has more layout and accessibility details to verify than Text: Dynamic Type, text-container sizing, links, scrolling, ScrollView nesting, and content compression. It is not as elegant, but it uses the mature UIKit text system that already supplies standard selection UI for native text views.

For custom UIKit text components, UITextInteraction can provide the system’s non-editable selection behaviour, including the selection UI and gestures, as long as the custom view implements the required text-input machinery.

A pragmatic compatibility strategy

Choose the implementation based on the user task, not ideology:

if #available(iOS 27.0, *) {
    Text(articleBody)
        .textSelection(.enabled)
} else {
    SelectableTextView(
        attributedText: NSAttributedString(string: articleBody)
    )
}

Use this strategy only when partial selection is a real requirement. A UITextView bridge is unnecessary complexity for a one-line order ID where copying the entire value is correct.

Decision guide

Short, whole-value content: use Text with .textSelection(.enabled).
macOS app: native SwiftUI text selection is usually the simplest choice.
Long text where iOS 15–26 users must select a phrase: use a read-only UITextView wrapper.
Custom interaction or selection menus: start from UIKit; evaluate UITextInteraction if UITextView is not enough.
Text inside a button: separate the button action from the copyable text.

Final thought

SwiftUI’s API is wonderfully small, and that is exactly why many teams reach for it first. But simplicity is only a win when the behaviour meets the platform expectation. Until iOS 27, .textSelection(.enabled) on iPhone is closer to “make this whole value copyable” than “let the user select text.”

That distinction belongs in product requirements, compatibility testing, and code review. Apple has finally closed the gap in the documented iOS 27 behaviour—but it took far too long for such a fundamental capability.