No-code app platforms allow business users to create apps without writing code. There are many vendors with offerings that are labeled “no-code”. This article describes a framework with six criteria used to evaluate and benchmark these offerings. The article uses these criteria to evaluate and compare the two leading no-code app platforms: Microsoft PowerApps and AppSheet.
Our focus is on business users rather than software engineers, programmers, or IT personnel. A classic business user works in some line of business in the organization (small, medium, or large organization), has an existing full time job, is comfortable with the consumption of desktop, web, and mobile technologies, and is competent with tools like Microsoft Word, Excel, PowerPoint, Google Docs, and WordPress. Often, business users will interact with cloud-based productivity systems like Salesforce, Workday, ServiceNow, Jira, Trello, Hubspot, etc that may be managed by their own teams or by a central IT team.
Worldwide, there are many more business users ( ~1.5B) than developers (only ~15-20M).
This article considers app platforms that support business users who create and deploy their own apps to their teams (colleagues, vendors, etc) to improve business productivity. Such platforms must conform to certain tenets:
As we compare no-code platforms, there are two implicit subjective criteria that apply to all features and functionality.
We evaluate PowerApps and AppSheet along six technical dimensions.
Business apps need to connect with business data. PowerApps is integrated with Microsoft’s Common Data Model that shares a data connector framework with other Microsoft tools like Power BI and Flow. As a result, connectors to most common data sources are available. This is a strength of the platform.
Every business app needs to be able to run offline or at least occasionally disconnected. However, the PowerApps architecture is implicitly connected. If you want the app to work disconnected, you have to set up local tables and manage data loading yourself via code. That is described at length in Microsoft’s documentation.
This leads to ugly “code” like this:
Unless you are a developer, you should steer clear of such logic. And even if you are developer, it is completely non-trivial to debug such logic and determine when it should and shouldn’t be used.
Yet at the same time, the apps do not behave seamlessly when connected. It is common for apps to tell their users when there is newly available data. However, PowerApps does not automatically provide this functionality. Instead, this is the responsibility of the app creator. As described here, the recommended design is to use code to create a second data source to the same data, set up a background timer to repeatedly fetch the data, do a data diff by comparing data counts, and if so, show a refresh icon. Further, this timer has to be placed (but can be hidden) on the ‘current’ view, or else it will not run. The problems with this design are too many to list here, ranging from correctness to performance issues.
This design choice also impacts operations like bulk update of multiple rows. This should be a standard operation in business app platforms. In PowerApps, you have to write code to do this. You have to keep your own “copy” collection of updated records and then you have to copy these back over into the original dataset. This is really a fragile design. The app is doing a “shadow copy” rather than updating data in place. It is not clear what happens to formulas that run at the same time: Do they work on the original data or the shadow copy?
Summary: While the breadth of data connectors is a strong positive, the data architecture of PowerApps itself assigns too much responsibility to the app creator.
In comparison, while AppSheet has fewer builtin data connectors, the platform automatically provides offline support, data synchronization, concurrent and bulk update capabilities.
Apps often have to work with moderately large data sets (10,000 rows or more). In some cases, the data sets may be much larger but each app user may only need to see a smaller subset of the data.
In PowerApps, all the data used has to be brought to the device, so to be efficient, the developer has to create filters that reduce the number of rows in each table. This is called “delegation” and is described here. PowerApps tries to be efficient with the delegation filters by “pushing” them to the data source. For example, if the data source were a SQL database, PowerApps will try to convert the request into a SQL query so that only the (hopefully small) result is brought back to the device.
However, there are two problems with this:
In these cases, all the data is brought to the device and then filtered locally. This should still lead to a correct (though perhaps inefficient) result, except that PowerApps arbitrarily limits the number of rows that can be fetched per table. The limit is 500 rows (though recently, they have announced an increase of this limit in some cases to 2,000 rows). This has the effect of both producing arbitrary truncation of results but also incorrectness when there is logic that is based on the data.
A more appropriate and scalable design choice would have been to filter data at a cloud-based web service and then send that data to the device. Under no circumstances should data be truncated.
Summary: If you use PowerApps, make sure your apps use small data sets.
In comparison, AppSheet apps can scale to significantly greater data sizes, limited primarily by the storage capacity on the device. The Security Filter mechanism is similar to the "delegation" concept of PowerApps, but more powerful. The Data Partitioning mechanism allows apps with very large data sets to still be supported.
Mobile business apps should be able to enforce security at two levels: (a) through authentication -- i.e., signin, (b) authorization -- who can use the app and do what with it.
In PowerApps, authentication is exclusively handled via Active Directory. This is good because it integrates with the standard authentication mechanism used within many organizations. However, this is not so good if you want to use an app with anyone outside the organization (e.g., vendors, partners, etc). This turns out to be one of the major sources of dissatisfaction among the PowerApps user community.
Authorization should be simple and transparent. For PowerApps, you authorize different classes of users based on their group membership in Active Directory. By itself, this is sound design if PowerApps were to handle it natively. However, in order to implement this authorization logic, you will end up having to write complicated code as described here. You set up an Active Directory custom data connector. Then you manually pull group membership data into the app as a local table. Then you check this data to see if a specific group is present and if the current user is part of this group. So in effect, groups and roles are not used as a security model at all. Instead, the security model is implemented by your code and may have loopholes if your code doesn’t get it exactly right.
Summary: Security should be built into the platform rather than bolted on via code.
In contrast, the AppSheet platform treats security as a first-class concept. Apps may require sign-in but the users may be within the same domain or outside the domain. No procedural code needs to be written involved in setting up or enforcing security. The app creator has control over data security at the row level, and also over actions at the row level. These security controls can be conditional and data-driven to provide rich dynamic security options.
Most apps require dynamic behaviors that can be customized by the app creator. In a no-code app platform, you should expect common behavioral patterns to be easy to express in an understandable and logical manner.
PowerApps provides two mechanisms to control dynamic behaviors --- spreadsheet-style formulas and procedural code. Formulas are widely used in PowerApps and they provide a powerful yet declarative mechanism for behavior. We really like and approve of this design choice! Where formulas are used, they conform to the spirit of a no-code platform.
However, where code is used, it often results in brittle and opaque behaviors. Here are two examples:
Summary: We really like the emphasis on formulas even though the procedural code extensions make things complicated.
The AppSheet platform has similarly embraced the use of spreadsheet-style formulas. In fact, if anything, formulas in AppSheet are more powerful and more ubiquitous, controlling computed columns, form logic, localization, actions, workflow rules, and much more.
Of course, you need to be able to choose and configure mobile-friendly UI for your app.
Some standard display patterns are really easy in PowerApps. For example, this article shows how to use a Gallery control. There is unfortunately no map control, which is a serious limitation at the moment.
The default layouts can be customized via a drag-and-drop editor. While this adds flexibility, it also becomes the responsibility of the app creator then to ensure that the new layout works well on different device form factors.
You can also define your own custom controls, but while this sounds powerful, it turns out to be a _lot_ of custom code for basic functions. This article describes how to build a confirmation dialog for a Delete operation.
You have to build every element of it, lay it out and then hook up the events. Just like in Visual Basic. You have to define how to connect it with search, with sort, how to highlight the current item, etc. And you have to style it separately for iOS and for Android. That is a ridiculous amount of effort for a confirmation dialog.
Summary: The flexibility adds power but takes a lot of work.
The AppSheet platform consciously makes a different decision. Users can pick and configure broad display patterns, but cannot layout individual display elements. While this is less flexible, the platform can ensure consistent behavior and performance across a variety of form factors.
PowerApps provides an authoring environment with an emulator to see your app as it is being built. While the environment is powerful in what it can do, it is very complicated for a new user. Of equal concern, it is also very slow and these performance issues are a significant source of dissatisfaction in the PowerApps user forum.
Summary: An authoring environment for app creators should be intuitive and performant. Performance improvements will greatly enhance the experience.
In contrast, the authoring environment of the AppSheet platform integrates the end-to-end capabilities of app creation, deployment and management into a single intelligent dashboard that suggests next steps, identifies opportunities and steers the user towards successful outcomes.
PowerApps is an evolving platform. While we expect some aspects to improve, some of the core architectural decisions have already been made and will be tough to change. While simple apps can be built in a no-code fashion, it is more of a framework for software engineers to build apps by writing code snippets in a stylized way.
The data architecture and scale are matters of serious concern and we do not believe these concerns will recede in subsequent versions. They are a direct consequence of architectural choices of the platform.
The security model has limitations at the moment, but these issues can be addressed.
The behavior model based on spreadsheet-style formulas is by far the best aspect of the platform design. If Microsoft stays with an enhances this aspect of the platform, that will enhance the platform. However, the code-based behavioral extensions seem hacky at best.
The UI model provides the potential for rich and flexible UI. In subsequent versions of the platform, we hope to see more standardized UI elements introduced so that app creators do not have to write code for common UI patterns.
Finally, the authoring environment is sluggish and unnecessarily complex.
As you evaluate PowerApps further, make sure to consider product reviews like the following:
Also, read case studies like this article from Microsoft’s own IT department describing how they build internal apps with PowerApps. They use an entire dev and design team and a waterfall design process to build these apps. While they have been successful, I believe it is a true reflection of the product and that it targets a traditional IT-based development team rather than a citizen developer.
You should also consider alternatives. Most mobile apps that you’d be able to build on PowerApps are built easily on other no-code platforms like AppSheet, or on low-code platforms like Mendix or OutSystems. If you find positive reviews and happy customers for another app platform, you’re unlikely to go wrong. Good luck and much success in your app making.
The core technology in AppSheet differs from PowerApps in one significant way --- it is firmly "no-code". Everything that the app creator specifics is understood by the platform. While this limits some flexibility, it allows the platform to be intelligent, guide and help the app creator. This reflects in significant gains in simplicity and productivity.Post Comment
Praveen is CEO of AppSheet and full-time coder. Over his career, he has pursued the "dream" of declarative end-user programming in various incarnations. In a previous life, he was a CS professor at Cornell University. And in another previous life, he was a partner engineering manager at Microsoft in the SQLServer and Bing teams.