To add voice input to an app you pick a recognizer, and the rest is a button.

The phone already has a speech recognizer

You do not need a model, a GPU or an account to start. Both mobile platforms expose a system speech recognizer to third party apps, and the shape is the same on each: request microphone access, request speech recognition access, start a recognition task against either a live audio stream or a recorded file, and read the transcripts that come back. For a search field or a quick note, that is the entire feature.

Apple is unusually direct about the limits, and they are worth reading before you promise anyone a speech to text mobile app. The Speech framework documentation says recognition tasks lasting longer than one minute are stopped, that individual devices may be limited in the number of recognitions performed per day, and that an app can be throttled globally on the number of requests it makes per day. It also tells developers not to send passwords, health or financial data for recognition at all. Those are product constraints, not edge cases, and the last one rules out a voice field on a login screen.

On device recognition is a flag rather than a separate API. On iOS you check whether the recognizer supports on device work, then set the request to require it, and Apple states plainly that on device requests will not be as accurate. The framework now also offers a newer analyzer with a transcriber module that has its own check for whether the current device supports the models it needs. The trade is the one you meet across on device ai mobile apps: nothing leaves the handset, nothing costs money, and quality depends on what the device can hold.

Apple, SFSpeechRecognizer: daily request limits and the one minute audio cap

What cloud transcription actually costs

Cloud recognition is priced per minute of audio and the numbers are small enough to be misread in both directions. Google Cloud Speech-to-Text charges $0.016 a minute for standard recognition on its v2 API up to 500,000 minutes a month, then $0.01, $0.008 and $0.004 a minute in higher bands. Its dynamic batch option, which processes audio at a lower level of urgency, is $0.003 a minute. The older v1 API gives 60 free minutes a month and then charges $0.024 a minute without data logging, or $0.016 a minute with it.

Two lines of the small print change the estimate. Billing is measured in increments of one second and each request is rounded up, so ten thousand three second voice commands are not the rounding error they look like. And each audio channel is billed separately, so a stereo recording of a two person conversation costs twice what the wall clock suggests. Record mono unless you have a reason not to.

Put your own numbers in before you decide anything. Five hundred people dictating ninety seconds a month is 750 minutes, which is twelve dollars at the standard streaming rate. The same five hundred people uploading an hour each is 30,000 minutes, which is $480 a month at the same rate. At small scale, cost is almost never the reason to avoid the cloud. Accuracy, latency and what happens with no signal are the reasons.

Google Cloud, Speech-to-Text pricing

The microphone button is most of the work

Calling the recognizer is the easy part. What makes a dictation feature app feel finished is the second between the tap and the first word on screen. Show a live level meter or a moving waveform so the user can see the app is listening. Print partial results as they stream in, even though they will jump around. Keep the final transcript editable, because it will be wrong sometimes, and a user who cannot fix it quietly stops using the feature.

Voice search in app menus and long lists needs one extra rule: do not run the query on the first partial result. Wait for the recognizer to settle, show the user what it heard, then search. A query that fires on a half heard phrase looks broken even when the transcription was fine, and the user has no way to tell which part failed.

Voice input is also an accessibility feature, and it has to work with the ones already on the phone. A screen reader user needs the microphone button labelled, needs to know that recording has started and stopped without watching an animation, and needs an obvious way to cancel. The same rules that govern every other control apply here, and they are set out in the app accessibility guidelines. One check before you build any of it: on most phones the system keyboard already has a microphone key, so for a plain text field you may be rebuilding something the user has already got.

Decide where the audio goes before you build

Two decisions outlive the button. The first is whether you keep the audio at all. A transcript is small, readable and easy to delete. A recording is a liability with a retention policy attached, and if you store both then you have shipped two features instead of one. Keep the recording only if a person will genuinely need to listen to it later.

The second is where the cloud call is made. An API key cannot live in a mobile app, because anyone who installs the app can read it out of the bundle. So the audio goes to an endpoint of yours first, which turns a screen level feature into a question about where transcription runs and what else that server is responsible for. It is a small server, but it is a server, and it is the point where this stops being an afternoon of work.

Permissions are the last thing to settle and the easiest to leave until review. iOS shows the user a purpose string for the microphone and a second one for speech recognition, and Android asks for microphone access at runtime. Those strings are the only explanation most people will ever read about what you do with their voice. Write one plain sentence, and make sure it is true.