Lovely Frameworks

Certainly any macOS or iOS developers have used a framework in their project and Cocoapods makes it even easier to use 3rd party ones.

But did you create one yourself?

You really should, because it has some great advantages:

  1. Structure
  2. Reusability
  3. Stability


The benefit I like the most is that creating frameworks of certain areas of your code base forces you to precisely separate it from the rest of the code. Often the code - especially old and long grown one - has references to different parts of your project. Creating a framework is giving the opportunity to clean that up and ask yourself: “Does this still make sense this way?”

The outcome of creating a framework should also be to get a clean and minimal API. Minimal in the sense of: “What is it that is really required to execute that functionality?” You’ll be surprised how simple things may become.


The main purpose of a framework is to reuse it over again in other projects. This indeed makes a lot of sense and can pay out for the upfront investment of creating a framework in the first place.

For example I have some code that provides logging and debugging features I like to use as my basic toolbox. It also contains categories for objects I need all day, like string manipulation or date parsing and formatting. That is my first import on a new project. And also other frameworks I wrote use this base framework as well.


A project should always be free of warnings and errors, otherwise you’ll not notice if some little problem that already showed up as a warning - which you ignored because it was hidden under dozens of others - causes you headaches a while after. But sometimes it is hard to get rid of warnings, because they would require a lot of workarounds or live in third party code you don’t want to touch. In your own frameworks just turn these warnings off, once your code ist stable and will not get changed any more.

Writing test suits for frameworks make sure you cover their functionality completely. You can focus on the single thing it is supposed to do and tests will not float around in a list of others in one big main project.

Real Life Example

As a real life example I would like to talk about my projects PDFify and Receipts. PDFify was actually made to have a test environment for my OCR and PDF features I offer in Receipts. I separated OCR, PDF extraction and creation, Mail Parsing and the Scanner Interface and made a framework for each of them. I was able to write test cases specific to the different topics thus having a minimal functionality I can focus on. I can even reuse most stuff for iOS as well or for future projects to come. Sharing the code with other developers is also much easier this way.

Screen Shot


I found it easier to add all frameworks to the main project, even if a framework used sub-frameworks. The problems I ran into were related to signing.


Frameworks finally got better support on iOS as in the early days, but there are still some pitfalls to care about:

  • If you use categories you should set OTHER_LDFLAGS = -all_load -ObjC
  • Dynamic frameworks don’t work well, set MACH_O_TYPE = staticlib


Frameworks also work great with HockeyApp (I know, this service is going to get replaced, but it is still first choice for me right now). Get more info here:

Published on October 11, 2018

Back to posts listing