Gameloft — and other developers according to Gameloft — are cutting back on development for Google’s Android platform due to the “weakness” of the Android Market. According to Reuters, Gameloft finance director Alexandre de Rochefort said:

We have significantly cut our investment in Android platform, just like … many others. [The Android Market] is not as neatly done as on the iPhone. Google has not been very good to entice customers to actually buy products. On Android nobody is making significant revenue.”

Ouch. Harsh words. Meanwhile, with iPhone generating 13% of Gameloft’s revenue (400 times more than Android), we’ll no doubt see plenty more on the iTunes App Store.

While we’ve heard developers and pundits talk about the business advantage of the iPhone before, and while Android’s numbers may be rising and soon, in the short term the bigger houses like Gameloft might just stick with where the money is.

[Thanks to the Reptile for the tip!]

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

Gameloft: 13% of Revenue from iPhone, Nobody Making Money on Android

Instapaper and Tumblr developer Marco Arment riffs on the NYT’s article on Palm webOS’ trouble wooing developers, and it’s predictably good stuff.

His major point is that with its huge install base (which topped 50 million iPhones and iPod touches months ago), it makes more financial sense to develop for Apple’s platform, rather than Google’s Android or Palm’s webOS which might have on 5% to 10% as many devices on the market.

Giving developers an app store is the easy part. The hard part is bringing us enough customers. The iPhone is so good that it built up a huge installed base without any third-party apps, but no Android or webOS devices can say that yet.

Arment points out that the iPod touch makes a huge difference as well, giving developers a similar device to work on without the need for an expensive cell phone contract. He also echoes Fake Steve’s comments on different hardware complicating development, though he thinks if Android popularity continues to grow, the platform might justify the investment one day.

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

More on the iPhone (and iPod touch) Development Advantage

MacRumors has heard from multiple sources that Apple is planning to release a (presumably free) Concierge app for the iPhone and iPod touch that would:

…provide many of the same functions available through the company’s retail store online reservations system, allowing customers to schedule Genius Bar and One to One appointments from their mobile devices. Sources have also indicated that the application will allow users to keep tabs on their premium membership subscriptions offered by the company.

Since the current option is via the web (screen shot above), it sounds good to us. If wanted to schedule service or training for your iPhone, Mac, or other Apple gear, would you use it?

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

Apple Retail to Release Concierge App for iPhone?

Speaking of Storm8, Unity-engine code, private API, and Gruber, A recent Twitter exchange between him shows just how seriously all of this is now being taken by the App Store:

Hockenberry: Hearing lots of reports about apps getting rejected due to private API usage. Maybe now you’ll believe me when I say it’s a bad idea…

Gruber: Yup: Apple recently started running apps through a static analysis tool to look for private API calls.

Google set off some of the private API discussion when they implemented them as part of the Google Mobile app (though it’s our understanding those API were later made public). Generally, private or unpublished API are kept that way because Apple (or whichever platform maker is supplying the APIs) hasn’t finished working on them, are planning changes, or is otherwise reserving their use — if 3rd parties implement them anyway, any future OS update can break them and cause problems for end users. Public API, on the other hand, are supported and intended to let developers do their thing without worrying about platform-level changes wrecking their apps.

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

Apple Using Static Analysis Tool to Find Private APIs, Reject iPhone Apps

It looks like Apple is using its rejection power for good this time — removing games built on the Unity engine which included private-API calls that could be used to steal private user information like your iPhone’s phone number.

Not all of the rejected/removed games were engaged in privacy violations (or even had the network capability to exploit it), but Apple isn’t taking any chances following the Storm8 lawsuit. Touch Arcade has the details:

The Unity engine currently uses the two private API calls that Storm8 allegedly exploited to steal user data, NSGetEnviron and excserver. Mantas Puida of Unity Technologies explains these two API’s utilized by the Unity engine serve the following functions:

_NSGetEnviron is used by Mono runtime to provide implementation of .NET core API method: Environment.GetEnvironmentVariable().

exc_server is also used by Mono runtime to provide graceful NULL reference exception handling.

The Unity engine, however, has been updated to remove the offending API calls, and the games are being recompiled and resubmitted to the App Store. Hopefully this will keep users’ data safe from unscrupulous developers, while the scrupulous ones continue to turn out great games.

[Touch Arcade via TUAW]

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

Apple Rejects/Removes Unity-built Games to Protect User Privacy

Apple is looking to hire an experienced multimedia engineer for the iPhone and iPod touch, who’s a passionate gamer and has shipped at least one “AAA” game in the last few years.

While first-party titles are a mainstay, and main point of attraction for dedicated gaming platforms like Nintendo (Mario), Microsoft (Halo), and Sony (Little Big Planet), so far all Apple has offered its “funnest iPod ever” is Texas Hold’em [$4.99 - iTunes link] back in 2007.

Just what could Apple be brewing now? Anyone imagine what a first-party Apple gaming franchise could be?

[via AppleInsider]

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

Apple Hiring Gaming Engineer for iPhone Team

After submitting a minor .1 bug fix for Airfoil Speakers Touch 1.0.1 [Free - iTunes link] for iPhone and iPod touch, longtime Mac developers Rogue Amoeba waited for what they assumed would be a routine App Store review. Three and a half months, three rejections, and the unsuccessful intervention of a champion at Apple, the app is finally in the store, but the developer has decided the process is too odorous to continue with the iPhone platform.

Don’t stop us just because you’ve heard this before over and over again.

The issue this time was Rogue Amoeba discovering the type of Mac and exact application that was being used as audio source, and displaying the corresponding Mac OS X-provided image of the machine and icon for the app.

Though standard — intended — behavior on the Mac, Apple’s App Store policy branded this a trademark violation and they requested it be changed. Rogue Amoeba assumed the request was erroneous and tried resubmitting, tried escalating via email, even had a champion inside Apple try help get it through. In the end, the App Store policy was an immovable object, and Rogue Amoeba had to remove the Mac and app icon images. Airfoil Speakers Touch 1.0.1 was then approved and placed in the app store.

(And during the whole process, Airfoil Speakers Touch 1.0, buggy as it was, and using the exact same artwork Apple had issue with in 1.0.1 was left untouched in the App Store for users to download and use).

In the future, we hope that developers will be allowed to ship software without needing Apple’s approval at all, the same way we do on Mac OS X. We hope the App Store will get better, review times will be shorter, reviews will be more intelligent, and that we can all focus on making great software. Right now, however, the platform is a mess.

The chorus of disenchanted developers is growing and we’re adding our voices as well. Rogue Amoeba no longer has any plans for additional iPhone applications, and updates to our existing iPhone applications will likely be rare. The iPhone platform had great promise, but that promise is not enough, so we’re focusing on the Mac.

Add our voice to the chorus: fix. this. More after the break…

While many of these developers point to Apple acting as App Store gatekeeper as the issue, we’d submit right now the actual issue is Apple continuing to act as a capricious, illogical, unpredictable, often stupefying gatekeeper.

Curating a store is just a business model. It may well cost them developers philosophically opposed to the idea, even incredibly talented ones like Facebook’s Joe Hewitt, but every decision has an opportunity cost. Choosing to curate a store, even one growing so fast it has 2 billion downloads and 100,000 apps, and continuing to suffer from poor communications, overzealous legal oversight, unclear guidelines, and the crap shoot that seems ultimately at the core of any given app getting approved on any given day… it just doesn’t work.

Getting rid of the gatekeeper might treat the symptom but is it the cure? Apple legal could just as easily issue a DMCA demand notice for an app using artwork they felt was a trademark violation, and have it taken down — even under Google’s more open, publish-first, investigate-if-flagged App Market system. The problem is Apple shouldn’t think using that artwork is a problem on the iPhone if it isn’t on the Mac. That, and the dozens of other so-obvious-it-hurts-our-brains-issues, are what needs to be fixed, and what are driving developers to question the platform.

Like Palm, Apple could allow developers to skip review entirely, leave them off the storefront, but give them a direct download link to market and distribute on their own. That wouldn’t fix this issue. They could extend Ad-Hoc to infinity so there’d be no update notification or over-the-air (re)downloads, but developers could make binaries available themselves and users could drag and drop them into iTunes to install, along with beefy warning flags for “unapproved apps”. They could create those $999+ “pro” developer accounts, along with dedicated App Store point-of-contact and accelerated review process (levels of partnership program exist on many other platforms and in many other businesses).

Or Apple could just spend some of that 35 billion on hiring a legion of reviewers (rather than just 40ish), training them to the standards of Apple Retail, creating a second team dedicated to communicating with developers, and third team focused solely on whatever tiny percentage of cases, like the one above, spiral out of control.

Yes, Apple is making incremental improvements like email escalation and better review status messages, but every step forward always seems to be met with an equal and opposing step back.

2 billion downloads, 100,000 apps — Apple touts the growth and size of the App Store in press releases, they need to start respecting that size in practice. Observably respecting. It shouldn’t take a champion inside Apple. It shouldn’t take emails from Apple Marketing SVP, Phil Schiller. It shouldn’t take an open letter from Steve Jobs. (Though it might help restore some developer confidence at this point). It should just work, and Apple needs to invest whatever they need to invest at this point to make it work.

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

After 3 Months, 3 Rejections, Airfoil Speakers Touch Ships, Developers Leave iPhone

Joe Hewitt, the developer who saw the Facebook App for iPhone and iPod touch to version 3.0, and the cusp of 3.1 (which promised/threatened push notifications), has thrown us the Twitter-equivalent of a curve-ball:

Time for me to try something new. I’ve handed the Facebook iPhone app off to another engineer, and I’m onto a new project.

Just to be clear, he’s staying with Facebook, just no longer working on their iPhone app. Does it have anything to do with his dissatisfaction with the iTunes App Store approval process?

According to the quote he gave TechCrunch, it did:

My decision to stop iPhone development has had everything to do with Apple’s policies. I respect their right to manage their platform however they want, however I am philosophically opposed to the existence of their review process. I am very concerned that they are setting a horrible precedent for other software platforms, and soon gatekeepers will start infesting the lives of every software developer.

(Hit the link above to read the rest of it). Some are no doubt happy to see such a high profile developer quit the App Store over the review process. Hey, we’ve complained about it quite a bit as well. Still, with the current process Hewitt was able to give us a pretty darn good app up to this point. Was it frustrating? No doubt it was, but many of us face frustrations on the job. The web is free, but it’s also often far from a premium user experience. Apple has thus far decided managing the App Store is, in their opinion, the best way to ensure their users’ experience (not just their noisy tech-blogging-and-commenting users’ experience, but the kids and moms and casual users as well). That the implementation remains capricious is another matter — one they need to be fixed and now. That the App Store should by all divine right and reason be as open as web development, however, is just another opinion, another option, and certainly not any more right or reasonable “just because”.

In any event, on behalf of TiPb, we thank you, Joe for all your hard work and the awesome app you’ve given us to date, and wish you well on your future endeavors.

And to the new developer, here’s wishing you the best, and the best for future versions of the Facebook app as well!

[Thanks to everyone who sent this in!]

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

iPhone Facebook App Developer Says Goodnight and Good Luck

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

The Register is reporting that a lawsuit has been filed against an iPhone game developer for privacy violations:

The complaint claims best-selling games made by Storm8 contained secret code that bypassed safeguards built into the iPhone to prevent the unauthorized snooping of user information. [...] to access, collect, and transmit the wireless phone numbers of the iPhones on which its games are installed,” states the complaint, which was filed in US District Court in Northern California. “Storm8 does so or has done so in all of its games.” [...] [including] World War, iMobsters, Racing Live, Vampires Live, Kingdoms Live, Zombies Live, and Rockstars Live.

The complaint claims they’re violating the Computer Fraud and Abuse Act, and is seeking Class Action status. It’s not the first time we’ve heard about apps violating user privacy, hopefully Apple’s new iPhone security manager will first and foremost focus on these types of exploits. And, yeah, let the courts smite any abusive developers in the meantime…

[via Wabbit in the TiPb forums]

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

Lawsuit Claims Game Company Violating Privacy, Collecting iPhone Users’ Phone Numbers