getting merge conflicts with inferredMetricsTieBreakers in Storyboard file

Question

Whenever I get a conflict in a storyboard file, I can usually resolve it. However, I have an issue that has now come up twice in two weeks.

At the very bottom of my Storyboard file, I see block named "inferredMetricsTieBreakers", with bunch of "segue" tags contained within. It seems that some segue in my local repo is conflicted with another segue in the remote repo. To be safe, I could just "choose both". But since this happened once before, I'm afraid that it will keep happening, and eventually have a long list of these segue references at the end of my storyboard file.

Just wondering if anyone is that intimately knowledgeable about these tags in the file, or whether I should just blindly continue to just "choose both" and ignore the issue.

Thanks, -Dan.

Answer 1

Same thing going on here. Got errors in my storyboard file after using your "choose both" method. Found that searching the storyboard for the segue references resulted in one segue that was mentioned inside the inferredMetricsTieBreakers section. Removing the segue from the list solved my breaking build.

To try and find out what this inferredMetricsTieBreakers does, I tried removing the whole section first. Breaking my build. Next I removed all the items. During the build, Xcode added 2 new and different segues to my list (before the merge I had 3). The application I'm building is working fine.

My conclusion: it's safe to remove all the items and perform a clean build. This will keep your storyboard clean.

Answer 2

Each view controller in a storyboard has "Simulated Metrics" which you can see in the attributes inspector:

Some of these metrics are inferred (thus, inferred metrics).

As mentioned by @thesystem, if a given view controller is the destination of multiple segues, there could be differences between the simulated metrics of the source view controllers of the segues. To address these differences IB picks a segue to break the tie when resolving the inferred metrics for the destination view controller.

@rick-pastoor's conclusion that it's safe to remove the entire inferredMetricsTieBreakers section is correct in that IB can just choose different tie-breaking segues. However, there is no guarantee that the new tie-breakers will lead to the same layout results in IB.*

For example, I had a situation in which, depending on the tie-breaking segue, a view controller was shown in IB either with or without a status bar. Its view maintained a height of 568pts in both cases, such that the position of the top layout guide kept changing. This snowballed into other undesired (and largely meaningless) changes to the frames of views constrained to the top layout guide.

Based on these observations, choosing both the new and old sets of inferred metrics is not advisable. Instead, remove both sets and then open the storyboard in IB to allow the ties to be broken before committing the merge. To avoid undesired frame changes due to a change in tie-breaking segue, pick some value other than "Inferred" for the relevant simulated metrics of the destination view controller. This will ensure that IB generates a consistent layout result.

* The results at runtime should be the same unless there is any logic that relies on the initial layout immediately after the view is unarchived.

Answer 3

It looks like, the tie breakers occur when in the storyboard one view controller is connected from two or more other view controllers via segues and its simulated metrics setting is set to "inferred" but Xcode cannot make sure that inferred means exactly one metrics setting (landscape or portrait) in every case.

I fixed it by changing all controllers simulated metrics to "inferred" and all metrics are inferred from a controller that has fixed simulated metrics setting "landscape". After that I removed the tie breaker segue ids from the section (but not the section itself).