We say a
lot about...
everything

Everybody likes being good at something. And, in order to become good, you need to spend some time being, well, not so good. But what happens when you spend the necessary time, and then decide that maybe it’s time for a change? That’s exactly what happened to us, so we decided to make the switch. We took a turn from full-stack to iOS development.

What did we do before?

Roko:
When I first started working in Ars Futura (2 years ago) I was working on an MVP as a full-stack developer. After that, I started working on a company product called Along, the only HR tool your company will ever need, really. (And yes, this is a shameless plug.) It was a great project to be a part of – the product is great, the team is great, and I was learning a lot whilst working on it. As a web developer, I was mainly using React and NextJS, technologies that were, as I would come to realize, very different from what I signed myself up for when I decided to do a career change.

Natko:
For my first project, I was developing a full-stack application using Ruby on Rails and React. Although I only worked on it briefly, I soon had the chance to switch to a brand new project and an even “fuller” stack of technologies. This time, I used SailsJS for the backend and React for the front-end, but the project’s main focus was on its mobile app, which was built with React Native. Despite having no prior experience with React Native, I was eager to take on the mobile development challenge and dove right in.

The switch 👻

Reasons

Roko:
There isn’t one concrete reason why I decided to make the switch. It’s not like I was having a bad time in web development, or that I didn’t like the projects I was working on (I enjoyed both). I just wanted a change.

I vaguely remember something being said about switching teams, so I decided to give it a shot. First, I talked to my HR colleague about it, and then to our executives, who gave their permission and blessing.

Natko:
As I mentioned, I found myself drawn to mobile app development more than web development. However, as I gained experience with React Native, I began to realize that it may not be the best technology for building more complex mobile apps compared to native languages.

While React Native certainly has its benefits - such as the ability to create cross-platform apps using a single language - it may not be the optimal choice for apps that require a high level of performance or specialized features. Plus, between the two mobile platforms, I was leaning towards iOS anyways, so I decided to try and make the switch.

Expectations

Roko:
To be honest, I wasn’t really sure what to expect. I knew (and everybody else also knew) that I didn’t know the first thing about mobile development in my current role. So I started looking at some tutorials and courses online to gain a better understanding of iOS. After talking to the iOS team about the switch and laying out the onboarding plan, I was sure it was the right thing to do. Thereafter, my decision was cemented.

Natko:
I knew this was going to be something quite different, as I went from working on a large team with familiar technologies to a much smaller team with entirely new teammates, programming languages, and tools. While I was excited about the opportunity to grow and learn new IT skills in this new environment, I also felt a sense of pressure to adapt quickly and contribute. Also, since I had some experience with mobile development, I felt like there was a bit more pressure on my shoulders to learn faster. It sounds negative, but don’t worry, it will get merrier as we progress further down this blog. 😂

Onboarding

How it went

Roko:
Once the onboarding process started, I was reevaluating my decision. Remember those tutorials and courses I mentioned? Well, as it turns out, the cool new declarative and reactive UI framework from Apple called SwiftUI, which I studied in my free time and reminded me a lot of React and Next, well, that was not what I was about to use for my onboarding project. Instead, I was to learn and use UIKit, a 14-year-old imperative UI framework. The reasoning was that a lot of apps still use UIKit and that SwiftUI is still not production-ready. How is it not production-ready if Apple says it is? Still though, I knew I would have expert guidance on this ✨ onboarding journey ✨ so it wasn’t that big of an issue really.

As our onboarding project, we were to do a TODO app ( 🥁ba-dum-tss🥁). By doing this, we learned the basics of iOS development for the career transition.

Whilst tutorials and courses are a great way to learn, having a real person as a mentor is so much better. Building the TODO app was great, challenging, and, at times, frustrating. We really learned a lot about app architecture (MVVM was used here), building out UIs using autolayout, dependency management, networking, and testing iOS apps. The app was simple enough not to be overwhelming but also complicated enough to portray the full experience of development.

All in all, I found the switch very nice, and I got exactly what I hoped for – a challenge. Even though learning Swift and UIKit looked daunting at first, it was actually a pretty nice experience full of a-ha, so that’s how this thing actually works. The framework provides you with an easy way to do almost anything you can think of, and chances are, if you see something in every app you use, it’s very easy to accomplish it in UIKit. Xcode, on the other hand, was a bit underwhelming. When it works, it works really well, but when it doesn’t, it really doesn’t. This came as a surprise, as I thought surely it would work great since Apple is such a big company. Sike! 🤦

Natko:
While the pressure could’ve been daunting, I was eager to take on the challenge and demonstrate my skills and abilities. As I continued to learn, I found that the new environment’s challenges actually had a positive influence on me. I was able to learn new skills quickly and effectively, in large part thanks to my supportive new teammates.

Just like Roko mentioned, we developed a TODO app as part of our onboarding process, so it almost felt like working on a real, small project with my new teammates. It was a nice introduction to all the technologies I’ll be using in the future and a good application of theoretical knowledge I got from tutorials and books.

Rather than moving directly to a client project following the onboarding process, the team and I decided to take the partially completed TODO app and turn it into a polished, App Store-ready application. The idea had multiple benefits – from researching new frameworks, like SwiftUI, which, at that time, was not used on a client product yet, to playing around with the designs and animations and exploring the capabilities of new tools that were at our disposal. The app is called Sparkle, and I wrote a bit about creating widgets for it in my previous blog.

Resources used:

Roko & Natko:
As always with software development, there are online resources you can use for learning, and iOS is no different. We both found YouTube great for video courses, especially for beginners, when you’re just starting out and pretty much don’t know anything. There’s also Kodeco (previously Raywenderlich) which offers great deep dives into specific topics, with tutorials, guides, books, and videos. We also found articles on Swift by Sundell and Hacking with Swift to be extremely well-made and very helpful. As always, Stack Overflow is a big one. We still find ourselves using all 4 of these, almost on a daily basis.

How’s it going now, a year later?

Roko:
I’m happy to report things are going great! One of the things I didn’t expect was app versioning and updating. When working in web development, you can basically ship updates as soon as you want, and the user always gets the newest version of the build. There’s also the process of App Store review, where Apple has the option of shutting down your release because you’re not complying with their rules or guidelines. This process always takes time, and can completely mess up your release schedule if you’re non-compliant.

Natko:
After completing the Sparkle project, I felt as though I had landed on my feet 🐱. Almost immediately after, I started working on a client project, so the learning pace accelerated. The app was much larger in scope, there were new developers to cooperate and communicate with, and within only a couple of months, it felt just like before the switch. We have weekly meetings where we share knowledge and insights, using presentations and code reviews, which come in really handy. Additionally, we’re currently in the process of developing a handbook that will serve as a reference for our team, providing guidelines and best practices for our work.

Projects we’re working on

Roko:
After the TODO app was completed, I started working on the Overwatch League (OWL) app for new feature development and maintenance. This was a pretty big codebase (the biggest I’ve worked on so far), and the app was already a few years old (hello UIKit!).

Working on OWL was challenging at first, but once I got into the groove, things were good. It was quiet at first with mainly bug fixes and minor features, and then we shipped a really big feature called Event Perks, which is an in-person feature for fans attending live matches. Fans that are watching the game live from the arena can scan QR codes and claim in-game items, wallpapers, and activation codes. This was the first big feature with a strict deadline I ever worked on and shipped, so it was a bit scary, but rewarding in the end.

Since January 2023, I've been working on a bookmarking tool Pincone, another great company product that makes saving bookmarks easy, both for private users and teams. I’m building the iOS app using SwiftUI, but more on that in the next chapter sometime soon.

Natko:
During the brief period between my work on Sparkle and the client project, I had the opportunity to work on an exciting research and development project utilizing SceneKit, Apple’s framework for creating immersive 3D environments, games, and physics simulations, among other capabilities. It was focused on creating a proof-of-concept app for a potential client and learning more about this technology.

At the moment, I’m working on an app called Enigma. It’s designed to help users report sightings of Unidentified Anomalous Phenomena (UAP), and it relies heavily on navigation and map technologies. This is a new area for me, but I’m really enjoying the challenge of working with these tools. Specifically, we’re using MapBox, which is a powerful mapping platform that offers a lot of flexibility and customization options.

Technologies we’re using

Roko & Natko:
As we’ve already mentioned, we’re currently using both UIKit and SwiftUI for development on different projects. But besides those, some other tools & technologies we’re using (other than the usual ones like Git and Jira) are:

• Xcode - Apple developed IDE for development on Apple platforms

• Xcode cloud - a continuous integration and delivery service built into Xcode and designed expressly for Apple developers

• Braze - a customer engagement platform (mainly for push notifications)

• Visual Studio Code - comes in handy when resolving merge conflicts, especially with the Syntax Xcode Project Data plugin.

Best resources we found:

Roko & Natko:
Most of our resources remained the same as in the beginning. YouTube has been completely phased out, as the videos are usually too generic, and as we become more proficient in Swift and various UI frameworks, they don't fit our needs anymore. One of the big ones we’ve started using more and more is the official Apple Developer documentation. One of the newer ones everybody’s talking about and we’ve been trying out is, you guessed it, ChatGPT. We’ve found it to be really good for writing boilerplate code, but you still need to guide it and know Swift to make the most out of it.

Another big learning opportunity we got to experience was the DO iOS conference in Amsterdam. The conference lasted 2 days, and in that time we learned a lot, from the history of Swift, iOS development, and even some WatchOS development. We also learned of many new blogs and resources we frequent from then on.

Conclusion

Roko:
I’m really happy with how the switch went. I got the desired change and challenge I was longing for. Should you switch careers? I’m not sure, that’s an answer only you know. All I can say is: if you want a change, your workplace allows it, and you’re not afraid of becoming a beginner again - go for it! As a final note, I’d like to thank everyone involved from Ars Futura for making it possible for the career switch to happen, and for supporting me the entire way.

Natko:
The switch from web development to iOS development has added some excitement and variety to my career. With each passing day, I feel more confident and fluent in Swift, just as I was in web technologies before. What I find most satisfying is the ability to have an understanding of the entire app stack, from remote databases to the UI on users’ screens. If you’re considering a switch to iOS development, or vice-versa, I encourage you to take that bold step and embrace the new challenges and experiences that await you. Who knows, it might just be the best decision you’ve ever made!