On 16 Oct 2015, at 16:33, Bill Cheeseman < email@hidden> wrote:
However, when a framwork isn't finished or isn't fully tested, it makes sense to place the framework project and the application project in a single workspace so you can edit, debug and build both of them together. It is very helpful to be able to single-step from application code into framework code and back out again. That's what I'm doing now.
It’s very easy in these email discussions to be at cross-purposes, so let me check that we’re on the same wavelength. My setup looks like this:
Workspace App project main app target other targets Framework-1 project main fw-1 target other targets Framework-2 project main fw-2 target other targets and so on…
Is this what you’re doing or is it something different?
In my experiment, I select the “main fw-1” target, and in its build settings, under “Packaging”, there is “Framework version”, which defaults to “A”. If I change that to (say) “M”, and rebuild, Xcode generates a new version “M”, merges it into the f/w bundle and the whole thing gets copied to the app’s bundle eventually (via a step in the app’s target’s build phases.) For release builds, it’s version ‘M’ that is signed (you can see it in the build transcript). Does it not do that for you?
One thing I noticed is that with the above steps, Xcode doesn’t update the “Current” symlink in the framework bundle. That still points to the older version, so if you were now to sign the built f/w from the CLI, it would sign the old version, not the new one (ie ‘A’ and not ‘M’ in the above example).
|