AppSheet ships your app inside the AppSheet app, and that is the whole difference.
An AppSheet app is not an installable app by default. It is a definition that runs inside a host app your users download from the store. Google says so in its own words: by default, your AppSheet app is hosted on a mobile device within an existing mobile host app. There is a paid route that does produce a real binary, called a branded app, and Google documents it in full. The catch is in its own description of it. A branded app is effectively a copy of the AppSheet host app that only runs your app. It is not your project compiled, and it still fetches its definition from AppSheet on every sync. Every claim on this page comes from the AppSheet help pages or from Apple, read on 22 October 2026.
Below: what each of the three routes actually puts on a phone, what Google documents about getting a branded build into the App Store and Play, what it costs, and the rebuild clock nobody mentions until your users are locked out. If you are earlier than that and still comparing ways to build mobile app without coding, start there instead.
See what AppSheet puts on the phoneThe short version
So what does AppSheet actually put on a phone?
Three things, depending on which route you take, and only one of them is a binary. Route one is a browser tab. Route two, the default, is a home screen shortcut that opens the AppSheet host app and loads your app inside it. Route three is a branded build, which is an App Bundle and an APK for Android or an IPA for iOS, signed by you and uploaded by you.
None of the three is a progressive web app. The word does not appear on AppSheet's pages about mobile support, install links, deployment or branded apps. What goes on the home screen is a shortcut, and AppSheet calls it one: Add Shortcut, from the app menu in the top left. The browser route is a real option and most features work in it, with five named exceptions. Barcode scanning, NFC scanning, offline image and document caching, offline app launch and push notifications are not available in a browser.
The cleanest statement of the model is in the AppSheet FAQ written for IT departments. Asked whether each app is deployed separately through the iOS or Android store, it answers no, and explains that mobile apps run on the device inside a common host app called AppSheet, which is why any new app is instantly deployable. The Deploy page gives the analogy: your app sits in the AppSheet Hosting app much like a web page sits in a web browser.
Is a branded app a real app, or the wrapper with your icon on it?
It is a real, installable, store distributable binary, and it is also the wrapper. Both are true, and Google states both. A branded app is described as a native mobile app with your own branding that you can publish directly in an app store or distribute on your own. Two paragraphs later the same page says that when you create a branded version, it is effectively a copy of the AppSheet host app, but with your branding, and it only runs your app.
That distinction decides what you get. Capability is identical to the host app, so barcode scanning and offline launch work. Your app gains a store listing, an icon of its own and the ordinary install experience people expect. What it does not gain is independence. AppSheet lists the places its name survives branding: the sign in screen, error messages, and the permission prompts, where third-party sign in and camera or location requests name appsheet.com rather than you. The reason given is that the branded app still connects to your cloud provider through the AppSheet service. On iOS you can supply your own splash icon, and the phrase Powered by AppSheet remains in small print at the bottom of that screen.
The upside of being a wrapper is real, and it is the thing people like most about AppSheet. After the branded app is in the store, you do not resubmit it when you change the app. The latest app definition is fetched and used on every sync the user performs, so edits reach people the same day. Only a few changes need a new build: a new app name, a new icon, new store metadata, or a platform change that AppSheet asks you to pick up.
The downside is that there is no project underneath. You cannot open it, read it, hand it to a developer or move it anywhere. The same thing is true of other configuration tools in this family, and it is the point worth checking first on any of them, so the jotform to mobile app walkthrough asks the same question of a form builder.
AppSheet Help, what is a branded app, read 22 October 2026
Check yours
What each AppSheet route gives you
Tick what you need the app to do. Every answer below comes from AppSheet's own help pages, read on 22 October 2026.
Nothing ticked. If all you need is a form over a spreadsheet for people you can email, the free install link is the whole answer and you can stop reading here.
What does Google document about the App Store and Play?
A great deal, in two long pages, and both end with you doing the submitting. Android is the short one. In the editor you open Manage, then Deploy, then expand Branded Apps, turn on Brand this app, open the For Android section and click create. The build takes up to 24 hours. You get an email with links to an App Bundle and an APK, and those links are valid for 30 days, so download and keep the files. The App Bundle goes to the Play Store. The APK installs directly, which is the route for distributing to employees, and your users have to allow installs from unknown sources first. Google's page also tells you to enable App signing by Google Play, and to answer no when Play asks whether your app uses the advertising ID.
iOS is the long one, and the first line under Restrictions is the one to read before you plan anything: an Apple computer is required to create an iOS branded app. The signing work is yours. You enrol in the Apple Developer Program, register an explicit App ID and bundle identifier, create a certificate signing request in Keychain Access using the email address of your developer account, export the certificate and key as a .p12 with a password, and create two provisioning profiles, one ad hoc for test devices and one for the App Store. AppSheet asks for all of it. Two limits in that page bite people: the app icon has to be perfectly square and at least 1000 pixels on each side or the build fails, and you cannot register more than 100 test devices, each by its UDID.
After the 24 hour build you get two links, an App Store bundle and a test IPA. The test IPA goes onto a registered device over a cable. The App Store bundle goes up through Transporter from the Mac App Store, and AppSheet warns that it can take several hours before the build shows up in App Store Connect, where you can also run it through TestFlight. Then you submit it for review yourself. AppSheet is direct about what happens next: it does not and cannot guarantee that an app will pass review or be available in the App Store, and it says the same about Google's approval on Play. For the Apple-side sequence in order, the publish to app store walkthrough is the one to follow.
Apple's rules explain why the work lands on you, and they also explain why the host app model is allowed to exist. Guideline 4.2.6 says apps created from a commercialized template or app generation service are rejected unless they are submitted directly by the provider of the app's content. That is why AppSheet hands you an IPA instead of pressing submit for you. The same clause then names the alternative it accepts: a single binary that hosts all client content in an aggregated or picker model. The AppSheet app, with its App Gallery of everybody's apps, is that binary. Worth reading alongside it is guideline 4.2, which asks for features, content and UI that go beyond a repackaged website. A thin form over a spreadsheet is exactly the sort of thing that clause is pointed at, which is the real reason AppSheet will not promise you a pass.
Apple, App Review Guidelines, page dated Updated 16 October 2026, read 22 October 2026
What does the branded route cost, and when does it expire?
The branded path is gated by plan. Google's page says its use requires AppSheet Core for every app user, with a minimum of 10 licences, or Publisher Pro if the app does not require sign in. The AppSheet pricing page, read on 22 October 2026, lists Core at 10 US dollars per user per month. The 10 licence minimum therefore puts the floor at 100 dollars a month, before your eleventh user. Publisher Pro is listed at 50 dollars a month per app for an unlimited number of users, and the trade is written into the plan: no user sign in and no security filters. Starter at 5 dollars and Enterprise Plus at 20 dollars per user per month are on the same page, and neither is the plan the branded page names.
Then the clock, which is the part that surprises people, because a branded app has an expiry date whether or not you touch it. AppSheet supports branded apps on an operating system for at least 5 years after that OS release, and only while the version your users have is less than 18 months old. When it is older, users opening the app see a warning telling them to contact the app owner for a newer version, and they are eventually blocked. Keeping to the 18 month cadence earns a grace period of roughly 6 months, which AppSheet states as 5 years and 6 months of use after the final OS update.
Three Google pages give three different cadences for that rebuild, all read on 22 October 2026. The mobile support page says app creators need to update and distribute their branded apps every 18 months. The Android branded app page recommends uploading the latest version about once a year. The page on updating a branded app says every 1 to 1.5 years. Plan on the shortest of the three and the other two take care of themselves. The warning in the editor is the thing to watch: open the app and AppSheet tells you if the build is older than 18 months.
The ordinary host app has a clock too, and it is worth knowing if your users are on old hardware. AppSheet supports Android and iOS versions for 5 years after the last minor OS update, and supports its own store versions for 2 years, so apps will not run on devices with an OS more than about 7 years old. Today the floors are Android 9 and higher and iOS 12.0 or higher. People stuck below that can still use the app in a mobile browser, without the mobile only features.
Three ways an AppSheet app reaches a phone
| What you get | Browser | Shortcut plus AppSheet app | Branded build |
|---|---|---|---|
| Needs the AppSheet app installed first | No | Yes | No |
| Has its own App Store or Play listing | No | No | Yes |
| Barcode and NFC scanning | No | Yes | Yes |
| Push notifications | No | Yes | Yes, after a Firebase project and extra setup |
| Launches offline from cached data | No | Yes | Yes |
| Faces Apple or Google review | No | No | Yes |
| A Mac is required to produce it | No | No | For iOS, yes |
| Paid plan required | No | No | Core for every user, 10 licence minimum, or Publisher Pro |
| You get source code you own | No | No | No |
When is it worth rebuilding the app instead?
Keep the AppSheet app if the honest description of your app is a form over a spreadsheet, used by people you can email, and nobody needs to find it in a store. The install link is faster than any build, the data stays in the sheet your team already edits, and every change reaches users on their next sync. That is a good trade and it is why AppSheet has the users it has. Branding it is also worth it if the only missing piece is a store listing and you can carry the plan cost and the rebuild habit.
Rebuild when the limits start being the product. No source code means no developer can help you later. The look is AppSheet's look, because the host app draws your screens from a definition and not from components you control. Anything the platform does not support is not a thing you can add. And the whole arrangement depends on AppSheet's service: its IT FAQ confirms that all communication between the app and your backend data passes through it, and that the definition of each app is stored there.
Newly is an AI app builder, and the difference here is what it leaves behind. You describe the app in plain English and it writes a real React Native and Expo project that you own. It runs the app on cloud iOS and Android simulators while it builds, uploads iOS builds to TestFlight, publishes to Google Play internal testing, and builds a standalone Android APK. There is two way GitHub sync, so the code lands in your repository and a developer can pick it up. It is $25 a month, with no free tier.
The honest limits, since this page is about reading the documentation rather than the marketing. Newly does not submit to the App Store for you either, and for the same reason AppSheet does not: guideline 4.2.6 requires the provider of the content to submit. Rebuilding also costs you the thing AppSheet does best, which is pushing a change to everyone in an afternoon with no build and no review. And moving an app means moving its data, which is work no tool does for you. If your app is really a visual layout you want kept, the builder io to mobile app route covers that case instead.
Questions people ask about AppSheet and mobile apps
By default, no. Google's help page on branded apps says that your AppSheet app is hosted on a mobile device within an existing mobile host app. The Deploy page calls that the AppSheet Hosting app and compares it to a web page running in a browser. The IT department FAQ is blunter: asked whether each app is separately deployed through the iOS or Android app store, it answers no, because apps run on the device inside a common host app called AppSheet. There is a second route, the branded app, which does produce an installable binary. Read on 22 October 2026.
Describe the app once, then own what comes out
Write down what your AppSheet app does, screen by screen, and which of those screens people actually open. That list is the brief, and it is most of the work. What you get back is a project with your name on it and a build you can hand to Apple yourself.
Start building