Maintaining a Growing Open Source Project

The best part is the journey

Badge icon made by Dimitry Miroliubov from

In 2015 I open sourced a small Swift framework called SwiftyStoreKit.

The goal: make in-app purchases simple on iOS.

I have written about my experience with it before:

This is a follow up on how my journey is continuing and how this project is pushing me to become a better developer.

First of all, I want to share some great resources that gave me inspiration and many practical tips on how to grow my project.

GitHub Open Source Guide

This guide contains some really great material. In particular, I recommend this section:

Scaling Open Source Communities

Felix Krause talks about the four stages of open source projects in his super-detailed Scaling Open Source Communities article. Summary:

  • Stage 1: Putting source code on GitHub
  • Stage 2: Developers start using your software
  • Stage 3: Project is popular and the go-to solution in its field
  • Stage 4: Hyper-scale open source projects

I can’t recommend this enough. Go read it.

And this one: Open Source at Artsy.

To the next level

When SwiftyStoreKit became popular sometime last year, developers starting opening issues and pull requests on the project.

Pressure was on

As the only maintainer, I felt some pressure due to a number of problems:

  • The issues list was growing. Some of them underlined some flaws in specific areas of the project
  • StoreKit is not a trivial framework to use and I didn’t understand some areas very well
  • I was worried to introduce regressions when changing things
  • I had no metrics on how often IAPs would fail and under which circumstances. Were my users losing sales? 1%, 5%, 10% of them? More?
  • I could not effectively test my library in all the possible end-to-end configurations (iOS, macOS, tvOS, sandbox, production, iTunes downtime, account/IAP configuration issues etc)

Keeping things sane

I soon realised I had to do a few things:

  • Read more about StoreKit and ensure my implementation was in line with Apple’s guidelines
  • Get organised and respond more timely to issues and PRs
  • Avoid feature creep and learn when to say no
  • Add unit tests
  • Standardise and streamline contributions — both mine and from other users

What I did

  • Rewritten the purchase flows entirely with full unit test coverage
  • Added a Travis CI job to run the build and the tests
  • Added an file to encourage reporters to include all relevant details. Big win
  • Added a file outlining the scope of the project, pull requests process, list of missing features
  • Added SwiftLint to the project to standardise project contributions and make them easier to review and accept. Go check it out! 💯
  • Adopted gitflow. This introduces a development branch where new feature work can be merged and tested before going to master
  • Use feature branches by default for my own contributions. Makes it easier to track features and reference relevant issues
  • Periodically spend a few hours reviewing all the issues and closing inactive ones
  • Publish milestones to give more visibility on priority and timeframes for for planned future work

These changes were quick to implement, but improved the process considerably.


Some open source projects out there are managed far better than mine, and I know I still have a lot to do.

Still, with my changes I now feel more confident in driving things forward, and I’m enjoying the journey a lot more.

Nothing better than having confidence from unit tests, linting and a good process to grow a healthy project.

I also feel that SwiftyStoreKit is slowing becoming the go-to place for in-app purchases on iOS, which gives me renewed motivation to make it better. As I said before:

I want my code to have an impact in the world.

As of today, SwiftyStoreKit celebrates the 100K downloads milestone, in line with a significant increase in traffic in the most recent period:

CocoaPods statistics for SwiftyStoreKit as of 25/02/2017

As developers increasingly use SwiftyStoreKit in their apps in production, I need to ensure it is safe and reliable, and become even smarter about how to maintain it going forward.

  • It is still hard to ensure the framework works correctly in all configurations
  • I still have no metrics on how reliable the framework is
  • Unit test coverage can still be greatly improved
  • Pull request etiquette should be formalised

Luckily, I don’t expect new feature development to happen at breakneck speed as most features in the original scope of the project are already implemented. But I’ll see if this prediction holds true. 😅

Wrapping up

Compared to other open source projects that have experienced wide adoption from the start, SwiftyStoreKit has been growing slow and steady. This was a blessing as I could keep things on course and improve my process along the way.

I’m getting better and better at managing software development in the open, and I can apply many of the things I’m learning on this journey to my other projects and client work.

  • If you’re just getting started with open source, I hope this will inspire you to build and share some great stuff.
  • If you already have a project and maintaining it seems like a chore, some of the tips above may turn it into an enjoyable and rewarding experience.

Who knows, maybe your project will make it to this list next year:

How has your experience been with open source? Let me know in the comments. 🙂

Read next: Want to live more sustainably? Meet the EcoBuddy app.

If you liked this, click the 💚 below so other people will see this here on Medium.