Carthage and nested frameworks


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:

  1. Scheme is shared.
  2. testability set to YES under build settings.
  3. Build settings -> Framework search paths set to: $(SRCROOT)/Carthage/Build (Carthage generates aliases in this folder) aka magic portals to other frameworks.
  4. .gitignore that excludes .framework files and other binaries (We should never have bins in repos)

1. The Automated workflow:

  1. Create a repo on github named “A” (this will be the child)
  2. Create a repo on github named “B” (this will be the parent to the child)
  3. In repo “B” add a Cartfile with github "eonist/A" "master" 👈 Informs carthage to build this before anything else
  4. On your local machine create a Cartfile and add github "eonist/B" "master"
  5. In terminal carthage update Now everything will download and be built in the right order. Children first 🔑
  6. Drag and drop the .frameworks located in Carthage/Build/<Platform>/

2. The Manual workflow:

  1. include all the repos you want to use in a cartfile on your local machine
  2. In terminal Do carthage update --no-build (this downloads all repos but skips building)
  3. Then do carthage build for each child dependency starting with the farthest descendants
  4. When you have built your last item drag and drop the .frameworks located in Carthage/Build/<Platform>/

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 Carthage/Build/<Platform>/

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.

Final notes:

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. 👈

Further discussions:

Advance nesting does and donts: https://github.com/Carthage/Carthage/issues/768

Related Posts

Startup Oslo

“Kulturhuset” is a new place in the startup scene in Oslo. It’s “free” and can be used by anyone to collaborate or work on different projects.

Infinite Tree List

My notes on Infinite tree list

Protocol Inheritance

My notes on Protocol Inheritance

Protocol Ambiguity

How to differentiate protocol ambiguity

The Ultimate Xcode Workflow

Spend zero time managing dependencies

Faster Xcode With Spm

How you can speed up compile times in XCode with Swift Package Manager

Spm And Ci Travis

My notes on Swift PM + CI Travis

Spm And Nested Frameworks

My notes on Swift package manager + XCode + Nested frameworks

Xcode And Spm

Here is how you use Swift package manager in your XCode app projects

Two Finger Swipe

Notes on implementing two finger swipe for macOS