Is the Android Marketplace a more open alternative for developers compared to the iPhone App Store, or does the growing diversity of hardware, software, and overlays make it just as frustrating in its own way? Okay, so Fake Steve is likely to be more pro-Apple than a Fake Eric would be, fair enough. And, yes, some high-profile developers have taken issue with Apple’s draconian incompetent App Store approval process, well taken. But as much as Fake Steve is funny, the real Dan Lyons (of Newsweek) behind him is an equal opportunity offender, happy to take the p*ss out of Apple at any opportunity, often anti-Linux, and just as often insightful when it comes to things like Old Media and, yes, competing platforms. So take this with a giant-sized fake grain of salt, but take it:

There are just a bunch of different devices that have a lot in common with each other but aren’t quite the same. Trying to turn that into a “platform” is like trying to build a porch using three hundred pieces of wood, none of which are the same size. From the [Gadget Labs] story:

A slew of problems have made managing Android apps a “nightmare,” they say, including three versions of the OS (Android 1.5, 1.6 and 2.0), custom firmware on many phones, and hardware differences between different models.

Dear friends, this is only going to get worse, not better. Think about it. Every handset maker wants its device to be different. And special. So they intentionally tweak the OS to give themselves what they think of as an “advantage,” when really it’s nothing of the sort, because all it does is prevent ISVs from writing apps for them. Even if the handset makers weren’t totally short-sighted and evil, there’s the competency issue.

No doubt Apple’s App Store can make developers tear their flesh off in frustration, and GPS/CPU/GPU/Camera/etc. issues fragment the iPhone/iPod platform as well, but at the end of the day, does 50+ million “compatible enough” iDevices that are gate-keeper’ed still offer developers a better experience than a wide range of quasi-competitive, free’er devices?

(Yes, Google is closed as well, just not as closed…)

This is a story by the iPhone Blog. This feed is sponsored by The iPhone Blog Store.

Fake Steve on Android Fragmentation, i.e. Why It’s Harder to Develop for than iPhone

Why is it easier to make a great Twitter client for Apple’s iPhone than for Google Android phones like the new Verizon DROID? After Robert Scoble wrote a typically impassioned post entitled The Droid fails AS A PRODUCT when compared to Palm Pre and iPhone, and used Twitter clients as an example, Thomas Marban of Android’s premiere Twitter client, Twidroid, responded:

one of the main reasons why UIs are unequally inferior are not only the way you build apps (open vs. closed hw/sw system) and the SDK itself but also marginal to non-existing UI standards, no ready-made drag & drop UI items, variations in carrier- & device firmware, hard- & software input, screen sizes, international customizations, modded phones, rooted phones and last but not least completely different expectations among users and the linux’ish target group itself. in a nutshell: beautiful mess. obviously, all these reasons eat up a huge pile of time that one could better spend with improving UX and polishing the interface. those who started early with android development have learned and are still learning it the hard way, just like they did with win 3.1 back in the days.

John Gruber of Daring Fireball, in Lots of Excuses comments:

That doesn’t sound like someone who plans to ever ship something of the caliber of Tweetie, Birdfeed, or Twitterrific. From what I’ve seen of Twidroid, it’s not even as good as Craig Hockenberry’s original version of Twitterrific for iPhone, which was written as a jailbreak app before the iPhone officially supported third-party software. If Android hardware diversity is already a problem for third-party developers, it’s only going to get worse.

This also highlights the advantages Apple has given iPhone developers. Not only is the iPhone based on OS X, but the development tools are based on Xcode and Interface Builder, and while not as many developers are likely already familiar with Cocoa touch as, say, developers might be with Android’s language(s) (or web developers may be for the Palm Pre), existing Mac developers can make those tools sing. And, given the SDK Apple provided, even new developers get a huge head start in terms of functions and user interface elements.

Sure, that means there’s a lower barrier of entry to creating poor iPhone apps, but it also means great developers aren’t wasting their time re-inventing UI wheels, or fighting the OS to do right by their apps. They investing that time in making great apps.

This is a story by the iPhone Blog. This feed is sponsored by The iPhone Blog Store.

Why It’s Easier to Make a Great Twitter Client for iPhone than for Android

Acceleroto, makers of the iPhone apps Air Hockey [$0.99 - iTunes link] and Air Hockey Free [Free - iTunes link] have written an interesting post on the differences between developing their app for the iPhone App Store vs. the Palm Pre App Catalog. Some take away:

• They charge more for the webOS version due to lower volume expectations
• iPhone and Palm Pre are “remarkably similar” hardware-wise
• They already knew Objective-C, but Javascript wasn’t difficult to pick up
• iPhone is native, webOS is interpreted, so there’s a difference in execution speed (more important for game developers)
• Getting code onto the Pre is faster. Debugging is much more difficult than iPhone.
• Had to “skinny up” iPhone code to get 30-fps for webOS.
• Multitasking and garbage collection impacts performance
• Since webOS apps are “web pages”, touch events are handled as mouse-clicks and aren’t as smooth
• No sound yet, because the requisite timing isn’t possible.

So, as we’ve heard before, development for non-intensive apps is likely quicker and easier for the Palm Pre, but more intensive apps, like games, are still a challenge. Doubtless Apple will continue to work on making casual apps easier to deploy, and Palm on making deeper apps run better.

The full post also includes the backstory of how and why Air Hockey was ported to webOS, and shown off as part of the Palm Pixi introduction. Give it a read, and then let us know what you think.

[Acceleroto via PreCentral.net]

This is a story by the iPhone Blog. This feed is sponsored by The iPhone Blog Store.

Acceleroto on Developing Air Hockey for the iPhone vs. Palm Pre

A short time ago we mentioned that Standford’s iPhone Application Programming course was being made available as a video podcast via iTunes U. In addition to two lectures a week, the course offers special Friday sessions, one of which recently featured Atebits‘ Loren Brichter (iTunes link), the developer behind popular iPhone (and now Mac) Twitter client, Tweetie (see our review).

Brichter, though he worked for Apple on the first generation iPhone, had no actual app development experience when he set out to make Tweetie, yet the app has become the most successful iPhone — and mobile — paid Twitter client in terms of both revenue and user base, hitting the #6 position in the App Store at one point. How’d that happen?

At the beginning of the lecture, Brichter shares his App Store daily revenue graph (sans actual dollar amounts) for Tweetie, which he says he made simply because he wasn’t satisfied with any of the existing clients. Focusing on a mix of functionality and simplicity, and an Apple-like experience, Brichter credits luck, quality, and marketing for Tweetie’s success. Part of that marketing, after a small initial sales spike due to friends and family, was the semi-facetious introduction of PEE (”popularity enhancers” like a flashlight and fart sounds) that garnered a lot of media attention and quintupled growth for a while.

Other growth occurred when Apple featured Tweetie on their main page, but the biggest growth-booster — also thanks to Apple — was when Tweetie 1.3 was rejected by the App Store due to the term f**kitlist just happening to be a trend on Twitter’s search results that day. Press jumped on it and users bought it up. (Apple reversed their decision later that same day).

The final two growth spikes occurred after Twitter itself began highlighting Tweetie as part of their sidebar factoid promotion, and after the press surrounding the recent introduction of Tweetie for Mac.

Being part of the Application Development course, Brichter also touches on some of the things he did from a programming standpoint to boost Tweetie’s performance.

Looks behind the app development curtain, especially in academic settings with some back-and-forth questions and answers, are rare enough in the iPhone world that anyone interested should definitely consider checking out the whole session.

This is a story by the iPhone Blog. This feed is sponsored by The iPhone Blog Store.

Luck, Quality, and Marketing: Tweetie’s Loren Brichter Talks Development and Success on iTunes U

Apple’s Ad-Hoc iPhone distribution method allows developers to register up to 100 iPhones or iPod touches so they can run their applications on them without having to go through the App Store. This is priceless for beta testing, educational environments, and other non-public environments.

Dragthing’s James Thomson, however, has posted on a problem that just might bite a few developers right in their beta tests:

Reading between the lines, and discussions on the forums, it sounds like every time I deleted or modified an entry, I was getting one closer to the magic figure of 100 device IDs you have entered since the beginning of time. When you hit the limit, regardless of how many total device IDs you have listed in the portal, your ability to further edit the list is removed completely.

In other words, if you change your beta testers — if you change your own device — you might just end up locked out of your own Ad-Hoc distribution.

Check out the full post for more on this problem and what, if nothing, Apple is currently doing to help developers fix and/or work around it.

Meanwhile, let us know if you have any ideas as well…

This is a story by the iPhone Blog. This feed is sponsored by The iPhone Blog Store.

Developer Warning: Ad-Hoc Slots NOT Changeable

Maybe this explains, at least in part, the new iPhone 3.0 Beta 5released yesterday? Looks like Apple is super-eager to get developers testing and submitting 3.0 compatible applications.

We’re really eager to see what developers are coming up with to leverage all those great 3.0 features as well. Really, really eager. Ahem.

Full text of Apple’s email to developers:

All apps must be compatible with iPhone OS 3.0

Millions of iPhone and iPod touch customers will move to iPhone OS 3.0 this summer. Beginning today, all submissions to the App Store will be reviewed on the latest beta of iPhone OS 3.0. If your app submission is not compatible with iPhone OS 3.0, it will not be approved.

Existing apps in the App Store should already run on iPhone OS 3.0 without modification, but you should test your existing apps with iPhone OS 3.0 to ensure there are no compatibility issues. After iPhone OS 3.0 becomes available to customers, any app that is incompatible with iPhone OS 3.0 may be removed from the App Store.

Begin testing now

iPhone OS 3.0 beta 5 and iPhone SDK 3.0 beta 5 are now posted to the iPhone Dev Center. Start testing today to ensure your application runs on iPhone OS 3.0. Visit the iPhone Dev Center for additional development information including iPhone SDK Release Notes for iPhone OS 3.0 beta 5 and Getting ready for iPhone OS 3.0.

(Thanks DevX for the tip!)

This is a story by the iPhone Blog. This feed is sponsored by The iPhone Blog Store.

Apple Now Accepting Submissions for iPhone 3.0 Apps

Read Write Web has posted the findings of mobile analytics firm Flurry. They break it down as follows:

• Apps (see charts above) put the iPhone staggeringly ahead in terms of active developers, applications developed, and consumer usage. (note: lack of analytics use by BlackBerry devs likely skews those numbers).
• Smartphones are being used more than ever
• iPhone apps, if they’re marketed effectively, are making strong development houses millions of dollars.
• iPhone apps are becoming “hit-driven” like the music industry.
• Free versions help sell paid apps
• Only 10% of users update their apps (we’re not sure if that’s skewed by other platforms, Apple makes it simple to update).

It’s important to remember that with this type of analytics, results are hyper-dependent on what’s included (and what’s missing) from the data set. If nothing else, however, iPhone developers are getting more attention from, and making greater use of, market analytics at the moment.

That said, anyone surprised by these numbers?

This is a story by the iPhone Blog. This feed is sponsored by The iPhone Blog Store.

iPhone Undisputed King of Smartphone App Mountain?

I was just listening to Dieter and Mike’s latest PalmCast, where they were crowing in duet about how sweet it was that the Palm Pre has an app that can book movie tickets and automagically add the movie event information to the Palm Pre calendar.

I know, I know. If they love the Palm Pre so much, why don’t they just marry it? (Dieter is, in fact, looking for a state that may allow it…) But they raise an excellent point — where’s the iPhone version of that functionality? Why can’t we push a button on our movie ticket app, or concert tour app, or tradeshow app, or whatever and have that slice of time booked off for us in our calendar?

While the iPhone SDK allows access to the Contacts database to do all manner of glorious, 3rd party app-powered magic, Apple has thus far not surfaced any APIs to do the same for calendaring. I don’t believe the new 3.0 SDK has announced any improvements in that area either.

What makes calendar so different? MobileMe and ActiveSync push both. Apple’s even giving Calendar some much-appreciated CalDAV and subscription love, with no CardDAV that we’re aware of for contacts.

We’re sure developers would appreciate it. We know users would adore it.

Anyone have any idea why we don’t have this yet?

This is a story by the iPhone Blog. This feed is sponsored by The iPhone Blog Store.

Dear Apple: Why Can’t Apps Access the Calendar?

Ars Technica’s iPhone wonder woman, Erica Sadun, has put together what must be the first expert level how-to: Pushing tweets to your iPhone with Apple Push notifications

Ars shows you how to create a Push-based Twitter update notification system for the iPhone without actually showing you any of the details due to the ongoing NDA. (But don’t worry, we tell you exactly where to find the instructions.)

Nin. Ja.

Now if you need help getting your code on, it just so happens that the Stanford iPhone Application Development course (the one being offered via iTunes U) looks like it has “make your own Twitter client” on the agenda.

Ready? Set? Push Tweet!

This is a story by the iPhone Blog. This feed is sponsored by The iPhone Blog Store.

How To: Roll Your Own Twitter Push Notification App

iTunes U has posted the first in what promises to be a series of video lectures on iPhone Application Programming [iTunes link] from Stanford University. Led by Evan Doll and Alan Cannistaro, it’s recommended for people with previous C, UNIX, object oriented programming languages, and graphics tookit experience, but will likely prove of value to anyone interested to in coding the next great iPhone app. Ars Technica says:

Videos of all the lectures, lead by Apple engineers, will be posted on iTunes U two days after each class meeting [...] The slides from the lectures will be available to download as well. The school notes that the material will be the same that enrolled students get, but unfortunately, following the lessons via iTunes U won’t make you eligible for college credit.

So, who’s adding it to their feed?

This is a story by the iPhone Blog. This feed is sponsored by The iPhone Blog Store.

iTunes U: Stanford Releases iPhone Application Programming