Coming from a C development background, long before the days of integrated debuggers, printf() was the primary tool for tracking down bugs. Building on that, NSLog is no doubt helpful. However, as the amount of code in a project grows, I often find that another reference point in the output would be helpful, namely, the filename and line number where the NSLog calls originate.

This is a two part series on creating a new class that wraps NSLog to add several additional debugging features including output of the filename/path, line number information and the option to turn debug messages off/on.

You can read the rest of the tip on the iPhone Developer Tips blog.

In building a recent project I encountered an error during the linking process. I want to point out the error message and show you how this simple error can be resolved. The reason for pointing out this error is that I have no idea why this error came about…more on that in a moment.

Read the rest of this tip on the iPhone Developer Tips blog…

I want to share another debugging tip, this something that applies to the final step of building an iPhone project, linking.

I was able to successfully compile a project that I’ve been working on, however, the build process generated an error that two symbols could not be found, CGRectZero and CGRectOffset.

The figure below shows the specific error messages (ignore the first error about .objc_class_name_BirdView for now).

Read the rest of this tip on the iPhone Developer Tips blog…

I recently ran into this error message within Xcode while writing an iPhone application. I was surprised how long it took to track this down. One of the reasons this is tricky is that message implies that the error occurred in the file referenced in the error message.

Read the rest of this tip on the iPhone Developer Tips blog…

I’ve been spending time getting familiar with Xcode as I learn to write applications in Objective-C, with the larger goal of writing applications for iPhone. My editor of choice on the Mac up to this point, is TextMate, an great all around code editor. I’ve written a number of tutorials/tips on TextMate on this blog (check out the TextMate Category for links).

One of the things I’ve become quite accustomed to is tabbed based user interfaces. For example, in FireFox I typically have a screenful of open tabs. When working with projects inside of TextMate, you can have multiple source code files open in tabs. Unfortunately, this is not a feature supported in Xcode (that I am aware of).

So, I spent a few minutes poking around at various options and came up with an approach that is far from perfect, yet offers a blend of coding in TextMate and managing compiles/builds in Xcode. Not perfect, however, it’s working for me.

Click on the image below to learn more.

Technorati Tags: TextMate, Xcode