Martin Gordon's Blog

Podcaster, an iPhone app that downloads podcasts over-the-air, was rejected from the App Store this past Friday on account of it "duplicating iTunes functionality." The Mac community is justifiable upset, with at least one developer refusing to develop any more apps, and others looking to coordinate some form of organized protest. I think that many are confounding two separate issues that the Podcaster rejection raises. First, that there are App Store approval guidelines that extend being what is listed in the developer agreement, and second, that Apple has seemingly decided to not allow any third party applications to compete with their own.

The first issue is not new. I wrote about it in my post about Flickup being rejected and we've seen it many times of the past couple of months. This incident just gives us yet another item to add to our unofficial approval guidelines. That these guidelines are (1) not published provided by Apple, and (2) a result of trial and error on the part of many very frustrated developers is inexcusable and irresponsible. As both Fraser Speirs and Paul Kafasis mention, development takes time, effort and money, and without a reasonable expectation that an app will be approved makes the App Store that much more unappealing to develop for, scares away developers and undermines Apple's goal of building a long-lasting ecosystem around its mobile operating system.

The solution, of course, is simple. Apple needs to release an all-inclusive set of guidelines. Knowing what is off-limits cuts developers off from the get go instead of forcing them to develop an app and spin the roulette wheel. Developers may not be happy that they can't release an app that does X, but at least they'll know before pouring weeks into development. A scary, but entirely possible situation is that Apple hasn't released such a document because even they aren't sure exactly what's in it.

The second issue is the anti-competitive nature of this specific rejection. I don't want to spend too much time extrapolating meaning from this specific rejection, particularly the common view that this rejection indicates that Apple won't allow any application into the store that competes with *any* of its products. I don't see Apple being stupid enough to actually have an explicit non-complete policy in place, so my view is that this is simply a case of a reviewer not fully understanding Apple's (currently nonpublic) approval guidelines and I fully expect Apple to correct this mistake. Until we see more cases of this anti-competitive policy being applied, I don't think we should go running for the hills just yet.

Technorati Tags: Apple, iPhone, iPhone 3G, App Store, iTunes, Podcaster

Merlin Mann on iPhone development (from the SF iPhone Dev Camp):

Think about having the courageousness to make an app that is crazy easy. Instead of making a circus that’s really fun to play in, just make something that’s easy to get in and out of quickly without hassle.

Yes! This is exactly what I'm going for with Flickup. I wanted it to be dead simple to post photos to Flickr and I think I've gotten pretty close. While I don't want to add frivolous features, there are some that are reasonable to consider - uploading to a set, security settings, etc. I struggled to fit the metadata view onto one screen and now I'm faced with the challenge of adding these new features without undermining the simplicity that I was going for in 1.0.

Technorati Tags: Apple, iPhone, App Store, Flickup, Flickr, Merlin Mann, iPhone Dev Camp

A few hours after my post about being rejected from the App Store, Flickup was approved. If that was all there was to the story then I would have posted about it immediately. Sadly, however, it took nine days from the time Flickup was approved until the time it was actually available for sale on the App Store.

In preparing the now-defunct demo version of Flickup, I stumbled across the contracts page on iTunes Connect and realized that my Paid Applications Contract wasn't complete. I completed it on July 17th and incessantly refreshed the contracts page to see if it had been approved yet. When Flickup was finally approved hours after my last blog post, I was met with the status of "Pending Contract" and frustration returned. I would have thought that three days would have been enough time for someone to review the contract, but apparently that wasn't the case. Having given Apple some breathing room, I finally sent them an email on the 24th asking how long the process would take. Their response? Nothing.

I didn't hear anything from Apple until the contract was approval last Monday, July 28th and the status changed to "Ready For Sale." When I finally got tired of searching the App Store every few minutes to see if Flickup was listed, I sent Apple another email. Again I received no response. It wasn't until I saw a tweet from Jon that I learned that Flickup had finally been posted and that the three week ordeal was finally over.

When I first started working on Flickup I set a lifetime sales goal ("If only X number of people ever buy the app, I would be satisfied"). I'm happy to say that I reached 10% of that target in the first full day alone. Since the app went live, I've been answering support emails (already!), pushed out (well, submitted to Apple anyway) a new version with some bug fixes, and already started working on some new features.

Now go out and buy it!

Technorati Tags: Apple, iPhone, iTunes, App Store, Flickr, Flickup

I am now a proud member of the elite group of developers who have had applications rejected from the iPhone App Store.

The application I have been working on since a few weeks after the SDK came out is Flickup, a simple Flickr uploader. When Apple announced the July 7th deadline, I pulled an all-nighter that day to finish it up and submitted the app to Apple around 6am in order to meet the 3pm deadline for inclusion in the App Store at launch. When the App Store is launched on Thursday/Friday, my app is nowhere to be found and the status remains "In Review". I sent an email on Saturday to Apple asking why Flickup was still in review and I received a non-response three days later telling me that "In Review" means my application is being reviewed by Apple. I responded immediately clarifying my inquiry and I finally received this response yesterday:

At this time, Flickup cannot be posted to the App Store because it does not allow the user to logout or change the Flickr account that they are using.

In order for your application to be reconsidered for the App Store, please resolve this issue and upload your new binary to iTunes Connect.

This is a perfectly valid critique, and an oversight on my part, but did it really take them two weeks to tell me about it? Would they have even told me had I not emailed them about my app's status? In any case, the time it took to get a decision on Flickup gave me time to fix some bugs, and of course add the required logout functionality.

As an aside, the Flickr Authentication API's Implementation Guidelines merely states, "Users must be provided with 'logout' functionality." The API documentation does not provide any way to revoke tokens and log users out. I had to resort to directing users to their revoke permissions page instead.

In the mean time, the App Store turned one week old and gripes about the review functionality sprouted everywhere, particularly with regard to the ability for people to review an app without actually having used it. This "feature" of the App Store prompted the cheapskates out there to use reviews as a medium to complain about price. Taking this to heart, I spent some time last week preparing a demo version of Flickup that would allow people to sample the app before dropping two Washingtons on the full version. I submitted the demo version on Friday and received a decision today:

Flickup Demo cannot be posted to the App Store because it is a beta or feature-limited version. Any reference to demo or beta needs to be removed from the binary and metadata. Free or "Lite" versions are acceptable, however the application must be a fully functional app and cannot reference features that are not implemented or up-sell to the full version.

In spite of the lightning fast turnaround time, I am still just as angry about this rejection than the last one since there was no prior warning (in program agreements or otherwise) that demo versions would not be allowed. It's hard to believe that Apple isn't aware that people are crying out for demos and trials; going as far as explicitly prohibiting them (while letting all other sorts of crap through) is nothing short of infuriating.

Technorati Tags: iPhone, iPhone SDK, App Store, Apple, Flickup

With 100,000 iPhone SDK downloads, the relative simplicity of the platform and the popularity of the iPhone, there's no doubt we'll be seeing tons of iPhone applications being released as soon as the App Store goes live. But will those apps be any good?

Brent Simmons, author of NetNewsWire, thinks we'll see a ton of to-do lists and Twitter clients. He's right: Apple has failed to provide a to-do list app for iPhone OS (or Mac OS X, for that matter) and people have complained about it since June 29, 2007. Twitter is also the love du jour of techies everywhere and an iPhone app would be much better than the web interface (look no further than Iconfactory's Twitterrific on the desktop for proof). I am personally working on an app that combines the two ;-)

Brent also thinks that the money is in the Cloud. He states that standalone iPhone apps are easy and cheap enough to write and too boring to use. The most interesting apps will be those that sync to the cloud. It's the development, maintenance and scaling of the server apps that will be expensive, and that's where he sees much of the iFund money going. Time to become an expert on NSURLConnection!

I can't help but agree. One app I'm working for will tie into a web app we've written internally - the API isn't currently there, but it will be. Blossom (as we call it) won't be the most revolutionary iPhone app out there, but it is a good testing ground for client-server iPhone apps. I've got ideas for other apps too, and the thing they have in common is that they all tie back into the Cloud. The 1st iPhone "SDK" (web apps) was far from perfect, but if it did anything, it helped developers focus their attention on where it should be - the Cloud.

Technorati Tags: iPhone, iPhone SDK, Apple, iPhone OS, Cloud, cloud computing, Cocoa Touch, development, Brent Simmons, NewsGator, NetNewsWire

Google has added a social networking aspect to Google Reader. Inviting a user to chat (i.e., adding them to your GTalk buddy list and you to theirs) allows you to view their shared feeds in a new section, cleverly titled, "Friends' shared items".

You can add me by adding martingordon at gmail.com to your GTalk buddy list. As an aside, there should be an easy way to link to this action instead of having to provide instructions. For now, I'll call it "Google Readerbook me", in honor of that other social network.

I only have one friend at the moment, Scoble, and there is a major flaw (which I mentioned to him last night and he blogged about): If they share an item from a feed you're subscribed to, you see it twice. For people with many friends and lots of overlapping shared items, the number of dupes that have to be processed can grow considerably.

The solution, of course, is to remove the duplicate items. But let's take it one step further. Show me how many times the item would have shown up in my feed list. I can list six metrics that are no-brainers: friends sharing/starring/subscribed to this item and all users sharing/starring/subscribed to this item. Google Reader instantly becomes a del.icio.us/Digg competitor if they decide to show the "all users" metrics. Perhaps it even turns into a del.icio.us/Digg killer since starring/sharing is such an "organic" action. Since I'm doing it anyway, there's no inertia keeping me from participating and there's no need for me to install and use browser extensions or Bookmarklets to bookmark/submit anything.

It's clear now Google's approach to building a social network is the exact opposite of Facebook's. Facebook first built the network and then tacked on applications; Google first built the applications and then integrated the social network into them. In Facebook's case, yes the network itself has its uses, but I have yet to find a truly killer app among the thousands of Facebook apps ("Zombies" and "Super Wall" aren't going to change the way I live, work, or for that matter, socialize). Google's way is sneakier (in a good way) and this means it may take longer to build up the network, but I feel in the end it'll lead to a more useful social network - the one that enhances the applications I already use.

Technorati Tags: Facebook, Google, Google Reader, social networks, sharing, feeds, RSS reader