If you just started learning how to build iOS apps, you might’ve felt overwhelmed by an endless list of things you should know. I’ve been there and I think I’m still there in a way.
Today, I’d like to share with you guys things I wish I had known before getting a foot into the door.
You don’t need to thoroughly understand every single detail about your code.
Because simply put, it’s next to impossible to understand all the moving parts in your code since they’re all tangled with one another, especially if you’re a newbie to Swift.
At the very beginning, it might be more helpful to just accept things as they are. Just follow the tutorial step to make the work done.
And then when you get more comfortable with how it works, you could get further into a low level of how this works.
Language first, framework later
People often first learn the tricks of a framework, and then move on to the language. That’s actually not the right way to go.
The simple reason here is that if you know about the underlying language, it helps you understand how the framework works. If you have no idea about the trades of a a language, there is no way you will understand why something is done a certain way in the framework.
Small Steps Can Make Big Changes
Don’t just read, implement. I’ve often seen developers read through tutorials or sometimes even whole books without anything much to show for it. However, my biggest concern is how much would you retain if you just read ?
Start with an app that you feel most comfortable. And add some function to it day by day. Even a tiny app also has its problem to solve. You wont believe what you would get after time.
Storyboard vs Code
If you’ve read enough articles about the iOS development, I bet you’ve stumbled upon an article about which way is better to create a user interface. In my opinion, you need to learn both of them.
Every company and every developer has their own taste in this matter but I do think you should go with the storyboard if you just start learning it.
It’s more intuitive and easier to see the visual change whenever you do something. And you might not even know what you can do with each UI component yet. Familiarize yourself with all the common components and auto layout enough before moving into creating all in code.
If you get that far with programmatic UI, figure out when one thing is more beneficial and how it’s better than the other. The time will come when you have to create a custom UI in code as if you’re heavily using the storyboard.
Learn about software design patterns
By the time you’re familiar with Swift, it will dawn on you that just making it work is not enough. You need to think about the maintenance aspect of an app, is it relatively easy to add a feature to the code base? is it easy to fix a bug when it’s found? is it easy to unit test?
When you’re working on a big code base and it’s not well-structured, you will find it extremely difficult to make a change or add another feature on top of that. It will get to a point where you made a change but not sure if it had any side effect on somewhere else in the code that leads to another bug.
That’s when design patterns come in the play. It’s all about how we structure code.
Try to learn different design patterns and apply them to your code base for practice. It will give you an insight into what should be considered to make the code base better.
Last but not least, expose yourself to anything related to iOS development
Mastering a technology on your own is great, but sometimes you learn a lot by just looking at the code of others. Be it your colleagues or random tutorials on the internet, try to find why someone approaches a problem in a certain way — and ask questions if necessary.
It’s also important for developers to realize that it’s impossible to know everything, but the knowledge is out there — you just need to Google it. As a beginner, if you’re stuck there is high probability that someone like you had the same problem in the past and the solution is somewhere out there in the internet (this often happens to the veterans too!)
Thank you for your time!
