Do I really need to create an iOS static library for internal-use-only code?

Question

In a brainstorming meeting, someone recommended that we use a static library in a future project. I have researched this topic all day.

I have found some helpful answers about what a static library is and how to create one.

Library? Static? Dynamic? Or Framework? Project inside another project

I've also found answers on how to use resources with a library:

iOS Library With Resources

My Question Is:

Do I really need to create a static library, or should I just create a class for internal-use-only code?

Conditions:

1. I have three projects that require a special encode and decode engine.
2. The engine's functions involve cryptography, IP packet transport, and hardware binary coding.
3. There are fewer than 20 functions.
4. We will never release this engine to a third party developer or open source it.

Another way to ask:

In what circumstances should I create a static library?

Answer 1

Even if you don't want to share your code with other developers, you can still gain tremendous benefits from creating a static library.

As Srikar Appal mentions, benefits gained from creating a static library are 1) Code Distribution, 2) Code Reuse, and I'd also like to add, 3) Versioning, 4) Testability (kudos to BergQuester's comments below) and 5) Documentation.

Let's look at these more closely:

1) Code Distribution

Static libraries are great because they make it easy to distribute your code- all you have to do is compile and share the resulting .a file.

Even if you never plan to share your code with other developers, you can still make use of this across your own projects.

Alternatively, you might instead include the static library's project as a subproject to your various main projects, making this a dependency of the main project... see https://github.com/jverkoey/iOS-Framework for how this can be setup.

2) Code Reuse

Even in very different apps, you'll often find that you're doing the same task that you'd previously written code for. If you're an efficient developer, you wouldn't want to write the same code again... instead, you'd want to just include your previously written, polished code.

You might say, But I can just include the classes directly.

What if your code isn't necessarily polished, however? Or as tends to happen, the frameworks it uses change over time?

As you make changes and bug fixes to the code set, it'd be nice to be able to easily include the latest version in your projects (or be able to easily update your projects later on). A static library makes this easier to do because all the related code is included within a single package.

There's also no worrying about what other project-specific hacks other developers have been imposed on it - the main project can't (or in the case of a static library included as a subproject, shouldn't) change the static library's code set.

This has the added benefit that if someone does need to change the static library's code set, he must make the change such that all projects relying on it will still be able to use it (no project-specific shortcut hacks).

3) Versioning

If you have a set of classes that are moved around and included project to project, it's hard to keep up with versioning. Most likely, the only versioning you do have is that of the main project.

What if one project fixes some bugs and another project fixes other bugs within this class set? You might not know to merge these changes (what if two teams are working separately even on these)? Or, each project might be fixing the same bugs!

By creating a static library, you can keep track of versioning (the static library's project has its own version number), and by making changes on the static library, you'll have less merge issues and eliminate the risk of fixing the same bugs over and over.

4) Testability

As iOS continues to mature as a platform, unit testing your code is becoming more and more prevalent. Apple even continues to build and expand on testing frameworks (XCTest) to make it easier and faster for iOS developers to write unit tests.

While you could (and, IMHO, should) write unit tests for your code at the application level, creating and encapsulating code withIN static libraries typically makes these tests better and easier to maintain.

The tests are better because well-designed static libraries encapsulate purposeful functionality (i.e. a well-designed library performs a specific task, such as networking tasks for example), which makes it easier to "unit" test the code.

That is, a well-designed static library sets out to accomplish a predefined "purpose", so essentially, it creates test boundaries naturally (i.e. networking and presenting the fetched data would likely be at least two separate libraries).

The tests are easier to maintain because they would be within the same repository (e.g. Git repo) as the static library code (and thereby, versioned and updated alongside this code). Just like you don't really want to copy and paste code from project to project, you similarly don't want to copy and paste tests, either.

5) Documentation

Like unit testing, in-line documentation continues to become more important in iOS.

While you can (and again, IMHO, should) document code at the application level, it's again better and easier to maintain if it's at the static library level (for the same reasoning as unit testing above).

---

So to answer your question,

Do I really need to create a static library, or should I just create a class for internal-use-only code?

You might ask yourself the following:

1. Will this code be used across multiple apps?
2. Will this code ever have more than one class?
3. Will multiple developers be working on or using this code concurrently (possibly in different apps)?
4. Will this code be unit tested?
5. Will this code be documented?

If you answer YES to most of the above, you should probably create a static library for this code. It will likely save you trouble in the long run.

If you answer NO to most of the above, you might not gain much benefit from creating a static library (as the code set would have to be very specific to a project in such an instance).

Answer 2

In my opinion creating a static library has the following benefits -

1. Code distribution - This is the biggest reason (perhaps the only reason) developers create a static library. It obfuscates the actual code and exposes the API methods. But since you have explicitly mentioned that this "library package" would never be distributed to 3rd party developers this reason might not apply.
2. Code Reuse - This is the other reason I can think of. But then, one can achieve code reuse by simply using classes in (.m files), having the method definitions in header file & importing the header file (.h files). So this is not much of a reason to create a static library.

I am not aware of any performance benefits due to statically linked code. Also creating static library has its own maintenance overhead. It would not be as simple as creating one build. You would have to keep in mind linking the static library, maintaining compatibility etc.

So in your case creating a static library might not make much sense.