This question comes up occasionally from app creators who want to use one of the per-app Publisher plans. The main feature difference between the per-app Publisher plans and the per-user plans is security.
If your app has any confidential data whatsoever, you should require user sign-in. This also means when you deploy your apps, you should be on a per-user plan (Standard, Premium, or Pro).
If you do not require sign-in, the data and the usage scenarios should be meant for the general public, and you should be in a per-app plan (Publisher, Publisher-Plus or Publisher-Pro).
Some of the security considerations are described below. There are four levels of security afforded to apps that require user to sign in:
- Requiring sign-in with a specific provider --- only users with an account hosted by a specific provider (eg: Google or Dropbox or Office365) can access the app.
- Specifying a user whitelist --- only specific users explicitly listed in a whitelist can access the app.
- Utilizing security filters --- the app can be configured to show different subsets of data to different users.
- Auditing --- the app can explicitly capture the identity of each user who makes a change to the app. Additionally, the audit history automatically captures the identity of every user who interacts with the app.
None of these security mechanisms are available to apps that disable the user sign-in feature.
Some app creators try to create their own workarounds for each of these levels of security. However, these approaches are inherently flawed:
- Instead of a whitelist, can I control distribution of the app install link?
- While this is possible initially when the app creator sends the install link to other users, there is no way to control who those users send the link to. Anybody with the link has access to the app.
- We have had multiple instances where an employee of a company has access to the app and then that person leaves the company. At this point, the company requests us to disable access and there is no way to do this.
- If the link is ever placed on a publicly accessible site, it may be crawled by a search engine. And the content of the app (the data shown in the app) could also be indexed by the search engine. This is because the intent for Publisher apps is to have broad public access to the app.
- Slices are a mechanism used to define "virtual tables". Even if somehow the user was identified and used in the filter condition of a Slice, this doesn't guarantee that the entire data set isn't accessible as well.
- When the app is opened in a browser, all the data used by the app is accessible to anyone who spends a couple of minutes to open the developer console and examine the data of the running application. There is no guarantee that the entire table isn't available even if a slice is defined on that table. The only way to ensure this is to use a security filter for the table.
- Not really. If you want to roll your own security, you need to worry about authentication (is the person who they claim they are), authorization (who has access to what), and a secure implementation (encrypted capture, transmission, and storage of passwords, as well as mechanisms to handle forgotten passwords, revocation, etc). This is a huge and complex undertaking. In fact, this is why AppSheet does not provide its own username and password mechanism. Instead, we utilize third party authentication via highly credible providers like Google, Dropbox and Office365.
To reiterate, if your app does not require user sign-in, you must be confident that the data in the app is meant for public consumption. If the app permits users to update the data, you must be willing to have anonymous user updates to the data. In all other cases, please require your users to sign in.