atomicbird

Since the iPhone SDK was first released in March, the biggest roadblock to developing good iPhone software is that iPhone developers are officially prohibited from talking to anyone about what they're doing. In order to get the iPhone developer tools, you have to accept to a non-disclosure agreement with Apple. The NDA covers not only the development tools, but itself. I'm not even really allowed to mention what the NDA says, because doing so violates the NDA. I'm hoping that detail will be seen as minor enough that I won't get sued. Saying that the NDA prohibits discussing iPhone development should be OK, since Scott Anguish of Apple has publicly said so many, many times.

One of the most useful sources of information for a software developer on any platform is... other developers working on the same platform. The ability to discuss issues with other developers, compare notes, and get questions answered is extremely valuable. But none of that is allowed for iPhone developers.

This has a direct effect on software quality. Although Apple provides documentation, that doesn't always explain things. Normally, faced with a difficult situation, I'd ask around and see what other people might do. The only permitted way to do that now is through Apple tech support incidents. If you're one of the lucky ones allowed to pay $99 to join the iPhone developer program, you get two incidents, meaning you can get two questions answered. If you have more questions you can buy more incidents for $195 each.

The NDA almost made sense when the SDK was first released. And anyway it had precedent, in that when Apple distributes pre-release software to developers, an NDA always applies. Historically the NDA on a particular release has been lifted when that version is released to the public. This has always been the case with pre-release versions of Mac OS X.

iPhone OS 2.0 was released on July 11. But the iPhone NDA still applies. The rationale for the difference with Mac OS X, as explained on Apple's Cocoa-Dev mailing list, is that Mac OS X releases always include developer tools, while the iPhone release does not. Since the public release of Mac OS X means making the tools publicly available, the prior NDA can no longer apply. With the iPhone this is not the case.

With no obvious milestones on the horizon, and with Apple reps continuing to repeat that the NDA still applies, I can't help wondering if the current situation will ever change. It's not like an iPhone OS release is ever going to include developer tools, because the tools don't run on the iPhone. At this point the iPhone NDA could apply forever, a prospect I find depressing but which I can't dismiss.

All of this might make a tiny bit of sense were it not for the fact that iPhone developer information is in fact widely available. Google turns up results for virtually any search term related to iPhone development. Of course, since I've had to accept Apple's NDA, I could not possibly comment on whether those results are accurate.

I also could not possibly comment on whether the iPhone developer discussions taking place at Apple's own web site are giving useful answers. Apple's steadfastly forbidding iPhone discussion on their Cocoa-Dev mailing list, but if you use their web site instead they don't appear to mind.

If you mention any of this on Cocoa-Dev you'll receive sanctimonious responses about following agreements you've accepted. Which, typically, ignore the bizarreness of so piously pretending to protect the privacy information which is already widely available to the public.

So why aren't I using that web site? Because iPhone development has so far been profitable enough that I can't risk being booted from the official developer program. I won't say I haven't looked at them, though as mentioned I couldn't possibly comment on whether I've found anything useful there.

The situation bears a striking resemblance to US laws restricting the export of encryption software. Those laws were based on the idea that, since bad people could use strong encryption to hide their plans, it was important to keep this software from getting into the hands of people who didn't have the good sense to live in the USA (because apparently that's where all the bad guys are). They also neatly ignored the fact that this software was widely available outside of the US anyway. The net effect was a bunch of idiotic restrictions that utterly failed to achieve their intended goals.

And so we proceed. Apple with its fingers in its ears, pretending that its NDA is keeping something secret, developers like me facing a major hurdle as a direct result, and anyone else with a passing interest in the topic having no trouble getting all the information they might want. Apple, you can pretend all you want, but you're not achieving anything useful to you in any way by doing so.

You haven't seen it on this web site, but it just so happens that I've completed version 1.0 of my first iPhone application, which is now available in the iPhone app store. The reason it's not here is because, as I described briefly back in March, I developed the app on a contract basis for someone else.

The application is called AirMe (which is also the client's name). In simplest terms it's a network-enabled camera application. You take a photo with the built-in camera, and the application immediately uploads it to the web. Right now it supports Flickr and AirMe's own photo-sharing site. The app also does some cool auto-tagging and titling of the photos-- like getting your location from the phone and doing a reverse-geocode lookup to get the name of the place the photo was taken. That information is used both for tags and for a generated title for the photo. It also finds the local weather conditions ("sunny", "83F") for use in tags. It can also automatically create Flickr photosets based on location, meaning that if you're in San Francisco, you can have photos automatically go into a "San Francisco" set.

You can of course disable the weather, location, and photoset stuff if you choose. Or add your own custom tags.

And it's free. If you have an iPhone, go and get it, OK?

It's been an interesting development process, enabled by great tools and frameworks from Apple, and simultaneously hampered by the slow process of getting into the iPhone developer program and by a bizarrely draconian non-disclosure agreement. For that last reason I can't actually discuss the development much. I will mention that, if you do go and try the app, keep in mind that there's already a bug-fix release just waiting to get posted to the store. I uploaded it to Apple a couple of days ago but so far it's just sitting there waiting for Apple's blessing. Rumor has it that updates can be very slow in processing.

The most interesting thing about getting this app into people's hands is that, unlike other software I've worked on, I can get a direct, personal insight into how people are using it. Flickr uploads have been a popular choice, and most people are making their photos public. As a result I can go over to Flickr anytime I like and see exactly what people are doing with the application. You don't get that with most software. You design expected use cases, you get feedback from a few people, but what people do with your software still often seems like a remote, almost abstract reality. This direct connection is a new, amazing experience.

I could sit and look through those pictures for hours. A woman walking her dogs in California. Two guys having beer in Germany. A family at a restaurant in Australia. A woman with straws up her nose in the UK. A rainy day in Tokyo. All of these people using software I wrote to share their pictures. Of course it's not my software per se since I wrote it for a client, but after putting this many hours into it I can't help feeling proud of my surrogate-child app.

More on this, and iPhone development in general, to come.

(XCTOTD == Xcode Tip of the Day, BTW).

Recently I found that the quickest way to get something working in a project was to borrow some HTML. I could have done it all in Cocoa, but someone had already created an HTML form for what I needed to do. Pressed for time, I decided to take this HTML, drop it into a web view, and be done with it. The purpose of this part of the app was to collect information to send to a web server anyway, so why not let an HTML form do what HTML forms do best?

Maybe because the HTML was not designed with this use in mind, and would look like crap? But that's not hard to fix, given that I have Dashcode just sitting there trying to look useful. It was quick work to set up a Dashcode project, drop the HTML form into it, make it all look nice, and then export it into something I could use in my application.

Dashcode, of course, exports a bunch of stuff, not just HTML but also miscellaneous Javascript files and images, all in a folder. Not a problem. I added the folder to my project in Xcode, as an application resource. Then I added a copy files build stage to make sure the new files stayed in their own folder in the compiled app. Compile the app, and... OK, now we have a problem.

Five new compile warnings. That's pretty impressive given that I hadn't actually edited any of the source code in any way. I didn't think I had added any, but Xcode believed otherwise:

warning: no rule to process file 
     '$(PROJECT_DIR)/signup-1/iphone-carriers.js' of type 
     sourcecode.javascript for architecture i386
warning: no rule to process file 
     '$(PROJECT_DIR)/signup-1/main.js' of type 
     sourcecode.javascript for architecture i386
warning: no rule to process file 
     '$(PROJECT_DIR)/signup-1/Parts/setup.js' of type 
     sourcecode.javascript for architecture i386
warning: no rule to process file 
     '$(PROJECT_DIR)/signup-1/Parts/Text.js' of type 
     sourcecode.javascript for architecture i386
warning: no rule to process file 
     '$(PROJECT_DIR)/signup-1/Parts/utilities.js' of type 
     sourcecode.javascript for architecture i386

Um, what? On the one hand I'm not all that surprised that Xcode doesn't have a build rule for Javascript files. On the other hand, I don't want it to process them, I just want it to copy them to the right place and move on. As far as I'm concerned, it's good that there's no rule to process these files, but why is it even trying?

Google, usually quite helpful in these situations, wasn't giving me much to go on. I was especially puzzled by the fact that these warnings showed up in Xcode's "checking dependencies" step. Why would there be any dependencies on these files?

I conducted what I thought was an extensive search through project settings and found nothing useful. I briefly considered creating a do-nothing build rule for Javascript files just to shut Xcode up, but held back for the moment on the grounds that it seemed like the stupid solution.

Finally I closed Xcode and looked at the project file in a text editor. Xcode projects are really file bundles, and the hidden file named project.pbxproj is where all the project info goes. Now things got interesting. In the file list, each of the Javascript files appeared twice-- once in "CopyFiles" and once in "Sources". Xcode had added the Javascript files as source code, but then found it didn't actually know what to do with them at compile time. Seeking a quick fix I edited the file (don't try this at home kiddies, this man is a trained professional driving on a closed track) to delete all reference to Javascript files as source code. I reopened the project in Xcode, compiled, and the errors were gone.

That got me going again, but it bugged me. Was that really necessary? It turns out not. Repeating the steps on a test project, I found that I could have fixed it all in Xcode. When I added the files to the project, Xcode had helpfully added the Javascript files to the "compile sources" stage of the build process. Except, as it soon complained, it couldn't handle this addition at compile time. Deleting the Javascript from this build stage fixed the warning message.

Anyway, I'm off to file a bug. Xcode shouldn't add files as source code unless it knows how to process them. Either don't put them in that stage or put them in but know what to do with them (even if it's "do nothing").

As promised, here's a recording of Thursday's performance of "Designated Initializer", performed by James Dempsey and the Breakpoints.

• Designated Initializer - James Dempsey and the Breakpoints

If you're not a Mac developer, you probably won't get it.

This was recorded on my MacBook Pro using the built-in microphone, using TapeDeck. I edited the raw recording with Fission.

OK, the rumor that Coldplay would play the WWDC bash tonight was off. Instead it was Barenaked Ladies, which as far as I'm concerned was even better. Ever since the iTunes music store started taking off, the bands at WWDC have been better known. In recent years we've had the Wallflowers, BT, and Ozomatli.

The band made a great match to the crowd, not just because they're talented and funny but also because they're dedicated Mac-heads playing to a crowd of the same. Not many bands would crack jokes about Apple-related stuff ranging from the Newton to Mac OS X 10.6, and not many crowds would respond so well to that kind of thing. Long, bizarre stories about the questionable content of semi-celebrity iTunes playlists? Check, and just the kind of thing the crowd would love.

For some reason EDGE data was severely off its game in the park where the bash was held, so my pictures were not quite so live as I would have hoped. I'm surprised there's anywhere in San Francisco not completely blanketed with wireless data coverage. At home it wouldn't have surprised me, but here? Next people will be telling me there aren't really hills in this city.

It was a musical day, as earlier one of the technical sessions featured James Dempsey continuing his tradition of geeky song performances. And I mean that in the best possible way-- the songs aren't on the schedule, but word gets around, and a good portion of the audience at this session was there solely to see Dempsey. This year's song was the Latin-inspired "Designated Initializer". If you write Mac software you'll know what the title refers to, and if you don't, it'd take too long to explain here.

I recorded a bootleg copy of Dempsey's song with Chris Liscio's excellent TapeDeck app. But I didn't have a microphone, and the built-in mic on the MacBook Pro doesn't exactly live up to the "pro" designation. If I can get the recording cleaned up enough I'll be posting it here.

Tomorrow's the last day of WWDC. It's not quite a full day, ending at 3:15, but there are some good sessions on the schedule. Keep an eye on Flickr for updates as they happen.