UPDATE: As Todd points out in a comment, the bug described here has been fixed in 3.2.4. That's now out of beta, and registered developers can download it from Apple.
(This is a continuation of a previous post. You may want to read the first post in this series for an overview of the architecture.)
The last problem I'm blogging about is actually the first one that I encountered. It's also what first inspired me to write this "Dealing With Dashcode" series of posts.
Early on in my development process, I made sure that I had the latest XCode installed (3.2.3), which is the iOS 4 development environment; my app is targeting iOS 4 on iPhone 3GS and 4. The iOS SDK includes the iPhone Simulator, with environments for iOS 3.2 on the iPad, and iOS 4 on the iPhone 3GS and iPhone 4.
Here's what I've been able to work out. Dashcode implements this debugger by loading an extra framework into Mobile Safari when it launches. When you click the "Run" button, Dashcode launches Mobile Safari with some extra arguments to load a framework called CayenneClientDebugger (which is within the Dashcode executable). It looks like Mobile Safari (as well as the Browser Simulator that's part of Dashcode's Safari targeting) has hooks to load this framework for some debugging usage. The debugger UI that's built into Dashcode communicates with the debugger backend loaded in Mobile Safari.
(By the way: I looked online to see if I could find any references to this Cayenne. There's an Apache project named Cayenne, but it seems unrelated. I suspect that Cayenne was the internal codename for Dashcode; it looks like the bulk of Dashcode is implemented in a framework called CYKit.)
Now, here's the catch. iOS 4 uses a different ABI than 3.x did. It looks like the CayenneClientDebugger is built for the old version. Mobile Safari refuses to load it, so instead of a debugger, all you get is a message in system.log.
I tried to cherry-pick a few bits of XCode from a backup I had from before I upgraded it. I tried copying iPhoneSimulator3.0.sdk into the current installation, and although the iPhone Simulator would display the 3.0 version in its Version menu, if I tried to actually select it, then the Simulator would crash. I tried a few other combinations of replacing the Simulator, CayenneClientDebugger, and even all of Dashcode, but couldn't get anything really going. I probably could back out the entire XCode installation, but that's a bit far.
As it was, I never did solve this problem. I just made a lot of use of console.log for debugging purposes. If I needed something more than I could get that way, then I'd use Safari (the OS X one); I could load my webpage there and use Safari's built-in development tools. The most signifiant bit of UI I was using for this app (StackLayout; it's essentially a nested list that you navigate one level at a time) doesn't actually work in Safari — only Mobile Safari — but I could still test little bits in some ways. It was enough for me to finish coding.
I haven't looked into the 4.1 SDK yet (as of this writing it's in beta and has limited availability); I hope that Apple's fixed this problem. Not having access to a debugger makes Mobile Safari development a bit tricky.
IBM has an article on using Aptana (a webapp development system for Eclipse) while developing iPhone web apps. It's entitled "Debug iPhone Web applications with Eclipse", but in truth, Aptana doesn't support the iPhone for debugging. Instead, the article recommends you use Firefox with Aptana to debug your application. Uh... no thanks. WebKit and Gecko are different enough that, if I'm developing an iPhone-specific application, I'll want to do my development with Mobile Safari.
Neither of these was really worth the effort of learning; the app in question is simple enough that console.log does everything I needed. But I do hope that Apple has fixed this problem in the newest Dashcode.