I just found (and fixed) a related problem — one that demonstrates similar symptoms but whose root cause is slightly different.
In particular, the symptoms I observed were that my iPad app would initially display an old storyboard image for the first page and, after a short delay, would bring up the most recently edited story board contents. I went through most of the above machinations to no avail.
The problem is that the iPad loader first just dumbly loads your app's launch image into the screen. You usually set up this image as part of the early administrative setup of the app in XCode. At launch time, while the end user is considering the content and cogitating about where to touch the screen, the application is in the mean time madly getting itself ready, un-archiving the xib/nib/storyboard, and doing the real work of getting ready.
In the ideal situation the provided launch image is pixel-for-pixel the same as the one generated by the nib-unarchiving-process. However, if you forgot to update your launch image after updating the story board, you'll see an image shift at the completion of the unarchiving.
I wouldn't have suspected this as the problem except that I had read Jef Raskin's description of how he did exactly this on the Canon Cat word processor to provide the illusion of an instantly ready application: it takes advantage of the fact that the typical human response time to an application startup is on the order of seven seconds — plenty of time for even a floppy-based system to load and overwrite the bitmap facade that the loader sets up. Sometimes, it's good to have read a bit of arcane history. Jef would of course later go on to found a project whose name was Macintosh, and the rest is history — and this bug.
