Category: Miscellaneous

Now that we’re all beta testing, we’ll hopefully get some crash logs from testers. But you’ll quickly realize that these crash logs don’t look as good as they do when you pull them off the device with Xcode’s Organizer: there are no symbols and fricken’ useless because you can’t tell where the code is crashing.

Thanks to the free-flowing information regarding this wonderful SDK we’re all using, it took me awhile to figure out how Xcode “symbolicates” these crash logs. The secret is here:

/Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Plug-ins/iPhoneRemoteDevice.xcodeplugin/Contents/Resources/symbolicatecrash

I copied this script into my ~/bin folder so I have easy access to from the command line. You’ll probably want to put it somewhere in your $PATH, too. I chose not to use a symbolic link because I don’t want to lose this valuable script during an Xcode upgrade.

After you’ve gotten things setup how you’d like, it’s a simple matter of running the script like this:

% symbolicatecrash Twitterrific_2008-07-21-191314_Nero.crash

Note that the script uses Spotlight to locate the .dSYM files used by atos. (Check the top of the PERL source code for a summary of how this tool works.)

This has a very important implication for your iPhone app development. It is absolutely essential that you save your .dSYM files for any release you make public. You also need to make sure that Spotlight is able to index those copies. (Some of us like to keep Spotlight out of project folders.)

I’d also suggest taking a look at the source code for the script. You’ll see that architectures besides “armv6” are supported: if you have a need to symbolicate logs from “i386”, “x86_64”, “ppc” or “ppc64”, it should work fine. There are also some options for parsing the crash log that I don’t fully understand. Yet.

Again, if Apple feels this information is crossing over the NDA line, I’ll be removing this essay. It’s probably a good idea to save it for reference. In any case, enjoy your newfound ability to symbolicate!

Update August 14th, 2008: symbolicatecrash has a bug that prevents it from working correctly when there is a space name in the path where the .dSYM files are being archived. Your app symbols won’t be included in the output if they are stored in a folder like “~/Projects/dSYM Archive”: use “~/Projects/dSYM_Archive” instead. (rdar://problem/6150458).

Update August 14th, 2008: If you add this script to the end of your build, it will automate the process of creating the .dSYM and .app archive. You’ll need to update the configurations which will be checked: $CONFIGURATION = “Distribution-Free” is specific to my project. Note that the .app binary that’s saved is not the same one that ends up in your build folder. It hasn’t been compressed or code signed (rdar://problem/6150088), but it appears to have enough information for symbols to be resolved with atos.

Update September 25th, 2008: If you’re having problems locating the crash logs, take a look at this article. It explains where iTunes puts the files on Mac OS X, Windows XP and Vista.

Update December 11th, 2008: Bryan Henry has discovered and fixed a bug with symbol name lookups. If you’re experiencing this problem, duping the Radar wouldn’t be a bad idea either.

First off, thanks to everyone for the kind words about the new version of Twitterrific. It’s really great to get all this awesome feedback! Don’t forget to post a review on iTunes: we want as many stars as possible :-)

As with any first software release, there are a few known issues:

• After you upload a picture to TwitPic, the keyboard disappears. This is an Apple bug which we can’t fix (they are working on the problem.) In the meantime, you can try to tap on the text area and when the loupe appears, so will the keyboard. If that doesn’t work, try tapping the “Close” button and then tap the Reply or Post button again to refresh the interface (your text will be preserved.)
• Some images uploaded to TwitPic are not rotated correctly. Again, this is a bug with the EXIF data that Apple is putting into the JPEG image. We are working on a workaround now, but didn’t have it ready in time for the launch. We’ve also heard from TwitPic that they are working on some AJAX code that will rotate the images directly in the browser, so that may help in the short term.
• Scrolling is jerky. Because we have links and variable height rows in the list, we are pushing the limits of the processor. We have some ideas of how to improve this in the future, by only displaying the text of the tweet after the scroll finishes (similar to how the avatar images work now.) This is really tricky code to write and we had a very tight deadline—trust me when I say it bugs us, too :-)
• The Sigur Rós ad from The Deck displays incorrectly. The root of the problem is that Twitterrific can’t handle HTML entities. It could, but that would compound the problems with jerky scrolling mentioned above. We’re working with the folks at The Deck to change this over to UTF-8 so it will work OK on the phone.
• Entering a “+” sign in your tweet ends up as a space after being posted. It’s surprising that no one typed this character in several months of testing. We’ll fix this ASAP.
• Launching the application can cause a restart of the iPhone. All indications at this point are that this is a problem with the iPhone OS and not Twitterrific (it’s happening with other applications.) We are working with Apple to resolve the issue. Please make sure to send any crash reports if prompted by iTunes. No matter how much you beta test, there’s always one problem that slips by—even if you’re Apple.
• Sorry, but we can’t offer discounts or free upgrades for the iPhone version to current Twitterrific users. There are no provisions on the App Store for developers to do this. Please contact Apple if you think there should be a way to do this—we already have :-)
• The push notification service announced by Apple during the WWDC keynote will not be available until later this year. We don’t know if Twitterrific will be able to support it or not: it requires additions/changes at the source of the data (Twitter) and the volume of information may be too great for Apple to handle. We are definitely keeping an eye on things and talking to the right people.

If you find something that’s not on this list, please let us know by using the contact form at the Iconfactory. Select “Support” in the drop-down menu. Thanks!

Now that I’ve covered some of the technical issues with background processing for iPhone applications, let’s take a look at why it’s a bad idea from the user’s point-of-view.

Assume that Apple changes their mind about background processing tomorrow–anyone can do whatever they want in the background. All the naysayers rejoice, and in a year’s time they’ll be asking Apple to remove background processing.

Why? Same reason as always. The iPhone requires a fundamentally different approach to user interaction. Something that goes way beyond the obvious things like the multi-touch interface.

If you can have a background process running on your iPhone, what is that process going to do when it detects a state change? What happens with a buddy comes online, or a new piece of data is available, or when a long running calculation is completed?

You’re going to want to notify the user, right? Again, “desktop thinking” makes this sound like a simple thing. But it’s not.

The iPhone is going to attract network aware applications like moths to a flame. In a year’s time there will be hundreds, if not thousands, of applications using the Wi-Fi and EDGE connections. You’ll likely have several of them on your iPhone: let’s say you have five.

You now have five independent sources for notifications. How do you let the user know which one is which? One might say, “make the sound different.” Another might say, “make something flash in the status bar.” Someone else might say, “make the phone vibrate.” Or even, “put up an alert box.” A truly sick individual might say, “Do all four.”

Can you see where I’m going with this? Your phone soon becomes a fricken’ pinball machine as multiple applications fight for your attention. With 24 notification permutations for every application, things will quickly get out of hand.

The desktop has evolved several mechanisms for notification: bouncing Dock icons, bezel windows, menubar icons, and things like Growl. These mechanisms all work together because they can share a common screen without unduly overloading the user.

But on the iPhone, you have a limited area and associated mechanisms for getting the user’s attention. In effect, it creates a notification bottleneck.

This notification bottleneck forces the user to work when figuring out who needs attention. First they have to recognize the notification by sound, feel or sight (or a combination of those senses.) Then they have to navigate to the recognized application, which may not be easy given the phone’s current state. Finally they need to deal with the source of the notification. Now imagine doing all this frequently: the network will end up being a constant source of distraction.

If you’re still unconvinced, let me ask you one final question: do you want to get IM notifications while you’re making a 911 call?