The Evolution of a Developer: Embracing Swift Packages

You've heard it before: "There's an app for that." While helpful to many, for developers who thrive on custom solutions, this phrase can be a double-edged sword.

The Wordpress Era: The Allure and Pitfall of Plugins

In my Wordpress days, adding a new feature often led to a common dilemma: Should I craft my own solution or simply install a plugin?

Plugins are tempting, but an over-reliance can wreak havoc—increased overhead, clashing versions, and sluggish performance. My ego often prevailed; I'd spend endless hours reinventing the wheel, dismissing plugins as shortcuts for the lazy.

NodeJS: A Lesson in Humility

When I transitioned to NodeJS, this "do-it-yourself" mindset became a liability. Case in point: I wrestled with fetch and corporate proxies for authentication, only to later discover the efficiency of simply using axios. It was a humbling revelation.

Discovering Swift Package Manager (SPM)

My entry into Swift development still carried remnants of this stubbornness. "Why not build my own crash analytics?" I naively pondered. The result? A buggy mess that could've been avoided by adopting mature packages.

Yet, as I observed other developers modularise their apps into private packages, my perspective began to shift. Apps like Ice Cubes showed me the power of well-implemented package systems for scalable app development.

Particularly for things that are consistent across all your apps, like a CoreDataManager or HapticsManager. They have the same implementation app-to-app (since they are written with generics), and dropping in a single package would make setups very quick.

It also means if you push one fix to the package, all your apps benefit from it.

Crafting My Own Packages

I once believed modularising an app was unnecessary if I was the sole developer. This notion crumbled after exploring frameworks like Publish and Retype.

I took the plunge and developed several plugins for Publish:

These low-risk plugins provided a sandbox for experimentation, and eventually became vital elements of my UI, enabling features like:

Lessons Learned

Creating plugins is more than just fulfilling your immediate needs; it’s about making something robust and adaptable. These experiences also compelled me to revisit and refactor some of my older Javascript plugins.

A Dive into Authentic Swift Packages

My real eureka moment came while watching a stream about creating an Astrology Horoscope App. Although I don't subscribe to astrology, it struck me that the zodiac logic (or the lack thereof) could make an excellent package. Thus, ZodiacKit was born.

Building it forced me to think not just as an app developer but as a tool builder. The mindset shift was profound and offered insights into the intricacies of API design and system architecture.

In Conclusion

My journey has taught me that packages are not the shortcuts or compromises I once considered them to be. While due diligence is essential, many packages are superbly designed and deserve a place in our toolbox.

As for me, I'm embracing the modular approach, one package at a time, to make my future app development faster, more reliable, and infinitely more maintainable.

This journey has shifted my view on development practices fundamentally, and I hope it nudges you to rethink yours too. Here's to more efficient, effective, and elegant code in all our future endeavours.