I would like track changes of the GUI development in GIT.
On the other hand I like to use the storyboard to develop GUIs.
Is there a way to generate Swift code from the Storyboards XIB file, that instantiates and initialises the GUI objects from code.
If that´s not possible, is there another way to reach my goal - tracking changes in GIT and using the storyboard?
Storyboard files are just a specialized type of XML file, like SOAP or XSL. Control-click on one and open it in your favorite text editor and you'll see for yourself.
Thus, tracking changes to a storyboard file (through Git or elsewhere) is the same as any other file, except you need to use something other than Xcode.
As for converting storyboard XML to Swift - there are no utilities out there for that.
Not sure about Git tracking, but for general-purpose UI refactoring, from Xib or Storyboard files to Swift source code, the tool is exists (Disclaimer: I'm the author of it).
It generates view properties (e.g. font, backgroundColor, etc), layout constraints and trait collection variations. Works with Xib or Storyboard files designed for iOS, tvOS or macOS platforms.
Related
My app is currently localized for English and Japanese, with seperate storyboards for each. I want to switch to base localization so that I only have to maintain a single storyboard. I've checked the "Use Base Internationalization" box in the project's info tab and chosen the English iPhone and iPad storyboards for the base.
I assume I should delete the Japanese iPhone and iPad storyboards I had previously used, but I don't see an option to delete them when right-clicking on their files in the file inspector. Should I delete these old storyboards, and, if so, how?
** Edit **
Changing the 'Main Interface' shown in the screenshot doesn't allow me to delete the Japanese storyboard. It's hard to tell which storyboard to select in the dropdown because its width is more narrow than the storyboard names, but that's a separate issue.
This tutorial drives you through the process step-by-step. This is how it worked for me:
Remove all localizations and leave only the base.
Ensure that the localized files were moved from the project directory (in Finder)
Add the localizations one-by-one
The localized strings are extracted from the storyboard only when the localization is created. The Tutorial above provides a script that can help you keeping the localized files up to date if the storyboard is changed.
In your case, you will have to merge the existing translations into the new files but I suppose it is not a huge deal compared to the gain with using a single file.
For reference, the process is described in this official tutorial too: http://developer.apple.com/library/ios/referencelibrary/GettingStarted/RoadMapiOS/chapters/InternationalizeYourApp/InternationalizeYourApp/InternationalizeYourApp.html
After cleaning and reloading, I was able to remove the Japanese storyboards by clicking on the - in the project settings:
I want to localize my app in multiple language (like 6 or 7) but i don't want to add as many as storyboard copy. So, for 6 differents languages, I want:
One storyboard
6 Localizable.strings
In my storyboard, all components are outlets so i can localize them programmatically.
My issue is that i can't load application in language which don't have storyboard localization (but have localizable.strings), I get an error:
Could not find a storyboard named 'XXXX' in bundle NSBundle.
Is there a way to just use one storyboard with multiple Localizable files?
It sounds like your storyboard is still in the en.lproj folder. When your launches on a system that's configured to use another language, resources from that language's lproj will be used not the resources from the en.lproj. You need to mark your storyboard as not being localized in Xcode so that it doesn't get deployed to a en.lproj folder in your built app. Also make sure it's still included as a resource in the appropriate target of your project. You should be able to do all of this from the file inspector with your storyboard selected.
If you're targeting iOS 6.0 and later, you can use the Base.lproj feature. With that feature, your application just ships one storyboard, and multiple strings files and storyboard's strings are replaced at runtime with the strings from the appropriate language's strings file.
You can read more about base.lproj here:
https://developer.apple.com/library/ios/#referencelibrary/GettingStarted/RoadMapiOS/chapters/InternationalizeYourApp/InternationalizeYourApp/InternationalizeYourApp.html
I am using XCode 4.3 and I am creating a tab bar application following an example in my book (likely used for XCode version < 4.3) but when I add a new tab and turn on check-mark to generate XIB file while adding a new file of Cocoa Touch, the GUI doesn't appear but display instead its generated XML file content. Do you know how to fix this ?
I find each time there is a new version of XCode, the Gui and defined functions seem to change a lot, doesn't this annoy for low programmers like me ? (By low, I mean newbies and those who can't keep up with such rapid changes). Thank you.
You can view my shot here
http://imageshack.us/photo/my-images/685/appleimg.png/
Right-click on the .xib file and choose Open as...
There will be a list of options. Currently you are using "Source Code", which displays as XML. Use Interface Builder - iOS instead.
This will be remembered between sessions. I don't know how it got set to this in the first place.
Alternatively, you may be in the Version editor instead of the Standard editor - this will show xibs as XML in order to correctly display changes.
I was creating a new View-based Application in XCode, adding some outlet and actions, using the IBAction and IBOutlet tags, into the automatically created controller view header file. I then double clicked the 'project_name_ViewController.xib' to launch the interface builder.
However the outlets and actions did not appear in interface builder. The only way I could get them to appear was the close the xib file and reopen it through file -> open command in Interface Builder it's self.
I recently upgraded to Snow Leopard, before that I never had this problem.
Has anyone else come across this?
Xcode is full of strange bugs. I always follow my 15 step arcane black magic ritual before I make an ad-hoc or release build. Any time something like your problem happens, I put it down to the flying monkeys twisting bolts somewhere in Xcode and restart the program (sometimes the computer). That generally fixes it.
Of course with outlets and actions, it's easy to forget to save the source header before you swap over. Make sure to save and build. Errors in the source can stop them from showing up in IB too.
What's up with the NIB->XIB change somewhere between XCode 3.0 to 3.1?
Is there any difference with this name change that I should know while I go through tutorials that mention nothing but the .nib file?
XIB's are very cool. they are basically an un-compiled NIB (in XML format if memory serves me)
during the build process they are converted to NIB's to be deployed in the final product.
As I understand it, xib files are xml nib files. xib files are compiled into nibs when the application is built. The xib format was created because nib files don't mesh well with version control (because they're not text), whereas a plain text xml file works well.
The other answers and link explain what XIB files are, but not about the specific change.
The new flat-file .xib format was introduced with Leopard (and Xcode 3.0) in 2007, but I believe that .nib remained the default, primarily for compatibility with older versions of Xcode and OS X. With Xcode 3.1, there was a shift to .xib as the preferred format. However, most documentation hasn't been updated, probably in part because the distinction is fairly minor from the standpoint of a normal developer.
I definitely echo the sentiment that XIB files are much better than NIB files, especially when using version control. (Flat files are much easier to manage than directory packages in most tools.)
the XIB file (XML Interface Builder) was introduced into Xcode because NIB files (Nxt Interface Builder) weren't so user/editable friendly. XIB's are designed in the format of a raw XML document making it a human-readable source code. Although the older bundled NIB files where editable, they were still a tiny bit more complicated than just a simple XIB, They contained multiple files including the XML XIB. Now most NIBs are compiled and are not readable by anything except for your Mac so it can read them. Apple started using compiled NIB files because people could read and understand the code put into other peoples programs :o. Xcode uses the "ibtool" command to compile nibs now.
If you wish to know more about compiled Nibs go to my detailed answer at this post