Apps Script or App Maker: a guide to picking the right tool to build your app

The great thing about building applications on G Suite is that you have flexible options. That said, we often get questions from developers about which tools they should use, specifically “should I build my application using Apps Script or App Maker?”

Apps Script and App Maker share a common deployment platform, and are perhaps more similar than they are different. Both let you build custom business applications quickly. Both leverage the same infrastructure. Both let you apply your skills in G Suite.

But they are uniquely different, too. Apps Script’s strength lies in the fact that it helps you integrate your app with G Suite apps like Gmail, Google Drive, Docs or Sheets. As a relative newcomer, App Maker builds off of Apps Script’s strengths, but also lets you build beyond the bounds of G Suite. It allows you to design your own user interface independent of G Suite apps, as well as declaratively design your own data model.

The good news is that you have a choice. Here are important factors to consider when choosing Apps Script or App Maker for your next application.

Consideration #1: Does your app need to run outside of your organization?
Choices made for you are often the easiest. In choosing Apps Script or App Maker, sometimes your app requirements will determine which technology you can use.

For example, App Maker requires that all your users have access to the product and they are all on the same domain. If your application needs to run cross-domain or will have external users outside your organization, then App Maker will not work. Another consideration is most apps built in App Maker rely on Cloud SQL for data storage, so if you don’t have access to Google Cloud SQL or would prefer not implementing it, then Apps Script is your choice by default.

Key takeaway: For external or cross-domain users, choose Apps Script.

Consideration #2: What do you feel most comfortable building in? And what coding language do you prefer?
Another important factor is a matter of comfort and personal preference. If you think you are more productive building an application within a spreadsheet, especially if one already exists, then start by building on Google Sheets with Apps Script. As a developer, there is slightly more of a learning curve with App Maker and a little more work to do at first to get your app up and running, like working with relational data models or laying out your user interface from scratch. Apps Script relies on the host applications for much of its functionality, and is, for the most part, faster and more flexible to produce a prototype in.

As mentioned, Apps Script and App Maker share many similarities including the same underlying programming language and runtime, which happens to be Google Apps Script. This is great because your skills (and even some code) is transferable, making choosing either option based on programming skill or language essentially a moot point. There are other differences to consider that go beyond the scope of this post, though, like distribution, versioning and the developer experience. But nothing that is dramatic or widens the gap between choosing one over the other.

Key takeaway: Toss Up. Both use Apps Script for coding.

Key takeaway: Choose based on your comfort level. With Apps Script you can take advantage of the G Suite applications for much of the heavy lifting, while App Maker puts you in complete control of how you build out your entire application. And when it comes to code, it’s a toss up because both use Apps Script.

Consideration #3: What experience do you want for your users?
Obviously you want your application to be easy to use—it encourages adoption. For this reason, picking a tool that provides the best user experience is important. But beyond making your app easy-to-use, it’s also important to consider how your users will use your app when you design it.

For example, if your app is helping with the sales cycle and all sales communication happens over email, then you really want your application to live within Gmail as a companion app. However, if your application is geared at managing a procurement process, and there is no single or canonical G Suite app that your users use for this task, then it’s best to create a standalone experience.

The simple rule of thumb is that Apps Script was designed to build companion apps that integrate tightly with the host applications, such as Gmail, Sheets, Docs or Slides. These companion apps can be deployed as a document-bound app or as a G Suite add-on, so that users can use the best of what host applications have to offer while also staying in context of how they are working (i.e. avoid switching tabs).

App Maker naturally allows you to design your own user experience from scratch, creating a controlled environment that ensures the user focuses on what you’ve specifically designed in the UI (plus, letting you to tap into G Suite APIs still, like for Gmail, Calendar, Drive, etc.).

Key takeaway: Choose Apps Script to create companion apps that work in context with G Suite. Choose App Maker to create standalone solution apps.

Consideration #4: What data requirements do you need for you app?
App Maker offers advanced data modeling functionality by way of its integration with Cloud SQL. This helps you build relational data models, create data views, run data-driven events, implement data level security permissions and more. Another obvious benefit of its Cloud SQL backend is that App Maker can scale to large, complex data models, without requiring much effort by you.

Contrast this with Apps Script, where you either need to create your own data management functionality or rely on storing data with Sheets. The latter is fine for applications that have more simplistic data requirements, but even for most simple CRUD-type applications, App Maker is likely a better choice.

Key takeaway: For advanced data needs, choose App Maker.

Consideration #5: What kind of user interface do you want to implement?
Another key difference is the User Interface (UI). App Maker gives you a blank canvas for you to design your own UI (for mobile or desktop) from scratch. The UI builder in App Maker offers two-way data binding which eliminates the need to write plumbing code to connect your UI to data. You can refine your UI using material design themes, CSS and with customizing widget properties, which lets your app have its own unique look. You can further extend the UI with client-side scripts and HTML areas allowing you to add completely custom functionality, but with some “assembly required.”

The UI ‘canvas’ in Apps Script on the other hand, is simply the G Suite application you are working with as the backdrop. This can be optimal because users will easily recognize the environment which makes it more intuitive. It also requires less effort on your part to get started. Much of the customization around your app’s look and feel can be done sans code; for example, with Google Sheets, cells can be used for gathering user inputs and stylized with conditional formatting and data validation (without writing a line of Apps Script). If you need greater custom interaction between users and your app, you can leverage Apps Script to extend the UI with custom dialogs, menus and sidebars right with the confines of the G Suite host app.

Key takeaway: For a more custom, do-it-yourself UI, choose App Maker. For G Suite as a backdrop, go Apps Script.

Tying it all together
If you’re in the process of choosing which tool to use to build your application, let us leave you with some final advice.

• Apps Script and App Maker are built on the same underlying technology base, so skills and code are transferable.
• Sheets can be used to present and store data with Apps Script handling the logic for simple application scenarios. App Maker coupled with Cloud SQL can tackle more complex data requirements with custom UI needs.
• Apps Script is better geared for building companion apps inside of G Suite, while standalone apps starting from scratch favor App Maker.
• Bottom line: think about the user experience first, then pick the technology that allows you to build that.