Searching for an app for Google Forms returns three different products to three different people, and the results page does not distinguish between them. One person wants something on a phone to build a form during a commute. Another wants something on a phone to read what came in overnight. The third has a specific gap, usually notifications or a closing date or turning an answer into a document, and is looking for something to bolt on.
The first want is the one with the cleanest answer, and it is not the answer most people expect.
Google does not publish a Forms app
Google's own product page for Forms offers a web link and a sign in, and no download for iOS or Android. Forms does not appear among the apps listed under Google LLC on the App Store either, alongside Maps, Calendar, Photos and the YouTube family. What the product page does say about devices is about the person answering rather than the person building: respondents can open and complete forms from any device.
That wording is accurate and it is the whole design. A Google Form is a web page for the respondent and a web editor for the builder. On a phone, both run in the browser, and the editor is usable rather than pleasant.
The consequence for anyone searching an app store is worth stating plainly. The listings there that carry the Forms name are published by independent developers, not by Google. Some are competent wrappers around the same web editor. Some are ad supported. None of them add a capability that the web version lacks, because they are all sitting on top of the same product. Paying for one buys a container, not a feature.
The Google application that does touch Forms on a phone is Google Drive, which will open a form and hand it to the browser, and Google Sheets, which shows the responses spreadsheet properly on a small screen. For the common case of checking overnight submissions while standing on a train, Sheets is the tool that actually works.
The three things people mean
| What was meant | Where it actually lives | Worth paying for |
|---|---|---|
| Build a form on a phone | The web editor in a mobile browser | No |
| Read responses on a phone | The Google Sheets app on the responses spreadsheet | No, included |
| Notify a person when a response arrives | Built in notifications, or a Marketplace add on for anything specific | Sometimes |
| Close a form on a date or at a count | A Marketplace add on | Often |
| Turn a response into a document or certificate | A Marketplace add on | Often |
| Track who is handling each response | Not solved by any add on | Different tool |
The pattern in that table is the useful part. Everything to do with capture and formatting has an answer inside the Google world. Everything to do with what happens to a submission after it arrives has either a partial answer or none.
What the add ons genuinely fix
Add ons for Forms come from the Google Workspace Marketplace, and the good ones solve narrow problems well. Four categories cover most of what people install.
Closing a form. Forms has no native setting to stop accepting responses at a specific time or after a specific number of submissions. Add ons that watch the response count or the clock and flip the form closed are the single most installed category, because event sign ups and limited places need it constantly and the alternative is somebody remembering to toggle a switch at midnight.
Richer notification. A notification that includes the answers, goes to a different person depending on a field, or arrives in a chat channel rather than an inbox is add on territory. This is the category that most often gets replaced later by something else, for reasons covered below.
Generating a document. Merging a response into a templated document, then emailing it back as a PDF, covers certificates, confirmations, quotes, and signed agreements. This genuinely removes work, and the work it removes is measurable.
Response validation beyond the built in rules. Checking an entry against an existing list, rejecting duplicates, or confirming a reference number exists before accepting the submission.
Each of these is a real fix. What they share is a ceiling.
The ceiling every add on shares
Almost every Forms add on is built on Apps Script, which means they all inherit the same published quotas. These are the numbers to know before designing a process around one, and they differ sharply between a consumer Google account and a Google Workspace account.
| Limit | Consumer account | Google Workspace |
|---|---|---|
| Email recipients per day | 100 per day | 1,500 per day |
| Triggers total runtime | 90 min per day | 6 hr per day |
| Script runtime per execution | 6 min per execution | 6 min per execution |
| Simultaneous executions per user | 30 per user | 30 per user |
| Custom function runtime | 30 sec per execution | 30 sec per execution |
| URL Fetch calls per day | 20,000 per day | 100,000 per day |
The row that causes the most trouble is 100 email recipients per day on a consumer account. A form that sends a confirmation to each respondent is fine at twenty submissions a day and stops working at one hundred and one. The failure is silent from the respondent's side: they submit, they see the confirmation page, and no email arrives. Nobody finds out until somebody calls to ask.
The trigger runtime limit bites in a different shape. Ninety minutes a day across all triggers sounds generous until a script that processes an attachment takes forty seconds per submission. Three hundred submissions in a day is three hours of runtime, which the quota will not allow, and the overflow does not queue politely.
Two structural facts matter as much as the numbers. An Apps Script add on runs as a specific person, so the confirmation emails come from that person's address and stop working when that person leaves and the account is suspended. And a script bound to a form or a spreadsheet is invisible to everyone who does not know to look in the editor, which makes it the classic piece of undocumented infrastructure that breaks eighteen months later with nobody left who knows it exists.
Checking an add on before installing it
Installation asks for permissions, and the list is worth reading rather than clicking past. A notification add on typically needs to see the form, see the responses, and send email as the person installing it. That third permission is the one with consequences beyond the form: messages will leave from a real person's address, counted against that person's daily allowance, and recipients will reply to them.
Two checks take a minute each. Look at who publishes the add on and whether the listing names a company with a support address, because an add on that stops being maintained becomes a broken step in a live process. And ask what happens to the data, since a script that reads responses can also copy them, which matters for any form collecting personal details.
On a managed Google Workspace domain, installation may need an administrator, and finding that out before designing a process around a specific add on saves an awkward conversation later.
What no add on changes
The gap that sends people looking for an app in the first place is usually none of the above. It is that a pile of responses in a spreadsheet has no idea who is dealing with each row.
A spreadsheet column called Status gets added within the first week. A column called Owner follows. Both are honest attempts and both record intention rather than fact, because the actual work happens somewhere else. The reply to an applicant gets written in Gmail, which means the record that it was sent lives in one person's sent folder. The next colleague to open the sheet sees a row marked In Progress with no way to tell whether that means somebody is reading it or somebody wrote to the applicant four days ago and is waiting.
Three specific failures follow, and every team handling more than a trickle of submissions hits all three.
Two people answer the same submission, in different words, within an hour of each other. Nothing in the sheet prevented it, because nothing in the sheet knew the first reply had been sent.
A submission gets no answer at all. It sits in a row below the fold with a status nobody set, and it surfaces when the person chases, usually to a third party.
Nobody can say how long anything took. The sheet has a timestamp for arrival and no timestamp for resolution, because resolution happened in a mail client.
None of this is fixable with a better add on, because the missing piece is not a feature. It is that the record of the request and the act of replying to it are in two different applications. Tools built for this put them in the same place, so that the status changes because a reply was sent rather than because somebody remembered to update a cell. That shape is worth seeing in motion before deciding, and a short walkthrough settles the question faster than a feature list does.
Deciding between an add on and something else
Three questions separate the two cases cleanly.
Is the missing piece a step or a place? A step is something that should happen automatically at submission: send a document, close the form, check a value. Add ons do steps. A place is somewhere the request lives while a human works on it. Add ons do not do places.
How many people touch a submission after it arrives? One person with a spreadsheet and a couple of add ons is a perfectly reasonable system, and replacing it would be a waste of a fortnight. Three or more people, and the coordination cost starts to exceed the cost of the tool.
How much of the work is individual replies? Where nearly every submission ends in a message somebody types by hand, that typing is the job, and the tool that does not hold it is in the wrong place. Where submissions mostly get counted and reported, the spreadsheet is fine and an add on will cover the edges. This is the same distinction described across the use cases for recruitment, grant programmes, and support intake.
What to change first
Install the add on if the gap is a step, and be specific about which quota row the volume will hit before building a process on it. If the gap is that nobody can tell who is handling which submission, no add on closes it, and the thing to compare is where the reply gets written rather than which wrapper looks nicer on a phone. Halict is priced by the number of people using it rather than by responses, which is the axis that matters once more than one person is answering.
Q1. Is there an official Google Forms app for iPhone or Android?
No. Google's product page for Forms offers a web link rather than a download, and Forms does not appear among the apps listed under Google LLC on the App Store. Forms runs in a browser on every device, and the Google Sheets app is the practical way to read responses on a phone.
Q2. Are the Google Forms apps in the App Store made by Google?
The listings carrying the Forms name are published by independent developers. They wrap the same web editor, so they do not add capabilities that the browser version lacks. Check who the seller is on the listing before paying for one.
Q3. Why did the confirmation emails from an add on stop arriving?
The most common cause is the Apps Script daily quota. A consumer Google account is limited to 100 email recipients per day, against 1,500 for a Google Workspace account. The form keeps accepting responses and shows the normal confirmation page, so the failure is invisible until somebody asks why they heard nothing.
Q4. Can Google Forms close automatically on a date or after a set number of responses?
Not natively. Closing a form on a schedule or at a response count is the most common reason to install a Marketplace add on, and several do it reliably. The alternative is someone manually switching off the Accepting responses toggle at the right moment.
Q5. Can an add on track who is handling each response?
No add on solves this properly, because the reply is still composed in a mail client while the tracking sits in a spreadsheet. Columns for Owner and Status record an intention that nothing enforces. Teams of three or more handling individual replies generally need the record and the reply in the same place rather than another add on.