Designing an app with a template: Should you?

Starting from scratch can be a very daunting prospect. Whether you’re making pie crust, or designing an app, beginning with no foundation can lead to a lot of second guessing down the road. Of course, any professional chef (just like any professional developer) won’t be phased by starting with basic ingredients that are paired with the intention to build something cohesive from them.

So, when designing an app, should you use a template?

By now, you’ve probably guessed the answer – it depends. First of all, we’ve got to nail down what we’re talking about when we use the word “template.” In the context of designing an app, there’s a few different types of templates.

While doing my research, I asked our director of marketing strategy what he meant by “templates.” He sent me a link to a gallery of fully-built, pre-made, slightly customizable, ready-to-implement platforms.

I asked our senior Swift developer the same question. She promptly showed me an example of a Master-Detail template in Xcode. Basically, it auto-generated the code for a view controller which held a table that came along with some limited functionality – the ability to add, delete, and edit data entries in the table rows.

I caught our CEO as he was leaving a meeting with a client that had run late (because their idea is so cool!), right before he had to leave for another meeting. I asked him the previously posed question. He quickly (I am not jealous of the busy CEO life) went over details as to why using a codebase template is a bad idea for many reasons – the main one being that if you want to make almost any change to functionality or the style, you’re pretty much out of luck.

Finally, I sat back down at my desk, swung my chair to the left, and popped the question to our senior UI/UX designer: “What’s your opinion on app design templates?”

By this point, I was purposely asking this in as vague a manner as possible – I wanted to see if I’d yet again have a different example given to me.

“Oh, you mean like standard UI elements?” For those of us who don’t design for a living, she was speaking about the generic icons (like arrows, menu icons, and other generic buttons and fields) that Apple has available for download for free. These templates can be used with different design programs, like Sketch and Adobe XD.

So, out of those four types of templates, should you use any of them?

And the answer, yet again, is it depends.

Do you have a designer?

If you do, the only templates they’d use would be the Apple Design Resources our own designer brought up a little bit earlier in this blog. These are very practical resources, and help to keep Apple apps looking “Appley,” like iOS users are accustomed to. Rather than entire screens, or rigid, unchanging guides, Apple Design Resources are small, customizable, separate UI elements.

Most iOS apps have a top bar that takes up the same amount of real estate on the screen, no matter what app it is. This is largely due to the library of available templates on Apple Design Resources. These templates ensure consistency throughout an iOS user’s experience, and help save time during an app’s visual designing phase; and unlike the other types of templates listed above, don’t hinder your app’s ability to stand out by presenting a unique layout, experience, and brand.

Other than those generic UI elements, a professional development team will most likely never touch a template. It would be the equivalent of a professional chef buying their pie crust from the grocery store rather than folding it over and over again on their own.

Why? It just doesn’t taste the same.

When I asked our senior Swift developer if she had ever used a template and then built off of it, she emphatically told me “No.” This is because when you’re a professional at something, you know the intricacies of every step you take when building a product – whether that product is a pie or an app.

And when you have your own way of doing things, generic building blocks can get in the way pretty quickly – you spend more time going back and tweaking boilerplate code in order to make the product you envisioned than if you had started from scratch.

As for those fully-fledged codebase templates our CEO was talking about – they’re never used at dev shops, for all of the previously listed reasons, and many more.

Are you the designer?

If you are, and you don’t have any experience designing anything that exists in an interactive medium, and you don’t have the budget to bring your idea to a dev shop, you’ve found yourself in the one situation where using a visual app design template (the kind our director of strategy brought up) is probably the right decision.

Unless you get lucky, or you discover nascent design talent that has resided within you this whole time, the template will most likely look better than what you make. And no offense meant; these templates are designed by professional designers themselves, so they do follow standard conventions, and tend to look good when they’re doing what they’re meant to do.

While they exist in a space near WYSIWYG app builders like Appy Pie (I promise, I don’t hate you Appy Pie), app templates lie directly adjacent from app building tools. Rather than selecting from a list of functionalities, putting them together, and then trying to make them both work properly and look good at the same time – with app design templates, you select the template based on two parameters: its visual style, and the functionalities it offers.

Store-bought vs. Homemade, Cookie cutter vs. Custom

When comparing an app built using a template, versus an app built natively, there are four categories of comparison:

1. Cost
2. Time
3. Robustness
4. Brand

Cost

When it comes to upfront costs, the template-made app will win every time. There are some templates available for as little as $14. You can spend more than that on a sandwich. There are apps that users pay more than $14 to download from the App Store.

But that’s upfront cost. Over time, that can (and most likely will) change.

Time

Again, if you’re comparing just the initial time that goes into designing an app, the template app will beat out the natively built one. Development, however, has no end – only a beginning. If your app is available for download, whether it’s today, tomorrow, or next year, your app will eventually need to be updated.

Updates (at least the significant ones) are either visual, provide extra functionality, or increase security. None of these are possible with a template-built app – other than very, very minute tweaks.

Robustness

This is where the innate differences between a natively built app compared to a template-made app really being to show. Native apps, for many reasons, are the most responsive, the quickest, and the all-around best feeling apps on the App Store.

Not only are native apps built to provide the most streamlined user experience, they also provide the most functionality – this is because every implementation is tailor-made to that specific app

Brand

Finally, it’s down to branding – which, just like robustness, native wins easily. Branding is more than just your app’s logo – it’s the color scheme, the amount of space the gutters between UI elements take up, the feel it produces when a user pushes their thumb up on their phone’s screen. Brands must be personal – and the only way to make your brand truly personal is to build it from scratch – not slap a layer of paint over someone else’s product.