How to reliably run an iOS app with a ton of internal and external dependencies.

Whenever setting up local pods.

  1. Go to the podfile and point to local pods.
  2. Then manually go to all podspecs and point to local…

Or…Maybe all I need to do is point to the local pod that I am working on…


When to Rebase:

When you notice there is a conflict

You could git pull and resolve the conflict, but then your commits will be in weird places, or you will litter the commit history with one commit that will be a “Merge commit” which is kind of sketchy.

It is better to do a rebase:

This puts your commits in a bucket, stacks the latest commits onto the commit history, and then applies your commits one by one, only stopping if there is a merge conflict. if there is and you want to keep both changes, resolve them in code and then

or remove the file:

DO NOT make other changes! Do not stash, do not commit. Only do this:

If you mess up something or want to start over,

It will be done when no more conflicts are shown.

So you work at a big company that has many dependencies (cocoa-pods for our purposes), and merely running the app is a major pain. Your a smart dude/dude-t, but this isn’t like starting a new project and running the app. Variables can’t be found, derived data issues, mach-0-linker failures, etc. etc. etc.

Have no fear my dude. I have provided all the tricks I use to ensure I can run the app 99.99% of the time.

If you have a weird commit that shouldn’t be there, do this:



git checkout . Undoes unstaged local modifications.

git branch Tells you what branch you’re on.

git checkout develop Switches to the develop branch.

git remote -v Checks what upstream and origin are.

git pull upstream develop Pulls from upstream repo, develop branch.

  • If that produced:

git status See what the recent changes are.

git reset HEAD --hard Undoes staged local modifications by pointing to the head or the last commit.

git status Checks that it works.

git log Shows the commit history

git reset HEAD~1 — hard Removes last commit

git log Shows commit history

git pull upstream develop pulls from upstream repo, develop branch

pod repo update updates the spec repos located at ~/.cocoapods/repos in your home folder in case there are new .podspecs or in case the .podspecs changed.

bundle exec pod install

  • Note: It is necessary to use bundle exec to run pod install so that it uses the version of CocoaPods which is set in Gemfile.lock after running bundle install


  • look at the errors, if they mention anything about derived data ANYWHERE. Try this:

Then click OPTION and you will see the values change.

Then select Clean build Folder

I recommend cleaning your derived data this way:

Close your project.

Click on Preferences
Then Locations
Then the white arrow in the gray circle
Then drag that file to the trash. If you left your project open, then it will respawn immediately after you throw it away.

Then run your project.

if you get this try the above steps to clear the cache, AND remove the framework from the linked libraries list. This might not even show up if you search.

If you get the Apple Mach Linker error you can run

Try cleaning like above.

run pod repo update if you haven’t already. Run it your app! fingers crossed.

If everything is failing, then you could try

Then start over. Also you should be pulling from your remote regularly to stay up to date. Keep going through the next options if that didn’t work.

If that didn’t work…

cd to your project first.

If that didn’t work…

It says we don’t have .numberPadStyle. But its there in the remote!

Now click "t"

Now we can search for the file that could have the enum case we are looking for.

Then you can command f and find the case you’re looking for. Woa. Here it is.

This means we need some cleanup of those pods:

That should do the trick!

One of the reasons I have trouble learning git, is because git command explanations lack relatable context. Learning material usually explains a command by saying, “this is what the command does” not “this is a command you can use in x scenario.”

This article will be disjointed blurbs of context -> git command -> what it does. Its really my personal notes/journal on git that I’m making public.

I think fruitful learning requires having some idea as to where to put the knowledge. If I don’t have context for when to use a git command, my brain will give up on trying to figure out where to store it.


So you get back to your computer and you want to work on a bug in the code. You want to plan ahead and make sure you don’t commit random things you staged yesterday, when you are going to make a push.

If you don’t care about the changes: git checkout . this takes everything back to how it was at the last commit.

git push fork branch

git push origin bugfix-62830


You want to ensure that you safely push to the right place. So you can make your push command more specific than simply git push.

git push fork branch


git push origin bugfix-62830


Lets say you encounter a merge conflict from a PR due to unintended changes accidentally made in your commit. You can see these changes by going to your pull request in GitHub, then clicking “Files changed.

You would like to fix the problem so you execute the following commands.

So you check which branch you’re on.

git branch

Then you switch to the local branch which mirrors the remote branch that has merge conflict PR (pull request).

git checkout <branch>

You would like to check that the local commit history matches the remote commit history.

git log

You notice the local commit history for this branch is different from the commit history for your fork, so you run:

You want the changes in your remote, so this would get you back to that commit.

git reset —-hard origin/<branch>

To double check, you run:

git log

So lets say you made a commit on your develop branch and you forgot and when you tried to pull you encounter merge conflicts. If you want to pull from the central repo of your team, the develop branch, and if there is any merge conflicts you prefer not to see them scattered disparately throughout your project, but instead one at a time to be addressed (this is much easier to work with) run:


You would like to work on your team’s latest code.

  • Lets say, before merging your pr you notice that you will not be able to due to a merge conflict. This means you have to bring in the latest code and resolve the conflicts. The best way is to do: which will pull in the code and overlay your commits over it one at a time.

git pull --rebase upstream develop

Lets say you want to see what files you have been working on since the last commit and whether or not each file is staged. The green ones are staged, the red ones are not. You can easily copy the file path names from this.

git status

Lets say you messed up with a previous commit and so you ran git pull — rebase upstream develop. You committed something you didn’t want to commit, or the rebase process is taking super long and you want to start from scratch tomorrow, you can run the following command.

git rebase --abort

We want to reset the pointer (HEAD) to just before the bad commit, in order to find that we run:

git log

We grab the commit hash that displays just prior to the commit which we want to point away from. And then we want to point the HEAD to that commit.

git reset --hard <pasteCommmitHashHere>

Now you are in the right place to get coding. After making your changes, you would like to see the difference you have made.

git diff

You decide you are happy with those changes, so now you would like to add/stage your changes to be committed. You don’t want to add changes accidentally made to other parts of the code which are not in focus, so you provide the file path when you add it:

git add <projectName>/<fileThatYouchanged>

After committing the change:

git commit -m "<your commit notes>"

You would like to make sure your commit was added to the history in the way you liked.

git log

You would like to make sure the correct changes are present in the correct commit.

git whatchanged -p

You like what you see so you want to send the correct changes to your remote fork, in anticipation of updating your problematic PR with the correct change. You tried git push origin <yourbranch>, but it failed because its telling you the tip of your current branch is behind its remote counterpart. You know that you diverged from the remote branches history when you ran git reset --hard <commitHash> but you also are confident that you want the most recent commit you made should override the remote commit in places where both differ.

git push origin <branchName> --force

Origin refers to your fork. --force ensures the push is successful, and in order to do that it chooses to let your local branch override the remote branch in places where they differ.


Lets say you are working on a team and your project is FDMized and otherwise fairly modular. Each module needs to use a specific pod version. Each module holds a gemfile which specifies which pod version to use.

bundle exec pod install


Lets say you want to see where all your branches are remotely pointing to. you can run:

git branch --v


You want to update the code in your forked repository with the latest code from an upstream (remote aka shared team repo).


If you notice yoru project isn’t finding a lot of pods.

Can’t find this pod and that pod x50, means you had stale pods, the chances of someone making a pr and

There is more issue with your local workspace where you are trying to reference your pods.

If there is maybe one or two pods it might have been a commit that was merged that shouldn’t have been merged. But if you are seeing over 20 pods not being found then you have stale pods. Which really means that you probably have pods that are still in your workspace from a previous pod install and the purpose of pod install is to check the necessary dependencies that should be downloaded, and based on the current state of the app which libraries and binaries should I pull in, though yesterday that might have been differ, if you are in a state where you might have older versions of those pods in your workspace and you run the pod install command, maybe there is a chance that you will see those pod versions and it will say, Oh you already have them, I won’t install them again, the pod install command might not be able to differentiate between the older version and the newer version, and so you are missing the latest changes, where in the older version they might not have had certain objects, so when you try to run the app it will say cannot find that object.

Go to your develop branch, then…

git remote -v

then pull…

git pull upstream develop --rebase

If that is causing issues like the following:

Then you can run git rebase --continue

If that doesn’t work and you are not interested in merging in the changes and you want your code to reflect the latest, you can fetch the latest from the corresponding branch, then have your head point to it. by doing the following:

git fetch upstream develop

git reset — hard upstream/develop

What do you make of the slash? Different commands have different syntax. so upstream develop is the same thing as upstream/develop. Each command has a list of paramters they can take, some might have their parameters separated by spaces and some by forward slashes.

You might want to push the latest to your fork, assuming origin is your fork:

git push origin develop

then clean your targets

xcodebuild -alltargets clean

clear your cocoapods caches

rm -rf ~/Library/Caches/CocoaPods/

remove your pods

rm -rf Pods

update your repo

pod repo update

or bundle exec pod repo update if you have gem files.

install your pods again! yay.

pod install

or bundle exec pod install if you have gem files.

Hopefully it runs.

If not try this:

If all else fails, I would like to introduce to you the ultimate pod nuke



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store