How to choose good third party frameworks

When starting a project, one of the most important questions is what third party frameworks to use. Choosing the wrong framework can be a major drag on development, and it’s often an irreversible mistake.

Fortunately for us, the frameworks we decided to use when we first began working on Safedome have stood the test of time. Our careful approach to choosing frameworks was a big part of this, so we decided to share our advice on .

What to look for:

1. Is this framework actually needed?

Dependencies add technical debt to projects, so only add a framework if you really need it. If a framework is just saving you a few lines of code or you just don’t want to figure out something tricky, don’t use it and code it yourself.

2. Recent and regular activity

Thanks to GitHub, it’s easy to see if a framework has been updated recently and how often it gets updated. If the framework isn’t worked on regularly, updates to iOS may not be responded to in a timely manner.

3. Good support

Look at whether issues raised are responded to promptly, or at all. If bugs are fixed, or at least responded to quickly, you can probably get help if you discover a bug yourself (or at least think you have).

4. A helpful community

If you see lots of questions and answers on GitHub, it’s generally a good indicator that you’ve got somewhere to go for help if you get stuck after having a question dismissed by Stack Overflow mods.

5. Thorough documentation

Having to look at the source code shouldn’t be necessary for understanding how to use a framework. Well commented header files that are essentially the APIs interface can be considered documentation, and not source code.

6. Examples you can run

Examples you can run and play with in Xcode — or AppCode if you’re a badass — can be used as templates or guides on how to use a framework.

7. Good looking code

Quickly scan and compile the code to see whether the developer cares about what they’re doing. Some things to look for when judging the quality of a framework’s code are:

  • Zero compiler warnings
  • Consistent code style
  • Follows iOS conventions

8. Plenty of tests

Frameworks with wide test coverage are less likely to have bugs, and their interfaces will be better defined and more dependable.

9. Good dependencies

Frameworks shouldn’t have lots of dependencies, and the ones they do have should be common and trustworthy. Having lots of random dependencies increases compile time and means your project can start to feel like a museum of old GitHub repos.

10. Dependency management

Good dependency management is crucial for large projects and teams of developers. Projects should be easy to set up and run.

What NOT to look for:

1. Popularity

Just because lots of people like a framework doesn’t mean it’s suitable for your project, or that it’s even a good framework.

2. Lots of contributors

Having lots of contributors can actually mean a lot of substandard pull requests are getting merged in. A few core contributors who are focused on building a great framework are much better than lots of ‘okay’ programmers throwing hacky code into a repo.

3. Ease of use

Easy to use frameworks are not necessarily a bad thing. Just make sure the framework isn’t making it too easy to abuse low level systems. Stuff like Core Data and Core Bluetooth should be hard, and should require discipline. Pretending they aren’t hard will only come back to bite you.


None of these snippets of advice should individually cause you to accept or reject a framework. Even good frameworks might let you down on one or two of these points. If some frameworks start to look dated or aren’t as useful to your project as you foresaw, be prepared to remove or replace them.

Frameworks are not frozen in time, and even though they can offer huge benefits, they also pose a large risk to the long term health of your project. By using these guidelines you’ll be more likely to choose frameworks that continue to support your project throughout its lifetime. Good luck!

by Aiden Benton