Known issues…

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!

Thank you

Wow.

There’s no denying the physical beauty of the award or the cool prizes that accompany it. But in this “day after” the thing that I’m finding most rewarding is the outpouring of support and congratulations. The six weeks of eating, sleeping, and breathing [REDACTED] preceded by months of digging through class-dump and respondsToSelector output was far from easy: but it’s all worth it.

From everyone here at the Iconfactory, all we can say is thank you. It means so much.

Unfortunately, we’re still under NDA and have been advised by Apple not to share screenshots. We’re all anxious to show off our work, but we need to respect the wishes of our new partner.

If you’re here at WWDC, you can get a look at the UI on the panels on the third floor. There are also some photos from last night’s event that hint at what’s about to come. For those of you wondering about the photo I took before going on stage last night: my big fat finger was over the lens on my iPhone—a great example of why ergonomics in your application is important.

Vote for virtualization

In this election year, there is an issue facing Macintosh developers. Ask yourself the following:

How can you develop new products for Leopard when you need to have Tiger installed for supporting your legacy applications? How easy is it to test a new feature on Mac OS X 10.4.11 when you’re running 10.5? How quickly can you reproduce a bug on 10.4.10 if you’re running 10.4.11? Can you run Xcode versions 3.0 and 3.1 at the same time from /Developer?

We all know the way to get Apple’s attention regarding our issues is to submit bugs. So now is the time to vote for virtualization. If you agree with the following, please copy and paste this bug report and submit it so that it becomes a duplicate of Bug ID# 5812840.

Summary:

A Macintosh developer’s ability to produce world-class products is inhibited by the lack of desktop virtualization.

Steps to Reproduce:

  1. Create a virtual machine using VMware or Parallels on your desktop.
  2. Try to install Mac OS X on this virtual machine.

Expected Results:

You should be able to install and run any version of Mac OS X on this virtual machine as long as the host is a Macintosh.

Actual Results:

The installation does not work.

Regression:

This ability has never existed, but ever since the arrival of virtual machines in Mac OS X, developers have dreamt of being able to do this.

Notes:

The ability to run multiple versions of Mac OS X has many benefits for a Macintosh developer and for Apple:

  • Being able to run any version of Mac OS X in a virtual machine makes it much easier for a developer to create features for both older and newer versions of the operating system. Many developers need to support their existing applications on the current platform, while at the same time developing new applications for an upcoming version of Mac OS X. For example, developers would like to have virtual machines that would allow Tiger and Leopard to run at the same time. The benefit to Apple is that there will be many more applications available at each new OS launch because the barriers to developing on that new OS are much lower.
  • Developers constantly need to test their products on various versions of Mac OS X. If a customer reports a problem on 10.4.11 and the developer is running 10.5.2, there is a significant amount of effort required to bring up a system that allows investigation. The result is that many problems are ignored or deferred. With virtualization these barriers are removed and fixing bugs becomes much easier. The benefit to Apple is higher quality software for the Macintosh platform.
  • Apple often releases beta versions of development tools that are not compatible with older versions. One such example is the current Xcode 3.1 release—it cannot be run simultaneously with the 3.0 release. This creates a situation where a developer working on iPhone applications cannot work on their current Macintosh applications at the same time. Again, developer productivity suffers and the availability of products for both of Apple’s platforms is affected.

Virtualization is currently being made available for the Mac OS X Server product. We respectfully ask that Apple make the same features available in the desktop version of the operating system.

Update: Several people have written to inform me that you can run Xcode 3.0 and 3.1 side-by-side. While this is true, I have heard that there are some problems. We all appreciate the excellent job the developers at Apple do with Xcode and the other fine tools we work with, but there will always be growing pains as these tools advance. Virtualization would lessen the impact of change on our development environments.

More brain surgery…

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?

A new kind of partner

While speaking with a writer from Business Week the other day, a thought occurred to me: the App Store radically changes the quantity and quality of Apple’s partners.

With the iTunes Store, Apple has partnered with a handful of media companies for recordings and video. And those partners are deathly afraid of online distribution. Developers, on the other hand, will number in the thousands (or much more.) We also embrace online distribution wholeheartedly.

We will ask for things a media company would never even consider. Expect there to be a learning curve for both parties involved in this endeavor.

Update: Daniel Jalkut points out that we have our own fears.