I’ve been writing code for a very long time now, using different IDEs and a varied array of languages. My current jam is developing iOS applications, or more specifically, writing Swift. However, one thing that is a constant for me – regardless of what language / glorified text editor I’m using is… keeping my file system neat and tidy.
I suppose you could say I was a bit obsessive compulsive in that way – although I warrant that most people who use a computer for more than email and Facebook probably spend a good amount of time making sure everything is organised on their hard disk (or am I truly the only one…). Anyway before I go off on a tangent I should bring this back to the core point of this article – neat and organised code on my file system.
Now anyone who’s used Xcode for any amount of time will know all about its concept of groups. Groups to Xcode are a conceptual way of organising your application within the project overview, but unfortunately have nothing to do with how your files are organised on your hard drive. Now for a lot of us this may not be an issue as a lot of iOS apps have a handful of classes, view controllers and storyboards; so keeping them organised isn’t a big deal (well not to normal people but I still see the issue :p).
The problem of ‘virtual’ grouping and file system organisation raises its ugly head when you work on a more complex and broader application that may have several hundred classes, view controllers or storyboards etc. and being able to quickly jump to one of the files from outside of Xcode can become problematic. If it does you can approach this in a couple of ways:
- Ignore it and accept this is how it should be
- Manually create folders in your actual app folder to replicate the virtual groups in Xcode and organise your code the same way
- Use something like Synx
So let’s go through my non-exhaustive list of options one-by-one and see which may be useful, if like me, you feel it needs more thought.
First up we have Option 1 – the head in the sand approach. It’s the way it is and so it shall remain. To be honest, I have no issue with this if it works for you. It doesn’t work for me so I’m more interested in options 2 and 3.
Option 2 – manually recreate the groups as actual folders and move the files in to the same structure as Xcode groups. This works but is very manual and will likely not work on the first pass. This is generally because you have to remove all of the compile sources, linked binaries and bundle resource entries in the Build Phase of your project because they will now all be pointing to the wrong location. Plus all of the entries in your actual project will now have probably turned red as Xcode can no longer find the files. The fix for this is to remove all the file references and add them back to the project based on their new location on your hard drive. That’ll fix it but as you can see it’s a bit brittle. Oh and don’t forget your info.plist files will need resetting in the project overview for each target you have set.
Not the end of the world, but still a bit “manual” and time consuming. Which leads us to Synx (which is obviously the focus of this article any way :D).
Option 3 – Synx. OK, so what is Synx? Synx is a simple command line tool that reads your .xcodeproj or .xcworkspace and recreates the folder structure based on your Xcode groups and moves the files in to these newly created folders. Yay! It does all the manual stuff and quicker than I can. FTW!
Whoa there horsey! There are a few things you need to know before cracking out the Playstation controller and kicking back. Firstly you need to have Ruby on your Mac (not a big ask as most modern Macs come with a version of Ruby installed by default). Next you need to install the Ruby Gem:
gem install synx
If you’re using the built in version of Ruby you’ll likely need to sudo the previous command, (and you should really consider using RVM).
Next via Terminal locate the root directory of your Xcode project, and once there use the following command to get Synx to rebuild your folder structure. WARNING – Make sure you have back up your project to Git or a separate location before doing this!
Firing up Synx
(obviously replacing the path with that of your actual project)
If you’re using Cocoapods it may have moved some bits around, which will likely confuse Cocoapods – so to be safe run pod install to recreate your Cocoapods repository again.
If you’d like to try it out or know more, head over to the Synx repo on Github: https://github.com/venmo/synx