Things you should decide when starting new iOS app
After reading this you should know more about what decisions you have to take when starting a new iOS project.
Recently, along with my friend we started to build a new product — it will help you buy a better quality food — stay tooned, it will be awesome. One of the steps is to build an iOS app. After a 5y of experience in doing exactly that i want to share what decisions i had to make each time. Let’s go!
Pick devices. Watch for iPad support
Probably when you start your app you’ve already picked up devices to support — business wise decision. But remember about few things here:
- Remember that it’s better to start from smaller set of devices then scale it up, after having a stable code architecture for a base device.
- Remember if you have an iPhone app, if you start to support iPad it’s no turning back from there. It will be there till the end!
Pick dependency manager
There’s 2 major managers here: CocoaPods and Carthage. Probably the most popular now is still CocoaPods. They actually differ significantly so you should make up your mind on that one. CocoaPods makes almost everything for you, but it touches your project file. Carthage builds dependencies (frameworks) from original repositories and gives you the responsibility to include them in project— most commonly by adding them directly to project file. Though you can always install all dependencies manually of course. My pick is carthage, but it’s ok to use CocoaPods — no worries here.
Pick your project dependencies
This is the most important point for me. Why? Dependencies are block from which you will build your app. You will use those functions or UI Controls across whole app. Imagine that one some day, Apple release Swift 7.0 which few of your libraries don’t support (forgotten projects). You have to release new version of the app for your client. Of course it’s ASAP as hell. What now? You alter the code manually (!!!), by forking github repository, or you remove this library and … you just realize that you use it everywhere. Either way it’s hard. Picking dependencies should be hard! My key advises here:
- The less the better
- Pick only essential ones
- In most cases you can do it native
- Don’t use this dependency when you only use 1/10 of it’s possibilities (the number is random — look for a library that you’ll use whole)
You have to be aware that those dependencies could cause crashes, framework can be unmaintained on some day (and who will add next Swift version support). Remember that they provide code, you will compile it.
When picking a library think of:
- How many of the things it have you will use — maybe you can write it yourself
- Is it supported by community (did it gathered community behing it) — github contributors, stackoverflow questions
- Did most concerning answers are already answered in tutorials or stack overflow
- How much it is appreciated— e.g. github stars
- How long it’s planned to be supported
- Look at posted issues and their history on github (were they solved, how many ignored there is)
Pick you initial global architecture
Think about global architecture. Should i use MVC, MVVM, VIPER or Flux? Remember that you can always scale up to bigger and more scalable solution. So pick the most sufficient one. You can grab some knowledge on the M* ones here or about Flux here.
Pick programing principles and stick to them
You can do normal OOP patterns, or maybe more Reactive / Functional approach. Probably you’ll use Dependency Injection pattern. You can pick either/or all of those, but the key here is to be consistent. Pick right solution for proper problem.
If you want to argue about the topic or my solutions — comment or message me directly. I’ll really appreciate it! If you like this article and my approach — please follow me/like and share this story. This will motivate me a lot for further work!