 Today, you'll learn how to choose the right tech stack for your app. We'll dive into iOS development tools, technologies and frameworks. It'll help you improve your technical thinking skills. When you're building your iOS app, you have a ton of tools, technologies and frameworks to choose from. As if coding your app isn't challenging enough... How do you choose the right tech stack for your app? You don't want to get stuck with the wrong choice. The cost of changing one tool for another can be huge. Imagine you chose a database platform, and after implementing it you discover that doesn't have that one feature you need. Do you go back and change it for another platform? In 2016 I experienced such a challenge first-hand. Parse, the Backend-as-a-Service tool, had shut down. An app project of mine ran on their service, and they pulled the plug. I wasn't happy, that's for sure! Fortunately for me, and many app developers, they open sourced the platform as Parse Server. I could port over much of what I had built already to the new platform. It took some effort, but thankfully I had prepared myself… Today I'll show you my 3-step workflow for choosing the right tech stack. You'll learn how to determine which tool is right for the job. The workflow is especially important for professional iOS developers. If you're freelancing, and you make a mistake, you might not be able to bill your client for those hours! And if you're working on a published app, your employer won't be too happy about hearing you need to pull the app to change it entirely. Rebuilds are costly… Here's a quick overview of the workflow: 
1. Discover Alternatives The Discovery step leads to a set of requirements, such as: - The app's database should be accessible via the cloud
- The app should be usable without an internet connection
- 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 architecture 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?
Based on the requirements you make a list of usable platforms, tools, databases, products, programming languages, etc. and their alternatives. They don't necessarily have to fit the requirements yet, so anything is a "good" solution for now! Here's an example list: - Databases: Realm, Firebase, Parse Server, Neo4j, SQLite
- Platforms: Android, iOS, the web
- Frameworks: Angular, React, Cocoa Touch, Meteor, Mono, Ionic, PhoneGap, Flutter, Xamarin
- Design Tools: Affinity Designer, Sketch, Photoshop, Figma
- Languages: JavaScript, Swift, Java, Objective-C, Python, C#
- Libraries: URLSession, PromiseKit, SDWebImage, MessageKit, SwiftyJSON
2. Eliminate Options Once you've made a list of solutions and requirements, you'll want to Eliminate unfit options. Filter out options that won't work. 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
Sometimes a tool 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, so you can get back to them in the future. If you can't find anything that matches your requirements, see if you can make them looser. Try to avoid building everything yourself. 3. Make Decisions Once you've eliminated bad alternatives, it's time to make a decision. To make a "decision" means to "cut off", to cut off all possible options but one. The Decision step of this workflow is simple. You've looked over every alternative that matches your requirements, and you end up with the tool that is the best match. The decision-making process is always 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. And your workflow 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 app, you don't want to pick the tech stack you hacked together last weekend. What if 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. 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. This flexibility is important. When you get better at developing iOS apps, you'll also find that you make better decisions and find it easier to change subpar decisions later on. What's Next? I'm sure you have a bunch of tools to choose for your tech stack. Now you know how. Let's get to it, then! —Reinder | 
0 Komentar untuk "[Lesson 6] How to choose the right tech stack for your app"