Product: Vozzy — custom keyboard + containing app for user-initiated dictation. Bundle: br.com.buddyapps.FlowType App Group: group.br.com.buddyapps.FlowType Flow: User selects our keyboard in a host app (Notes/Messages). Without Full Access, QWERTY input works locally. With Full Access, user taps Microphone to dictate. Containing app owns mic permission, AVAudioSession, capture, SpeechAnalyzer, Foundation Models. Keyboard never captures audio; it reflects shared state and inserts via textDocumentProxy. Already settled (do not re-ask): No public API to identify the host app. No public API to return to the host app. Feedback: FB22247647. Question (single issue): App Review Guideline 4.4.1 says keyboard extensions must not launch apps other than Settings. Is there any public, App-Review-compliant mechanism for a custom keyboard to request its containing app to activate audio capture for this user-initiated dictation flow? If yes: Which public API / App Intent surface? Is a visible switch to the containing app required? May the audio session continue while the user returns to the host app? May Stop/Cancel commands travel through an App Group while the containing app is backgrounded? Our current policy: Launch uses public NSExtensionContext.open (Debug only). Release has no keyboard path that opens the containing app. Release does allow in-place signaling when the app is already resident (App Group command + Darwin notification; launches nothing). We will not enable Release launch without a written answer naming an allowed public mechanism. App Group payload inventory + retention, Full Access-off QWERTY behavior, onboarding privacy copy. I do not have a focused Xcode sample because this is an API / App Review policy question, not a crash or incorrect return value. The keyboard extension never captures audio. Debug uses public NSExtensionContext.open; Release compiles that path out. I can attach flow diagrams and a device screen recording. Related: FB22247647 (return to host — already answered No; not re-asking).