The cloudbase.io iOS helper class comes as an iOS framework you can easily include in your XCode project. However, you may have noticed in XCode there is no project template to create a framework for iOS. Luckily this is still possible.
A framework is just a bundle like any other and XCode already knows how to work with bundles. Some tweaks to your project settings and custom scripts is all you need to create your own framework. Cocoanetics has an awesome article describing this process. Even better, Karl Stenerud has created an “insanely great” project template to create universal iOS framework.
Once you have setup your project, either as described in the Cocoanetics article or using Karl’s project template, you should be able to build your bundle to a framework.
You need to make sure all the headers needed for developers to interact with the objects in your framework are included in the package and marked as public. In your bundle target’s Build Phases open the Copy Headers step and add all of the header files that your framework needs, make sure they are in the public section.
For the cloudbase.io helper class framework we have added an additional item to the Build Phases as a last step to copy the .framework folder to the build subfolder of our project. Sweet and simple.
# copy generated framework to build folder
if [ -d $SOURCE_ROOT/build/$WRAPPER_NAME ]; then
rm -rf $SOURCE_ROOT/build/$WRAPPER_NAME
cp -rf $BUILT_PRODUCTS_DIR/$WRAPPER_NAME $SOURCE_ROOT/build/$WRAPPER_NAME
A common mistake when building custom frameworks for redistribution is leaving the debugging symbols links in your library. When testing the framework on your machine with a new application project it will work like a charm. However, when using it on a different machine, you will see a dsymutil warning for each object in your framework.
This is because GCC generates the debugging symbols for each object in your framework and deploys them in your install path – normally under /Users/<your home>/Library/Developer/Xcode/DerivedData/… – These are obviously not available on the other machine as the framework project was not built there.
While this is not a fatal issue it does not look good, or particularly professional, for a lot of warnings to appear when somebody tests your new framework.
Assuming you don’t want to re-build the framework on each machine there is a simple solution to this. There’s a GCC flag called GCC_GENERATE_DEBUGGING_SYMBOLS which can be set to NO in your original framework project. This way the framework library will not look for its debugging symbols. This property can be set from your framework target’s Build Settings – it’s called Generate Debug Symbols.
You should now be able to distribute your framework without these annoying warnings popping up.