Creating your own custom libraries in iOS?

Question

I'm fairly new to programming and wanted to start programming more efficiently. Try as I may I often find myself straying from the MVC model.

I was wondering are there any tips or methods in keeping your code organized when coding in xcode objc? To be more specific (I know you guys like that :) I want to

1. Be able to write libraries or self-containing code that can bring from one project to another
2. Share my code with others as open sourced projects
3. Prevent myself from writing messy code that does not follow proper structure

Answer 1

• Use a high warning level. Build cleanly.
• Remove all static analyzer issues.
• Write some unit tests.
• Keep the public interfaces small.
• Specify your library's dependencies (eg minimum SDK versions and dependent libraries).
• Compile against multiple/supported OS versions regularly.
• Learn to create and manage static library targets. This is all you should need to support and reuse the library in another project (unless you drag external resources into the picture, which becomes a pain).
• No global state (eg singletons, global variables).
• Be precise about support in multithreaded contexts (more commonly, that concurrency shall be the client's responsibility).
• Document your public interface (maybe your private one too…).
• Define a precise and uniform error model.
• You can never have enough error detection.
• Set very high standards -- Build them for reuse as reference implementations.
• Determine the granularity of the libraries early on. These should be very small and focused.
• Consider using C or C++ implementations for your backend/core libraries (that stuff can be stripped).
• Do establish and specify any prefixes for your library's objc classes and categories. Use good prefixes too.
• Minimize visible dependencies (eg don't #import tons of frameworks which could be hidden).
• Be sure it compiles without the client needing to add additional #import s.
• Don't rely on clients putting things in specific places, or that resources will have specific names.
• Be very conservative about memory consumption and execution costs.
• No leaks.
• No zombies.
• No slow blocking operations on the main thread.
• Don't publish something until it's been well tested, and has been stable for some time. Bugs break clients' code, then they are less likely to reuse your library if it keeps breaking their program.
• Study, use, and learn from good libraries.
• Ask somebody (ideally, who's more experienced than you) to review your code.
• Do use/exercise the libraries wherever appropriate in your projects.
• Fix bugs before adding features.

Don't let that scare you -- it can be really fun, and you can learn a lot in the process.

Answer 2

There are a number of ways you can reuse code:

• Store the code in a common directory and include that directory in your projects. Simple, but can have versioning issues.
• Create a separate project which builds a static iOS library and then create a framework. More complex to setup because it involves scripting to build the framework directory structure. But easy to use in other projects and can handle versioning and device/simulator combined libs.
• Create a separate project which builds a static iOS library and then include this as a subproject in other projects. Avoids having to build frameworks and the results can be more optimised.

That's the basic 3, there are of course a number of variations on these and how you go about them. A lot of what you decide to do is going to come down to who you are going to do this for. For example I like sub projects for my own code, but for code I want to make available for others, I think frameworks are better. even if they are more work to create. Plus I can then wrap them up with docsets of the api documentation and upload the whole lot as a DMG to github for others to download.