User Profile

TLDR: Adding the Facebook SDK to a fresh, empty Xcode project yields an executable that links to AdSupport. Q: Can I prevent this? This happens without importing or using the SDK. The mere presence of the dependency (via SPM) in an otherwise empty app triggers the inclusion of AdSupport.framework in the executable, as confirmed by nm and otool. The phrase "Facebook SDK does not require AdSupport.framework to be included." appears in lots of searches, but is never accompanied with an explanation of how to exclude the framework. This is also a question for a Facebook forum, but I am posting it here as a question about build tools: Apart from downloading the SDK source and painstakingly commenting out the transitive closure of all references to AdSupport, ASIdentifierManager, and IDFA, are there any compile/link directives that could stop the inclusion of the forbidden fruit?

Bear with me, this sounds like an FAQ but my specific situation is a little less frequent.I am working on an architecture in which I have the same "front-end" (entrypoint Storyboard, `AppDelegate`, top-level `ViewController`, Launch Storyboard, Info.plist, sound & image resources) for multiple apps. That is, I "append" the app-specific code to the common front-end.So the question is: how best to manage independent development of the front-end and the multiple back-ends. Including SCM. Some ideas:Libraries, static or dynamic - a non-starter because the common code-base includes Storyboards and assets.Completely separate projects, with the individualized apps including (by reference) the common code.Single project, separate targets.Separate sub-projects in a single Xcode Project.Separate projects inside a single Xcode Workspace.One criterion would be how well Xcode and Git[Hub] deal with the separation of code bases. I have had mixed results with Xcode getting out of sync with git. Advice welcome. I've been cut&pasting the common code into separate projects, but you can easily see how this is not sustainable.Addendum: I have read the ongoing discussion about Apple Guideline 4.3 (https://forums.developer.apple.com/thread/85411); it does have some relevance.

The goal: To revert to a shared main storyboard for two targets.The symptom: Outlets don't seem to connect. (KVC-compliance complaint.)Already tried: Deleting the app from the deviceDoing a clean buildDisconnecting and reconnecting offending outletRenaming the offending outlet (in both source code and Storyboard)Poking around the Storyboard XML (all looks as expected)Creating an entirely new target, setting Build Settings, like paths, etc.I inherited a project with two targets, each with its own Storyboard. The targets share the exact same code. The second target's Storyboard was cloned from the first target's. And its differences are minimal: mainly differing background images. All outlets in both Storyboards go to the same ivar in code. (AFAIK)Now, the first naïve step is to merely tell the second target to use the first target's main Storyboard. That happens in Targets > General > Deployment Info. (Or in the app's plist file, for hackers.) The appropriate Storyboard is being copied in the second target's Copy Bundle Resources build phase.However when the app runs, while loading the home view, we crash with NSUnknownKeyException. (I.e. "this class is not key-value compliant for <myOutletName>".) For an outlet that is properly connected in both Storyboards. (To the same ivar of course.) I can verify this in both the InterfaceBuilder GUI and by direct examination of the Storyboard XML. \Insert here: all the "Already tried" tactics cited above. Result is always the same: KVC complaint about outlet that is properly connected.This should work. The runtime connecting of outlets to their referents is purely text-based. I have pored over the raw Project file and the raw Storyboard, and all seems in order. What gives?