Xcode tidbits: Open as Hex, Open As Source Code, (Git) line endings, and text encoding

With this article, I’m starting a series about all the goodies — useful tools — that can be found in Xcode. Some of these tidbits are tools everyone knows about while others are barely documented to undocumented. For example, how many of you know that you can view, inspect, and debug all your Auto Layout constraints live during app execution using the “Debug View Hierarchy” Xcode feature? I discussed that feature in detail in this article, “Troubleshooting Auto Layout using Xcode’s Debug View Hierarchy.” Today, we’ll discover two editors that ship with Xcode, the “Open As > Hex” and “Open As > Source Code” editors, both only available by right-clicking on files in the “Project Navigator” to reveal a contextual menu.


The Xcode hex editor
A couple of days ago, I found myself Googling the term “Xcode hex editor.” I didn’t know that Xcode had a built in hex editor! I never even noticed it and I’ve been using Xcode since 2011. Doh!

To open a file in hex, right-click on the file in the “Project Navigator” to reveal a contextual menu, and choose “Open As > Hex,” like so:

Click to enlarge image

The file I selected, “CodeFile.swift,” opens in a typical hex editor — columns of bytes encoded as hex values on the left and columns showing the corresponding human-readable text on the right, as follows:

Click to enlarge image

“CodeFile.swift” is a file I had just pulled from my remote Git repo. Here’s the contents of the file as pulled:

Notice that I’ve highlighted the two consecutive hex characters, 0D 0A, on the left, in the hex editor screenshot above. Notice that the corresponding human-readable characters are highlighted on the right. I checked the next two consecutive hex characters, 0D 0A:

Click to enlarge image

Would anyone like to speculate as to why I’m looking at the sequence 0D 0A? I’ll give you a hint. I work in a mixed development environment. Some members of my teams develop code on Windows using Visual Studio. Other members of my team write code on OS X using Xcode. Read one of my Git tutorials, “Typical Git/GitHub workflow tutorial: configure, clone, commit, stage, push, pull, status,” specifically the section on “Git handling of line endings.”

Xcode is screwing up my file line endings (Git)
As I discussed in my aforementioned Git tutorial, Windows uses two invisible characters to mark the end of a line, a “carriage return” and a “line feed,” CR LF (hex 0D 0A). OS X uses one, a “line feed,” LF (hex 0A). When you want to go to the next line while coding, you hit the Enter key on Windows and the return key on Mac.

   

Git has settings to compensate for, and thus allow us to compare, files with different line endings. I discussed this in my Git tutorial and there’s lots of information on the web for configuring Git.

The problem I’m having is documented:

Since I upgraded to Xcode 9 every time I change even one character in the code, whole file gets its line breaks changed (I checked with xxd) and so it looks like I modified the whole file.

My Preferences->Text Editing is set to CLRF (Original line breaks) and yet it changes everything to LF. …

Reported to Apple and bugreport marked as duplicate, so they know it already. …

Git is hard enough to understand and configure properly, but having Xcode jump into the line ending quagmire is a royal pain in the ars. I don’t want to get involved in a long-winded discussion of Git here; I just want to point out the usefulness of Xcode’s hex editor — despite Xcode’s other problems.

Patch for Xcode’s screw-up
I have a manual workaround. Whenever I pull a file from my remote, and before making changes to code and saving the file, I look at the file in the hex editor. Look at the hex editor images above. Note that file “CodeFile.swift” was saved in Windows format (CRLF). Can you guess what happened when I made some changes and I saved the file? It was saved into Mac format (LF):

Click to enlarge image

Here’s “CodeFile.swift” after I made changes:

What lines of code in “CodeFile.swift” do you think Git is going to mark as changed? Since Xcode changed the line ending of every line in the file, Git is going to indicate that I changed every line in the file! @!!!#@#@!!@!!!#! (expletive). How do I know this? I do a git diff:

Click to enlarge image

That’s just crazy. Imagine if “CodeFile.swift” was a big, complex file and I made 5 changes in different parts of the file. The whole purpose of using Git for source control would be defeated. The history for the file would be reset. It would be very difficult for other developers to see the changes I made. So what to do?


I used a reliable text editor, TextWrangler, to save “CodeFile.swift” with Windows line endings (CRLF):

Click to enlarge image

Now look what happens when I do a git diff:

Click to enlarge image

Now I can commit and push “CodeFile.swift” to Git and see an accurate representation of the changes I made.

The Xcode source editor
A lot of configuration files in the software development world are stored in XML, and rightly so, as XML is a very readable format. With XML tags and indentation, looking at a .plist or .storyboard file in XML sometimes is a necessary “evil.”

For example, viewing a .storyboard file as XML, you can find precise values for various settings, like constraints (i.e., a constant), positions (i.e., rect x, y, width, and height values), and connections (i.e., IBAction, IBOutlet). There’ve been a couple of occasions when I’ve had very complex layouts, encountered Auto Layout problems, and was only able to fix my layout by looking at the XML.

When using .plist files, I sometimes find it easier to add a setting by editing the XML. Remember my article, “Oh, my — App Transport Security has blocked a cleartext HTTP (http://) resource load since it is insecure”, where I had to configure App Transport Security settings to allow loading of insecure, clear text URLs? There’s an image in that article that shows how I added the settings.

To open a .plist or .storyboard file in XML, right-click on the file name in the “Project Navigator” to reveal a contextual menu, like so:

Click to enlarge image

   

Here’s a .storyboard file being edited as XML where I’ve highlighted some of the settings I mentioned earlier:

Wrapping up

Software development is so complex, and it’s only getting more complex. If you’re going to be a good developer, you need to make sure you’re making use of all the tools at your disposable. That means you may have to take some time just poking around in your IDE, trying to find tools you didn’t even know existed. One of the best things you can do is to read Apple’s Xcode documentation or some of the great third party resources out there on getting the most out of Xcode.

Be your best!

Author: Andrew Jaffee

Avid and well-published author, software engineer, designer, and developer, now specializing in iOS mobile app development in Objective-C and Swift, but with a strong background in C#, C++, .NET, JavaScript, HTML, CSS, jQuery, SQL Server, MySQL, Oracle, Agile, Test Driven Development, Git, Continuous Integration, Responsive Web Design, blah, blah, blah ... Did I miss any fad-based catch phrases? My brain avatar was kindly provided by http://icons8.com under a Creative Commons Attribution-NoDerivs 3.0 Unported license.

Leave a Reply

Your email address will not be published. Required fields are marked *