Feature request: 'Nimbus' as a set of static frameworks about nimbus

[jverkoey]

Interesting tips! Would you like to write up a quick walkthrough on how to do this for Nimbus?

On a separate, but related note: I personally find it incredibly easy to just drop the Nimbus source into my various projects and not worry about configuring any dependencies or linker flags. I want to avoid walking Nimbus down Three20's path of multiple separate projects. This is because, while in theory it made sense to share static libs of Three20 between projects, in practice this results in a net negative due to the hassle of configuring projects and debugging external Xcode projects.

[bubnov]

Sometimes I have to hide my sources from the customers ;) It's about my intellectual property protection. So, I realized that it is a bad idea to include all sources to the project (very often customers asks for the project sources).
So, I found that the static framework is a pretty good solution for me.

Nimbus is open-source project. So hiding the sources isn't argument here =)

But, protecting the sources isn't the only thing that static frameworks can offer.

Adding the framework to the project is much easier, than adding a bunch of files from specific folder. When we're using the framework - all we need is to add the framework to the project and import the header. Moreover, static frameworks are visible for xcode, because they are real frameworks. Just like UIKit and Foundation frameworks )

Also, sometimes I don't want to have sources of the third-party lib or framework. I don't want to have a deal with warnings, related to it. And the static library isn't solution for me due to the painful integration.

Btw, XCode 4 works just perfect with this frameworks. Just read the readme here: https://github.com/kstenerud/iOS-Universal-Framework, add projects templates to the xcode and try! It is easy.

So, the quick walkthrough:

1. Add frameworks template projects to the xcode. There are two ways: use fake or/and real framework. Both of them has their pros and cons. I prefer real framework.
2. Create empty framework, for example, NimbusCore, and add the sources to it. Then make needed headers public and compile ;)
3. If framework projects lies in the same workspace with another projects - this framework will be visible in the list of frameworks in "Workspace" section.

I hope (while I've typed this reply) you've already tested this solution ;)
It is late night in Kiev, so, good night!

[rogchap]

I've created scripts to build static frameworks for an internal iOS library and they do make it easy to add to your project, just like adding UIKit, StoreKit or any other iOS framework.

It also solves the ARC/non-ARC project issue. (Although I still prefer Nimbus to be ARC enabled).

I had issues loading Categories using a static framework, even with the Category Macro fix, but will try again.

If we provided the scripts to generate the framework folders then it should be easy for people to chose which method suits them and we don't need to dictate how to use the library.

[jverkoey]

@rogchap Agreed; that sounds like the safest solution here. How easy are the scripts to use?

[rogchap]

Easy enough to run and output all the nimbus modules and should be straight forward to add new modules to the script. I'll put together a working prototype for you to look at.

[Vaseltior]

I branched "frameworks" and started to create targets that are "Real Static Frameworks"
from ( https://github.com/kstenerud/iOS-Universal-Framework )
Packages compile as any target you would build, but create the framework files and then copy them to the
./frameworks directory of the git repository.

And by associating them to the scheme, adding a "rm" of old frameworks files before compilation keeps everything up to date.

Tell me if you're interested : you can see that starting work there : https://github.com/Vaseltior/nimbus