The #1 argument against using storyboards in your project most likely is:
Merging storyboards is hell
Well, that’s pretty much true. Fortunately there is an easy way to reduce the possible conflicts in merging. Rule number one is:
Keep storyboards small.
This approach has several advantages:
- You will lower the chance of two developers editing the same file
- Smaller storyboards are more descriptive and provide the app(module) navigation at glance
- Speeds up compile time
To make it happen, you should make use of external Storyboard References. If you can’t use them because you are still supporting iOS7, then… STOP and raise your deployment target! I mean…seriously, iOS10 out there already!. It’s time to move on.
But even with small storyboards conflicts do happen. Here is a list of possible steps to resolve them in no-time.
So your version control system reported a conflict in storyboard file.
You resolve conflicts in merge tool. And then when you try to open storyboard file you notice this error:
The document “Main.storyboard” could not be opened. The operation couldn’t be completed. (com.apple.InterfaceBuilder error -1.)
The build is failing too. Oh noz!
There is no silver bullet for this, but I’d recommend following things.
Check XML validity
Since storyboard are just hugeass XML files you can use various tools to check if the syntax is valid.
You could use builtin command line tool
Check for obvious confilicts
Sometimes the conflicts are quite easy to solve like:
- canvasLocation is the location of given scene inside the storyboard canvas. Most of the times pretty irrelevant
- simultaneous custom font usage entry:
That is also quite irrelevant from my experience and you can resolve this anyway you want
- true confilcts — so the situations when two or more people edited for example the constraint constant value. Well.. just talk to other team members;)
Very often the source of the conflict is the last section of the storyboard file — node called inferredMetricsTieBreakers. It’s quite hard to pick the correct version of it since it’s just a list of segues’ identifiers. When you notice conflicts there or you cannot open the storyboard file, have no fear. Remove all the entries in inferredMetricsTieBreakers and let IB regenerate them (by reopening the storyboard file).
What are inferredMetricsTieBreakers?
They are references to the segues used to break the tie when multiple segues infer conflicting simulated metrics. It happens when multiple segues point towards single VC from different places. They are autogenerated by Interface Builder and most of the time you can not worry about them.
Hopefully these tips will save you some time. I also hope that Apple improved IB in Xcode8 to make it produce less conflicts by itself.
We’ll see what time will tell…