--- title: "Design speech input for denied permissions and offline limits | R&D COPILOT" lang: en canonical: https://rdcopilot.com/insights/mobile-speech-permission-fallback-offlingua/ content_version: 1514a85636b2bb5fc0d911a16ee1b115935f069d521add596184926710cdd39a contact: https://rdcopilot.com/contact/ --- [RDC](https://rdcopilot.com/) [Insights](https://rdcopilot.com/insights/)OffLingua OffLinguaHow-to guide # Design speech input for denied permissions and offline limits Speech input involves several separate capabilities: recording audio, recognizing words, processing the resulting text and optionally speaking the answer. OffLingua uses Apple Speech for voice input, whose offline availability depends on the language and iPhone. We use that distinction when designing a new mobile product so a denied permission or unsupported local recognition path does not leave the person unable to complete the task. By R&D COPILOT6 October 20265 min read In this guide 1. [Define what voice changes in the task](https://rdcopilot.com/insights/mobile-speech-permission-fallback-offlingua/#guide-section-1) 2. [Represent each stage of the voice path](https://rdcopilot.com/insights/mobile-speech-permission-fallback-offlingua/#guide-section-2) 3. [Keep text entry available after a refusal](https://rdcopilot.com/insights/mobile-speech-permission-fallback-offlingua/#guide-section-3) 4. [Separate audio handling from text retention](https://rdcopilot.com/insights/mobile-speech-permission-fallback-offlingua/#guide-section-4) 5. [Test availability, language and interruption](https://rdcopilot.com/insights/mobile-speech-permission-fallback-offlingua/#guide-section-5) 6. [Scope speech as part of the complete interaction](https://rdcopilot.com/insights/mobile-speech-permission-fallback-offlingua/#guide-section-6) [Sources & inspiration](https://rdcopilot.com/insights/mobile-speech-permission-fallback-offlingua/#guide-sources) ## Define what voice changes in the task Voice may help when typing is inconvenient, but it also introduces noise, pauses and transcription errors. Decide whether the user dictates a short field, a longer note or a command with consequences. The confirmation step should match that consequence. A recognized command should not become an irreversible action merely because it was spoken fluently. A dictated field and a spoken command need different confirmation. A note can remain editable before saving, while a command to submit a report may need a visible preview and explicit confirmation. Decide how the app handles pauses and the end of an utterance. Avoid acting on a partial transcript that may still change. This is particularly important for quantities, identifiers and short negative phrases, where a small recognition error can reverse the user's meaning. ## Represent each stage of the voice path Show recording, recognition and subsequent processing as distinguishable states. Let the user see and correct the transcript before it enters a business record where accuracy matters. Spoken output has its own language and device behavior. A product should not imply that every translation language is also available for recognition or speech playback. Model microphone capture, speech recognition, text processing and playback as distinct steps. The app can have permission to record while recognition is unavailable for the selected environment. A transcript may arrive successfully while a later service fails. Show which stage needs attention and retain useful text where appropriate. For an on-device requirement, check the relevant recognition capability and request behavior rather than inferring support from the presence of a microphone button or a translation language choice. ## Keep text entry available after a refusal Ask for microphone or speech access at the point where the person chooses voice and can understand the purpose. If access is denied, explain the relevant option without repeatedly blocking the main task. Preserve a usable text route and retain any confirmed content. Where local recognition is required, verify capability rather than silently switching to a network path. Design the first refusal as an ordinary product path. Offer typing immediately and make the route to settings available without repeated permission prompts. If the person changes language, reassess the recognition capability for that choice. A network-required path should be clearly explained before it is used where the product promise requires that distinction. Preserve the user's selected task so switching to text does not force them to navigate back through setup. ## Separate audio handling from text retention The application may need a transcript without needing to retain the recording. Decide that explicitly and examine any processing service involved. Permission text should match the actual purpose and data path. For EU users, the privacy review should account for people incidentally heard in the background and the information users may dictate into an otherwise ordinary field. Decide whether raw audio is temporary, stored for the user's own history or sent to a service. The transcript can contain personal details even when audio is discarded. Keep dictated content out of routine analytics and review whether crash information can include it. Explain recording with a visible control and state, including what happens when the app moves to the background. The permission request should describe the concrete feature, not ask for broad access with a vague productivity promise. ## Test availability, language and interruption Run the intended languages on the supported device range with and without connectivity. Include denied permissions, interrupted recording, long pauses and noisy environments. Measure usable transcription, corrections and successful fallback to text. Apple's on-device recognition capability needs to be checked for the relevant recognizer and environment; a general offline promise is too broad. Use a language-and-device test matrix with separate results for recognition and playback. Include quiet and noisy conditions, denied permission, interrupted capture and a language change after setup. Test connectivity loss before recognition starts and while it is running. Measure the corrections needed to produce usable text and whether users can complete the same task through typing. A successful transcription in one configuration does not establish offline behavior for every supported translation language. - Distinguish recording, recognition, text processing and playback states for the languages and devices you intend to support. - Keep typing available after a permission refusal without discarding the user's selected task or confirmed text. - Verify on-device recognition requirements separately from translation language choices and spoken-output availability. - Test partial transcripts, noise and interrupted capture before authorizing actions based on recognized commands. ## Scope speech as part of the complete interaction Bring the spoken task, expected languages, physical environment and required fallback. We can build the permission journey, voice states, transcript review and subsequent action together. The proposal should state which combinations will be tested and how unsupported conditions behave. This makes the voice feature useful without making every other part of the app depend on it. We can build a speech interaction around one defined task and an explicit fallback. The scope should identify transcript review, permission handling, recording states and the action that follows recognition. Bring example utterances, target languages and the environment where people will speak. The proposal can then name the combinations tested and the behavior outside that scope, with future language expansion treated as additional validation rather than a simple change to a picker. Inside the product ## OffLingua [![OffLingua text translation on iPhone.](https://rdcopilot.com/mobile-apps/offlingua-text.jpg)View full size](https://rdcopilot.com/mobile-apps/offlingua-text.jpg) OffLingua — translation on the device. Swipe or use the arrows to explore. Image 1 of 1 Follow the references ## Sources & inspiration ### [OffTongue](https://devpost.com/software/offtongue) Devpost project by Shivansh Chauhan, Tanishq Maheshwari On-device speech translation. This independently created project is credited as inspiration. The workflow and implementation guidance in this article are RDC’s analysis. - [Apple: supportsOnDeviceRecognition](https://developer.apple.com/documentation/speech/sfspeechrecognizer/supportsondevicerecognition) - [Apple: clear purpose strings](https://developer.apple.com/help/app-review/guideline-reference/5-1-1-purpose-strings) - [OffLingua official product page](https://offlingua.rdcopilot.com/) Put the guide to work ## Start with your workflow. Tell us what your team needs to do, which systems are involved and where the current process slows down. [Discuss your project](https://rdcopilot.com/contact/?service=mobile-apps) [Explore OffLingua](https://offlingua.rdcopilot.com/) OffLingua ## Keep exploring. [All guides](https://rdcopilot.com/insights/) Workflow ### [Camera-to-text workflows that let the user check the original](https://rdcopilot.com/insights/mobile-photo-text-review-offlingua/) Design camera-to-text workflows with usable framing, source-linked review and controlled corrections, informed by OffLingua's original and translated photo views. [Read guide](https://rdcopilot.com/insights/mobile-photo-text-review-offlingua/) Decision guide ### [Designing an on-device AI app: the OffLingua example](https://rdcopilot.com/insights/offlingua-on-device-ai-app-development/) Use the OffLingua engineering example to scope model downloads, local AI readiness, device testing and explicit data boundaries for a new mobile product. [Read guide](https://rdcopilot.com/insights/offlingua-on-device-ai-app-development/)