Do I need bcsymbolmap files created by Carthage - xcode

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

Related

Swift Package Manager - How to add checkouts to source control? [duplicate]

I started using new Xcode 11 which integrates SPM.
I added first dependency to my project:
but detected that files are not fetched into my project folder but into Xcode's cache:
I would like to commit all my dependencies files into my main project repository so my question is:
Is it possible to change location of fetched packages via SPM using Xcode 11?
It's somewhat possible, although the solution isn't necessarily a good or great practice, so I can't recommend.
Set the DerivedData in workspace settings to be relative to the workspace.
Add gitignore rules such that the workspace/WORKSPACE_NAME_DIR/SourcePackages/checkouts and related files are includes. Maybe best to ensure repositories directory is not included.
Add a Run Script phase to remove .git and .gitignore files in the checkouts directory.
Obviously, this is fragile largely through fighting the way SPM works. The workspace settings are per person so it's not great in teams.
SwiftPM integration has been setup to prevent this. It clones the files into a DerivedData/ProjectName-[RandomStuff]. You should commit your Package.resolved into the repo to ensure that you get the same version of each dependency across clones of the project.

Is it possible to include SPM checkouts in Git?

It's possible to store Checkout and Build directories when using CocoaPods and Carthage.
Is this possible using Xcode 11's SPM?
Or, if I could modify the location SPM uses for Checkouts, then I think this could work by setting this directory to somewhere in the workspace's directory structure.
(I'm in the camp that prefers to keep all assets required to build projects in the same Git repo as the project itself. Don't hate me :) )
You can't do this.
See my previous response to this question here.

How to really work in team on React Native project?

How do you work in team on react native projects?
I'm working in Team of 2 people and having a lot of issues with working on the same project.
I don't understand how to properly create an environment so we can sync our code between each other while working on the same project. Now, we create a git repo with /ios and /android folders, but the thing is: the /ios folder always needs to be changed, because it links to the computer that was last building the project.
For example: we are working at the same time on different .js files and add a new npm dependency and we wish to sync our changes, so we commit changes to the Git repo and try to sync, this is where our pains begin.
The one need downloading the changed has to go to Xcode and manually update all the Framework Search Paths, Header Search Paths, delete libraries that Xcode doesn't see and then add them again.
I know it's moreof an Xcode problem, but I didn't see any detailed guide about team syncing in projects. I know that at Facebook people are doing a lot of cooperative work and I'd appreciate some input over our issues!
If you are using git, you can configure your .gitignore-file to prevent committing xcode-specific stuff and other configuration files.
I can highly recommend gitignore.io, which is a "web service designed to help you create .gitignore files for your Git repositories" [Source].
You can for example type in XCode (or AndroidStudio, ReactNative, Gradle, etc.) and it will automagically generate a .gitignore file for you.

Gradle incremental on different machines

We have multiple GitLab runners on different machines.
We broke our pipeline in multiple steps that are dependent and I see that gradle doesn't run incrementally.
For example, we have build apk and upload apk to hockeyapp. We always copy apk output from one step to another. However gradle still start building apk from scratch because upload needs it.
How can I troubleshoot it?
What folders to copy to make sure gradle runs incrementally?
We are on Gradle 4.x (4.1 and moving to 4.2)
I don't think you should do this. You would probably need to copy over the .gradle directory from the root project, but I'm not sure this works too well and as expected. I guess you should instead use the new Build Cache which sounds like being exactly what you need in your situation and is an official feature and does not involve some unsupported copying-around of build metadata.

Unable to both Archive and run in debug with framework project dependency in xcode5 workspace

I've got a workspace containing an iOS app project, which is dependent on another framework project, also in the workspace. I ran into issues with Archive while building for distribution, where the resulting output was unusable for creating an .ipa. Googling turned up this solution, where you delete the Copy Headers phase from the framework project, and which worked for getting the Archive exported and submitted, but now when I go back to running the app project in debug, I'm failing builds due to missing header files from the framework project again. So, what is the proper way to configure everything so I can both archive and run in debug without having to go through all this nonsense? I mean really, I'd think this would be pretty typical.
I ended up replacing the previously deleted Copy Headers phase within the framework project, with a Copy Files phase, and that did the trick.

Resources