Adapting and Succeeding in the iOS Industry

When Apple released Swift to the world, a new era of excitement began.

I've seen this trend of new technologies coming and going many times, but when a company as big as Apple releases something, you can be certain it comes with a staying power. This is particularly true of a language that Apple is actively investing in and betting on as the future of development on its platforms.

This kind excitement surrounding a new language reminds me of other things in our industry, which either have occasional peaks of popularity or else simply fall into disuse and disappear without a trace — things like OOP, POP, FP, FRP, MVC, MVVM, MVP, TDD, BDD, DDD, and VIPER.

As a developer, it's easy to get overwhelmed and feel left behind by all the catchy names, ideas, and programming paradigms popping up. In fact, you wouldn’t be blamed for wondering how you could keep up to date with such a quickly changing industry.

Plus there are questions that breed doubt: Is that new technology the silver bullet I've been looking for? Am I missing out by not doing that? What is the current standard?

And even then, there are times when a dominant technology eventually falls into disuse. For example, Objective-C has stood up to the test of time and is proven to work, but who knows what's going to happen to it in 10 years?

Apple's MVC approach on iOS is criticized nowadays. However, I remember how great it was back when the SDK was released in early 2008 and how easy it was to build iOS apps, especially when compared to the competition — Symbian, for example. (I'm not saying Symbian was a terrible platform; I was developing apps on it too. But I’d be lying if I said it was easy or enjoyable.)

The fact is, you’re probably productive using techniques you’re comfortable with, but you could also be missing out.

For example, I prefer dynamic typing. Not by much, but I do. However, if I'm writing code in Swift, I won’t fight the language. I want to take full advantage of its features to achieve my goals, so I go all-in with static typing. And I have to admit that in doing so I’ve learned a lot.

I’ve also learned that there’s more than one way to reach a goal. For example, many years ago I worked in a bank writing software in COBOL. Yet today I know of a very successful bank that bases its technologies in Clojure and Datomic.

Two completely different approaches, both very successful.

Where's the silver bullet? Well, I’ve been working in the industry long enough to know that there isn’t one, otherwise everybody would be using it.

I could be wrong, but I’d like to believe that every software developer wants to deliver the best software they can, and we still use many different technologies in an attempt to achieve just that. There’s no gauge for determining who's right and who's wrong, but I have my own rules for how to effectively keep up to date with the industry and deliver great software using various approaches.

For example, I don't believe reading a book cover to cover will directly and instantaneously make me a better developer. Rather it requires a combination of learning that knowledge and then applying it to my work. Indeed, getting ideas from good sources and putting them into practice is an effective way to achieve your goals.

And if you work for a company, you should be working to achieve its goals, but you can benefit from those results in order to achieve your own goals. In this way, you create a win-win situation that will tremendously increase your value as a professional.

Meanwhile, if you're working for a company and you can't see how to align your goals with theirs, maybe you should think about switching jobs.

I can give you another example. When I heard about Functional Reactive Programming (FRP), I was skeptical, because it wasn’t like how I was used to programming. However, after trying it for a couple of weeks, I fell in love with it. I had by no means mastered it in that short amount of time, but I started talking about incorporating it in my day-to-day work to improve the codebases I was working on. To my surprise, other developers at my workplace weren't very keen on learning this new approach, which resulted in some conflicts. But as I thought about it, I realized they were correct in a sense. While I thought FRP could improve our codebase, the codebase was already healthy and well maintained. In the end, I came to the conclusion that there wasn’t a need to bring FRP into the workplace. Instead, I decided to focus on using it in my personal projects, both as a way to possibly improve my work and to master something new.

Fast forward a couple years and I was hired to write the iOS app for a big company in London. They chose me specifically because of my experience with FRP.

This company was keen on building its app with an FRP approach, and I was excited because I had been waiting for the opportunity to put it into practice on a large scale. The end result was better than expected, but, as everything has a downside, we found it challenging to hire people to work on that project, as FRP has very low adoption rate and the learning curve is a bit high.

This proves the point I mentioned before: that there are no silver bullets. As such, you should use the resources and technologies available to support the needs of the projects you're working on, while simultaneously progressing your career and improving your engineering skills.

And if you haven’t yet invested the time in mastering functional programming with Swift, it’s something you should do in order to take advantage of all it has to offer toward improving your skills as a developer.

Let's raise the bar of the industry and grow together. Win-win.