xcode

A while back a couple of our devs were having some problems syncing to the git. It seemed everything but their Xcode projects would sync up. I looked into it, and while it took a bit to solve the problem I finally figured out what the issue was.

The solution was quite buried, so hopefully this post helps at least one other person out there.

There have been a few very rare scenarios where I have actually required a dynamic header in a project. I mention Xcode in the title however this technique really applies to nearly any IDE or command line project.

When developing an iOS or Mac app, NSLogs are very handy during development. These are quite useless for an app on an end users phone or computer, so removing every log is often a good idea, especially if you like to log a lot of information. This might sound like a pain, commenting out every NSLog whenever you build for the AppStore? But no, there’s a much simpler solution, coming from our friend the preprocessor macro.

If you’re a developer and you find your HD space just seems to disappear without your putting any new files on your computer, take a look into what Xcode is doing. For every project you create Xcode will cache a lot of data for intellisense, autocompletion, and some other features. Whether it’s a test project or a full on client project, Xcode will keep this data until you delete it. On my laptop I don’t think I’ve deleted any of this data for about 8 months, which worked out to be roughly 16GB worth. This includes archived apps I send to clients for testing purposes, stuff that I consider to be a one off.

Xcode’s “Analyzer” is normally a great way to determine where most memory leaks will occur in your project without actually running it. If you follow Apple’s Memory Management Guidelines the Analyzer is pretty accurate. By no means is it a replacement for the Profiler, but offers some quick checks.

When developing on the Mac and using custom frameworks in your application, when you compile the frameworks are copied into your applications bundle then linked at runtime. These frameworks will most likely be bundled up with their headers. Some of the frameworks you include may not be things you want to make public to the world, which you are essentially doing by including the headers with the framework.

Since Xcode 4.1 when your application throws an exception your console just prints a list of function pointers and you don’t get a proper stack trace. This isn’t helpful if you’re trying to find the exact line the error occurred on.

In Xcode the build settings screen can be pretty daunting for some people, especially when you start iOS/Mac development. Knowing which settings to pick can be tricky, but I still see a lot of people that do this individually for each of their projects, which makes it easy to miss crucial build parameters you don’t want to distribute your app without. Using a .xcconfig file is extremely useful for solving this problem, it is a type of file for determining build parameters, meaning you can have this file sitting in one spot and have each of your projects referencing it. If you need to make a build setting change to all your projects, you can just add it to this one file and the next time you compile each of the projects the change will be taken into account.

Shell scripts are very handy for custom actions after compiling an Xcode project, but unfortunately they can no longer be run before compiling, not as easily as before at least. To set this up now, you must do the following…

So you’re coding away, everything is coloured nicely so you can distinguish between reserved words, datatypes and variables, but then the unthinkable happens; all your code turns black. Not to worry, you can live without the colours, but when you see the “symbol not found” message and Xcode is no longer autocompleting variables and functions for you, you start the panic. Your development time rolls to a halt and you can no longer quickly jump around from method to method. You realise Xcode has broken it’s intellisense index.