CODEWITHSUNDEEP
iphonexcodehyperlinkprojects
nosuic
nosuic

Reputation: 1360

XCode: Linking projects inquiry

I have 2 projects and I want to use in the first project, a class (i.e. view controller) of the second. Instead of importing all the files of the second project in the first one, is there a way to link it like a framework or library?

I tried the following unsuccessfully:

  1. Dragged-dropped SecondProject.xcodeproj and checked SecondProject.app as a target
  2. Added it as a dependency project in the first project dependencies
  3. Pointed to the header files by adding in the "Header Search Paths" a path pointing to the second project which I copied in a subfolder of the first project.

When I include "SecondProjectViewController.h" I get no errors but when I try to instantiate it I get the "OBJ C referenced from" error.

Any help is deeply needed and appreciated! =)

F.

Upvotes: 1

Views: 1923

Answers (3)

justin
justin

Reputation: 104698

You have only a few steps to go:

4) in First project, click the disclosure triangle in the Groups and Files section for the Second Project reference. this will display the targets of Second Project.

5) Drag the target reference (e.g., static library) from Second Project to the target in First Project's link phase.

That should clear up all the linker errors for the symbols which exist in Second Project's library. Of course, you'll have to remove those sources (based in second Second) which are compiled and linked from First.

Managing static libraries for huge codebases is dead easy this way (although I prefer the build up to the minute (as well as several build variants), and don't reference archived binaries as Derek does). Learning to minimize changes which break builds takes time to learn. dynamic libraries are a bit different - depending on their distribution, you may want to version (as Derek outlined). It's good to share, but you should put the shared exported symbols in a library, which is a dependency of both apps. Just be careful not to add too much unnecessary objc symbols to the library - objc symbols and their references cannot be stripped from the final executable and they will cause runtime collisions if they appear in two images (dylib, app, static lib) within the same process.

Upvotes: 1

drekka
drekka

Reputation: 21883

As an experienced developer I would suggest not sharing code this way across projects. The simple reason is that changes in one project will then directly effect other projects, often rendering them un-compilable. For example, if you share a controller class and decide to implement a change with a new import, then any project that uses that class will be broken until you open then in xcode and ensure that the imported class is available.

A better method is to compile your first project as a static library or framework. I'd also recommend ensuring that it is version some way. For example, in my projects I create static frameworks and store them in a directory called "v0.0.1", "v0.0.2" etc.

The framework can then be dragged and dropped into a second project to use it. The second project then refers to it via the directory path. The advantage of doing this is that if I then change the first project, the second one if not effected by the changes until I choose to update the frameworks path.

Sharing files between projects will work for small cases, that being 2 or 4 projects, but once you have more than that it rapidly becomes un-manageable.

Upvotes: 3

Richard
Richard

Reputation: 3386

You can add the view controller's files to your 1st project regardless of where they are on disk -- the project will make a reference to their location.

Upvotes: 0

Related Questions