How to avoid Xcode gratuitous edits to storyboard files?

59
votes

When I navigate to one of my xib files, Xcode marks the file as touched. Undo and revert have no effect. Saving seems to do no harm, but the glitch causes me frequent additional git work.

Has anyone else seen this or have an idea about something in my MainWindow.xib that would cause it?

Edit in 2019 - still happening!

3
xcodexib
I don't see that behavior in my environment. I wonder: Could it be that the xib in question was last used in Xcode3, and Xcode 4 is doing some conversion behind the scenes? Or, are you seeing this any time you select a xib file, whether it's the first time selecting it in Xcode4 or not? Are there any git settings where your file is read-only and perhaps Xcode is changing the permissions so you can edit it? That might account for the modified status. – Mark Granoff
Thanks for the ideas. The file had been in an xcode 3 project. The problem occurs every time I navigate to that one file. Your conversion idea is a good one, but the issue continues even after a save/build. No special git settings. – danh
Here are the minimal steps with which I can reproduce this problem: xcode->New File...->User Interface->Application xib. Drag a Tab Bar controller in. Save. Select any other file in the project. New xib gets touched by xcode. Diff-ing the original with xcode's mods shows a bunch of tags like this: <reference key="NSWindow"/> and <reference key="IBUITabBar" ref="795333663"/> and a very large block that opens like this: <object class="NSMutableArray" key="referencedPartialClassDescriptions">. Am I nuts? – danh
Wow. I see the same behavior, following your steps. I wonder if it's specific to the XIB file being an Application xib? You can imagine that that xib has special knowledge about things like your app delegate and such. This is indeed bizarre behavior, that's for sure. – Mark Granoff
Thanks for checking it out. I can reproduce with any xib. The key does seem to be the presence of a UITabBarController. I reported a bug with Apple... bug #9847336. – danh

3 Answers

30
votes

Apple says it's a known issue:

This is a follow up to Bug ID# 9847336. After further investigation it has been determined that this is a known issue, which is currently being investigated by engineering. This issue has been filed in our bug database under the original Bug ID# 9056156. The original bug number being used to track this duplicate issue can be found in the State column, in this format: Duplicate/OrigBug#.

14
votes

After attempting many different solutions to get around this extremely annoying bug, I've found one method that works (it is certainly not a "fix", but a workaround).

Lock controllers when you're done with them.

Select a view controller in a storyboard, open the Identity inspector, and at the bottom in the Document section, you'll see a Lock dropdown. Select "All Properties" from the lock drop down.

If you do this for all of the controllers giving you issues (or just all of the controllers in general, even), you'll notice when you open the storyboard, Xcode will still modify the frames of various elements, but then immediately undo the changes.

This then leads to the development cycle being:

  1. Unlock a view controller
  2. Perform any necessary changes
  3. Lock the view controller
  4. Commit

Locking also works on a view-by-view case if that suits your needs better.

The bug has been around for quite some time now and it doesn't appear to be getting fixed any time soon, so unfortunately this will have to suffice for now.

3
votes

I personally feel that knowing that it's a known bug doesn't exactly fix the issue. Here's what I figured out so far and how to keep them from coming up.

NOTE: This is for a storyboard with AutoLayout enabled. I haven't yet figured it out yet for manual storyboards.

Below is an example of a button.

<button opaque="NO" contentMode="scaleToFill" contentHorizontalAlignment="center" contentVerticalAlignment="center" buttonType="roundedRect" lineBreakMode="middleTruncation" translatesAutoresizingMaskIntoConstraints="NO" id="Ebd-ny-Ill">
    <rect key="frame" x="97" y="5" width="135" height="30"/>
    <color key="backgroundColor" white="0.94557291669999999" alpha="1" colorSpace="calibratedWhite"/>
    <constraints>
        <constraint firstAttribute="width" constant="86" id="bXV-mS-ksp">
            <variation key="heightClass=regular" constant="135"/>
        </constraint>
    </constraints>
    <fontDescription key="fontDescription" type="system" pointSize="13"/>
    <state key="normal" title="See Full Menu">
        <color key="titleShadowColor" white="0.5" alpha="1" colorSpace="calibratedWhite"/>
    </state>
    <variation key="default">
        <mask key="constraints">
            <exclude reference="bXV-mS-ksp"/>
        </mask>
    </variation>
    <variation key="heightClass=regular" misplaced="YES">
        <rect key="frame" x="97" y="5" width="135" height="28"/>
        <mask key="constraints">
            <include reference="bXV-mS-ksp"/>
        </mask>
    </variation>
    <connections>
        <action selector="showMenu:" destination="eQk-yf-uDh" eventType="touchUpInside" id="xOP-Se-FXQ"/>
    </connections>
</button>

If you take a look, you'll see that the button has an element called <rect/> This defines the size and position of the UI item. If you look below, you'll also see an element called <variation/> that describes the change in position based on the size class. In order to fix the position for this, we have to use the following steps:

  1. Take a look at the warning that shows up in Xcode. Take note of what needs to be changed for that UI element.
  2. Open the storyboard in an external (text) editor.
  3. Find the UI element in the storyboard.
  4. Change the value to match what the warning is suggesting in both <rect/> and <variation/>.
  5. Save the file in the external editor.
  6. Go back to Xcode. Let it re-calculate all the constraints.
  7. Accept the warning for the UI element that pops up again.
  8. If you go back to the external editor, you'll notice that the <variation/> element is gone.

In my example, I had to update x="97" to x="597".

I'm still working on elements that don't have a <variation/>. I'll update this answer as soon as I figure it out.