In 2020, I made my first MacBook purchase, and I was incredibly excited for several reasons. It marked a significant milestone as my first major acquisition since embarking on my journey as a software developer. Beyond being a mere laptop, it symbolized the culmination of my first year in the programming world. To me, it was a personal affirmation that I had chosen the right profession and was making progress.
In the country where I reside, owning a MacBook is not commonplace; it's considered a luxury product that few can afford. At that time, I wasn't aware of anyone in my circle who owned a MacBook, which added to the intrigue. I was about to explore a completely new operating system, immerse myself in a new ecosystem (I later purchased my first iPhone that year), and potentially adopt new workflows in my coding endeavors.
Prior to this, I had already developed Android and web applications. I like to believe that I was a proficient junior developer - learning quickly and relishing every moment of the process. However, at a certain point, I reached the conclusion that to advance and take the next step in my career, specialization was necessary and at that moment, the specific tech stack wasn't entirely clear.
Why Didn't I Continue with Web or Android Development?
In my first job, there were a handful of great senior software developers with many years of experience behind them. I had the opportunity to ask some of them about the strengths and weaknesses of each of their main technologies. Now that I'm very close to becoming a senior developer myself, I can say that they were not wrong at all.
The first area I thought would be cool to specialize in was web development. All of my friends knew about it; it was super popular at the time, and almost all the projects in the company where I worked had a JavaScript component. However, even with my short experience, I noticed that the JavaScript world was inconsistent and sometimes even redundant, with a huge number of libraries or frameworks trying to solve the same problem. Many times, the differences were not enough to justify the plethora of options.
I personally don't think JavaScript is a bad thing at all, at the day of writing this I feel it is redeeming itself and turning towards a more stable and standard era, but at the moment it was not like that, when I had to take the decision of which stack to specialize the options where to many, and it was not clear which one was going to be the principal one in the future.
I owe a lot to JavaScript. I started learning software development with the intention of earning money with Vue and Express, and I really had fun with it at the moment. However, from a more professional perspective, the kind of problems and how different two projects using the same JS libraries can be were taking me away from it, but that is a topic for another post.
What About Android?
Native Android development was my second option, and my mentor in that company was probably one of the best Android developers I've ever known. However, his expertise meant he was well aware of the challenges inherent in Android development. The issues he pointed out, both in discussions with me and during our collaborative work, made me reconsider pursuing a path in Android development.
Android development many years ago was in a similar state to JavaScript development nowadays: many libraries, an unclear future, unstable behavior, and Google making changes to the OS frequently. When I was working at that company, Android was just recovering from that situation, and many of those problems were being resolved. However, this also meant that a vast amount of tutorials, documentation, and posts on Stack Overflow and blogs quickly became outdated. I remember a period where, upon trying to implement something I had just learned from a course or a solution found online, my code editor would warn me that the functionality was soon to be deprecated. Even though the courses weren't old at all, this constant state of change frustrated my junior brain.
Additionally, Kotlin was very new at that moment, and my mentor informed me that it had many bugs, and not all of the core Android libraries worked well with it. Consequently, I had to learn Java if I wanted to specialize in Android, and that was the final piece of information that led me to decide against choosing it as my main technology. Many things have happened since then, and nowadays, I find myself eager to give native Android development another chance. I've superficially checked some things, and it looks truly exciting!
I Tried Technologies Outside UI Development.
Originally, my aspiration was to become a backend developer even before securing my first job. However, landing a backend developer position proved to be quite challenging. In my country, the backend development ecosystem wasn't as refined as it is nowadays (Colombia experienced significant growth in its developers and software companies around 2022). During that period, most backend development jobs relied on PHP (exclusively vanilla PHP, powering large-scale applications), Ruby on Rails, and occasionally .NET, but with notably outdated versions.
I yearned to work with the latest and most innovative backend technologies like Express, Django, or perhaps Golang. Unfortunately, those opportunities weren't readily available at the time.
How I Fell in Love With the Apple Ecosystem
In the project I worked on at that company, we had an iOS application, and the person responsible for it had more than 10 years of experience with Apple development. Who better to teach me the pros and cons of it? The application was old, around six or seven years, and it was written in Objective-C. However, Diego was slowly migrating it to Swift. He told me that the only real problem with Objective-C was its ugliness, as it was incredibly stable and consistent during the years it was more widely used. Diego explained how Swift addressed the lack of prettiness and enhanced the overall developer experience in the Apple ecosystem. He walked me through how Swift simplified memory management and other low-level tasks that were challenging to accomplish in Objective-C.
Later, Diego recommended a book to start learning Swift, SwiftUI, and UIKit called "iOS Apprentice," published by Ray Wenderlich (nowadays known as Kodeco). However, before delving into the world of iOS development, I needed a MacBook. It was a significant investment at the time, but my current laptop, an aging Asus Vivobook, was on its last legs. The M1 chips had just been released, making the MacBook Air an enticing option. I remember watching countless videos reviewing it, delving into how the M1 chips worked, and eagerly hyping myself up while waiting for my MacBook to arrive. I wanted specific specs—16GB RAM and a 512GB SSD—so I had to order it in advance and wait until one was available.
After enduring what felt like the longest weeks of my life, it finally arrived, and it exceeded my expectations. I promptly downloaded Xcode and all the necessary tools on day one. For the next few days, I barely slept as I immersed myself in the book, tackling challenges and learning the ropes of Swift. The MacBook's performance was nothing short of phenomenal—fast, ridiculously fast. Compilation, indexing, running—everything was seamless and wonderful.
I was slightly worried about the M1 chips being so new that not all software would work on them, but that turned out not to be a problem at all; Rosetta worked phenomenally.
If you're thinking, 'Well, he had a crappy laptop before, so obviously the MacBook felt super fast,' you're not entirely right. A few months ago, I built my first gaming PC with an i3 10100 and an RX570 OC, so it was not bad and had a really good processor for the price. However, it wasn't a laptop, and at the time, the M1 chip competed with processors like the i5, making it definitely faster. Additionally, the OS and user experience of MacOS were far superior to Windows or Linux (my main OS before MacOS).
This speed, combined with the excellent UX and the quality of my MacBook Air, excited me even more as I delved into learning Swift. I never encountered any unsolvable problems while learning iOS—no non-compiling examples, outdated dependencies, or the like. Maybe it's because Kodeco rocks and creates amazing resources for learning mobile development. At this point, I was 100% sure I wanted to be the best iOS developer I could be.
Conclusion
I acknowledge that Apple is not perfect and sometimes engages in peculiar practices. However, when scrutinized with a more analytical and objective perspective, it emerges as a company offering excellent products with extensive support and useful lifespans. Throughout these years, I have not once regretted being an iOS developer. As I delve into the final and challenging aspects required to take the next step in my career, I can confidently say that it is a platform characterized by its goodness, stability, and consistency.
Thanks for reading the whole post, and if you are reading this it means you found it interesting, please consider helping me keep creating these types of content with a small donation, and consider giving me a follow 🩷.
Top comments (0)