10th December 2011
By default, Xcode 4 integrates with and “manages” Git repos of all projects. Xcode attempts to “help” by providing a unified version control GUI that looks the same for both SVN and Git. The result is a shockingly bad integration that’s inspired lots of workarounds posted all over the Internet – and this Git integration is enabled by default for every new project.
All of the workarounds I found require extra action every time you make a new project. I wanted a solution that permanently disables Git integration in Xcode 4. I’ll never use the version control GUI – and neither should you.
So here is the permanent solution. This is how to completely remove Xcode’s ability to “manage” your Git repo.
First, we need to locate and remove the offending plugin – hat tip to this tweet for pointing out the location.
Quit Xcode, open up a terminal, navigate to Xcode’s plugins directory.
$ cd /Developer/Library/Xcode/PrivatePlugIns/
Rename the Git plugin to a different extension, so that Xcode won’t load it when it starts. Feel free to be creative.
$ mv IDEGit.ideplugin IDEGit.bak
When Xcode 4 first came out, this was enough. But Apple has patched Xcode since then. If you try to launch Xcode now, it will just error out.
Xcode “expects” the plugin to be there, so now we have to get creative. Here’s my take on the simplest thing that can possibly work:
- We know that Xcode checks the plugin’s identity based on some key in its Info.plist. Possibly, it also checks some other things.
- There’s another version control plugin (Subversion) that isn’t enabled for projects by default. In case Xcode checks some other things about the plugin, the Subversion plugin is the most likely to return true for the same checks as the Git plugin.
- So let’s make a copy of the Subversion plugin and see if we can turn it into a fake Git plugin. It doesn’t have to work – it just has to pass Xcode’s cursory checks on launch.
Here we go:
Copy the Subversion plugin into a plugin with the “expected” name.
$ cp -r IDESubversion.ideplugin IDEGit.ideplugin
Take the Info.plist from the real Git plugin, and overwrite the Info.plist in our fake plugin to complete the ruse.
$ cp IDEGit.bak/Contents/Info.plist
IDEGit.ideplugin/Contents/Info.plist
Launch Xcode, make a new project, and see if it worked.
Everything appears to be working well since I did this. Now I can use git exclusively from the command line, without worrying about Xcode’s attempts to “help.” That’s the way git should be used, and that’s the way you should use it.
By the way, another thing you should do is follow me on Twitter here.
22nd February 2011
“Can you recommend a good book for getting started with Objective-C?”
I get this question a lot, but there’s no need to spend any money or even to spend time digesting an entire book. I always point people to the Apple docs – the documentation is very modular and (mostly) very reliable.
But the sheer volume of documentation can be intimidating. So this is a list of articles, arranged in the order that I recommend you read to get started writing your first iPhone app. You can work through the whole list in a day or two. I’ve learned everything I needed to ship about 20 apps between the docs and a lot of Googling – this list is based roughly on the path I took through the docs to get started, and I think it will serve you well.
The only prerequisite you need is some knowledge of C and OOP. Let’s get started:
- Learning Objective-C: A Primer will show you the highlights of the language, and it explains the syntax for standard OOP practices.
- Your First iPhone Application will walk you through shipping the classic “Hello World” app, including showing you around the IDE.
- The View Controller Programming Guide: After building your Hello World app, you’ll have a taste of the Model-View-Controller architecture of the SDK. View controllers house a lot of the logic of most apps, and this guide will show you how to structure and decouple relationships between the views in your app.
- UICatalog is one of my favorite pieces of sample code. It will give you a huge head start on building views, with plenty of code that you can copy-paste. Read the code, and be sure experiment with changing some lines and running the code – you’ll be able to immediately see the effects.
- The memory management rules are vital. I recommend reading the whole guide eventually, but at the very least, read and memorize this one page.
- Build something! You’ve got all you need to get started – you will need to learn more (lots more), but the best way is to pick an idea, start building, and learn what you need as you go.
The clever among you will note that I covered views and controllers, but not models! At the very least, you’ll be using NSObject subclasses to model your data, so you should read and understand the class and the protocol.
If you need to store your data across app launches, there’s a lot of choices, and proper data modeling is well beyond the scope of this post. (Maybe next time.) I usually use straight SQLite, which does take a while to get comfortable with, but you could also use CoreData if you need something simple.
I’ll close with some of the most common guides/frameworks that I reference. At some point, you’ll end up learning all of these. But in the meantime, keep these links handy, and read whatever parts you need as you build your app:
By the way, if you do learn better from books or videos, or want something other than the Apple docs, I recommend:
If you read this far, you should follow me on Twitter here.