Recently at Untold, we had a project that needed an additional developer on the team and after developing web applications for a couple years now, I was very confident I could easily tackle an iOS application. However, I was shocked at the profound differences between web and iOS. It humbled me as a developer, and it shed some light on the vastness of knowledge that I have yet to discover.
In this post, Iʼll try to expose the things I wish I would have known at the start of jumping into iOS native apps as a web developer.
Is the DOM your friend? Coming from a mostly JavaScript, Angular, Node background, I was used to dealing with the DOM and I was expecting that building a Swift app would be somewhat similar.
....It’s not.
When jumping into building native apps, any automation is out the window and in the moment, you realize you have to do a lot more lower level coding. You position everything based on its X and Y axis. You tell it how wide and high you want the element to be, and if you want the element to calculate its height and width, you have to specifically code that. Nothing is free. (In web development the DOM provides various APIs that help you avoid these lower level concerns.)
While I was happy to not have to deal with nodes, child nodes, and the whole DOM manipulation dysfunction, I quickly realized all the things the DOM does for us. From positioning, to the box model, to assigning the hierarchy, the DOM does a lot.
The manual setup required with an iOS build can be a relief or a dreaded complexity you hadnʼt realized was going to be part of the job. At first, this process was quite daunting, but once I realized the iPhoneʼs width and height are pretty much fixed, as opposed to the various web-accessible device sizes, the manual setup for iOS is not as crazy as I initially believed.
Having come out the other side, I now think manual setup (aka not dealing with the DOM) is a much better process.
Leaving the Wild West
In JavaScript you can lump data in generic objects. The organization of data is pretty much figured out by the browser’s JavaScript runtime. In Swift, the container for data actually cares about what type of data it contains. This makes Swift a strongly typed language, not something traditionally worried about when building web frontends.
Also not present in Web Development, is true Object Oriented Programming. Given that JavaScript is not technically Object Oriented but Prototypal Inheritance, developers can go around it if the pattern does not accomplish what is needed while OOP forces the developer to follow its rules.
Itʼs a pretty humbling moment when you realize you have to pay a lot more attention to your models and architecture and no longer can play cowboy in the wild west of JS.
If you are interested in the set-backs and the hurdles involved in making the leap from PI to OOP, this article does a great job explaining misconceptions and shortcomings.
Itʼs more than just Swift I thought I just needed to learn Swift ...and I was wrong. Although learning Swift is crucial, it is only part of the equation.
Learning Appleʼs SDK is as important as the language itself. Appleʼs SDK is massive and comprehensive.
There is a lot of domain knowledge and best practices that only time in the seat can give you.
It is not as easy as asking a bunch of stackoverflow questions, although you will do a lot of that, you also need to have a base level of understanding to even comprehend the replies.
From simple UI positioning, to in-app purchases, to Appleʼs app acceptance process, there is a whole world in here that involves a bit more than just a new language.
I have a lot of respect for the amount of knowledge an average iOS developer has with regards to the domain knowledge needed to build native iOS apps.
I hope this short blog post has shed some light on what are some realistic challenges you will encounter when you decide to branch out of web and start building native applications.