views:

4232

answers:

7

The error I'm getting:

in /Users/robert/Documents/funWithFrameworks/build/Debug-iphonesimulator/funWithFrameworks.framework/funWithFrameworks, can't link with a main executable

Cliff notes:

  • trying to include framework
  • doesn't want to link

More detail: I'm developing for a mobile device... hint, hint using Xcode and I'm trying to make my own custom framework which I can include from another application. So far, I've done the following:

  1. Create a new project; an iPhone OS window based app.
  2. Go to target info-> under packaging, change the wrapper extension from app to framework
  3. Go to Action->new build phase -> copy headers. Change roles of headers to 'public'
  4. From my application, I add the framework to the frameworks group.
A: 

I haven't tried it for so called mobile device, but I would guess its very similar to the method for a regular Cocoa application. Check out this tutorial:

Embedded Cocoa Frameworks

amrox
+7  A: 

Apple clearly said that you cannot use dynamic libraries on their mobiles. And a private framework is just this.

You can, however, use static libraries.

A: 

>

Apple clearly said that you cannot use dynamic libraries on their mobiles

Saw this and tried to Google around a bit but I didn't find anything in black on white... Where exactly to they say that own dynamic libraries cannot be used on in iPhone aps?

+1  A: 

Egil, that's usually considered as one of the implications of section 3.3.2 of the iPhone developer agreement, which (in part) forbids plug-in architectures or other frameworks. The fact that they don't provide an Xcode project template for an iPhone-compatible framework tends to reinforce the idea, though of course it could just be an oversight or something they're discouraging without actually forbidding.

Whether this is the intended meaning of that section is something you'd have to ask Apple about, and possibly consult a lawyer, but this is where the oft-stated "no frameworks" idea comes from.

For those who have framework code they'd like to use in an iPhone app, an alternative approach is to use the framework code to build a static library. That then gets compiled into the application instead of getting dynamically loaded at run time. The fact that it's part of the application executable avoids any potential concerns about this part of the agreement.

Tom Harrington
A: 

Hi Tom,

I thought this was in reference to 3.3.2… However clause 1 defines an Application to mean one or more software programs.. The Application (e.g. an executable and an accompanied shared library) must not as per 3.3.2, call other frameworks or APIs. I.e. it would be perfectly kosher to call the Applications own frameworks and APIs.

Also in order to comply with 3.3.14, use of shared libraries would be an only option.

But of course, in the end it’s up to Apple to define the intention of the agreement.

Cheers,

A: 

Egil, I'm not a lawyer, so I'm not going to get into this any deeper than I have. But you were wondering where the idea that frameworks are prohibited comes from, and that's it, whether that idea is accurate or not. I expect it would come down to a decision on what "other" means in the context of "other frameworks". Given that the app review process for the iPhone store is almost completely opaque, I prefer to stick with things that definitely won't violate the agreement while avoiding those that might or might not do so.

Tom Harrington
A: 

Though dynamic libraries are not allowed, you CAN create a framework (using static libraries and lipo).

Check out: http://accu.org/index.php/journals/1594

jbenet