Building iOS Apps: basic decisions

While starting a new project, every choice you make will influence your project forever, so lat me give you some advice based on my personal experience.

1. Don’t abuse Github or Cocoapods frameworks
   Taking advantage of prewritten code or frameworks can be very fast at the beginning but you’re making your project dependent from other developers and you’ll never know what they will do in the future.
   For example: are you ready to base all you network functions on AlamoFire? What if they stop maintaining the project and it’ll be not compatible with a future version of iOS? Are you ready to fork the project or to rewrite all of your network classes?
   So my first advice is: don’t use libraries just to improve starting speed if you’re not ready for the worst. If your project has a visibility of years is better to write your own code based on Apple frameworks, it’ll be slower on the beginning but can be less bloody maintaining it in the future.
2. Choose the right technology
   I’ve seen so many wrong choiches in my dev life. One of that was rewriting a whole storyboard-based app in code UI: the result was that an estimation of 4 month has become a 12 month work.
   Choose reliable technologies, both for your app and for the backend, if can choose it.
   If you’re planning a new app that will be available for year, don’t start developing with death technolgy. Doesn’t matter if you’re very strenght in xib or Objective-C, they are gone, nobody will maintain your project in the future.
   My second advice is: start developing looking ahead and starting from the state of the art. do you really want to start an Objective-C non-storyboard-based project with the certainty to convert it in a Swift Storyboard-based project (rewriting from scratch) in the next few years?
3. Don’t over-engineer it
   We’re talking about an app. Even if it’ll be the most complicated app on the App Store, it will be simple and solid for the user, so it’ll need to be simple and solid for you and for those who are maintaining it in the future. Doesn’t matter how much classes or REST calls your app should manage, it has to be simple. If you try to apply strange concepts, dozens of abstraction layers or blocks inside blocks inside blocks, you’ll bleed for just fixing a stupid bug, you’ll propagate it everywhere.
   My third advice is: man, it’s an app. It borns to be simple, keep it simple or you will pay it in the future.
4. Don’t follow trends
   This advice works in life and in coding as well. Don’t follow trends, sooner or later they will be abandoned.
   Very often applying non-native patterns become a trend that many developers follow. Reconnecting to point 1, what if you apply reactive paradigm to your app and one day all the developers maintaining swift reactive frameworks will stop doing it due to a iOS X.X incompatibly? Are you ready to rewrite an enormous part of the code (at least the app or the framework, so basically 50% of the codebase)?
   My fourth advice is: follow the leaders of technology you’re building on, don’t follow trends. It’s more safe to spend a little more of time applying Apple best practices than using a treinding technology that most likely will die sooner or later.
5. Be yourself
   You have to apply this advice in life as well. You are coding your app (even if it is under commission) and your code.
   Don’t be influenced by others, it’s your choice and it’s your son. Take care to do the best and to learn from what you’re doing.
   Put your fingerprint in the code for the best of your new project.