A few workflows concerning Carthage and nested framework
⚠️PRE-REQUISITES:⚠️️ In your github repo you need to include .xcodeproj file with framework settings all setup. The settings should also include:
- Scheme is shared.
- testability set to YES under build settings.
- Build settings -> Framework search paths set to:
$(SRCROOT)/Carthage/Build(Carthage generates aliases in this folder) aka magic portals to other frameworks.
.gitignorethat excludes .framework files and other binaries (We should never have bins in repos)
1. The Automated workflow:
- Create a repo on github named “A” (this will be the child)
- Create a repo on github named “B” (this will be the parent to the child)
- In repo “B” add a Cartfile with
github "eonist/A" "master"👈 Informs carthage to build this before anything else
- On your local machine create a Cartfile and add
github "eonist/B" "master"
- In terminal
carthage updateNow everything will download and be built in the right order. Children first 🔑
- Drag and drop the .frameworks located in
2. The Manual workflow:
- include all the repos you want to use in a cartfile on your local machine
- In terminal Do
carthage update --no-build(this downloads all repos but skips building)
- Then do carthage build
for each child dependency starting with the farthest descendants
- When you have built your last item drag and drop the .frameworks located in
3. Downloading prebuilt .framework files
If project owners include .framework files in their releases. (Some do, some don’t) then using
carthage update --no-build And the binaries will be placed in
4. Using submodules:
Don’t do it, Google it if your not familiar with why you shouldn’t use submodules for nesting dependencies or just read this article https://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/ or this That being said. Projects such as AlamoFireObjectMapper project do use submodules in conjunction with Carthage framework nesting.
Which workflow is better? The future is automated so go with option 1. Also you need something that can work in a CI environment. The first workflow has a bit more bloat attached and carthage could have avoided this by allowing order take priority when building. (Feature request!!!) 👉 The optional workflows are written down in order to justify the extra contextual files one has to place in sub dependencies. 👈
Advance nesting does and don’t’s: https://github.com/Carthage/Carthage/issues/768