Google has announced they’ll be limiting and eventually shutting down the Google Translate API, meaning any iPhone or iPad apps that rely on the service for free translation functionality aren’t going to be able to reply on it any longer.

The Google Translate API has been officially deprecated as of May 26, 2011. Due to the substantial economic burden caused by extensive abuse, the number of requests you may make per day will be limited and the API will be shut off completely on December 1, 2011.

Google Translate is a great, free-as-in-Google web-based language translation service that can tell you what a seal is in French or what ferme means in English. The API let developers use that free service in other web apps, or in native apps like those in iOS. Which is what Marco Armant guesses just might have been the problem.

I wonder how Google felt about all of these iPhones hitting their free translator constantly. Seems like the kind of service that they might want to be exclusive to Android. Maybe iPhone apps are the “abuse” they’re talking about.

Microsoft’s Bing still offers a free translation API, so developers have an alternative, for now at least. It’s another example, however, of how risky it can be to base your app on the goodwill and free offerings of a big internet company like Google, Twitter, or Facebook.

[Google Code via Marco.org]

Multitasking was widely rumored to be coming to the iPhone with iOS 4, but instead of a traditional “leave full apps running in the background” approach, Apple instead chose to implement a more restricted but, they felt, better performing and power friendly solution involving 7 specific background API (application programming interfaces.) Is that, however, the best solution to the multitasking challenge as Apple claims? I spoke to several developers during WWDC 2010 and asked them that question.

First, we’ll review what Apple is doing in iOS 4, then we’ll see if developers think it works as well in reality as as Apple says it does on stage.

How does Apple say iOS 4 multitasking works?

In addition to the existing push notification service from Apple’s servers, which provide sound, badges, and alert popups for everything from IM to game challenges, iOS 4 adds local notifications so something like an alarm-clock app could register an alert that would sit in the iPhone in the background until the proper time, then activate. That takes the online server out of the equation which is good for tasks that don’t need additional information from the cloud, and so don’t have to activate the radios.

There’s another API for task completion so that, for example, if you’re uploading a picture to Twitter and leave the app, it can register a thread to keep uploading the picture in the background while you do something else. That means the entire app doesn’t have to keep running, freeing up memory and lightening battery load, and even the thread will terminate when the upload is done.

Fast task switching deals with the perceptive speed that multitasking offers. With previous versions of iOS, if you left an App Store app it would shut down completely and if you went back — regardless if it was a second or a week or later, it would usually restart not from where you left off but from essentially the beginning. (A few developers tried to add persistence on their own, so they’d save your place when you came back as best as previous OS versions allowed, but most didn’t — especially games which was aggravating when phone calls pulled you unexpectedly out of them). Likewise, if you closed one app and went to another, you could theoretically be stuck swiping back or forth between 11 home screen pages.

Saved state is now built into iOS 4 so all developers can more easily have their apps remember exactly where you were when you left and put you right back at that position when you return, Apple has also added a fast app switcher UI that, when you double tap the home button, lifts up to show you your apps “in the background” sorted in order of last usage. That means, if you’re moving between a set of commonly used apps, they’re most likely right next to each other and not screens and screens away. These two elements combine together to make launching apps perceptively much faster, even though the apps don’t have to be running in the background consuming resources just for that convenience.

Lastly, but perhaps most famously, Apple is allowing apps to register three specific types of the threads for persistent backgrounding (they can just keep running until you close them). Again, this isn’t the whole app running, just one thread from the app, so the idea is it won’t slow down performance, use up memory, or drain battery to the same degree. These API are for streaming music, location, and VoIP (voice over IP).

This means you can listen to Pandora, Slacker, etc. while surfing the web. Navigon, TeleNav,TomTom, etc. can keep using the GPS and alert you to directions while you’re on the phone, and to further save resources, non-critical location apps like FourSquare, Gowalla, Loopt, etc. can be alerted when you change cell towers. Fring, Skype, Line2, etc. can answer calls and receive messages when you’re not in the app, making the. More equal telephony citizens.

How do developers think iOS multitasking really works?

Of the developers I spoke to during WWDC — and I certainly didn’t speak to them all — they were remarkably pleased with how iOS multitasking was working out in practice. For those who made large, resource intesive apps, they actually preferred Apple solution since they didn’t want to be blamed for performance hits on other apps while they were in the background (especially performance hits for other intensive apps like games). So far, they were also excited by the relatively low impact on battery life compared to traditional, full-on app backgrounding.

In terms of implementation, the devs I spoke with were really happy about how quickly they could implement the background APIs in their apps — really quickly, much faster than they thought.

(if you’re a developer with a different opinion, send it our way so we can get as well-rounded a sampling as possible).

How will users think iOS 4 multitasking works for them?

Like with copy and paste, it’s possible Apple really did take their time to get multitasking right. It’s also possible that, like many other Apple solutions, it will be outstanding at what it does, but limited or non-functional for those who want to do more — like have an SSH session stay open in the background, or have their Twitter, IM, or RSS timelines be ready and waiting, just like mail, when they open an app.

We’ve heard from Apple, we’ve heard from developers, and starting June 21 when iOS 4 goes live for end users, we’ll hear how it works for all of them in the real world.

That, of course, will be the true test.

iPhone 4.0 beta 1 is now available to developers via http://developer.apple.com/ and it doesn’t just bring the 7 “tent-pole” features announced so far for consumers, it brings 1500 new APIs to developers including some we’ve been waiting for for a long time:

• Date data detectors
• Calendar access
• address data detectors
• Automated testing
• Block based animation
• iPod remote control accessories
• In-app SMS
• Regular expression matching
• Performance profiling tools
• Accelerate (2000 API’s for hardware accelerated math functions)
• Date formatters
• Spell check
• Photo library access
• Image I/O
• Embed PDF metadata
• Draggable map annotations
• Half-curl page transition
• Quick look
• Power analysis tools
• Full map overlays
• Call event notification
• Full access to still and video camera data
• ICC profiles

Tweetie 2 and Twitterrific 2 aren’t just two of the best Twitter clients for the iPhone, they’re two of the best mobile micro-blogging interfaces on the planet and now both WordPress and Tumblr are taking advantage of them — which is ridiculously awesome for iPhone users.

WordPress now lets you “Post and Read via Twitter API”, and they have a complete walkthrough posted on how to set it up.

We’ve enabled posting to and reading of WordPress.com blogs via the Twitter API. Any app that allows you to set a custom API URL will work. This project came out of our Quebec meetup and was developed by Team 55 (Andy, Terry, and Raphael).

Inspired by WordPress, Tumblr has also jumped on board:

The really cool thing – because our following models follow a lot of the same principles, we’ve been able to take advantage of a ton of native features:

• Retweeting = Reblogging
• Replying = Reblogging w/ commentary
• Favoriting = Liking
• “@david” = ”http://david.tumblr.com/”
• Conversations = Reblogs

So if you use Tweetie or Twitterrific, and WordPress or Tumblr, the API elves have given you an early present. Let us know how well it works for you.

[via @roustem]

UPDATE: iPhone dev extraordinaire Erica Sadun investigated over at Ars and found the following: Google is both linking to Private Frameworks and using unpublished APIs. While the latter is likened to jaywalking, the former is apparently a ban-worthy offense. Yikes. Check out her complete investigation for more. And now that it’s public, the question shifts to what if anything Apple will do about it? Cave to Google over a killer feature and betray the confidence of other developers, or yank Google’s app, alienating a huge (if guilty) partner and likely creating another furor among users?

Original post:

Is Google using private (i.e., not publicly available via the official iPhone SDK) APIs to create the silky-smooth “raise the phone and talk” activation for their new Advanced Voice Search feature in the update Google Mobile App? That’s the latest question Daring Fireball‘s been looking into, and here’s what they’ve found so far:

If you use something like the command-line strings utility to examine the UIKit framework, you can see that there’s an undocumented (and therefore private to Apple) method named proximityStateChanged. And if one were to strip the FairPlay DRM from the current Google Mobile application binary — which, of course, you wouldn’t do, because you’re not supposed to strip FairPlay DRM, but I’m just saying if one were to do this — a class dump of the application binary would show that Google Mobile does in fact implement proximityStateChanged.

DF posits three possible explinations: 1) No one at Apple noticed the private API usage, 2) Apple noticed but turned a blind-eye, or 3) Apple approved the use of a private API. Citing sources, DF claims #3 to not be the case, and perhaps that’s why Google promoted the feature so heavily, and stirred up interest so high Apple would feel pressure to approve it (though we wonder if Steve Jobs’ Apple ever feels that type of pressure?)

By contrast, DF states #1 is not without precedence, while #2 would be grossly unfair to other developers, and either way, users may suffer if Apple makes changes to their private APIs (which is one of the reasons to keep them private after all).

So what do you think? Which scenario is most likely? And what would you rather, that developers (Google or not) use officially unsupported features if it means better apps but also apps that might just break when the next firmware drops?