Back to blog

How to Pick a Tech Stack for Your App

---

How do you choose the right tech stack for your app? You’ve come up with an app idea, designed the app, and now – before you start coding – you have to pick a tech stack: what platforms, databases, programming languages, etcetera, are you going to use. Ehh, HELP!?

In this tutorial, you’ll learn how to make the right technical decisions. We’re going to use a workflow to choose the right tools, platforms and libraries. We’ll start with a general approach for choosing a tech stack, and then apply it to several “X vs. Y” problems.

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

Got An App Idea. Now What?

Discover Alternatives

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 these stacks as possible. This is the Discovery step.

Start by making a list of “requirements”. Things like:

• The app’s database should be accessible via the cloud
• The app should be developed for both iOS and Android
• You’ve got $100 max. for a select few tools; a small budget
• The app must use on-device speech-to-text because of user privacy
• You’re building a prototype now, but v2 should scale to 100k users
• You want to keep the number of 3rd-party libraries to a minimum

Requirements limit your options and they make taking decisions easier. They sound like “problems”; like things you can’t get around. That’s a good thing! It’s hard to choose from unlimited options.

Some requirements are obvious, and easy to overlook. Have you thought about the following aspects?

• 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?

Next, make a list of potential tech stacks: platforms, tools, databases, libraries, frameworks, architectures, apps, products, programming languages, etc. and their alternatives. Use Google, GitHub, DuckDuckGo, communities, wikis, documentation, etc. to discover tools that can help you out. A few hours typing queries into search engines can help you discover a wealth of information.

Once you’re done with the Discovery step you should have a list of all options. Don’t worry about finding a 100% exact match, it’s about volume right now.

Here’s an example of such a potential tech stack:

• Databases: Realm, Firebase, Parse Server, Neo4j, SQLite
• Platforms: Android, iOS, Windows Phone, J2ME, the web
• Frameworks: Angular, React, Meteor, Cocoa Touch, Ionic, Xamarin, PhoneGap
• Design Tools: Affinity Designer, Sketch, Photoshop, Figma
• Languages: JavaScript, Swift, Kotlin, Java, Objective-C, Python, C#
• Libraries: Alamofire, SDWebImage, PromiseKit, Haneke

Quick Tip: Don’t forget the official SDKs, for example for iOS. You may not need a 3rd-party Augmented Reality framework if ARKit has exactly what you need. It’s easy to overlook standard options, thinking you need something novel or special.

Eliminate Options

Once you’ve made a list of tech stacks, 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 choice, because 80% of your target audience uses iOS. iOS is the better alternative here.
• Cross-platform tools aren’t an option, because your client insists on using native platforms. Native iOS/Android development is the only alternative.
• Photoshop isn’t a viable tool, because it doesn’t fit the budget. A cheaper alternative like Sketch is a better option than Photoshop here.

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

1. Throw out the solutions that are absolute dealbreakers
2. Throw out the solutions that have better close alternatives
3. Throw out (or keep) the solutions that have 2-3 minor disadvantages

Sometimes a library 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.

Keep track of your findings, in a wiki for example. You’ll want to get back to your decisions – and why you made them. Documenting your decisions makes them insightful. For yourself, but also for others who are working on your project, now and in the future.

Eliminated all alternatives, and now you’ve got no options? Loosen up your requirements or rediscover better alternatives. The perfect tech stack is impossible, but also keep in mind that the tool you’re looking for simply doesn’t 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?

It’s a subjective exercise, so you don’t only have to focus on the side with the most points. It’s up to you what you’re going to choose.

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

Make A Decision

Once you’ve discovered possible tools and eliminated unfit ones, 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 tech stack 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. Commit to discovering whether your choice was the right one.

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.

The decision-making process is continually ongoing. 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 is why documenting your findings is important to do.

Your choices also depend 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.

What if you’re halfway through development and you find out that you forgot about a must-have feature? Now what? You backtrack and find a better tool, or you choose to incorporate that must-have in the tool you’ve already chosen.

Preparation is key here, of course. Do your homework! Map out requirements, discover tools, frameworks and libraries, match and eliminate them, and pick one.

The accuracy of your decisions doesn’t necessarily come from making the right ones, but knowing you made the right decision based on all available information you had at that time.

When you get better at developing iOS apps, you’ll also find that you make better decisions and gain more experience with your preferred tech stacks.

Discovery: Mobile Platforms

OK, now that you’ve familiarized yourself with the workflow, let’s apply it to a few real-world tech stacks.

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 so arbitrary! You can choose either one, 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? Every one of them isn’t about iOS vs. Android, but instead it’s about the requirements and constraints surrounding the project.

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

Here’s how you can now think about this:

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. You can also save 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, and make a decision based on that.

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.

Elimination: Cloud Databases

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…

Whatever tool 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. These tools usually come out of your research in the Discover phase.

• Firebase
• Parse Server
• Neo4j
• Realm
• SQLite
• Core Data

You’ve also listed requirements. What does the tool you’re about to choose need to do? What do you require from it? Let’s say that…

• The database needs to be in the cloud, and not local
• It needs to support real-time queries and data push instead of pull

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 or purchase an enterprise plan.

The best (hypothetical) 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 has two different kinds of cloud database platforms (Realtime Database and Firestore). If you choose Firebase, you’ll have to apply the tech stack framework again to discover what this means for your app.

Parse Server also supports real-time data binding, and 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.

With this use case, we’ve discussed how requirements affect the tools, libraries and frameworks you can use in your app. 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…

Pro tip: Are you learning how to build iOS apps? Discovering tools you can use to build apps, and doing a deepdive into how they work, is an opportune moment to learn more about app development. So many rabbit holes to dive into…

Decision: Programming Languages

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 they 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…

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?

Let’s say you want to learn app development. In that sense, it’s logical to want to choose between iOS and React Native. Both are separate “branches” building apps. Here’s an interesting question:

“Which would I rather learn?”

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 it 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 cross-platform tools. 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 going cross-platform. You’d have too little “hooks” to latch new information onto.

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 choosing a tech stack? 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!

A mistake you can make in choosing a 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!

Further Reading

You know that sinking feeling you get when you’ve discovered that you need to rebuild your app completely, because you’ve chosen the wrong tool for the job? In this tutorial, we set out to avoid such a conundrum with a workflow to choose your tech stack.

Here’s that workflow once more:

1. Discover tools, frameworks, libraries and their alternatives
2. Apply requirements to the things you found, filtering them
3. Make a decision, based on the above, and stick with it

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.

We’ve discussed the importance of discovering good alternatives, and eliminating solutions that are unfit by using requirements. You also know now that it’s important to stick with a decision, and to revisit your choices continually as you’re building your app. Awesome!

Create Your App Now