Thinking of building your applications on G Suite? If yes, then you will be dealing with many flexible options. Many developers mostly ask questions about which tool they should use, specifically as “should i build my application using Apps Script or App Maker?”
They share a common deployment platform, perhaps more similar than being different. Both let’s you build custom business applications quickly. Both holds the same infrastructure. Both let’s you apply your skills in G Suite.
Now let me take you towards their uniqueness. App Script’s strength lies in the fact that it helps you integrate your app with G Suite apps like Gmail, Google Drive, Docs and etc. 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 design your own data model.
Here are few important factors to consider while picking apps Script or App Maker for your next application.
Factor #1: What makes you more comfortable building in? And in which coding language you would prefer for?
One of the most important factor is the matter of comfort and personal perspective. If you think you are more productive building an application within a spreadsheet, especially if one already exists, then start building on google Sheets with Apps script. As a developer there is slightly more of a learning curve with Apps Maker and a little more work to do at first to get your app up and running, if working with relational data models or laying out your UI 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.
These two share many similarities that includes the same underlying programming language and runtime, which happens to be Google Apps Script. This is really great because your skills and even some code is transferable, selecting among either option is based on programming skill or language essentially a moot point.
There are other differences to consider that go beyond the scope. Like distribution,versioning and the developer experience that goes beyond this post.
Key Takeaway: Toss up and both use Apps Script for coding.
Choose based on your comfort level. With Apps Script you can take advantage of the G Suite apps for much of heavy lifting, while App Maker puts you in complete control of how you build out your entire application. And when it comes to code, raise a toss as both use App Script.
Factor #2: Experience you want for your users?
Its quite obvious that you want your application to be easy to use- as it encourages adoption. Picking a tool that provides the best user experience is important. Beyond making your app easy-to-use, it’s also important to consider how your users will use your app when you design it.
If your application is helping with sales cycle and all sales communication happens over Gmail, 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.
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.
App Maker 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.
Key takeaway: Choose Apps Script to create companion apps that work in context with G Suite. Choose App Maker to create standalone solution apps.
Factor #3: Does your app needs to run outside of your organisation?
While 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 organisation, then App Maker built 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.
Factor #4: What data requirements do you need for your application?
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 much more. Adding one more benefit of its Cloud SQL backend is that App Maker can scale to large, complex data models, without requiring much efforts by you.
In contrast to this is the 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 apps 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.
Factor #5: Implementing User Interface
Another important aspect 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 probably refine your UI using material design themes, CSS and with customising 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 scrim. This can be optimal because users will easily recognise the environment which makes it more intuitive. It also requires less effort on your part to get started.
For example, with Google Sheets, cells can be used for gathering user inputs and stylised with conditional formatting and data validation. 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 G Suite host app.
Key Takeaway: For a more custom, do-it-yourself UI, choose App Maker. For G Suite as a scrim, go Apps Script.
Try it all together If you’re in the process of choosing which tool to use to build your application, let me leave that to 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 presnt 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.
- Think about the User experience first, then pick the technology that allows you to build that.