How to Choose the Right Tech Stack for Your App

Written by: Reinder de Vries, August 2 2017, in App Development

How to Choose the Right Tech Stack for Your App

It’s challenging, right? Picture yourself doing this: you’ve come up with an app idea, designed the app, and now you have to make technical decisions: iOS vs. Android, React Native vs. Swift, Firebase vs. Realm. HELP!?

How are you going to make the right decisions?

In this article, you’ll learn a framework for putting technical decisions in the right perspective. Just so you know: it’s tailored for beginner iOS developers.

We’ll start with a general approach for making technical decisions, and then apply it to several “X vs. Y” problems.

Once you’ve completed this article, you can choose a tech stack with confidence and without worrying if you’ve made the wrong decision…

Ready? Let’s go.

  1. The Framework for Choosing Your Tech Stack
  2. Discovery: Android vs. iOS
  3. Elimination: Firebase vs. Parse Server
  4. Decision: Swift vs. React Native
  5. Further Reading

The Framework for Choosing Your Tech Stack

It’s impossible to make accurate decisions with incomplete information, right?

Before you can choose which platforms, tools, databases and SDKs you should use in your app, you’ll want to get as much information about the decision as possible. This is the Discovery step.

How to Choose the Right Tech Stack for your App - Diagram

Discovery

The Discovery step leads to a set of “requirements”. Requirements are things like:

  • The database should be accessible via the cloud
  • The app should be usable by 80% of your target audience
  • You can’t use paid tools because there isn’t sufficient budget

Don’t be scared of requirements. They sound like “problems”, like things you can’t get around. That’s a good thing! It’s very hard to choose from unlimited options. Requirements limit those options and they make taking decisions easier.

Some requirements are too obvious to get noticed, so it’s important to take your time finding out what they are. Have you thought about these things?

  • What platforms do you want to use? What’s your personal preference?
  • What’s your expertise? Which tools do you know best?
  • What solutions costs a lot of effort to implement? What do you have time for?

You make a list of usable platforms, tools, databases, products, programming languages, etc. and their alternatives.

Once you’re done with the Discovery step you should have a list of all options. They don’t necessarily have to fit the requirements yet, so anything is a “good” solution for now!

Here’s an example of such a list:

Elimination

Once you’ve made a list of solutions and requirements, you’ll want to Eliminate unfit options. Filtering is the second step in the decision-making process.

It’s surprisingly simple: compare your requirements with the tools, platforms, and products you’ve found. Eliminate every option that doesn’t match, until you’ve found the best alternative.

Like this:

  • Developing for Android isn’t a viable solution, because 80% of your target audience uses iOS. So, iOS is the better alternative.
  • Cross-platform tools aren’t a viable solution, because your client insists on using native platforms. So, native iOS/Android development is the only alternative.
  • Photoshop isn’t a viable solution, because it’s too expensive and doesn’t fit the budget. So, a cheaper alternative like Sketch is a better option than Photoshop.

It’s easy to get lost in the nitty-gritty of requirements, so focus on eliminating solutions from “large to small”. Like this:

  • First, throw out the solutions that are absolute dealbreakers
  • Second, throw out the solutions that have more viable close alternatives
  • Third, throw out the solutions that have 2-3 minor disadvantages

It’s obvious to eliminate dealbreakers. If you throw out close alternatives, you don’t have to spend so much time investigating two options that are similar anyway.

Sometimes a solution looks OK at first glance, but turns out to have multiple minor disadvantages that add up to a major drawback. It’s smart to eliminate those early on, to avoid making a decision that can get costly in the future because of those minor disadvantages.

Make sure to document your findings! The decision-making process is iterative, so you’ll want to get back to your decision in the future. When you discover new information, you want to add it to your investigation without having to repeat the entire process.

If you end up with no solutions, because you’ve eliminated them all, loosen up your requirements or rediscover better alternatives. Always keep in mind that a good solution may not exist.

It always helps me to make a pros-and-cons list. Here’s how you do that:

  • You divide a piece of paper in two sides. At the top of one side you write “Pro”, and on the other side you write “Con”.
  • You then start with a question, like “Should we use React Native for this app?”
  • Then you write arguments in favor, and arguments against. You can write down anything you want. You don’t necessarily have to choose categories or topics.
  • Finally, you “weigh” every one of the arguments and add them up. Do you have more points in favor, or more points against?

Don’t forget that this is a very subjective exercise, so you don’t have to be science-y about it and only focus on which side has the most points. You, the developer, have to live with your decision – so it should be yours.

How to Choose the Right Tech Stack for your App - List

Decision

Once you’ve discovered options and eliminated bad solutions, it’s time to make a decision. Making a decision is as much about the options you don’t choose, as it is about the option you do choose.

To make a “decision” means to “cut off”, to cut off all possible options but one. It’s important that, once you’ve made your decision, you stick with it for a while.

The Decision step of the this framework is surprisingly simple. You’ve done your homework, and if you’ve done it well, the right alternative should literally appear on paper before you.

Ultimately, the decision-making process is ongoing. When it comes to tech, you may want to build a prototype with a particular tool to figure out if it’s a good fit for the final product.

This also depends on the stage your company or product is in. If you’re building a Minimum Viable Product (MVP), you don’t have to choose a tech stack that scales to millions of users. If you’re building a production-ready tool, you don’t want to pick the tech stack you hacked together last weekend.

Maybe you’re halfway through development, and you realize that you forgot about a requirement. You then backtrack, correct your decision, or you choose to incorporate the requirement in the tool you’ve already chosen.

That’s why the decision process is ongoing. The crucial aspect of making a decision is preparing it. Do your homework! Map out requirements, discover solutions, match and eliminate them, and then decide.

Your confidence in a decision doesn’t necessarily come from knowing you made the right one, but knowing you made the right one based on all the information you had at that time.

When you get better at developing iOS apps, you’ll also find that you make better decisions and find it easier to change worse decisions later on.

Get 5 of my best practices

Get 5 of my best practices

Learn how to build better iOS apps

I’ll show you exactly how I built a dozen professional iOS apps,
write extensible Swift code, and turn coffee into code.
Wait, what? Yup – into Swift code.

Discovery: Android vs. iOS

OK, now that you’ve familiarized yourself with the decision framework, let’s apply it to a few real-world problems.

The first one: Android vs. iOS. It’s a topic for much debate, and both sides always appear to be extremely in favor for just one of the platforms. I’ve yet to come across someone who likes Android as much as they like iOS…

As with most decisions, “Android vs. iOS” isn’t a real decision. It’s hardly a question! You can choose either, right? So, as part of the Discovery step, you’ll want to define exactly what it means to choose Android or iOS.

Here’s some ideas:

  1. “I can’t afford a Mac, so I choose to develop apps for Android because I can do that on my PC.”
  2. “Our budget currently doesn’t allow to build apps for both iOS and Android, so we’ll have to choose one.”
  3. “Most of the people close to me have an Android smartphone, but I have a gut feeling that the target audience for my app mostly uses iOS.”

See how nuanced these statements are? All of these come directly from emails, questions and discussions I’ve had with clients, customers and app developers.

What forms the basis for your decisions? It’s not “Android vs. iOS”, but instead it’s:

  1. Money and/or existing tech
  2. Budgeting constraints
  3. Peer pressure and/or research

Ultimately, the people that asked these 3 questions can’t make a decision on their own. Here’s what they have to do:

  1. Mac vs. PC → What do you really want? If you want to develop for iOS, find a way to get access to a Mac. If you want to develop for Android, stick with it.
  2. Only has budget for one platform → What platforms are the app’s users on? Make a decision based on that. Or… save time and costs with a cross-platform tool.
  3. Android vs. iOS environment → Be careful with biases from your environment! Research what platforms your target audience uses.

You see that choosing the right tech stack starts with Discovery. You want to make a decision based on as much information as you can possibly get your hands on. This starts with asking the right questions.

Build better iOS apps by mastering best practices and app architecture » Find out how

Elimination: Firebase vs. Parse Server

OK, here’s another problem. Which is better: Firebase or Parse Server? Like most questions about Life, the Universe and Everything, the best answer is:

It depends…

You’ve discovered by now that whatever is “best” depends on what you want to do with it!

Firebase and Parse Server are both cloud-based app back-ends, so let’s first list a few other back-ends and databases you can use.

  • Firebase
  • Parse Server
  • Neo4j
  • Realm
  • SQLite

Then, you need to know your requirements. Let’s say that…

  • The database needs to be in the cloud
  • It needs to support real-time push and data binding

You can now eliminate many of the options, for instance:

  • Sqlite is an offline local database, so it doesn’t run in the cloud. It’s pretty fast on the local smartphone, but you’d have to code the “cloud” part yourself.
  • Neo4j supports real-time data processing and retrieval, but it doesn’t support push and data binding out-of-the-box. You’d have to integrate that separately.
  • Realm has a cloud-based product, and it’s real-time, but it appears not to support push, and you most likely have to run and maintain your own Realm server.

The best alternatives, at this point, are Firebase and Parse Server.

Firebase has supported real-time push and data binding from the start. It’s “serverless”, so you don’t have to run and maintain your own servers. Firebase Database uses a NoSQL JSON-like structure, with its own advantages and disadvantages. When you choose Firebase, you’ll have to apply the decision-making framework again to discover what this means for your app.

Parse Server also supports real-time data binding, but it’s a relational database. You also have to run your own Parse Server instances on platforms like Heroku or DigitalOcean. Just like before, you’ll have to dig deeper to better understand these requirements. Parse Server could be a better platform for your app, because you rather work with relational data than NoSQL data.

The crucial aspect of the decision-making process is choosing the best tool for the job. In the Elimination step of the framework, you want to figure out what it means to choose a particular tool, platform or product.

It really depends…

How to Choose the Right Tech Stack for Your App Click To Tweet

Decision: Swift vs. React Native

React Native is a popular cross-platform tool to build apps, and lately I’ve gotten a lot of questions similar to this one:

“Which is better, React Native or Swift?”

It’s an odd question, because React Native and Swift don’t belong to the same category! Swift is a programming language and React Native is a cross-platform tool and SDK. It’s logical to ask:

  • Which is better, Swift or JavaScript?
  • Which is better, React Native or the Cocoa Touch SDK?

Just like before, it depends…

Once you’ve gone through the Discovery step, you’ve hopefully figured out that Swift is a programming language and React Native a cross-platform tool.

You can then ask yourself if you’d rather code JavaScript or Swift? Do you want to use the native SDKs or a cross-platform tool?

Nevertheless, I understand that React Native and Swift occupy the same decision-making space in the minds of beginner app developers. This is a better question:

“Which would I rather learn, React Native or Swift?”

It comes down to what you want.

One of the advantages of React Native is that you can learn JavaScript once, and use it to publish on both iOS and Android.

A downside many beginner developers forget about, is that React Native doesn’t publish to both iOS and Android with 100% the same codebase. Like most cross-platform tools, you’ll have to do a bit of custom work to make your app work smoothly on both iOS and Android.

It helps to understand web development, or native platforms, before you start with React Native. If you’re a beginner app developer with no experience on any platform, be it native iOS/Android or web development, I strongly recommend against choosing React Native.

You’ll have to learn about two native platforms at the same time, with similar characteristics, while learning a new programming language, JavaScript. Therefore, a popular answer to the “React Native vs. Swift?” question is simply “Both!”

How does this tie into the decision framework? Ultimately, your decision comes down to your own conviction that one alternative is the best alternative. Once you’ve made your decision, stick with it – that’s what this step of the framework is all about!

Perhaps the biggest mistake you can make in choosing a particular tech stack is choosing it because someone said it was the best alternative. There’s a name for this: Hype-Driven Development.

Blindly following what others say is a disservice to yourself. You learn so much more from investigating alternatives yourself!

Get 5 of my best practices

Get 5 of my best practices

Learn how to build better iOS apps

I’ll show you exactly how I built a dozen professional iOS apps,
write extensible Swift code, and turn coffee into code.
Wait, what? Yup – into Swift code.

Further Reading

So… what have you learned?

There’s nothing worse than choosing one solution, getting frustrated because you feel that you’ve made the wrong decision, and giving up on it as a result.

You now understand the importance of discovering good alternatives, and eliminating solutions that are unfit by using requirements.

You also now know that it’s important to stick with a decision, and to revisit the decision framework ongoing as you’re building your app. Awesome!

Want to learn more? Check out these resources:

Enjoyed this article? Please share it!

How to Choose the Right Tech Stack for Your App Click To Tweet

Reinder de Vries

Reinder de Vries is a professional iOS developer. He teaches app developers how to build their own apps at LearnAppMaking.com. Since 2009 he has developed a few dozen apps for iOS, worked for global brands and lead development at several startups. When he’s not coding, he enjoys strong espresso and traveling.

Comments & Questions

Got a comment or question? Let me know! I read and respond to every one. Thanks!