mag 25

Apple clamping down on AirPlay receiver apps, including Rogue Amoeba's Airfoil

Apple has recently removed Airfoil Speakers Touch by Rogue Amoeba and AirFloat by The Famous Software Company from the iTunes App Store for using AirPlay APIs in a way Apple did not intend them to be used. These apps basically let you use another iOS device as an AirPlay speaker. So, for example, you could beam your audio from your iPhone to an iPod touch or iPad. Though these API's are public, it looks like some reverse engineering was needed to get them to work in this way, and that's what Apple has taken exception to. Airfoil was just taken down this week, while AirFloat was yanked last week.

Apple may just be sour that these devs have found a way to crack into AirPlay without going through the usual "Made for iPhone" accessory certification process, and allowed users to have AirPlay speaker setups without buying additional AirPlay certified audio gear.

There's obviously a big business in that kind of thing, but also a lot more quality control; there's no way of making sure these apps don't provide a sub-par experience, since there's no documented iOS API to test against. If the AirPlay is glitchy or inconsistent, then buyers might get the idea that AirPlay sucks, and will refrain from spending more on, say, an Apple TV.

There was a certain amount of noise made since these types of apps have been in the App Store for years in some cases, and have been approved over and over again during that time, including when they submitted versions with the AirPlay features.

Again, it shows that frustration doesn't only exist in Apple's curation, but in the sometimes arbitrary and sometimes delayed ways in which they enforce it.

Well, I guess the Cydia store exists for a reason... Is Apple right to shut these guys down and protect private APIs, or should they go ahead and let developers make cool apps that leverage the technology that's already there, stability and testing be damned?

Source: Rogue Amoeba, Daring Fireball, The Verge



Tagged with:
mag 02

Dropbox SDK technically violates App Store policy, causing Dropbox integrated apps to be rejected

Apple is currently rejecting apps that use the Dropbox SDK to provide integration with the popular cloud storage solution. The reason for the rejections is apparently that, under a specific but not inevitable set of circumstances, someone using an app with Dropbox integration could end up on Dropbox’s web site and find a way to pay Dropbox for additional storage. That would violate Apple’s prohibition against using external websites to circumvent Apple’s 30% cut of subscriptions. Dropbox attempted to patch the problem by removing links that would make getting to the full version of the website and finding and buying additional storage possible, but the rejections seem to have continued. Dropbox is now working to try and find a more satisfactory solution and says they’ll have more information on that next week.

On the surface, Dropbox broke a rule, caused a problem for developers using their SDK, and is now correcting the mistake. It doesn’t appear to have been an intentional or obvious violation, but it was eventually discovered and now Dropbox and their developers have to deal with it.

It’s that latter part that highlights some of the continued frustration with Apple’s App Store policies, frustrations that persist some 5 years after the introduction of the App Store. The review and rejection process is still, as often as not, impenetrable and capricious. Plenty of apps with Dropbox integration are already on the App Store, presumably using the same SDK as the apps rejected today. That they weren’t rejected as well doesn’t excuse Dropbox or the apps that were rejected today, but it shows that what one (or many) reviewers let in, another (or many others) may reject.

One of the rejections listed account creation for both Dropbox and Google. (You can pay Google for Google Apps or Google Drive, among other things.) It makes you wonder what would happen if an app linked to store.apple.com…

That’s part of what causes frustration with Apple’s system. Another part is things like the recent scam app plague. Apps that should have been obvious candidates for immediate rejection to any reviewer who laid eyes on them, were let onto the store to violate intellectual property rights and cheat users out of money.

One absolutely doesn’t excuse the other, but people have innate senses of fairness, and for rules to be respected they need to be perceived as being far. (As the old saying goes, people don’t mind paying taxes only because it’s generally believe everyone pays taxes.)

We want and need real humans reviewing App Store apps, but developers need to believe those reviewers are being fair, and applying broadly consistent standards with generally predictable results.

To their credit, Apple is continually improving the App Store review process. Because the process is human, they recognize they can’t always predict all of the edge cases, all of the time. They’ve made changes over the years, sometimes major ones like un-banning the use of cross-compilers, sometimes small ones like un-banning satirical political cartoons.

So far, however, they haven’t changed the policy that affects Dropbox — the requirement that Apple get 30% of all subscriptions, and that apps can’t link to external websites where the same subscriptions can be purchased without Apple getting that cut.

Again, Dropbox knew about it, accidentally broke it, and is now working to fix it. In the meantime, Apple will catch some criticism, both for the policy, and for the way the App Store handles policies. And given the power Apple wields, that kind of ongoing discussion isn’t a bad thing.

Source: Dropbox via @sethclifford



Tagged with:
mar 30

Apple let it be known back in August of 2011 that they’d be deprecating developer access to UDID ( Universal Device Identifier), they’ve now taken the next step and begun actively rejecting App Store apps that use it. The fine developers of Tweetbot have reported that one of their latest updates was rejected from Apple for collecting UDID information without getting user consent first. What does this mean for apps like Tweetbot?

[UDIDs] allowed us to restore push notifications settings after Tweetbot was deleted and re-installed. With this new change in place this is no longer possible, if you delete and re-install Tweetbot you’ll have to setup your push notification settings again.

The UDID is 40 characters that are unique to your iPhone and iPad, used most generally by developers to provision pre-release apps through the App Store. Now developers will need to create their own unique ID within the app and store it in iCloud.

Ultimately, it’s good news that Apple is making sure that developers aren’t easily getting a hold on potentially sensitive data like UDIDs; iOS users are a little on edge about privacy after that Path incident.

This might also explain the speed with which Apple went from deprecating the UDID collection to outright rejecting apps. Typically something deprecated in one iOS version will be removed in a later version, giving developers time and an expectation for when they need to have an alternative approach in place. This has led some developers, including Subfurther, to call it a “lousy way to communicate policy change”.

Source: Tapbots, Subfurther



Tagged with:
gen 05

Apple refunding purchases of "prematurely" released GameStore app

Apple is sending out refund notices to iPhone users who purchased GameStore, the bizarre Apple app that briefly appeared in the App Store over the weekend.

You recently purchase the GameStore app. The app was made available for sale prematurely. We apologize for the problem and have refunded the purchase amount back to your account. These funds will be applied to your original payment method within 5 business days.

While GameStore showed a release date of Dec. 31, 2011 in iTunes deskstop, the on-device App Store showed a date of June 9, 2009, which suggested it might have been a beta app used to test the iOS 3 in-app purchases feature.

The refund language, however, clearly says “premature”, which would suggest it will be properly released at a later date.

Whether or not that’s accurate, whether or not a new app with the same name but more current functionality, or whether there’s a different explanation remains unknown.



Tagged with:
 

Pages Menu 

Tags 

 

Archivi 

 

Categories 

Meta

preload preload preload