Turn Google Sheets into a Mobile App: 3 Routes

There are three real ways to turn a Google Sheet into a mobile app: build it in AppSheet, put a phone-friendly Apps Script web app on top of the sheet, or have a native iOS/Android app built that connects to your data. AppSheet is fastest and works offline but charges per user. An Apps Script web app is the cheapest and keeps everything in your Google account, but it needs signal and isn't a store app. A native app gives you full control over offline sync, push notifications and your own store listing, and it costs the most. Which one is right depends less on the spreadsheet than on who is holding the phone, and where.

This isn't a pitch for one route. Below is what each route does, where each breaks, and a table to choose from. For the money side in depth, see what moving from Google Sheets to a custom app costs.

Start with the person holding the phone

Before picking a tool, answer four questions. They decide the route more than anything else.

1. What does that person need to do in 30 seconds? Mark present, log a delivery, check a balance, take a photo. If the answer is "edit the whole sheet", you don't need an app, you need the Google Sheets app and a better sheet.
2. Do they have signal? Pitches, pools, basements, warehouses and rural sites often don't. This one question rules routes in or out.
3. Who are they? Your own staff can install anything you tell them to. Customers and parents expect a store app with your name on it, or at least a link that just works.
4. What should they not see? A field worker on a phone shouldn't be one tap from every customer's payment history.

Keep those answers in mind through the three routes.

Route 1: AppSheet (no-code, on top of the sheet)

AppSheet is Google's no-code app builder. You point it at a Google Sheet, it reads your columns and generates a working app with list views, forms and detail screens, usable on Android, iOS and the web.

What it does well:

• Speed. A usable first version can exist the same day.
• Offline. Google's help centre says AppSheet apps can run on a device with no network, because the app definition and data are stored locally. Edits sync when the device reconnects. The app has to be launched online on that device at least once first.
• Phone features. Camera capture, barcode scanning and GPS are built in.
• The data stays in your sheet.

Where it pinches:

• Per-user pricing. Building and testing is free for up to 10 test users; production is billed per user per month (our AppSheet pricing breakdown has the current tiers). Many paid Google Workspace editions include AppSheet Core licences on a domain-verified account, so check yours first. For 5 staff, it's trivial. For 300 parents or customers who each need a login, it isn't.
• It looks like AppSheet. You can theme it, and on a paid plan AppSheet can generate a white-label app to submit to the Apple and Google stores, but the app still runs on AppSheet's engine and design system.
• Complex rules get awkward. Multi-step approvals, unusual permission matrices and heavy integrations are possible but quickly become a maze of expressions that only one person understands.
• Offline has caveats. Google's own guidance lists them: maps can't be shown offline, file columns aren't stored on the device, images are cached only if you turn that on, and running offline for days or weeks at a time isn't recommended.

Choose AppSheet when the users are your own staff, there are not many of them, they need offline data entry, and the screens are fairly standard forms and lists. For many field teams this is the honest answer, and it's the one we'd give you. Our AppSheet vs Apps Script comparison goes deeper on that choice.

Route 2: An Apps Script web app (or "PWA-like") on top of the sheet

Google Apps Script can publish an HTML page as a web app at its own URL. That page can read and write your sheet, check who's logged in and show each person only their screen. Built mobile-first, it gives a coach one big "present" button instead of a grid. Our guide to building a custom frontend for Google Sheets shows the pattern in code.

What it does well:

• Cost. It runs inside the Google account you already pay for. No per-user fee, no hosting bill.
• Fit. It's your code, so the screens can match exactly what each role does, with the business rules (locking, validation, approvals) in one place.
• Ownership. The script, the data and the logic live in your Google account. Nothing to cancel, nobody to renew.

Can it be a PWA? We hear this question often, and the honest answer is: only in a limited way. Here's what Google's documentation supports:

• Apps Script serves your HTML inside a sandboxed iframe (IFRAME is the only sandbox mode left), so you don't control the page's <head>, and links have to open in the top window or a new tab.
• HtmlOutput.addMetaTag() accepts only four meta tags: viewport, mobile-web-app-capable, apple-mobile-web-app-capable and google-site-verification. Meta tags written directly into your HTML file are ignored. You can also set a favicon with setFaviconUrl().

function doGet() {
  return HtmlService.createHtmlOutputFromFile('Index')
    .setTitle('Attendance')
    .addMetaTag('viewport', 'width=device-width, initial-scale=1')
    .addMetaTag('mobile-web-app-capable', 'yes')
    .addMetaTag('apple-mobile-web-app-capable', 'yes')
    .setFaviconUrl('https://example.com/icon-192.png');
}

That gives you a page that fits a phone screen and can be saved to the home screen as a shortcut. What it doesn't give you is a real installable PWA: Google documents no way to attach a web app manifest or register a service worker on the Apps Script page itself, and without a service worker there is no offline caching. Treat it as "a good mobile web page with an icon", not an app.

There is a workaround: host a small shell page on your own domain and embed the web app in it. Apps Script allows that if you set setXFrameOptionsMode(HtmlService.XFrameOptionsMode.ALLOWALL), and Google warns that you then have to handle clickjacking protection yourself. Even then, every save still goes to Google's servers, so it still needs signal.

Other limits to know: each script run stops at 6 minutes and there are caps on simultaneous executions per user (see our Apps Script 6-minute limit guide), there are no push notifications, and Sheets underneath is not a transactional database. Google may also show a notice bar at the top of the page saying the app was created by another user, not by Google. Google doesn't document when it appears, so check what your users actually see before sending the link to customers.

Choose an Apps Script web app when users have signal, the audience is mostly your own team (or a handful of clients through a secure portal), and you want the lowest running cost with full control over the screens.

Route 3: A native iOS/Android app

A native app is a real app in the App Store and Google Play, with your name and icon, installed on the phone. Built well, it does three things together that the other routes only do in part:

• Offline-first sync. Records are saved on the phone and sent when signal returns, without duplicates or lost edits. This is genuinely hard engineering (two people editing the same record offline is a conflict someone has to design for), and it's the main reason teams pay for a native app.
• Push notifications. "Your payment is due", "Training moved to 6 pm", "New job assigned". Notifications people actually see, instead of messages lost in a group chat.
• Separate experiences per role in one app. Staff see their tasks; customers or parents see only their own records.

What it costs you beyond the build:

• Store accounts: Apple's developer programme is $99 a year and Google Play charges a one-time $25 registration fee, and every release goes through store review.
• Hosting and a database behind it, plus maintenance as iOS and Android change every year.
• Time: weeks to months, not days.

Does the sheet stay? For a small team, a native app can read and write a Google Sheet. But once you add offline sync, many people writing at once and strict permissions, you'll want a real database and an admin panel behind the app, with Sheets kept for reporting. Our mobile apps service builds iOS and Android from one codebase so you don't pay for two apps, and our custom software service covers the admin panel behind it.

A real example: a multi-site sports academy we worked with moved from Excel and WhatsApp groups to a web admin panel plus one app with parent and coach roles, where coaches take attendance offline at the pitch or pool. A web page couldn't do the offline part, and parents and coaches needed different screens and permissions inside one app. That system is now a product, Academision.

Choose a native app when offline matters, you need push notifications, or the users are customers who expect a store app with your brand. And check first whether an off-the-shelf app for your industry already does it: if one fits at a fair price, it will beat any build on cost and time.

Decision table

	AppSheet	Apps Script web app	Native iOS/Android app
Time to first version	Hours to days	Days to weeks	Weeks to months
Running cost	Per user per month	Nothing extra on your Google plan	Hosting, store fees, maintenance
Works offline	Yes, with caveats	No	Yes, if built offline-first
Push notifications	Yes, from AppSheet bots, to the app on phones	No	Yes, fully under your control
App Store / Google Play	White-label app on a paid plan, still AppSheet underneath	No (home-screen shortcut only)	Yes, your own listing
Custom screens and rules	Moderate	High	High
Best audience	Your own staff, small to mid teams	Staff and a few clients with signal	Staff in the field and customers at scale
Data lives in	Your Google Sheet	Your Google Sheet	A database (Sheets possible when small)

A quick read of the table:

• Staff, signal, simple job: Apps Script web app.
• Staff, no signal, standard forms: AppSheet.
• Customers or parents, offline, notifications, your brand: native app.
• Not sure the sheet itself is the problem? Read the six signs you've outgrown Google Sheets first. Often the fix is a better sheet, not an app.

Migration: can the data stay in Google Sheets?

With routes 1 and 2, yes. The sheet is the database, and nothing moves. The one thing to fix first is the sheet's shape: one table per thing (customers, jobs, payments), a unique ID column, no merged cells, no colour-coded statuses. Apps built on a messy sheet inherit the mess.

With route 3, it depends on scale. A practical path we often recommend:

1. Start where you are. If an Apps Script web app solves 80% of the problem, ship that now. It's cheap and quick, and it tells you how people really use the screens.
2. Design the data as if it will move. Clean IDs, consistent dates, a status column with fixed values. That makes a later migration a copy, not an archaeology project.
3. Move to a database when the signals appear: offline needs, many simultaneous writers, outside users who must see only their own records, or audit requirements.
4. Bring the history with you. Past payments, jobs and attendance come across, so day one doesn't start from an empty screen.
5. Keep Sheets for reporting. Many teams keep exporting to a sheet for ad-hoc analysis long after the move, and a good system makes that one click.

Moving later doesn't mean starting over. The screens you designed in a web app become the specification for the native one.

Want help picking the route?

Most "we need an app" conversations we have end in one of three places: a phone-friendly Apps Script web app on the existing sheet, AppSheet for a small offline field team, or a native app with a proper back office. The useful first step is to work out which one fits your case.

• Book a free 30-minute discovery call. Bring the sheet and tell us who would use the app, where, and on which phones. We'll tell you which route fits and what would drive the cost, including "a web page is enough" when it is.
• Message us on WhatsApp with what the sheet does and who needs it on their phone. We'll reply with the route we'd start with.