Author: Johnson Goveas

Posted On Nov 24, 2011   |   4 Mins Read

Working with XCode IDE, I had always felt the need for a top-level entity that could support and organize my multiple XCode projects.  It wasn’t easy to access the files of one project from another in XCode 3.2, even if you had cross project references between them. Code sharing was always an issue if two or more projects used the same libraries and we had to copy them into each project folder separately.

Introduction of “Workspaces” brings in one of the new bits of “magic” that XCode 4 does for you: Multiple-Project Support. A workspace is basically a container meta-file that groups together multiple projects and other documents. It also provides implicit and explicit relationships among the included projects and their respective targets.

Concept of workspace also allows us to create and use third party libraries in iOS projects in a much simpler way. However, the procedure is still more complex than it needs to be. Apple documentation suggests that it should automatically detect dependencies and other index classes across workspace.

 There are few key behaviors of workspace on how to share code across different projects in XCode:

  • All the projects in a workspace are built in the same directory, referred to as the workspace build directory.
  • XCode inspects the files in the build directory to discover implicit dependencies between them.
  • Each project in a workspace continues to have its own independent distinctiveness.

 Steps that worked for me:

  1. Create a new workspace and add the shared library project.
  2.  Add the application project that would use the above shared library.
  3. Open Build Phase of shared library and make sure when copying headers it is grouped to public .
  4. Open Build settings of application and in the Header Search Paths type in “BUILD_PRODUCTS_DIR”\usr\local\include .
  5. And in Build Phase of target, include a link to static library (shared library) .
  6. Now, clean and build and everything should build successfully.

Incase you are having linking errors while setting up the workspace in XCode, you can refer this article whats-the-correct-way-to-configure-xcode-4-workspaces-to-build-dependencies

All said and done, this worked like a charm for me. The workspace concept benefited me by sharing the code and build folders across multiple projects. Now, with the use of XCode 4 workspace we don’t have to copy the library files in every project and this saves lot of development time and effort.

How is it better than eclipse workspace?

There are two main aspects in which I found XCode workspace to be better than Eclipse workspace:

  1. In XCode 4.0, file indexing is done across the whole workspace so, code completion and refactoring operations act across all the content of the workspace. You can refactor the API in a framework project and in several application projects that use that framework all in one operation. This feature is missing in the current version of Eclipse.
  2. All the XCode projects in a workspace are built in the same directory, which is referred to as the “workspace build directory”. As all of the files in all of the projects in a workspace are in the same build directory, all of these files are visible to each project. Hence, if two or more projects use the same libraries, you don’t need to include them into each project folder separately.

How it improved my development process?

This article might give you an impression that setting up the workspace is a lot of work; but fortunately it’s not, especially if you do it more than once (considering that the aim here is to share code across multiple projects). I have been using this workspace approach for about four months with several projects and it’s definitely saved me a lot of time especially when the application projects used the same static libraries again and again.

Instead of copying the source code from the “shared libraries” into every project (which used to take me an hour or so for every project), I just keep the shared library code in a separate XCode project and use it to build static libraries along with the application project. It is just a 5-minutes job now!