In Storyboard using table cell is better then XIB because it gives more flexibility. In Storyboard it is not easy to handle if you have a large amount of code. It is useful only for a small amount of code.
If you're trying to resolve any connection issues and have noticed that you need to edit a XIB file but have selected the Use Storyboards option when creating your project, simply right-click the Main. storyboard > click Open As > then click Source Code . This way you don't have to recreate the project from scratch.
Application interface created with Interface Builder, a graphical editor for designing and testing user interfaces; saved in a text-based flat-file format, introduced in Interface Builder 3.0. NOTE: XIB files are also called "development-time format" files.
This is not a bug, this is a consequence of how Xcode processes storyboard files. I am writing a diff and merge program for storyboard files (GitHub link) and I have spent hours analyzing the storyboard files logic and how Xcode processes it. This is what I discovered:
Why do weird changes occur in storyboard files?
Xcode uses the NSXML API to parse storyboard files into some NSSet
-based logical tree structure. When Xcode needs to write changes it creates an NSXMLDocument
based on the logical tree structure, clears the storyboard file and calls XMLDataWithOptions:
to fill the file again. Because sets do not preserve the order of their elements, even the slightest modification could change the whole storyboard XML file.
Why does the class tag disappear or reappear randomly?
The <class>
section is nothing more than an internal Xcode cache. Xcode use it to cache information about classes. The cache changes often. Elements are added when class .h/.m
files are opened and removed when Xcode suspects they are outdated (at least older Xcodes behave like this). When you save the storyboard, the current version of the cache is dumped, which is why the <class>
section often changes or even disappears.
I have not reverse-engineered Xcode; I made these observations by experimenting with Xcode and storyboard files. Nevertheless, I am almost 100% sure it works this way.
Conclusions:
MyController1
view controller in a storyboard document. Open the storyboard file, and find something like this
<viewController id=”ory-XY-OBM” sceneMemberID=”MyController1”>
.
You can safely commit only changes in this section and ignore everything else. If you changed segues or constraints, also commit anything that has “ory-XY-OBM”
inside. Simple!This is a bug in XCode 4.5+, I hope it gets fixed, and yes its a PITA.
Here's the full bug at Apple
How to avoid Xcode gratuitous edits to storyboard files?
This issue can be mitigated somewhat by extremely judicious use of git add -p
on any of Xcode's generated files, including storyboards, XIBs, Core Data models, and project files, all of which suffer from similar transient modifications that have no impact on the actual interface/model/project.
The most common junk changes I've seen on storyboards are the system version numbers (as you mention) and the constant addition and removal of the <classes>
section, the omission of which I have never seen cause problems. For XIBs, it's the addition and removal of <reference key="NSWindow"/>
, which isn't even a class in Cocoa Touch. Just wow.
Think of it like the sea: there is both a high and low tide. Let it wash over you.
Ahh. That's it.
You can ignore these modifications when staging your changes, reset the junk changes, and make a clean commit.
The single advantage I've seen with storyboards over XIBs from a technical standpoint is that Apple has not yet neutered FileMerge to refuse to merge conflicted storyboards. (FileMerge used to be able to merge XIBs, but newer versions broke that. Thxxxx guys đź’ś!!!)
Please file lots of bugs about all of these problems at http://bugreporter.apple.com/! And don't forget to create entries on OpenRadar.
Throwing on another answer here because this situation has improved greatly. The XML for the XIB file that represents the StoryBoard has been greatly simplified.
I have also recently bitten the bullet and started to use the interface in Xcode to Source Control. I have been on the command line for years and happy there, but the interface is nice and it lets you split commits, which is really important if you use a ticketing system that links to commits.
Anyway, I noticed today that there was a change on the storyboard and the built in diff showed me it was a single attribute in the document tag (systemVersion). So not a big deal.
I have read articles where people say SBs were outlawed on their teams because of merging issues. Total madness. They are so amazing, especially now that they have intelligent autolayout built in, you are really missing out if you are not using them.
It's helpful to know why this insanity is happening, but for those who believe in keeping their projects free of warnings and who just want a quick-and-dirty to get their projects back to a healthy state:
Don't commit anything until explicitly instructed.
Open Xcode and create a new storyboard (Command+N > iOS > User Interface > Storyboard). I'll assume you call it the default name of Storyboard.storyboard
.
Open the storyboard that Xcode has violated. I'll assume this is Base.lproj/Main.storyboard
.
Select and copy everything on the storyboard (Command+A then Command+C).
Open Storyboard.storyboard
.
Copy and paste everything into Storyboard.storyboard
.
Close Xcode.
Open a terminal and change directories to your repository.
Replace Main.storyboard
with Storyboard.storyboard
(mv Storyboard.storyboard Base.lproj/Main.storyboard
).
git add Base.lproj/Main.storyboard; git commit -m "Fix Xcode's insanity."
Disregard the changes to project.pbxproj
via git checkout -- project.pbxproj
. If you git diff
the file, you'll see that it has just added information about our temporary storyboard (which no longer exists).
Open Xcode back up and see that the warnings has disappeared.
Breathe.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With