Rule 0: Do not make a framework.
Ask yourself if you should be making a framework given that you are not in the business of making frameworks. Believe it or not, most of us have the urge to solve problems completely and in the general case as our first inclination, but getting things done requires not doing so almost all of the time.
Rule 1: Do not have dependencies on other 3rd party frameworks.
Frameworks should be modular and standalone. They should require nothing but the standard system libraries in order to run. If the framework relies on other functionality, it should encompass it entirely. If it cannot, it probably violates Rule 3.
Rule 2: Use a non-viral open-source license like MIT or Apache, NOT GPL.
If you do write a framework it should be for some reason between pure altruistic love and the need to collaborate with people smarter than yourself. Your intentions, politics, and monetization strategies detract from the utility of your framework, which is an object of pure utility. If it doesn't have code that is free to use without restriction, anyone who is paying attention will not bother.
Rule 3: Encompass the narrowest possible scope to solve a single problem incredibly well.
You know that framework that you have been dragging around with you since the beginning of your career that contains every useful line of code you have ever written? That is not a framework. That is the coding equivalent of a reality show about hoarders. It is OK to have more than one framework at a time, so keep your frameworks as small and specific as possible.
You might want to take a look at
https://github.com/seivan/SHFoundationAdditions and https://github.com/seivan/SHUIKitBlocks
Both are modular, do not rely on third party libraries like libffi and come with tests and documentation.
Also come in separate components if you want that.