Under The Microscope

Archive for August, 2009

SoundSource 2.5 and a Story About the Menubar

SoundSource IconEarlier today we released SoundSource 2.5, an update to our audio device switcher. SoundSource is a handy little tool for rapidly adjusting the audio input and output devices on your Mac (switching between microphones or various speakers or headphones, for instance). Our new version 2.5 features full compatibility with Mac OS X 10.6 (Snow Leopard), and now requires Mac OS X 10.5 or higher.

Although SoundSource 2.5 does not have any new features, it has changed dramatically internally. The first place you will notice this, is right after you expand the .zip file it comes in: SoundSource is now an application.

A bit of background is probably needed here before that statement will make much sense. On MacOS X, there are two ways to display little icon-and-menu-thingys in the menubar.

The first method, is something called a “menuExtra”. All of OS X’s built-in menubar bits are done with menuExtras: the Volume control, the Clock, the Airport menu, and so on. You can see the whole list of them at: /System/Library/CoreServices/Menu Extras. MenuExtras offer several nice features. First, if you double-click them they will load in the menubar, and automatically open again each time you login. As well, you can command-click on them and drag them around, putting them in any order you like. Finally, if you want to remove one, you can command-click on it and drag it right off the menubar. They’re very nice all around. Unfortunately, their usage is limited to Apple applications only.

The second method for getting an icon-and-menu-thingy into the menubar, is something called an “NSStatusItem”. Nearly all third party applications that put things in the menubar, for example Airfoil Speakers, use NSStatusItems. Unlike menuExtras, StatusItems have no nice features. They display in the order they are opened in, they can not be reordered, and removing them from the menubar typically means quitting the application that is providing the StatusItem. All around, StatusItems generally provide an inferior experience compared to menuExtras.

NSStatusItems do have one very important feature on their side however: Apple officially supports their usage. Because menuExtras run as a plugin within the system process SystemUIServer, Apple does not allow third parties to create their own. Various methods of getting around this limitation (such as MenuCracker and MenuExtra Enabler) have long existed.

For all versions of SoundSource until now, we have used MenuExtra Enabler to allow SoundSource to exist as a menuExtra. This enabled it to behave like it was any other built-in system component, with full drag-and-drop support. As of SoundSource v2.5.0 and Mac OS X 10.6, we’ve finally given in, and converted SoundSource to be an NSStatusItem running as its own standalone application.

The reason is primarily one of defeat. With every new release of MacOS X, MenuExtra Enabler breaks and requires updating. We simply no longer care to fight Apple on this front. When it was relatively easy to improve SoundSource’s user experience by making it a menuExtra, we did so.

We now also believe that providing a good user experience in this area is Apple’s job and not ours: NSStatusItems should simply behave as menuExtras do, and if they don’t, the burden of fixing that is on Apple.

That all said, SoundSource running as its own application is not all that terrible. It is a little annoying to not be able to move it around the menubar, but there are some benefits. We no longer need an installer for it and it can live in your Applications folder like any other application. It’s also easy to open and close, and delete when you are done with it. And if we’re lucky, SoundSource may even work on OS X 10.7 without requiring an update.

That, and we got a pretty new icon for it.

Buy Software and Give to Charity

Looking to buy software for your Mac or iPhone? Do it through the PMC Software Charity Fundraiser, and you’ll raise money for charity too. You can find our own apps on the site, as well as many others.

Fission 1.6.6 Is Ready for Snow Leopard

Update: We’ve discovered (and fixed) a potentially serious crashing bug in Fission 1.6.5. We’ve already released Fission 1.6.6 to take care of this, so if you haven’t yet moved up, get Fission 1.6.6 now. If you’re already running version 1.6.5, update to 1.6.6 as soon as possible.

Fission IconToday we’ve released an update to Fission, in the form of version 1.6.5, which brings with it full Mac OS X 10.6 (Snow Leopard) compatibility. This update also has several new features along for the ride.

First up, it’s now possible to drag tracks from iTunes right onto Fission’s icon to open them up for editing. As well, we’ve added a button for the very handy Split at Playhead command, so that you can play until the exact point you want to make a cut, then pause and click Split at Playhead. Finally, in addition to a myriad of minor fixes, Fission 1.6.5 has smoother, more pleasing fades on lossless audio formats.

This is a free update for all licensed owners of Fission, so be sure to update whether you’re on Mac OS X 10.4, 10.5, or 10.6. Just choose Check For Update from the Fission menu, or click to download from our site. If you haven’t used Fission before, see how easy audio editing can be with a free trial.

Mac OS X 10.6 (Snow Leopard) Compatibility

Update: Our software is now 100% compatible with Mac OS X 10.6 (Snow Leopard), so update now!

Snow Leopard DiscThis morning, Apple announced that Mac OS X 10.6 (Snow Leopard) would be arriving in stores and on doorsteps this Friday, August 28th. So, it’s time to update you, our customers, on the compatibility of our software with the new OS.

We’re currently hard at work on updates for almost all of our Mac OS X applications for Snow Leopard. While Radioshift, Pulsar, and LineIn all work fine already, and we’ve already updated PongSaver for compatibility, other applications will need updates.

Specifically, Airfoil, Audio Hijack Pro, and Nicecast require updates to the optional Instant Hijack component. We’re hard at work on Audio Hijack Pro, Airfoil, and Nicecast updates. Meanwhile, Fission needs an update to handle changes in the decoding of Apple Lossless files.

We hope to have these updates out by Friday, but we’re not certain we’ll make that deadline. Your best bet is to check our site for updates over the next couple weeks and be sure to install the latest versions when they’re released.

So keep your eyes on our status page and we’ll have more updates soon.

Note: Some users might notice the MemoryCell is absent from this page. At this time, we have no plans to update MemoryCell for Mac OS X 10.6, due to increasing technical challenges and time constraints. MemoryCell has always been open-source, so for those who may be interested, the source code for MemoryCell is free to all here.

Reading Between the Lines of Apple’s FCC Reply

Three weeks ago the Federal Communications Commission wrote a letter to Apple to inquire about their rejection of the Google Voice iPhone application, and subsequent removal from the App Store of other iPhone applications related to Google Voice.

Apple’s rejection of this app brought up a lot of questions in the community about Apple’s relationship with AT&T and the openness of the platform, and it seems that the FCC had similar thoughts. This was bound to produce something interesting from Apple because, while Apple may ignore most people in the community, they were not likely to ignore the FCC. Today Apple replied to the FCC and made this reply available to the world. Since Apple is usually reluctant to provide any information at all about the App Store, this letter provides an interesting inside look.

Introduction
The beginning of the letter reveals that Apple is justifiably proud of what they’ve achieved with the App Store. This is not directly related to the FCC’s inquiries, but Apple clearly wants to put their reply in context. They note 65,000 iPhone applications, less than three months after they announced 50,000 apps. The platform is certainly not hurting for developers. They also point out that AT&T has no direct say in what applications are available for the iPhone, which was an unusual situation in the US at the time. Those of us who look at the iPhone from a personal computing perspective tend to see it as restrictive, but from a cell phone perspective it’s relatively open, at least relative to American smartphones circa 2007. While I personally believe it needs to be much more open still, this is still an interesting point to consider.

Protection
Next, Apple explains why they have a review and approval process for iPhone apps. They state that they review apps, “in order to protect consumer privacy, safeguard children from inappropriate content, and avoid applications that degrade the core experience of the iPhone.”

These reasons are interesting. The first one, privacy, is completely justified and I won’t spend any more time on it. The next one, “safeguard children”, is much less justified in my eyes. It’s certainly a noble goal, but the vast majority of iPhone users are not children. Restricting what content is available on my phone does nothing to protect children, as no children ever get to use it.

The last reason is the most interesting to me. They state a wish to, “avoid applications that degrade the core experience of the iPhone”. How would an application actually accomplish this? It’s an interesting thought experiment. The iPhone presents a highly restricted environment to applications. Apps can’t run in the background, can’t access files belonging to other apps, can’t prevent the user from quitting them, and in general can’t really do much that’s harmful. If the user isn’t running your app, then you can’t do anything to degrade his core experience. What is Apple afraid of here?

The answer can be found in Apple’s response to the FCC’s first question, regarding why Apple rejected the Google Voice application. This answer starts off with a wonderful piece of doublespeak:

“Contrary to published reports, Apple has not rejected the Google Voice application, and continues to study it.”

In other words, it hasn’t been rejected, it just hasn’t been approved! I can’t fathom why Apple wants to make this distinction, or draw attention to the fact that they often leave apps in limbo for weeks or months without an explanation.

Back to the degraded core experience. Apple talks about how the Google Voice application replaces the standard telephone functionality of the iPhone with Google’s version, which looks and acts differently. Google Voice provides its own system for receiving voicemail, using SMS, working with contacts, and performing other related tasks. In short:

“[Google Voice] appears to alter the iPhone’s distinctive user experience by replacing the iPhone’s core mobile telephone functionality….”

This would be a decent justification… if it were even remotely true.

The fact is, Google Voice can’t replace anything. As I mentioned above, iPhone applications run in a restrictive environment. It is completely impossible for an application to replace another application, or indeed affect it in any way. No, all Google Voice does is provide an icon, a regular application icon like any other, which the user can use if they wish. As with any other iPhone application, if the user doesn’t launch it, it doesn’t run. The user can continue to use all of the normal built-in iPhone functionality exactly as they always have.

It would seem that Apple’s true concern with the Google Voice application is that it “duplicates functionality”. It’s well known that Apple hates applications which duplicate functionality that they already provide. Apple rejected a podcast app because it duplicated the podcasting functionality of iTunes (on the desktop!). They rejected a GMail app because it duplicates the functionality of the Mail app. And now they’ve apparently rejected several Google Voice apps because they duplicate the functionality of the Phone app. But the way they explain it, saying that they work “by replacing the iPhone’s core mobile telephone functionality” is misleading at best, if not an outright lie. They provide an alternative, but do not, and can not, replace it.

Terms of Service
The answer to the third question provides an interesting window on the relationship between Apple and AT&T. It states:

“There is a provision in Apple’s agreement with AT&T that obligates Apple not to include functionality in any Apple phone that enables a customer to use AT&T’s cellular network service to originate or terminate a VoIP session without obtaining AT&T’s permission. Apple honors this obligation, in addition to respecting AT&T’s customer Terms of Service, which, for example, prohibit an AT&T customer from using AT&T’s cellular service to redirect a TV signal to an iPhone.”

Ignoring the question of why it’s Apple’s job to prevent their customers from breaking AT&T’s terms of service, it’s interesting to note just how much this policy is centered on the United States. The iPhone is sold in dozens of different countries and works with dozens of different cellular carriers all over the world. You can be certain that each one of those carriers has different terms of service. Why is AT&T so privileged that their terms of service, and theirs alone, are the ones that Apple looks at when deciding whether to reject or accept any given app? It’s quite likely that people all over the world are missing out on great iPhone apps that their cellular carriers would permit them to use just because AT&T does not permit Americans to use them.

Cluelessness
The answer to the fourth question is just classic:

“Apple does not know if there is a VoIP element in the way the Google Voice application routes calls and messages, and whether VoIP technology is used over the 3G network by the application.”

So let’s see. Apple rejected Google Voice on July 27th. It typically takes at least a week before Apple gives any response to an app submission, so we can assume that Google Voice was submitted on July 20th or earlier. And let’s not forget that Apple says that they “continue to study it” in its supposedly non-rejected state. Apple has been studying Google Voice for over one month now and still doesn’t know if it uses any VoIP technology? Give me a break! Just how are they carrying out this study?

Overload
The answer to that last question is revealed, implicitly, at the end of the letter. Apple claims, “There are more than 40 full-time trained reviewers, and at least two different reviewers study each application….” No problem there. They also claim, “We receive about 8,500 new applications and updates every week….” Also no problem. But what happens when we put them together?

There are 8,500 App Store submissions each week. Each submission gets reviewed twice, so there are 17,000 reviews per week. There are “more than 40″ full-time reviewers; let’s give Apple a nice cushion and say that this means 45. Let’s also assume that these reviewers work a standard full-time 40-hour work week1.

With 17,000 reviews per week and 45 reviewers, that means each reviewer performs 378 reviews per week. At 40 hours per week, this is 9.4 reviews per hour, or one review every 6.4 minutes.

Think about that figure for a moment. You put in literally months of work on your product, slaving over it and struggling with the half-baked developer experience. And then, at the end of all that, everything rests on a go/no-go decision from two people who collectively spend thirteen minutes evaluating your months of work.

And Apple shouts this to the world as though we were supposed to take it as a good thing.

Footnotes
1. In reality, Apple being Apple, their reviewers probably work significantly more than 40 hours per week, and thus spend proportionately more time on each review. But even if they worked, say, 80 hours per week, this would only leave 13 minutes for each review, which is still a very small amount of time. It would also means they’re proportionately overworked, and is that really better for the review process?