Palm Rejects First App, More Things Apple Could Learn from Palm

Earlier this week, I detailed a number of things Apple could learn from how Palm handles its phones, operating system, and applications. Today, news broke out of the first application rejection from Palm’s App Catalog, and from this and Palm’s actions surrounding this rejection Apple can again learn a whole lot.

Earlier today, it was revealed that Palm had not accepted the music player NaNPlayer into the App Catalog. Since this is the first rejection by Palm, it gives us the opportunity to look at how Palm handles these situations, and as it turns out, Palm appears to be a lot more developer-friendly than Apple.

NaNPlayer is a music player which fixes a lot of the shortcomings of the stock webOS one, which is very limited and lacks basic functionality like scrubbing and on-device playlist creation. NaNPlayer has been in development for a while, and its developer aimed to have it included in the App Catalog.

Palm rejected it, for a rather clear reason: NaNPlayer is using private APIs, and these APIs are very much in flux, and not set in stone. These APIs are also used by the stock music player application, and aid in indexing and querying the metadata attached to music files. The use of private APIs is a breach of the SDK agreement, but more importantly: using APIs that are not yet finished means applications can beak at any given time, deteriorating the user experience.

Now, let’s look at what Palm is doing right, as compared to Apple. First of all, the reason for rejection was clearly communicated to the developer – he knew exactly why his application was rejected, and has a clear understanding of how to possibly fix it. Of course, you can (rightly so) argue that APIs to query and index music metadata should’ve been part of the SDK to begin with.

The second thing Palm is doing right is immediately responding to this issue publicly. Chuq Von Rospach, Palm’s Developer Community Manager, responded publicly to the PreCentral news item in which the rejection was announced, and in clear detail explained (again) why the application was rejected, that Palm is listening to the community to help prioritise which APIs and features end up in the webOS, and, most important of all, that Palm is happy the application will continue its life as a homebrew application – until the APIs are finalised.

That last thing also happens to be the third thing Palm is doing right: blessing the homebrew community. This way, the community can still use the applications they want, whether they are in the App Catalog or not. It makes sure that it is the users who decide which applications they run, and not Palm, Apple, or whatever.

The fourth thing Palm does right is actually having something called a “Developer Community Manager”, who handles these issues quickly and efficiently, explaining carefully the why and how, so that stories can not get out of control. Palm has clearly learnt from the total lack of communication and transparency from Apple towards its developer community.

Now, you could argue that Apple’s App Store is a whole lot larger, with a whole lot more rejections going on. This is not an excuse – the App Store is the size it is, and its size is not an excuse to mistreat your third party developers. Apple could’ve seen this coming. They could’ve hired more people. They could’ve appointed a developer community manager – instead of having the acting CEO send out a few emails for marketing purposes to quickly sooth the community.

Of course, Apple could also scratch itself behind its ears, and take a long and hard look at its set of magical, indefinable rules of which only they seem to have a copy, and maybe remove some of those rules to lessen the number of rejections.

The list of things Apple could learn from Palm is growing. Many people think that the success of the App Store means Apple’s model is perfectly valid and successful, but let me point out that popularity is generally not a valid measurement of quality. If it was, Windows would be the best desktop operating system, and Mac OS X would be a total mess.


  1. 2009-09-10 11:01 pm
    • 2009-09-10 11:42 pm
      • 2009-09-10 11:59 pm
        • 2009-09-11 7:22 pm
          • 2009-09-11 9:48 pm
          • 2009-09-12 4:26 pm
          • 2009-09-13 6:32 am
          • 2009-09-13 8:48 pm
          • 2009-09-14 12:56 am
  2. 2009-09-10 11:05 pm
    • 2009-09-10 11:34 pm
      • 2009-09-11 10:58 am
  3. 2009-09-10 11:07 pm
    • 2009-09-11 12:34 am
      • 2009-09-11 9:06 am
      • 2009-09-11 7:42 pm
      • 2009-09-11 8:15 pm
  4. 2009-09-10 11:24 pm
    • 2009-09-11 1:49 am
      • 2009-09-11 4:19 pm
  5. 2009-09-10 11:37 pm
    • 2009-09-11 5:19 am
    • 2009-09-11 7:02 am
  6. 2009-09-11 12:24 am
    • 2009-09-11 12:32 am
      • 2009-09-11 12:56 am
        • 2009-09-11 9:46 pm
      • 2009-09-11 10:45 am
    • 2009-09-11 10:13 pm
    • 2009-09-12 5:17 pm
  7. 2009-09-11 7:23 am
    • 2009-09-11 11:08 am
      • 2009-09-11 11:39 am
        • 2009-09-11 4:12 pm
  8. 2009-09-11 10:09 am
    • 2009-09-11 12:08 pm
      • 2009-09-11 12:14 pm
        • 2009-09-11 8:53 pm
    • 2009-09-12 12:16 am
  9. 2009-09-11 6:45 pm
  10. 2009-09-11 6:56 pm
  11. 2009-09-12 1:32 am
    • 2009-09-12 6:44 pm