Programatically adding to a TextField and moving the TextSelection point in SwiftUI

Thanks for the focused reproducer and the video — they made this easy to investigate. There are two separate problems in what you're seeing, and the right answer is to switch to a different SwiftUI API for this kind of programmatic text editing.

The bug in your code: String.Index invalidation after replaceSubrange

RangeReplaceableCollection.replaceSubrange(_:with:) invalidates all indices into the collection (per the documentation), not just indices at or after the modified range. In your code:

self.text.replaceSubrange(from..<to, with: "Z")
let newIndex = self.text.index(after: from)   // 'from' is no longer valid!
selectedText = TextSelection(insertionPoint: newIndex)

After the mutation, from may not correspond to a grapheme boundary in the post-mutation string. The visible result depends on the underlying byte layout: for ASCII-only positions it often appears to work; near multi-scalar graphemes like 🧁 it can land mid-character, and index(after:) returns a position that doesn't match the new visible character layout. That's why the Z occasionally landed at a byte offset that recombined with adjacent cupcake bytes into a different grapheme cluster (the fairy emoji you saw).

If you stayed with TextField + String + TextSelection, the minimal fix is to capture the position as an integer offset before the mutation, then recompute the index against the new string:

let insertOffset = self.text.distance(from: self.text.startIndex, to: from)
self.text.replaceSubrange(from..<to, with: "Z")
let newFrom = self.text.index(self.text.startIndex, offsetBy: insertOffset)
let newIndex = self.text.index(newFrom, offsetBy: 1)
selectedText = TextSelection(insertionPoint: newIndex)

That eliminates the emoji corruption. But there's a second issue this fix doesn't resolve.

The second issue: the visible cursor doesn't follow your programmatic selection update on TextField + TextSelection

After the index fix, the I-beam still visually moves to the end of the text after the insert, even though selectedText correctly holds the new insertion point (you can verify this — the next "Add Z" press inserts exactly where the cursor logically is, not at the end). I tried Task { @MainActor in ... } to defer the selection update, @FocusState to keep the field focused across the Button press, and forcing TextField re-creation with .id(). None of those reliably repositioned the visible cursor.

This isn't really a "bug" so much as an API mismatch. TextField + TextSelection (introduced in macOS 15) gives you read access to where the user's cursor is — it isn't designed for programmatic text mutation with cursor control. There are no mutating methods on TextSelection, and no atomic "mutate text and update selection together" API on plain String.

The proper fix: TextEditor + AttributedString + AttributedTextSelection

In macOS 26 (which your project targets) Apple shipped a richer API specifically for this case. TextEditor has an AttributedString-based initializer, AttributedTextSelection is a value type that travels with AttributedString, and AttributedString itself has replaceSelection(_:withCharacters:) — which mutates the text and updates the selection together, internally handling all the index migration:

import SwiftUI

struct ContentView: View {
    @State private var text: AttributedString = AttributedString("abcdef🧁🧁🧁🧁ghijkl")
    @State private var selection: AttributedTextSelection = AttributedTextSelection()

    var body: some View {
        VStack {
            TextEditor(text: $text, selection: $selection)
                .font(.title)
                .frame(height: 60)
            Button("Add Z at Insertion Point") {
                text.replaceSelection(&selection, withCharacters: "Z")
            }
        }
        .padding()
    }
}

I built this against your repro with the cupcake string and stepped through every case you listed in the original post. It behaves correctly in all of them: Z lands exactly at the cursor, the cursor moves to right after the Z and stays visible there, and there's no emoji recombination near the cupcakes regardless of how many times you tap.

For richer mutations beyond a single replace, there's also AttributedString.transform(updating:body:), which lets you mutate the string inside a closure while the call site keeps the selection in sync.

One caveat

The catch is that TextEditor is multi-line by design, and TextField (the single-line control you're using) doesn't have an AttributedString initializer. If you need the single-line TextField look for this UI, you have three options, in roughly increasing effort:

1. Constrain TextEditor to single-line height and disable scrolling — visually similar in many designs.
2. Wrap NSTextField (or UITextField) via NSViewRepresentable/UIViewRepresentable, which gives you full programmatic control over selectedRange.
3. Stay on TextField + TextSelection with the index-fix workaround above, and accept that the visible cursor will drift to the end after each programmatic insert.

If you'd find a TextField initializer that takes AttributedString + AttributedTextSelection useful, please file a Feedback Report. The shape of the API already exists for TextEditor; extending it to TextField is a reasonable enhancement, and FBs from real-world use cases like yours raise the priority on those gaps.