Trying to solve this problem last night, I came across this great script to automate the process. Works great, right out of the box.

build_for_iphoneos

If you want to integrate this with an xcodebuild, you’ll still need to build a small xcodeproj file. There’s a template for this and instructions here:

Building Makefile Projects With XCode

Joel Spolsky, of Joel on Software is one of my favorite writers in the software industry. He’s insightful, pithy, and practical. But sometimes he and I part ways, at least in practice, and “Evidence Based Scheduling” is one of those times.

The trouble with the “break it into tiny pieces” approach is that the number of pieces quickly explodes so large that the act of tracking them swamps the project. And now, rather than getting wildly behind schedule because you underestimated how long a particular piece will take, you’re behind schedule because you underestimated how many pieces there were. And now you have more project management overhead….

• There is only one keychain, and it belongs to the OS.
  • It is backed-up, but it's encrypted w/ a key that is not backed-up.
• You can only read your own keychain entries, so you can't share data this way
• "Your own" is defined by your application name (not identifier)
  • If you change your application name to match some other application, you can read it's keychain
  • You will of course overwrite that application in the process
  • This fact does not appear to be documented, so it might change
• Because the keychain belongs to the OS, it outlives your app.
  • Even if your app is deleted from the phone
  • And reinstalled... your old keychain data is still there.
  • Beware if you change your keychain format
  • I know of no way to clear out the old data except to walk through and delete them all inside your app

Here are the three magic words: +alloc, -copy and +new. If you commit these magic words to memory, and devote yourself to a life of accessors, then Cocoa memory management should cause you no fear.

For those interested in the path to memory management enlightenment, you should first deeply understand every word of the Memory Management Rules. Don’t be afraid, it is very short, and if you will commit it to heart, you will avoid much suffering in the future.

Unregistering

Because these bugs are very hard to track down and very easy to avoid, I’d like to direct everyone’s attention to how to properly unregister for notifications.

If your object uses NSNotificationCenter ever, you must add the following to -dealloc:

[[NSNotificationCenter defaultCenter] removeObserver:self];

This removes you from all notifications. If you fail to do this, and you are dealloc’ed, and a notification you were observing is later posted, the application will crash with a bizarre access violation deep in NSNotificationCenter when it tries to post to an object (you) which no longer exists. It is tricky to figure out even what notification is being passed in these cases.

If you are not observing anything, then -removeObserver: does nothing, so it is not dangerous to call. There is a slight performance cost, especially for objects that are alloc’ed and dealloc’ed a lot, so there’s no reason to add it to objects that do nothing with notifications, but I recommend better safe than sorry in most cases.

This advice does not apply to KVO observations, which are a completely different animal.

When faced with the need to return “not found” for something that normally returns an index or other value that would normally be unsigned (whether this is an error condition or a normal event), Cocoa offers the NSNotFound constant as an alternative to returning an illegal index like -1 (which forces you to change the index to an NSInteger, raising the likelihood of sign-based errors if there’s ever a long promotion).

NSNotFound is 0x7fffffff, which is not -1 (0xffffffff), but is still very large (~2 billion) and so should never be a real index for any sanely-sized spaces, and is more readable than -1. NSNotFound is a good constant to remember when these issues come up. Look at NSString -rangeOfString: for an example of its usage.

I move between VS and XCode a bit without shuddering or fussing, which seems to make me a strange creature. In general, shocking as it is to say on a Cocoa list, VS is actually a much more powerful environment. Most who love XCode have little used VS (at least VS2005 or later, VS.NET is clunky IMO). But learning what actually is better about VS requires using XCode for quite some time. Most of the initial complaints are simply small differences between the two; many of which I prefer the XCode way. But then, XCode is a Mac app, and I generally prefer Mac UI.

A fie on useless attempts to stop hacking… At least that’s my current assumption on why Microsoft did this. I’m a Cocoa guy, but I actually like .NET and hack a bit of it now and then. It’s a pretty good framework, though you can see some of the seams where Microsoft didn’t quite think it through when they were designing it and had to tack on later (the whole System.Text.Encoding namespace that’s made up of methods that should exist on String; but then C# doesn’t have ObjC-style categories so they probably also being more careful about throwing 10k methods on a single class the way Cocoa does, but I’m running off on a tangent here).

The point today is the headache that is the HttpWebRequest.Date property. What HttpWebRequest.Date property you might ask? That’s right; there isn’t one.