[BUG] Dictation overlay floods the macOS unified log with SwiftUI state-update warnings

[jonathanroomer]

Describe the bug

While FluidVoice's dictation overlay is active, the app repeatedly emits:

Modifying state during view update, this will cause undefined behavior.

On an always-running dictation setup with the global hotkey enabled, the warning reached roughly 90 records per second during active overlay refreshes and accumulated 170,870 records in the retained seven-day unified log.

A symbolicated backtrace points to PromptSelectorAnchorReader.updateNSView(_:context:), AnchorReportingView.reportFrame(force:), and the selector frame-change handlers in BottomOverlayView.swift.

updateNSView currently calls reportFrame(force: true). The resulting callback synchronously writes selector frame/window values into SwiftUI state during the current render pass. The overlay has three selector anchors, and each writes two state values, matching the observed six-warning bursts.

A locally tested minimal fix removes the forced unchanged report from updateNSView and delivers required callbacks on the next main-queue turn. The macOS test suite passed 153 tests with 0 failures (the existing Tiny Whisper fixture E2E was skipped in line with the project's CI command). Comparable debug runs emitted 114–120 matching warnings before the fix and 0 after. I have the patch ready and would be happy to open a linked PR if the maintainers agree with the approach.

Disclosure: This report was drafted and submitted by Codex on behalf of the account owner, with their authorization. The observations and measurements come from local diagnostics on the affected Mac.

Reproduction steps

1. Launch FluidVoice 1.6.5 on an Apple Silicon Mac.

2. Keep FluidVoice running with its global hotkey enabled.

3. In Terminal, run:

   /usr/bin/log stream --style compact \
     --predicate 'process == "FluidVoice" AND subsystem == "com.apple.runtime-issues"'

4. Trigger dictation so the overlay is shown.

5. Observe repeated SwiftUI Modifying state during view update faults.

Expected behavior

Showing or refreshing the dictation overlay should not mutate SwiftUI state during the current render pass or emit runtime faults.

Actual behavior

The selector anchor reader synchronously reports frames from updateNSView, causing repeated SwiftUI state-update faults and high-volume unified-log writes while the overlay refreshes.

App Version

1.6.5

macOS Version

macOS 26.5.2

Architecture

Apple Silicon

Logs or crash report

[com.apple.runtime-issues:SwiftUI] Modifying state during view update, this will cause undefined behavior.


Symbolicated application frames include:


PromptSelectorAnchorReader.AnchorReportingView.reportFrame(force:)
PromptSelectorAnchorReader.updateNSView(_:context:)
BottomOverlayView.handleActionsSelectorFrameChange(_:window:)

Screenshots or screen recording

No response

[github-actions]

This issue has been marked stale because it has had no activity for 5 days. It will be closed in 2 days if there is no further activity. Add the keep-open or pinned label to prevent automatic closure.

[github-actions]

Closing this issue because it remained inactive for 2 days after being marked stale.

[jdfetterly]

Additional observations from FluidVoice 1.6.9 (build 20), Apple Silicon that may relate to this issue.

Symptoms

Activating dictation with the configured hotkey displayed the recording overlay, but it became stuck and dictation was unusable. Quitting and reopening the app did not prevent recurrence.

Diagnostic findings

• Application logs showed microphone samples continuing to arrive while the overlay appeared stuck.

• The macOS unified log contained approximately 60,000 instances of the following warning over roughly 12 minutes, spanning app restarts:

  Modifying state during view update, this will cause undefined behavior.
  

• A short process sample showed repeated main-thread activity through these overlay and prompt-selection functions:

  BottomOverlayView.promptSelectorTrigger
  BottomOverlayView.selectedPromptLabel
  SettingsStore.dictationPromptDisplayName(for:appBundleID:)
  SettingsStore.dictationPromptSelection(for:)
  PrivateAIProviderPromptFormat.isAvailable(settings:)
  PrivateAIProviderPromptFormat.verifiedModelID(settings:)
  

Workaround and result

In Settings → Primary Dictation Shortcuts, we changed AI Prompt from Fluid Intelligence to Off. The user then confirmed that dictation worked again.

This was a single successful workaround test. We have not re-enabled the setting to test repeatability, and we have not established that the freeze has exactly the same cause as the selector-anchor warning reported here.

Is the fix proposed in this issue tracked elsewhere or included in an upcoming release? If this warrants a separate issue, we can report it there.

This follow-up was prepared with Codex from local diagnostics and reviewed by the affected user. No audio, transcription content, or full diagnostic files are included.