Feature Request: Option to disable audio record lock (slide-to-lock) in ChatView

[swift2geek]

Summary

When a user holds the microphone button to record audio, a lock capsule appears that allows sliding up to lock the recording into a hands-free (tap-to-toggle) mode. This UX pattern is not desirable for all apps — some want a simpler or different recording flow — but there is currently no way to opt out without forking the package.

Problem in Detail

Starting from v2.1.4, the recording model changed significantly:

• Before (≤ v2.1.4): The mic button toggled between two states on a single button: mic icon → tap → recording starts; stop icon → tap → recording stops and sends. Simple, stateless, no gesture required.
• After (≥ v2.2.x): Recording requires hold-to-record. While holding, a lock capsule appears above the button. Sliding up locks into hands-free mode. Releasing without locking sends immediately. There is no way to replicate the old tap-to-toggle behavior without modifying the package internals.

The lock capsule UI is hardcoded inside InputView and lockRecordButton view (lines 413–430), with the swipe-to-lock gesture in dragGesture() (lines 551–555) and auto-lock on drop in onEnded (lines 573–575). There is no public API to disable this.

Proposed API

Option 1 — A simple opt-out modifier on ChatView:

.audioRecordLockEnabled(false)

Disables the lock capsule UI and the swipe-to-lock gesture, keeping everything else intact.

---

Option 2 (preferred) — A recording mode modifier:

.audioRecordingMode(.tapToToggle)

Restores the v2.1.4-style flow: mic and stop on a single button, no hold required, no lock capsule. This is more user-friendly for many use cases and would be a natural default for simpler chat UIs.

---

Option 3 — Expose InputView building blocks so consumers can compose their own recording UI using the existing InputViewAction / InputViewState API.

Workaround

Currently the only options are:

• Forking the package and patching InputView directly — not maintainable across updates.
• Pinning to v2.1.4 — loses all improvements made since then.

Neither is acceptable for production apps that want to stay on a supported version.

Environment

• ExyteChat: 2.7.8 (also reproduces on 2.7.9, 2.7.10 / 3.0.x based on source)
• iOS 17+, SwiftUI
• Xcode 16

Screenshots

• Screenshot 1: lock capsule appearing during hold-to-record