Bring your old iOS Library back to Life in just few easy Steps
Revive an outdated Package with a new and fresh Look
Yeah, it happens. Time flies. “Tempus Fugit” as the cool people used to say. It could be a new grey hair or wrinkle when facing the merciless mirror, the sudden realisation that your team did not win the league in few years or an iOS library written for iOS 8. And the sooner we accept that fact, the sooner we can cope with it and go on with our lives. Accept the things I cannot change, don’t look back and all this. Only that there is something we can change here. We can retake our decrepit library, give it some energizing love and resurrect it with a fresh and youthful look.
On NMT we use any given chance to encapsulate an implemented feature into a library, and if time and privacy allow it, publish it Open Source for the common good. The proof is in the pudding: back in 2016 we extracted the Homescreen Navigation of our WELT News App into LazyPages, a highly customizable library that helps you to show a scrollable list of view controllers synchronized with an index menu. With Lazy Pages you can lazy load your view controllers, instead of having them all in memory when creating it.
But, as time is impermanent, so is the UX & UI Design of a product whose owner is eager to improve. For a time we opted for a kinda like Burger Menu to navigate among the sections of our app, to later realise that the original Lazy Pages approach produced more traffic and optimized our app’s user experience. It was time then to open the storehouse of memory searching for Lazy Pages again.
The advantages of both modularising your architecture and publishing Open Source are common knowledge nowadays, so I won’t delve into these topics here. Instead, I’d like to focus on the why and how we can bring these old libraries back to life.
Why?
Of course, as with any other aspect in our lives, the big question comes: why? Why spending even a tiny bit of our precious time in that? Well, for us the answer was easy; we needed that functionality again, and we needed it in production. That means that, as any other piece of our code, it had to be adapted to the latest requirements.
But even if we are not going to use it, maintaining our Open Source libraries is very convenient. Firstly, because that way it could still be used by the community. Likewise, keeping a product up to date would encourage other users to contribute, and in that manner, leverage the necessary effort to sustain a well looking product.
In addition, our personal or brand name will still be linked to a well maintained product, avoiding the bad impression produced by the unfortunate “last commit three years ago”.
I still don’t wanna do it!
Ok ok, there are cases when we do not want to spend time on it. Maybe our project is redundant because Apple already provided that functionality in a later version of the SDK, as they did with Combine for Reactive Programming. Or perhaps the huge amount of required effort to migrate from ObjC to the latest Swift version or to make it compile with the newest SDK makes it simply not worth it.
In that case there is still something we can do instead of deleting it. We can archive it. That means that we are not actively working on that project, and likewise we won’t accept any further contribution. It makes it read-only:
Just because a repository isn’t actively developed anymore and you don’t want to accept additional contributions doesn’t mean you want to delete it. Now archive repositories on GitHub to make them read-only.
Just like that we can quickly show our userbase that the library is no longer being updated so they should use it at their own risk, and by the same token it will probably need a bit of refurbishing before using it.
But be wary of this option; as stated above, archiving means that no further contribution is allowed in your repo. It could be the case that you don’t have time to enhance your owned library, but any other kind fellow developer might be eager to do that. If we archive it they won’t be able to do it anymore.
The Quest for Eternal Youth
Yeah, you convinced me, I want to renovate or maintain that old library of mine. What should I do? Can you provide me a checklist to achieve it? In order to update our library, we should:
- Migrate it to the last Swift Version
- Make it compile with the last iOS SDK
- Use new technologies
- Convert it to a Swift Package and support Swift Package Manager
- Update your README file and draft a Release
- Add it to the Swift Package Index
Here we go! Firstly and foremost, we have to …
Migrate it to the last Swift Version
Yup, if we are going to make it, we have to eat that frog first. So in the case that we have an old Swift version or, even worse, if our library is still in Objective C, we have to migrate to the last Swift version so it can benefit of all the advantages of the language. We are many developers that would prioritise a Swift codebase over Objective C almost blindly, among other reasons because of the easiness of the package integration and future usage. That brings us to the next topic , it …
Should compile with the last iOS SDK
Yeah, if we migrated to the last Swift version this step was probably required, but notwithstanding it is worth remarking it. Your library should be buildable with the last OS SDK version so it can be usable in any project. Needless to say, this does not mean that we should supporting older iOS versions, we can still set our minimum deployment target to a previous value. We will delve into this when talking of SPM, but now that we are using the latest iOS version, we can …
Use the newest technologies
Together with newer versions of the iOS SDK, new features and technologies APIs are shipped by Apple, APIs that can be integrated in your library replacing or enhancing your old codebase. For instance, if you used reactive programming with RxSwift you can now use Combine, getting rid of one big dependency and thus decreasing the build time. If you were using ARKit, you can now use the brand-new Depth API introduced in ARKit 4, thus making your package much more attractive for the community.
Once we have our codebase ready, it is time to …
Convert it to a Swift Package and support Swift Package Manager (SPM)
Whether your library is older than Xcode 8 or you preferred not to support it due to its early stage, now it is essential that your package is installable through Swift Package Manager. With Lazy Pages we were as far as to remove the support for CocoaPods, in order to simplify the installation process.
SPM is the standard tool build by Apple to distribute Swift packages. It is fully integrated in Xcode and automatically manages all the dependency’s dependencies, what makes the process painless and transparent. Here you can delve deeper into how to create a standalone Swift Package, or convert your existing codebase.
If you already have your shiny new Swift Package, you should …
Update the README file and draft a new Release
After the changes above it is very likely that the information in the README.md file should be updated. Your requirements are different now: you require higher versions of Xcode, iOS and Swift, and furthermore, it should be stated how to install it via SPM.
Moreover, if the changes forced your to modify your library’s public interface it is time to edit your usage code snippets, to include the new additions.
Similarly, a new library version should be drafted, with a proper tag version, title, and a short description mentioning whether this new release included breaking changes, so your users can decide to install it or postpone the effort of adapting to the new modifications.
All your hard work deserves to be acknowledged. You can finally …
Add it to the Swift Package Index
These days, with the immense amount of information and resources available in the internet, it is likely that your library gets lost it is not somehow indexed. To avoid that, you can of course write a blog post about it, send it to your favourite iOS developer community newsletter, or add it to the Swift Package Index.
Swift Package Index is the place to find Swift packages, indexing at the moment 3,486 packages and 53,590 versions, and growing everyday. To add your package there, check their Master List repository to submit it. As they say:
Please feel free to submit your own, or other people’s repositories to this list. There are a few requirements, but they aren’t onerous.
That’s it!
That was it, not so tough right? Now your team and the community are thankful for your shiny package, that can be used again as if it were totally new.
In this post we have seen why and when it is important to maintain and keep our libraries up to date, how to do it, and when it is not worth doing it. Even in the latter case we can do something with it.
Certainly i might have missed some important steps along the process, if you think so or have any other suggestion please add a comment here.
Carpe Diem!
