Override preset Name field is not tappable: first List row sits under the navigation bar (iPhone 16 Pro/iOS 27.0 beta)

[BirdBearBeast]

Override preset Name field is not tappable: first List row sits under the navigation bar (iPhone 16 Pro/iOS 27.0 beta)

Describe the bug

In the Add Override and Edit Override forms, the Name row renders on screen but does not accept taps. Nothing happens at all: no cursor, no keyboard, not even the help sheet. Every other control in the same form (percentage, duration, target, SMB options) works normally.

The result is that override presets cannot be named on this device. They fall back to the auto-generated name in OverrideStorage.swift:133-137:

if !override.name.isEmpty {
    newOverride.name = override.name
} else {
    let formattedDate = self.dateFormatter.string(from: Date())
    newOverride.name = "Override \(formattedDate)"
}

so every preset ends up called something like Override 8/14/26, 08:35. Existing presets cannot be renamed either, because the Edit form has the same problem.

There is a workaround that also isolates the cause: raising Dynamic Type (Settings, Accessibility, Display & Text Size, Larger Text) to a large size makes the Name field tappable. Verified on the affected device. Details under Technical Details below.

Attach a Log

attached.

To Reproduce

1. Go to Adjustments, Overrides, tap + to add an override.
2. Tap the Name field in the first row.
3. Nothing happens. No keyboard, no cursor.
4. Set any other values and save. The preset is named Override <date>, <time>.
5. Swipe left on that preset and tap Edit. Tap the Name field. Same result.

Expected behavior

Tapping the Name field focuses it and opens the keyboard, in both the add and edit forms, at any Dynamic Type size.

Screenshots

Couldn't think of a good way to reproduce/show in screenshots and screen recording doesn't register taps.

Setup Information (please complete the following information):

Smartphone:

• Hardware: iPhone 16 Pro
• OS Version: iOS 27.0 beta

Pump:

• Manufacturer: Insulet
• Model: Omnipod 5

CGM:

• Device: Dexcom G7
• Manager app: Dexcom App

Trio Version:

• Version Number: 0.8.4.54 (build 1)
• Repo: nightscout/trio
• Git Reference: dev 29a5417 (2026-08-09)

Technical Details

Why the Dynamic Type workaround points at layout, not the TextField

The row's top edge stays pinned at a hardcoded 30pt, but a larger text size increases the row's height, so its bottom edge grows downward until it clears the navigation bar and becomes hit-testable. Returning Dynamic Type to normal makes the field unreachable again. The TextField and its binding work correctly; only the layout is wrong.

The modifier stack

Both override forms share an identical stack, and in both the Name row is the first row of the List:

• Trio/Sources/Modules/Adjustments/View/Overrides/AddOverrideForm.swift:26-36
• Trio/Sources/Modules/Adjustments/View/Overrides/EditOverrideForm.swift:83-93

List {
    addOverride()      // first Section is the Name TextField
    saveButton
}
.listSectionSpacing(10)
.padding(.top, 30)
.ignoresSafeArea(edges: .top)
.scrollContentBackground(.hidden)
.background(appState.trioBackgroundColor(for: colorScheme))
.navigationTitle("Add Override")
.navigationBarTitleDisplayMode(.inline)

.ignoresSafeArea(edges: .top) places list content at the physical top of the screen, and the offset is then corrected by a hardcoded .padding(.top, 30). On a Dynamic Island device the top safe-area inset plus a 44pt inline navigation bar is roughly 100pt of chrome, so 30pt does not clear it. The first row is drawn underneath the navigation bar, which is touch-opaque across its full width, so it is visible but not hit-testable.

A fixed 30pt against a device-dependent safe-area inset would explain why this does not hit everyone. In #1147 the reporter was clearly able to name temp targets on an iPhone 14 Pro, which has a smaller top inset.

The Name TextField is also .multilineTextAlignment(.trailing), which places it directly beneath the questionmark.circle toolbar button in topBarTrailing, so on devices where it is partly reachable it may trigger the help sheet instead.

Likely also affects Add Temp Target

Trio/Sources/Modules/Adjustments/View/TempTargets/AddTempTargetForm.swift:32-42 carries the same modifier stack with the Name row first, so I would expect the same behavior there. I have not confirmed it on device, so treat that as inference from source rather than an observation.

Suggested fix

Replace the hardcoded .padding(.top, 30) with a safe-area-aware inset, or drop .ignoresSafeArea(edges: .top) on these forms so the navigation bar reserves its own space.

Additional context

TrioRemoteControl+Override.swift:23 matches presets for remote activation by exact name string:

if let preset = presets.first(where: { $0.name == overrideName }) {

Auto-generated timestamp names make remote activation impractical, since the command has to carry a string like Override 8/14/26, 08:35.

log_prev.txt
log.txt

[dnzxy]

Works fine on iOS 26.6 running latest Trio dev (currently 0.8.4.61).

[dnzxy]

The additional context comment is nonsense; presets don’t carry a timestamp name.

[BirdBearBeast]

hmmm...weird, maybe it's because I'm not on the latest dev version but screenshot from my preset list attached. That one is called Override 8/16/26, 19:25. I didn't type that, Trio did, because I can't tap the Name field to enter anything.

Trio doesn't require a name to save a preset, and when the name is blank it fills in "Override" plus the current date and time. If the Name field works on your device you'd never run into this, which is consistent with your 26.6 response.