Using Xcode Build to build a framework, mach-o binary and a package separately

Developer Tools & Services Xcode
abhi_mohata OP
Created 2w
Replies 3
Boosts 1
Views 205
Participants 2

I am building an interactive application. My application architecture looks like this:

  1. There will be a LoaderBinary that will load 1 or more shared libraries (.framework in this case). This is also where the entry point from an OS perspective lies.
  2. There will be 1 or more frameworks built. This framework is expected to have large part of my logic as shared code so that multiple flows like the application flow, widget, notifications etc can reuse code by loading this framework itself.

Now, I want to achieve the following:

  1. Building a framework independently - I believe this is doable and works fine too.
  2. Building a mach-o binary - This is what we are not clear if it is allowed or not to build just a mach-o binary ? Yes, there is an option to build a command-line tool but as this is an interactive binary, what should be the path to take ?
  3. Building a macOS bundle (.app) using 1 and 2 - Now, as I have a PRE-BUILT framework and a PRE-BUILT mach-o binary, can I create a application bundle using these ?

Some directions here will help to take this forward - in alignment with both my architecture as well as how Apple Build system works.

Thanks!

Replies  3
Boosts  1
Views  205
Participants  2
DTS Engineer OP
Apple
2w

The setup you’re proposing is probably feasible but I’d definitely considering it to be ‘fighting the framework’ (well, fighting the developer tool). Is there a specific reason you need to build the app’s executable separately from the app bundle? Why not build the executable from source? That is, merge steps 2 and 3?

That’s how most Xcode projects work and it’s very much the well trodden path. And that means that certain Xcode functionality expects things to work this way. For example, if you tried to do this by creating a generic bundle target and placing your pre-built executable in that bundle, you’ll miss out on a bunch of cool app-specific functionality, most notable the stuff in the Signing & Capabilities editor.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
abhi_mohata OP
5d

Thanks Quinn. The response helps.

Apologies for the delay in reverting here.

I do understand that merging step 2 and 3 would have been better. We are moving to that approach so that we are not fighting against the tool's natural framework.

However, you did mention above that what I originally wanted to do is probably possible. Would help if you can let me know, how ? and if there is some material that I can refer to for the same. This will help in understanding the rationales better.

DTS Engineer OP
Apple
3d
Apologies for the delay in reverting here.

No worries. I had plenty of other things to do (-:

you did mention above that what I originally wanted to do is probably possible.

Possible, but it has significant caveats.

In an Xcode project, each target has a built-in target type. Xcode customises its options based on that target type. For example, if you create a target from the macOS > App template, Xcode knows that that target builds an app and thus customises its UI to show all the stuff relevant to an app.

Consider this:

  1. In Xcode, choose File > New > Project and select the Other > Empty template.
  2. Choose File > New > Target and choose the macOS > App template.
  3. Choose File > New > Target again, but this time choose the macOS > Command Line Tool template.
  4. In the project editor, select one of those targets and switch to the Signing & Capabilities tab.
  5. Click the add (+) button and scroll through the list of capabilities.
  6. Now select the other target and do the same. You’ll see that the app target shows many more capabilities than the tool target.
  7. And look at the list of tabs at the top of the editor. The app target has an Info tab, whereas the tool target does not.

So, the only way to take advantage of all the Xcode smarts is to start with an app target. And keep in mind that the above is just an example. Xcode has a lot more app-specific smarts that I’ve not highlighted (and there’s probably even more than I don’t even know about).

So you could probably get what you want by choosing some other target type — like a generic bundle, or the Other > External Build System template — but that comes at the cost of losing all of the app-specific smarts. Is that worth it? It’s hard to say.

The other option is to try to use an app target but convince Xcode to use your pre-built executable rather than the one that it’s compiling and linking. However, I don’t think that’ll actually work. Within a target, Xcode has its own idea of how to build any given file. For an app target, it expects to compile source code and link it together to build the app’s main executable. You might be able to subvert that in some way, but I’m not aware of any good option to do that.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Using Xcode Build to build a framework, mach-o binary and a package separately
First post date Last post date
 
 
Q