What is the recommended way to reuse utility functions among apps in my XCode based iphone apps?

Question

Hi,

I am new to iphone development and xcode, coming primarily from a unix/windows C background.

I have some utility functions like:

void myVibratePhone() 
{
    AudioServicesPlaySystemSound (kSystemSoundID_Vibrate) ;
}

that I'd like to use across all my projects.

In C, I'd give each project the header file, and link in the .OBJ file (or perhaps create a library).

What is the apple-approved recommended way to share code ( cocoa and C primarilly) among my apps? Would I need a framework for this? How would I go about creating one?

Also, since I'm using subversion for version control, if I use a framework, do I place the version of the framework that the app is using in the subversion repository for the project so that anyone who checks it out can build it straight away or make it a requirement that people check out a project + check out the utility functions also for a successful build of any project?

I don't plan on putting anything on the App Store at this time, but I don't want to do anything that will cause apple to not accept an app in any case.

I found this writeup about xcode 3.0 (I'm using Xcode 3.2.1):

http://stackoverflow.com/questions/159221/how-do-i-create-a-bundle-of-reusable-code-in-xcode

I followed it, but am having one issue:

1) trouble finding my library .h file in the main project: I've tried both hardcoding it in the main projects .h file

#import "file://localhost/Users/piesia/Documents/My Utilities/MyUtilities.h"

as well as:

#import "/Users/piesia/Documents/My Utilities/MyUtilities.h"

and

    #import "~/Documents/My Utilities/MyUtilities.h"

I've also tried updating Header search paths in the Project Build settings:

"/Users/piesia/Documents/My Utilities/**"

when using #import

After a lot of trying (and replacing %20 with space), I was only able to get the variants

#import "/Users/piesia/Documents/My Utilities/MyUtilities.h"

and

#import "../../My Utilities/MyUtilities.h"

but I'd prefer not to hard code the path if I can figure out a better way.

So, in closing, 1) is the writeup that I'm following the recommended way to do shared code in Xcode 2) is it recommended that I keep the shared files in a separate subversion repository from the main program and link and include it in as I'm doing now and 3) do you know what I'm doing wrong in my attempts at loading the shared header file? Would anything that I'm doing or not doing with shared code hurt my chances of getting approval if I ever decided to submit it to the App Store?

Thanks very much!

Piesia

Answer 1

Oh this one is a bugger! - I think unfortunately the easiest way is to hardcode.

Answer 2

I agree with creating a static library to share the code.

To add the headers to the project you need to set the "User Header Search Paths" to the location of the .h files.

You then import the headers using something similar to:

#import "YourHeader.h"

You shouldn't need any additional path information in the import if the header search path is set correctly.

Answer 3

My team has dozens of reusable components in our products, many of them shared between Mac and iPhone. My experience in this is that most of the time it's much easier to just include the source code rather than to create a separate static library. The separate project for the library adds a lot of complexity and seldom provides much value. Here is how I usually approach it:

In subversion we have a directory tree like this:

/common
    /Component1
    /Component2
/Project1
/Project2
...

In Project1.xcodeproj, we just drag in "Existing files" from common into the tree (don't copy). Doing it this way avoids lots of overhead in managing another project. This does mean that changes to the common tree can break any of the projects. That means you need to recompile everything before committing (we use a top-level build script to check that you didn't break anything). The advantage of the static library is that you can stage this by upgrading the library for each project when it's ready. On the other hand, it means that you have to rev the library often and manage syncing it around. We've found that just sharing the code directly typically is much more effective.