Instead of an Introduction
About 10 years ago I was handing things over to my colleagues when Craig Federighi, at WWDC 20141, announced a new programming language — Swift.
We were promised that work on it would not stop, and that it would evolve based on community feedback. Nobody
guaranteed backwards compatibility, so with every Xcode update my colleagues’ Xcode would go red — that’s the color
it takes on when it can’t compile something.
Back then, iOS development was pretty wild — however rough that sounds: anyone who could afford an iPhone and a MacBook, after buying yet another self-study book on connecting storyboards with arrows, would show up for an interview.
Yes, storyboards already existed, and these folks weren’t shy about declaring that supporting iOS below version six
was no longer relevant to anyone.
Code quality at the time wasn’t really worth discussing. In an hour or hour and a half, the average developer would
dump a couple of thousand lines of code into a UITableViewController, without separating out either a UITableViewDelegate or the networking layer.
Ask what an IoC container was, and eyes would widen. Things like Typhoon2 were, for some reason, available
only to the chosen few. Everyone else was reading the not-especially-good tutorials on Ray Wenderlich’s site.
The words VIPER and MVVM only entered the vocabulary of the major players. After yet another talk on the subject,
the verdict was usually that it was all very cool, but “we don’t need an architecture that powerful for our simple
app”. Even if that app was in the top ten in its category.
Ferocious arguments would break out over whether to draw a cell in xib or describe it in code, with a couple of days
then spent aligning labels.
Many projects stayed on Objective-C for a long time, but after a couple of years “Objective-C for Swift
developers” courses started appearing.
By that point I was no longer doing iOS development.
Why this blog and this Telegram channel?
We’re at the very start of a new year — time to dream and make plans.
The idea of starting a blog and a channel came to me literally on December 31st, and my first subscribers were my colleagues.
Let’s try, looking back on past experience and on experience from other areas of development, to walk the path of someone diving into mobile development.
We’ll start from the premise that development has shifted from individual — when a company might have a single iOS
developer — to team-based. That imposes certain requirements on how you organize your workspace and build your
processes. If in the past the app was built on one person’s laptop, or a pair of people were competing to upload the finished .ipa file to the developer console by hand through the browser, reissuing the signing certificate every
time, today that process has to be automated.
For me personally, it would be interesting to bring my command of this topic back up to speed, even though one way or another I do keep tabs on what’s happening in the industry.
I’d also like to spare newcomers the mistakes that are so easy to make at the very start.
Ready?
Then don’t rush to download Xcode from the AppStore — in the next post I’ll explain why you shouldn’t, and how to handle it more sensibly.