Sign in

As commits keep piling up, and last minute fixes come in, its easy to forget to do a final run through of the app. Getting in the habit of posting a video after your last commit is valuable, for catching bugs when you are in the zone, instead of getting interrupted by QA or user complaints when you have competiting priorities.

2. When you open the app, you will see something like this. The green portion is the recording zone. When you click the red circle,

These are the peskiest merge conflicts. After spending days on resolving the same merge conflict, it makes you wonder whether it would be easier to copy and paste files.

Alternatively many people suggest prevention, and that you basically change your daily habits so as to avoid these conflicts. They encourage commiting changes and pulling frequently. While this is not a bad idea, it isn’t a guide on how to deal with merge conflicts when they happen and it isn’t great advice after the fact as well.

Here are the tricks I use to make resolving pbxproj conflicts as smoothly as…

git checkout develop
git pull upstream develop --rebase
git checkout -b yourBranch
git push upstream yourBranch
git branch -u upstream/yourBranch yourBranchgit rebase develop

Before you push

git rebase develop

You should pull the latest develop into your branch before merging, so that you can create a merge commit which will run the latest develop ci functionality in your pr as well.

Scroll Views are important for dynamic text and should probably be the container for every view controller in your app because of it. This tutorial teaches you how to create a scroll view in interface builder so you can get visual feedback while you design your constraints.

2. Open Storyboard.

1. clone the shared repo, in this case: (<Organization>/<project>)

git clone <sharedRepo.git>

If you run


You should see it in your current local directory.

2. create a fork from the shared repo, in this case: (<Organization>/<project>) into your personal github, for example: (<yourName>/<project>)

3. now we make sure the local/cloned repo is pointing correctly.

git remote -v
git remote rename origin upstream
git remote add origin <yourFork.git>

4. Create your local develop tracking branch:

git checkout -b develop upstream/develop

The branch develop must already be in the shared remote, if it isn’t you can add it via github website by first searching for it, and when it isn’t found, an option to add develop will be provided.

5. Create your feature branch and start working:

git checkout -b develop_myFeature upstream/develop

We have @State, @StateObject, @EnvironmentObject, @ObservedObject, @ObservableObject, @Published. @Binding

First I recommend Checking out Data Essentials in SwiftUI WWDC.

3 key questions for a new view:


When the view doesn’t change the value nor have power to, then use let alone without property wrappers. The data will come from the superview somewhere higher up the view hierarchy.


When the view can change the value. When the value isn’t passed in as a reference. Should usually be…

How to beat Sibo

- Kambo

- Candidate popper before bed

- Spinach salad with strawberries and goat cheese vinegrette before bed

Difficulties with @Binding:

Take the following struct:

Looks normal right?

If I pass this as a Binding, the formModel, employeeDestination, authViewModel will not update properly with the binding.

Well we could do this and it will work but…

Its misleading. It will give you the freedom to assign a value to each of these variables, but it won’t actually assign a value to them. Not only that, I can’t say its very clean or swifty…

Your file structure may look similar to this:


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