Developing a public iOS framework, do’s and don’ts

Thoughts By 3 years ago

When you build a framework for people to use, you want to make sure it’s as easy to implement as possible. Even if your framework does amazing things, developers will be turned off if it’s too hard to use, or has bugs. I have worked with some really bad frameworks in the past and wanted to share some do’s and dont’s when developing a framework.

Easy to use and implement

It should be obvious, but if you require more setup or more code than should realistically be requried then nobody will want to use it. A good example of an easy to use framework is Flurry, which simply requires you to write one line to import the framework, and one more to start it with your session key. It’s also worthwhile distributing you framework precompiled, so nobody has to worry about building it themselves.

Class prefixes

You should do this in your regular projects anyway, but it’s more important when making public code used by others. Adding a prefix to each of your classes avoids compilation collisions. If your classes clash with the developer’s, the developer will either need to drop your framework, or rename their own classes.

Using popular libraries

I’ve seen frameworks that use libraries such as Apple’s Reachability and ASIHTTPRequest, simply leaving them named as is and not providing the headers. This means if you also want to use the same libraries in your own project then you need to rename them. Instead the developer of the framework should prefix any used libraries, as noted above.

Don’t touch the spinner

Don’t interfere with the spinner in the status bar. Because the way you turn it on and off is simply a boolean, most developers have their own increment and decrement methods to determine whether it should be on or off. Having another piece of code setting this means that an app’s spinner may do some weird stuff.

Get your interface right

When you first create your framework, make sure the public interfaces that other people will use are perfect. When you release a new version, you don’t want to force developers to have to change their code because your figured out you forgot or changed your mind on something.