Release day

Unless your Internet tubes are broken, you’re probably aware that we released Frenzic for the iPhone today. It’s been a long time coming, but we’re all very proud of what we’ve accomplished—and very grateful for the great feedback we’ve been getting. As always it’s been a great pleasure working with Wolfgang Ante on this game.

But let’s go beyond all of this self congratulation and look at some of the details about how to coordinate your App Store release.

The first trick is setting your release date. As we all know, there can be some long wait times in the iTunes Connect queue. Indications are that the approvals are getting quicker, but it’s still an indeterminate value. And not knowing when your application is going to appear in iTunes means that it’s hard to coordinate press releases, website updates and other things that are dependent on having an product for sale.

The way to handle this is surprisingly simple: when you add or update your application in iTunes Connect, set the release date far into the future. Then, once you’ve been approved, you can update the release date to coordinate with PR. We knew that Frenzic would show up in the App Store on November 19th. But we didn’t know exactly when.

So what does it mean to “show up” in the App Store? iTunes is a worldwide enterprise so the date and time on your wall clock doesn’t mean much. There are timezones that will see November 19th before you do. Since Frenzic stores scores with unique ids and timestamps on its website, we collected some data that provides insight on how applications are deployed on iTunes.

The first scores started coming in just before midnight GMT on the 19th. The bulk of the traffic was coming from throughout Europe, although there were also some scores from Australia. As far as the listing in iTunes is concerned, we first saw it appear in the UK store. It then appeared in Sweden and Austria: this was not an exhaustive search, merely one of convenience (we have employees in these countries.)

The most important thing, of course, is getting the iTunes link for the product. This link is used throughout the site on buy links. We needed this information before doing a website deployment.

Happily, the link that showed up in the UK is also the same one that’s used in the US (we assumed it would be, but were reluctant to a deploy until we were sure.) You can get the link by control-clicking on the product icon in iTunes and selecting “Copy iTunes Store URL”. The resulting URL looks something like this:

http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=296581959&mt=

Unfortuately, the only way to know this URL is by having it show up in iTunes. It would be nice to have this information ahead of time, and if you agree please submit a duplicate for ID# 6386452.

Updated November 19th, 2008: Thanks to Derek Del Conte there is a way to get the application ID. Just click on App Details in the “Manage Your Applications” list. The “Apple ID” can be used to create the link.

Another option for the purposes of deployment is to use a URL with the product name:

http://www.itunes.com/app/Frenzic

This format generates a redirect to the iTunes product URL. Unfortunately, it has been buggy in the past, so use it sparingly.

Finally, I’ll leave you with some eye candy. Wolfgang has posted some screenshots of Frenzic throughout its development:

  • The first prototype that we ever played on OS X. This is what got everyone at the Iconfactory hooked.
  • The game screen. The first pass at this used the same color scheme and contrast as the desktop version. That was a bad idea: put this screenshot in Photos and take it outside and you’ll see why.
  • The scores list. There is an art to making table views look nice. Both Wolfgang and I are lucky to work with some very talented designers :-)

So give Frenzic a try and if you like it as much as we do, tell your friends. Thanks!

Killing our enthusiasm

Dear Steve,

I am an iPhone developer. I love Cocoa Touch—it’s an amazing piece of engineering. I’m having great success with the products I’ve written (one of them even won an ADA at this year’s WWDC.) Sales through iTunes are great and well above my expectations.

And despite of all this, I’m feeling ambivalent about developing new applications for the iPhone.

Of greater concern is that I’m not alone: many of my colleagues are starting to feel the same way. To illustrate, here are some thoughts from people whose work I respect and admire:

Steven Frank – Panic (Transmit/Coda/Unison)

Fraser Speirs – Connected Flow (Exposure)

Wil Shipley – Delicious Monster (Delicious Library)

Brent Simmons – NewsGator (NetNewsWire)

You should also be aware that much of the discontent is being masked by the NDA that’s currently in place. I, and many others, do not want to anger Apple and there are no forums to voice our concerns privately.

As you’ve seen throughout your own career, great engineering is not driven solely by financial rewards. Woz didn’t write Integer BASIC by hand because he thought it would make him rich. Andy Hertzfeld’s and Bill Atkinson’s work on the original Mac wasn’t motivated by greed.

Great developers create amazing software for love as much as money. Take away the artistry and craftsmanship and you’re left with someone pumping out crapware for a weekly paycheck.

I have worked on many different platforms throughout the years: the most important benefit to working on the Mac is the vibrant community of developers. The high quality of Mac applications is due in large part to great developers being able to learn, compete, innovate, and share in a common success. This camaraderie sustains the love for the platform.

I was hoping the same would be true for the iPhone. Sadly, it’s not, and that makes this new platform really hard to love. I’m trying to stay positive in spite of recent developments, but I’m finding my attraction to the iPhone fades a little bit each day. I think it’s important that you know that.

Thanks for your time,

Craig Hockenberry

P.S. As I was writing this essay, Jason Snell and Dan Moren posted some articles at Macworld about the App Store and NDA. The disaffection is starting to spread outside the development community.

Update October 1st, 2008: Thank you.

Nike – iPod

Having just presented a talk at C4[2] about the human factors involved in developing touch-based applications, I find it rather ironic to see the Nike + iPod integration move into the latest iPod touch.

Why? Because I see some serious problems with how our bodies will interact with this device and its software.

Note: These are first impressions. I obviously haven’t had a chance to use the product, so the implementation by Apple/Nike is just a guess at this point in time. I’ve heard that there are some special controls in this software that allow “eyes off” control: if that’s the case, then we’ll all learn something from that UI.

The first problem is the size. When I’m running, I want the smallest piece of equipment possible. The simple reason is that any mass acts as a pendulum as you move. Sure the new iPod touch is lighter than its predecessor, but it’s still bigger and heavier than its nano sibling. Bigger is certainly not better.

There’s also a problem with where this device will attach to your body. Because of the size and weight, it’s likely that you’ll need to use it on an armband or in your pocket. Both of these locations present problems with interaction. You can’t see buttons on a touch screen when they’re in your pocket. It’s also uncomfortable to operate an interface that is strapped to your arm: try to unlock, launch and use an application while it’s positioned on your upper arm. Now do it while you’re running.

Good luck finding the PowerSong button without looking, too. Unlike the Nike + iPod application on the nano, this and other operations can’t be done solely by feel. Being able to operate the device while running is essential: you literally don’t want to take your eyes off the road. This “eyes off” approach to interaction is why the new iPod touch has physical volume buttons and why it was the most popular request by customers.

Some may argue that this device will be fine in a more controlled setting such as a gym. But if you’re running on a treadmill, there is already plenty of feedback from the machine’s built-in sensors and monitors. You don’t need a sensor in your shoe.

But in either case, you’ll find the biggest interaction problem is that sweaty fingers don’t work well on a capacitance-based touch screen. The salts in your body fluids make it much harder for the device to recognize your input. If you don’t believe me, try dissolving a teaspoon of salt in a cup of water. Then dip your finger in the salty water and try using the screen. You’ll find touch controls are jerky and non-responsive. Now add some body movement and you’ve got a real interaction problem.

Sometimes a few simple buttons, and not a fancy multi-touch UI, is the best way to solve an interaction problem. 

 

Listeners found this review helpful

A major feature of the App Store are the user reviews about the software being offered. There’s just one problem: software is not music. I’ve never had an MP3 crash or lack features. Applications also evolve and improve; I’m pretty sure the Jimi Hendrix track I’m listening to right now is the same one he recorded in 1969.

The App Store in iTunes fails to address these fundamental differences between their latest offering and what has been offered previously (media.) There is so much potential here: iTunes could be a great way for developers to collect feedback and find problems. Instead, we get gems like these:

The icon to this App scares me so much… That I’m too afraid to install the App. That bird looks angry like it wants to peck my eyes out for even concidering [sic] to install the application.

If you are gullible enough to watch FOX “News,” then you are gullible enough to download this app and work for them for FOX for free– you already are in a way, just by watching. This would be a great app for those of you that like to monitor “ethnic” types when the nation goes to “Code Orange,” or, God forbid, “Code Red!” Make sure you have this app when you’re digging your bomb shelter or spying on your neighbors’ subversive activities.

What makes this worse is that flagging reviews as inappropriate content seems to have no effect. I have flagged reviews of my own products, and those of other developers, and nothing has changed. If Apple wants developers and users alike to take this system seriously, they must address this problem immediately. Yes, it’s tedious and costly to do this review, but with continued neglect this system will end up being like YouTube for software.

If you have doubts that this will happen, take a look at the most helpful review for Band. Users are already learning how to game the system.

Some have suggested that buying the app should be a requirement before leaving a review. I agree, but this will not completely mitigate the need to vet content. A large percentage of applications are free: the trolls will just download before going on their merry way.

If all of this wasn’t depressing enough for developers, I’ll leave you with my biggest disappointment: reviews are a one way street. I’m not one to feed the trolls, but many of the reviews I’m seeing would benefit from a “Just try this…” or “We’re working on that…” type of response. There’s not even a link to our support on the reviews page.

I remain hopeful that someone at Apple will see what’s going on and have the power to fix it. My only advice would be to act quickly: the longer you wait, the harder it will be to clean things up.

Bugging

It’s pretty clear that the App Store is a huge hit. We’re all loving the ability to customize our iPhones and iPod touches with cool new software!

But with any big new release, there are problems that didn’t pop up while beta testing. As iPhone developers, we’re finding ourselves in a position where we can’t help customers who are encountering these issues.

Let’s take a couple of examples with our app Twitterrific. My friend Jeffrey Zeldman reports a problem where the application would crash just after launching. Another developer friend, Alex King, is having a problem with an authentication alert appearing when it shouldn’t. As a conscientious developer, I want to help these people and fix these bugs. The problem is that I have no tools to do so.

Jeffrey’s problem appears to be something with data that is stored on the phone. Alex’s problem is likely to be an issue with how data is being loaded from the network (from Twitter.) Note that I say “appears” and “likely”; I don’t know for sure, and that’s what is bugging me.

The first problem is knowing where the crash is occurring. The iPhone generates a crash report that automatically gets synced with iTunes. The crash report is stored in ~/Library/Logs/CrashReporter/MobileDevice. Unfortunately, this crash report is “raw” and developers don’t have tools to make it easy to understand (e.g. “symbolicating” crash reports only happens when they are loaded through Xcode’s device organizer.)

And even if I could interpret these crash reports, I’d be faced with another problem. There’s no way to gather additional information about what’s happening on Jeffrey’s and Alex’s device. With a desktop application that’s acting up, developers will often add logging and other kinds of output that track what is occurring around the time of a crash or other misbehavior.

In Jeffrey’s case, I would want to dump out the internal database that’s in use at the time of the crash. For Alex’s bug, I’d want to track the network requests to Twitter and the corresponding response. It’s easy to add this logging to Twitterrific, but the only way to retrieve the results is if you are a registered developer. There is no way I’m going to ask Jeffrey and Alex to spend $99 and install Xcode just so I can collect some debug output.

Assuming that I could get some debugging output, the next step in resolving these problems would be to create a special build with a proposed fix. After having Jeffrey and Alex verify the fix, I’d distribute that same build to a larger group of testers so that we could test for regressions (e.g. we don’t break some functionality in the process of fixing something else.)

The big problem here is that the only way to install software on an iPhone or iPod touch is with the App Store. There are also no provisions for beta testing. Without the ability to sign code, there is no way for a user to get code onto a device: most users fall into this category.

The only way to “test” a fix is to release the changes to tens of thousands of users. It’s the developer equivalent of playing Russian roulette.

(Note: there may be workarounds to some or all of these problems, but with the NDA in place, it’s difficult for developers to share their experiences and solutions.)

Apple has done an fantastic job with the tools that let us develop iPhone software. That’s clearly evident from the fantastic work we’ve seen displayed in the App Store. Unfortunately, the tools that developers use to analyze and debug problems are sorely missing at this point in time.

It’s our hope that this essay will do two things:

  • As a user, please be extra patient when developers tell you that they are working on a problem—it’s hard work at the moment and the time it takes to resolve an issue will be longer than with a desktop application.
  • We hope that bringing these shortcomings to Apple’s attention will help them address the issues and improve the iPhone SDK.

Until then, these problems will be bugging us all.

Updated July 15th, 2008: If you’re a developer, please feel free to submit a duplicate (“me too”) bug on the following Radars:

Updated July 16th, 2008: After fixing bugs for customers, Brent Simmons notes that there are frustrations with the final part of the development cycle: making public releases.

Updated July 23rd, 2008: Brandon Sneed has discovered some techniques for doing remote debugging of iPhone applications.

Updated August 6th, 2008: We don’t have to play Russian roulette anymore.

Updated August 8th, 2008: I discovered how to “symbolicate” crash logs.

Updated November 10th, 2008: Getting preferences and data from customers who are having problems just got a lot easier.