Deprecated: Assigning the return value of new by reference is deprecated in /home/martingo/ on line 512

Deprecated: Assigning the return value of new by reference is deprecated in /home/martingo/ on line 527

Deprecated: Assigning the return value of new by reference is deprecated in /home/martingo/ on line 534

Deprecated: Assigning the return value of new by reference is deprecated in /home/martingo/ on line 570

Strict Standards: Declaration of Walker_Page::start_lvl() should be compatible with Walker::start_lvl(&$output) in /home/martingo/ on line 1199

Strict Standards: Declaration of Walker_Page::end_lvl() should be compatible with Walker::end_lvl(&$output) in /home/martingo/ on line 1199

Strict Standards: Declaration of Walker_Page::start_el() should be compatible with Walker::start_el(&$output) in /home/martingo/ on line 1199

Strict Standards: Declaration of Walker_Page::end_el() should be compatible with Walker::end_el(&$output) in /home/martingo/ on line 1199

Strict Standards: Declaration of Walker_PageDropdown::start_el() should be compatible with Walker::start_el(&$output) in /home/martingo/ on line 1244

Strict Standards: Declaration of Walker_Category::start_lvl() should be compatible with Walker::start_lvl(&$output) in /home/martingo/ on line 1391

Strict Standards: Declaration of Walker_Category::end_lvl() should be compatible with Walker::end_lvl(&$output) in /home/martingo/ on line 1391

Strict Standards: Declaration of Walker_Category::start_el() should be compatible with Walker::start_el(&$output) in /home/martingo/ on line 1391

Strict Standards: Declaration of Walker_Category::end_el() should be compatible with Walker::end_el(&$output) in /home/martingo/ on line 1391

Strict Standards: Declaration of Walker_CategoryDropdown::start_el() should be compatible with Walker::start_el(&$output) in /home/martingo/ on line 1442

Strict Standards: Redefining already defined constructor for class wpdb in /home/martingo/ on line 306

Deprecated: Assigning the return value of new by reference is deprecated in /home/martingo/ on line 103

Strict Standards: Redefining already defined constructor for class WP_Object_Cache in /home/martingo/ on line 431

Deprecated: Assigning the return value of new by reference is deprecated in /home/martingo/ on line 61

Deprecated: Assigning the return value of new by reference is deprecated in /home/martingo/ on line 1109

Strict Standards: Declaration of Walker_Comment::start_lvl() should be compatible with Walker::start_lvl(&$output) in /home/martingo/ on line 1266

Strict Standards: Declaration of Walker_Comment::end_lvl() should be compatible with Walker::end_lvl(&$output) in /home/martingo/ on line 1266

Strict Standards: Declaration of Walker_Comment::start_el() should be compatible with Walker::start_el(&$output) in /home/martingo/ on line 1266

Strict Standards: Declaration of Walker_Comment::end_el() should be compatible with Walker::end_el(&$output) in /home/martingo/ on line 1266

Strict Standards: Redefining already defined constructor for class WP_Dependencies in /home/martingo/ on line 31

Strict Standards: Redefining already defined constructor for class WP_Http in /home/martingo/ on line 61

Strict Standards: Non-static method unfancy_quote::init() should not be called statically in /home/martingo/ on line 55
<br /> <b>Strict Standards</b>: call_user_func_array() expects parameter 1 to be a valid callback, non-static method unfancy_quote::strip_quotes() should not be called statically in <b>/home/martingo/</b> on line <b>166</b><br /> Martin Gordon's Blog / development

On Podcaster and App Store Rejections

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: , , , , ,

Crazy Easy

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: , , , , , ,

Flickup 1.0 Is Out!

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: , , , , ,

Rejected (Twice!) From the App Store

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 App Gold Rush

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: , , , , , , , , , ,

Tab Dump - Long Overdue Edition

Too many tabs sitting open for far too long. Here we go:

Hugh Macleod on Applying "Creativity" to Your Professional Life Etc. Some nice tips, especially for those of us just starting our professional lives. Not really much to say about this, but a lot to think about. I'll probably keep this open and glance at it every once in a while despite having linked to it. (Note: This was posted on January 9th so I've had it sitting in my browser for a month!)

Andre Torrez's first Django app is a simple random color generator that is absolutely amazing and beats any other "Hello, World" I've ever seen. I'm a Rails guy and this is so cool I might just try writing my own just for kicks.

Today Is The Day is a really weird and creepy one-post blog about a day in the life of a styrofoam man. Really can't say much else about it, but it's worth checking out.

Air Traffic Controller Don Brown on air traffic safety vs. capacity. Quite an interesting and enlightening read, though probably not the best thing to read two weeks before boarding a 17-hour flight (granted I read this before I knew I'd be going back to South Africa).

I will keep doing this periodically, but it's worth noting that I'm sharing a lot more of what I come across over on Google Reader. Check out my link blog or add me as a friend directly from Google Reader/Google Chat (martingordon at gmail).

The Anti-37signals

This Official Google Docs Blog post title ("We can't stop adding features!") struck me as the complete opposite of the 37signals/Getting Real philosophy.

Now granted, I'm sure the title was tongue-in-cheek and caters to the general populace's "more features = better" mentality, AND the three features they added are actually quite useful (Save to PDF, better printing options, and vector shapes), but the title just struck me so much that I wanted to comment on it. Still, I think it's worth mentioning that I hope they can stop adding features, lest Google Office become too much like Microsoft Office.

Technorati Tags: , , , , , ,

Tab Dump - Long Weekend Edition

Can't say I want to write anything too substantive on these links, but I do want to get them out there anyway because they're cluttering up my tab bar.

Monsters of the Programming World is a neat little poster anthropomorphizing common programming errors. I've been meaning to pick this up for our office.

Jeffrey Friedl has developed a Lightroom export plugin for Flickr. I haven't had a chance to test it out yet, as I've shamefully not uploaded any pictures to Flickr this year, but it should shave off a few clicks in my workflow if it works well enough.

Ken Rockwell on How To Afford Anything. The great thing about this article is that Ken isn't a personal finance guru, he's a photographer. This article isn't coming from a "I want to be rich" perspective but more from a "I want cool cameras" perspective, which appeals to me greater than the usual run-of-the-mill personal finance article.

Fraser Speirs on his photo editing workflow. Fraser uses Aperture, so his workflow is a bit more flexible than what is allowed (or rather suggested) by Lightroom. Still, some of his ideas carry across between any such application. I particularly enjoyed his rating process, something I currently do without much thought.

I'm working on listening to all of Fred Wilson's Top 10 Albums of the Year. Music recommendations from a VC, who would have thought? Fred's musical tastes are a bit off from mine and listening to his picks is an interesting experience. I haven't gotten through the entire list, but I did grab a copy of the Kings of Leon's Because of the Times, his number one pick. There are some songs I can't stand to listen to, and although the album as a whole isn't memorable, it is very catchy. That is, I can remember parts of songs but I can't identify which song it is or if it's the same part of another song. My biggest disappointment has to be the lyrical work. There's just not a whole lot going on there unfortunately.

Technorati Tags: , , , , , , , , , , , , , ,

AJAX Web Browser?

When I first saw the headline that the Opera Browser is headed to the iPhone (later confirmed as false), I joking thought that Opera would be releasing a JavaScript web browser that ran in Safari. On second thought, I realized that a JavaScript browser could be used to bypass proxies by requesting pages from the server and passing them to the client via AJAX.

A quick Google search reveals one JavaScript browser called Accent JavaScript Browser, but it was released in 2001 and says it only runs in IE. A quick test of the browser in Firefox on the Mac shows that it doesn't work too well and that the buttons are only a proxy for the client-side JS functions. I also found another "browser", but I couldn't get this one to work in Safari or Firefox.

So far I'm 0/2 on working AJAX browsers. If a working one did exist, would it even be possible to use it for bypassing proxies? I have no need for this functionality, I just thought that it could be a pretty neat loophole.

Technorati Tags: , , , , ,

iPhone SDK Announced

From the Apple Hot News weblog (for lack of a better term):

Let me just say it: We want native third party applications on the iPhone, and we plan to have an SDK in developers’ hands in February.

I knew this had to come eventually, it was just a matter of when. The timing of a February launch is a bit strange only because a demo of the SDK (Software Development Kit) at January's consumer-oriented Macworld is inevitable. What was Apple's reason for waiting so long?

We are working on an advanced system which will offer developers broad access to natively program the iPhone’s amazing software platform while at the same time protecting users from malicious programs.

I don't think needing to digitally sign every app is in all parties' best interests. Developers have another hurdle to cross to get apps out there, Apple needs to expend resources validating every app, and consumers lose out due to both of these additional costs. I don't see Apple blocking out unsigned apps completely, and I don't want responsibility to be placed on users to determine the safety of an app. Instead, I think we'll see Apple restricting what APIs an application has access to based on their signed status. This could be an extension of the new Sandboxing feature in Leopard:

Enjoy a higher level of protection. Sandboxing prevents hackers from hijacking applications to run their own code by making sure applications only do what they’re intended to do. It restricts an application’s file access, network access, and ability to launch other applications. Many Leopard applications — such as Bonjour, Quick Look, and the Spotlight indexer — are sandboxed so hackers can’t exploit them.

The news item is short on details, so all we can do is speculate at this point. What is certain, however, is that this is undoubtedly good news, and the first good press the iPhone has gotten in a while.

Technorati Tags: , , , , ,