After updating to Xcode 12.2, my project started failing to compile because of Apple Silicon-related linking errors. I seem to have most of them fixed, but one sub-project that builds a statically-linked framework is giving me problems. And yet a sibling sub-project with apparently identical build settings doesn't.
During linking, I get this warning about the one framework:
ld: warning: ignoring file ...Build/Products/Debug-maccatalyst/TCSiOSC.framework/TCSiOSC, building for Mac Catalyst-x86_64 but attempting to link with file built for Mac Catalyst-arm64
I'm building on an Intel Mac, to boot (so "build active architecture only" is not a factor). I can't find any build setting that would address this problem, and a Web search turns up no hits on this exact error. Any ideas appreciated!
I consulted Apple for this one, and their engineer recommended some things:
Turn any Swift sub-projects into Swift packages, not embedded Xcode projects. So, I deleted one library's Xcode project from the parent project, and dragged its top-level directory into the parent project to include it as a Swift package. Now... this particular sub-project (SQLite.swift) already had a Swift package defined. I haven't generated a Swift package myself before, so I can't help with that. Also, don’t forget to add it to the Frameworks, Libraries, and Embedded Content list on the app’s target.
Go into your project's build settings and delete the "Supported platforms" setting. If you click on the "levels" button above the build-settings list, you can see where each setting is coming from. "Supported platforms" should be non-bold. Highlight the line and press Delete if it's bold. Then go into your target and do the same thing: delete "Supported platforms."
Set the Base SDK at your project (top) level to iOS; this is a must. Delete it from the target level, so it inherits from the project; I don't know if this holds true for multiple kinds of targets or all projects, but it's working for me.
Remove the VALID_ARCHS build setting from all targets, if it's present. That setting is deprecated.
The "build active architecture" setting doesn't make any difference after these changes in my case. The project now builds and runs under Catalyst just fine.
I have the same issue and found this question. In my case, building on Debug succeeds but on Release fails. The reason is exactly the "build active architecture only" option. It is an option can be found in your PROJECT - "Build Setting" Tab then "Architectures" section. There is a setting for "Build active architecture only". By default, the Debug mode it is Yes while Release mode it is no. That caused my build to fail in release.
In order to automize the build process when using a cross platform framework (FUSE). Unless I am wrong, I coudn't find any settings in FUSE to cover this cases so that's why I am trying to set them after FUSE builds and generates the xcode project files.
One of the issues I am facing right now is about the target device and the other one is adding an entry in the build phases.
STEP BY STEP
FUSE build generates the xcode project files including a new xcodeproj file everytime with a different FUSE-XCODE classes mapping so I cannot reuse it from one build to another
I can open the project in xcode IDE
Do some settings manually (target device and add a bundle resource)
Generate a build
Publish it to TestFlight
However, I am trying to make a command line build with the following steps:
FUSE build generates the xcode project files including a new xcodeproj file everytime with a different FUSE-XCODE classes mapping so I cannot reuse it from one build to another
Set the target device and the bundle resorce path by script
Build by xcode command line tools and generate the IPA file
Publish it to TestFlight
I already achieved to writhe the app name, version and build number by PlistBuddy using an script. However I didn't manage to do the same for the target device and adding a bundle resource.
About the device, I wanna set iPhone only:
About the Build Phases, I wanna add a Bundle Resource with the license of one library we use in the project. The license file is in a path belonging to the project.
I am using Carthage dependency manager in my iOS project.
I have the Carthage/build folder in my repository to always have ready to go built frameworks when checking out the repo.
I am wondering what the bcsymbolmap files in the build folder are for. Quite a few of them are created with every carthage update.
Do I need to keep these files? Should I have them in my repository?
No, you don't need those files. If you set up Carthage properly, binary, .dsym and .bcsymbolmap files will be copied on build phase. When you archive the build for distributing using App Store, all needed files will be included in archive and after you upload the build to App Store you will be able to upload dsyms files anytime (to be able to decode your crash reports). If fact you don't need to store .dsyms and .bcsymbolmap files in your repository.
There is a good article explaining what is happening when the framework is being build (and what in fact Carthage scripts do) https://instabug.com/blog/ios-binary-framework/. Also it explains what for .bcsymbolmaps files used for - so Apple servers can rebuild your code using Bitcode and then you can desymbolicate your crash reports.
So, you don't need to keep those files. No need to store them in repository. The other reason not to store content of Build folder is that anyway your project can fail build with it on another machine with different environment. If you want to build your project with the same versions of dependencies - use Carthage bootstrap command instead of update.
P.S.
Also you can investigate what copy-frameworks command do:
https://github.com/Carthage/Carthage/blob/fc0166b4827736bac2c804fc928797f1a742c455/Source/carthage/CopyFrameworks.swift
If you use carthage build without the specification of a project, all
.bcsymbolmaps should be deleted, but if you use e.g. carthage build Alamofire it should just delete the corresponding .bcsymbolmap
From the discussion of a github issue. Looks like you do not need those files, since the default behaviour is to delete them when building a new build.
In general, you should not commit files generated during a local build into your repository, since builds can be device specific, and everyone cloning into or pulling from your repository should be able to perform a build themselves.
Bitcode Symbol Map(BCSymbolMap)
.bcsymbolmap is a textual file with debug information and which is generated for decoding stack trace. Solves same issues as .dSYM[About] but on more low level for and when Bitcode[About] is generated
It looks like:
BCSymbolMap Version: 2.0
__swift_FORCE_LOAD_$_swiftCompatibility50
__swift_FORCE_LOAD_$_swiftCompatibility51
__swift_FORCE_LOAD_$_swiftCompatibilityDynamicReplacements
_$sSo26SCNetworkReachabilityFlagsVMa
_$sSo24SCNetworkReachabilityRefaMa
...
Do I need to keep these files? Should I have them in my repository?
They are optional
When following the apple doco here for archiving an application, i.e. setting "Skip Install build setting" to YES, when I do then go Product->Archive it does not show up in Organizer/Archives.
However if I ignore the doco and leave "Skip Install build setting" as NO, then I do get a resultant archive appearing in Organizer.
Question - What setting should I be using to make sure the archive is good for distribution? If the answer is by setting (ie. "Skip Install build setting" ) it to YES, then how do I get around the fact the archive in this case doesn't appear in Organizer?
You should set the SKIP_INSTALL build setting for all targets in a scheme but your application, i. e. for all dependencies like frameworks and libraries. Don’t set it for the application target itself.
I'm working on an iOS app project, and add the json-framework project to the workspace. The project navigator on the left shows both projects, and the build scheme selector shows the schemes from both projects too. Now I want to add the libjson.a target from the json-framework project as a dependency on the iOS app target in the other project. The expected result is that whenever the app target is built, it builds (if necessary) the library target and links the app target against it. Here are the ways I've tried to do this:
Build both as part of the same scheme. The way I try this is to edit the scheme for my app, adding 'libjson.a' to the 'Build' portion of the scheme, and by the way "Find Implicit Dependencies" is checked. Then I go to the target editor for my app target, and in "Build Phases"->"Link Binary With Libraries", I choose 'libjson.a' from the list of workspace libraries.
When I subsequently try to build the scheme, I see it build the library target, but building the app target fails with linker error "Library not found for -ljson" - suggesting that it hasn't actually discovered that the library has been built. Indeed in the project navigator, the entry under the app project for the library is still red indicating that the file doesn't exist.
Add the json target as an explicit dependency. To try this, I don't modify the build scheme, but go to the target editor for my app target and click the add button under 'Target Dependencies'. No targets from other projects in the workspace show up, so this is a non-starter.
Drag the JSON project into the other project, then add the target as a dependency. This is what I would have done in Xcode 3. In the project navigator, I grab the library project and drag it over the app project. This brings up the usual 'add files' pane, which I just dismiss by clicking 'Finish'.
There are now two entries for the library project in the project navigator: one at the top level, and one under the app project. I can now add the library target as a dependency of the app target using the target editor, and can link against it without error in the link libraries phase. But it looks broken: there are multiple entries for the same project in the navigator. Is there a different way to do this?
What should be considered the "Xcode 4-ish" way of connecting these targets in different projects in the same workspace? It would seem lacking if multiple projects in the same workspace can't actually interact with each other.
Thanks,
Graham.
I’ve just set a test project up, pretty much as you describe in version 3, by creating a new workspace and dragging the two Xcode project into it, nested as shown.
You can delete the sibling project if you have it already.
Hitting build on this and it just works, as far as I can see.
I imagine there is internal path-confusion if you have two projects, and I’d be inclined to fiddle with location settings in "View"->"Utilities"->"File Inspector" and see what effect that has.
Another thing to try is to set your paths up in Xcode "Preferences…"->"Source Trees" and refer to them that way, as described here: Easy, Modular Code Sharing Across iPhone Apps: Static Libraries and Cross-Project References
HTH. Andy W.
I managed to get dependencies between projects in a workspace to work as I described here: http://blog.carbonfive.com/2011/04/04/using-open-source-static-libraries-in-xcode-4/.
Unfortunately I can't find a way to get Xcode to discover implicit dependencies or index everything in the build as advertised. I found workaround to both but I'm hoping that less manual configuration will be needed as Xcode 4 matures.
I was going to ask the same question, thinking that my own solution couldn't be right. But I don't see it mentioned here, and it does seem to work. Clearly XCode 4 is a work in progress. :)
I have a workspace with two projects: a static library and an app which uses the library. The projects are siblings. Each project has its own scheme, and each scheme is set to only build one target. In other words, I added two projects to the workspace and that's it.
To add the static library as a dependency of the app, I just drag the libsomething.a product from the library project (Project Navigator) into the "Link Binary with Libraries" list for the app target. That's it. Now when I build the app the library project is built first and then linked. Interestingly, when I modify the app's scheme to use a different configuration (eg, Release instead of Debug), the library is built using the same configuration.
So it works, and there is clearly some automatic dependency checking going on here. But it feels wrong. Then again, so does the modal scheme editor/manager and lack of a workspace object in the project navigator... I never thought I'd say it, but the Visual Studio UI (bleh) is a lot clearer.
My bullet-proof solution to do this :
Create "Per Debug-Release / Per Architecture" settings in Build Settings in the Main project (not the lib), to include either
../MyLibProject/build/Debug-iphoneos
or
../MyLibProject/build/Release-iphonesimulator
or
etc..
depending on the configuration (you can create those kind of configuration by clicking on the + next to Debug or Release and choose either "Any iOS Simulator SDK" or "any iOS SDK".
You need to do that for both "Header Search Path" (in case your library copy some headers files, which is more than likely) AND for "Library Search Paths". Which means that for each setting, you'll probably end-up with 4 different paths (debug sim , debug ios, release sim, release ios).
That would make sure the configuration of both projects match.
Now, to auto-compile the lib, that is to create the dependency, you can use the "Build Phase -> Link to Binary With Libraries -> + -> select the .a file" advice given above.
That's the only way I managed to have something that builds and link correctly for every environment on xcode 4.5
Note : I even added the -lmyLib flag in "other linker flags", but i'm not sure that's really necessary
I've had some success with creating framework-like static libraries, though it's not a perfect solution.
I see the next variants:
Explicit dependency in a project[About]
Implicit dependency in a workspace[About]
See the Xcode user guide: Xcode Concepts -> Xcode workspace under 'Projects in a Workspace Share a Build Directory'.
All projects in a single workspace share a build directory. Dependencies are discovered automatically and build if needed:
"Xcode examines the files in the build directory to discover implicit dependencies. For example, if one project included in a workspace builds a library that is linked against by another project in the same workspace, Xcode automatically builds the library before building the other project, even if the build configuration does not make this dependency explicit. You can override such implicit dependencies with explicit build settings if necessary. For explicit dependencies, you must create project references."