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.
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.
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.
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
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.
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:
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.
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.