Also, you'll need to be on a Mac with the iPhone SDK installed to do this...

1 ) Plug device into the Mac

2 ) Open Xcode Organizer

3 ) Put the device into DFU Mode (hold power + home for exactly 10 sec, release power - phone should disappear then reappear in Xcode)

4 ) Attempt to restore to 2.2.1 in Xcode (a second device with same name should appear in the organizer window and the original device should show "Waiting on device..." in Xcode)

5 ) While first device is restoring, start restore on second device (obviously there isn't a second physical device, just a relisting of your original device..just select it and do the restore the same way as you did in step 4) At this point, your phone's screen should turn white. If not, you may need to start over.

6 ) Close Xcode (you'll be prompted that the device is busy...quit anyway...twice)

7 ) Close iTunes (if it opened automatically when you connected the device)

8 ) Unplug the device

9 ) Open iTunes

10 ) Reconnect the device to the Mac

11 ) Option+Click Restore in iTunes (phone screen is still white at this point)

12 ) Choose 2.2.1 firmware and wait

You're done. Fun huh?

Again, try a regular DFU restore first, but if that doesn't work, these steps *may* work for you - I tried lots of less roundabout ways, but this was the only way that it worked for me.

To the Budgee Users

First off, to anyone still having CSV export issues with Budgee - I apologize.  The bottom line is that there is a bug in the OS itself that is preventing it from working (more detail below if you're interested).  After getting a couple of new bug reports since the last update, I've been able to create an example of the problem and have sent it to Apple - but the reality is that the next OS update will be the earliest it will be fixed.  I'm looking into alternatives to the current export method at this time, but do not have a solution at this point.

To Developers Thinking of Using mailto: or Currently Seeing Bugs with mailto:

Since the first version of Budgee, I've been using a simple CSV export method that passes the encoded data to the iPhone/iPod Touch's Mail application.  It's worked great - no issues at all - until about two months ago.  I don't remember which OS update started causing problems...it seems like it was one of the 2.1 releases.  The export code is really simple - it goes like this:

1. Build NSMutableString with data to export
2. Url encode said string so it is safe to use in an url (i.e. convert a space to %20 etc)
3. Tack on a mailto: with a subject & body parameter passing in the url encoded data
4. Call the shared UIApplication's openUrl method

Pretty basic stuff.  Well, as the OS has evolved, the openUrl method has gradually been getting more and more screwed up.  There is no feedback as to what went wrong when you call it - it simply returns "NO" randomly now...which means it did not pass the url to the Mail application...which means my customers can't get the CSV data out of the iPhone app.

My first thought was that I didn't encode things properly.  Sure enough, there were "reserved" characters getting through the encoding process.  I should have done more extensive testing, but from reading the docs (and the method name), one would think using NSString's stringByAddingPercentEscapesUsingEncoding would kinda do what it says.  But that wasn't the case...it escapes some things, but not all things.

So the next approach was something I found on the Apple devforums.  The suggestion there was to use CFURLCreateStringByAddingPercentEscapes to do the escaping.  It certainly looked a little nastier than the NSString method, but whatever works right?  Well, the most recent Budgee update used this new method of encoding.  On my development device, this new fix did indeed make things better and export started working again.  After releasing the update on the App Store, I had several reports of users seeing CSV work again as well - so all was good right?  Wrong.

This weekend, I had more reports of CSV breaking.  After testing for about 4 hours with all kinds of different data, I saw that openUrl seems to fail arbitrarily.  Budgee is a budgeting application where you enter categories and transactions and it tells you how much money you have remaining in your budget.  Well, when I added a new category, just one, the export would sometimes work.  When I took away that category, the export would sometimes fail.  The thing is, the data is more or less the same each time...the is a new record for the new category and the message has a new timestamp, but other than that, nothing changed.  But openUrl refused to actually open Mail about 1/2 the time I tried the export.  After more testing, it seems that even the timestamp can change the url enough to cause openUrl to fail - so it's not just the category data that is causing the problem.

At this point, I have verifed the URL I'm passing to openUrl is correct and encoded properly.  In fact, I went overboard and encoded everything other than basic ASCII letters - that should be overkill, but I saw reports of openUrl failing when periods were in the url (which should be legal)...so I opted to encode the heck out of the thing.  I passed the url to openUrl and guess what?  No dice - still refuses to open.  It does this 100% of the time as long as I hardcode this url into my test application.  So, the good news is that I've opened a bug with Apple (bug #6635825 if that is useful to you) and attached sample code that should reproduce this error consistently.  Before I opened this bug, there were posts by an Apple employee (also on the devforum) stating that they know there are issues with mailto: links, but they essentially haven't been able to track down what is happening to cause the issue.  Maybe the sample code I posted to them will help.  The bad news is that my customers still can't export data sometimes and I have no workaround other than to try adding a new category, transaction, etc. and then trying the export again.  That is totally unacceptable for me - but the only other workaround I can do is to totally re-write the export to use a method other than a mailto: link...but of course, that's not a trivial thing to do quickly.

The bottom line for developers is that if you're thinking about using a mailto: link to export data, be ready to hit this issue and have to wait on Apple.  It still isn't clear what triggers it.  It may be the complexity of the data I'm exporting, but it's just not clear.  There are quite a few reports around the different forums where people are having similar issues - so I know Budgee isn't the only app exhibiting this problem.  It looks like the only reliable way to get this data off the phone is to send it yourself via web service calls, export to google docs, built-in web server, etc...all of which are considerably more involved (for the dev and/or end user) than the mailto: link.

This tip is for any fellow iPhone developers getting the 0xE8000058 error when you try to install your app in debug mode on your physical device.  I just spent the last several hours trying to figure out what had happened when I tried to branch my code from a production (App Store) release back to a new dev build to start working on some new improvements.  As soon as I did that and changed my build configuration back to Debug, I started getting the 0xE8000058 error.  Turns out, there are all kinds of causes for it that you'll find online if you search google, but in my particular case, the cause is particularly redicious (and insane to track down).

I had recently found that you can give your application an icon in iTunes when distributed as Ad Hoc.  You do this by taking a 512x512 icon, renaming it to iTunesArtwork (no extention), and putting it in the root of your application bundle.  Works great.  BUT, apparently, you can't install a device debug build with that in your bundle.  It has no use in such a build of course, but I didnt expect it to break the install process...but it sure did.  So, if you're seeing this particular error and you've tried the other tips on google and nothing works AND you did put an iTuneArtwork file in your bundle - try this:

• Remove the iTunesArtwork from the bundle (you just need to remove the reference, you can leave the physical file there since you'll need to re-add it when you get ready to distribute the app)
• Run Build -> Clean
• Then run Build and Go (Debug)

That should do it (or did it for me at least...hopefully this will same someone else the hours of frustration I just went through to figure this out.  It'd be awesome if these Xcode error messages were just a tiny bit more helpful.