Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Apple yanks Wi-Fi detectors from App Store (theregister.co.uk)
48 points by alexandros on March 4, 2010 | hide | past | favorite | 50 comments


I think this is the real reason - just a couple of days ago Microsoft announced they would license a database of geolocated WiFi transmitters from Navizon:

http://www.navizon.com/Microsoft_selects_navizon_for_geoloca...

Navizon was able to develop a huge database of geolocated WiFi transmitters by having people run their application on iPhones. They got people to run their app by offering actual cash for number of WiFi transmitters you located


Even if that is the "reason", it still doesn't explain why, or provide a "reason". What has that got to do with Apple yanking such apps.

Is Apple now just pissed that its hardware was used to create a valid business for another company?

So what if Navizon created that database, and so what if MS purchased that database. What has that got to do with Apple??


One of the very cool things about the iPhone is that it can locate you almost instantly because it uses SkyHook's database of geolocated WiFi locattions (exclusively maybe? anyone else know of a mobile device that uses SkyHook for location?) I see it as Apple trying to defend that instant location feature from Microsoft adding it to it's new mobile OS. Apple isn't suing them, but no sense in helping them make their device work better with an app running on an Apple device.


Skyhook is no-way exclusive on the iPhone. You can use it in your Android or WinMobile app, I think it's included in the Droid, and it's in other Wifi products.


GPS and tower triangulation make location by WiFi not as useful on a phone. Phones by law have to be able to know where they are (for e911) and a WiFi database doesn't meet the level of accuracy.


Tower triangulation is really just not very precise (at the moment). If I'm in an area with no wi-fi networks and attempt to get my position without GPS, then I'm given a pretty huge range of coordinates I can be in (at least a square mile). If I give it enough time, AGPS can kick in and get me closer, but if I am in range of a couple of wi-fi networks, I'm usually within 50-100 feet or so in a couple of seconds. The majority of APs seem to be in Skyhook nowadays. I understand why Skyhook can't be used for e911 — APs can move, or the information can be inaccurate from the start. So, in that respect, AGPS is more accurate, but not as precise. In my daily usage, precision is more important to me.


WiFi location is fast and works indoors and in the concrete jungle, that's the advantage. It may not be accurate but it could be self-correcting - the iPhone could feed info back into the skyhook system about the location of a new hotspot after it gets the call tower and GPS info.

I have no proof that it does, but I have an anecdote. The first time I plugged in my WiFi point at a new address, the phone connected and thought I was at the old address - until 5 minutes later when if shot me across the country. Never happened again.


So why do you think Apple use WiFi positioning on the iPhone?

GPS can take minutes (or never come back with a location if you are inside) and tower triangulation has never lived up to the accuracy claims that they made.


It's a nice backup and is very useful in the iPod Touch.


citation needed


"We received a very unfortunate email today from Apple stating that WiFi Where has been removed from sale on the App Store for using private frameworks to access wireless information," explains one developer, though Apple has apparently declined to explain exactly what rule the scanning applications are breaking.

---

Well if they are using private APIs as the quote suggests, there's the rule they're breaking right there. If so, this isn't news, move on.


I wrote the first WiFi stumbler that hit the app store (WiFinder / WiFi Checker). It was probably the first app to use private APIs, as dubious a distinction as that is.

The reviewers rapidly figured out I was using them, told me about their displeasure, and let me know they'd not be approving any updates. They just only now (more than a year later!) got around to removing the other applications using the same APIs. Until now, they were just denying updates but leaving the applications in the store. And occasionally, a new application using the same APIs would squeak through a foreign app review site (I'm looking at you, Japan!).

Overall, though, at least this is a set of rules they're trying to be clear on and are finally consistently enforcing. If only they had the ability to, oh, I don't know, check if the submissions were linking against dlopen() instead of expecting the reviewers to guess if private APIs are in use! If only we had the technology... owait...


I'm not familiar with development for the iPhone, but the whole public /private API is interesting. Back when Microsoft was getting investigated by the antitrust depth some put forward the argument that MS had internal docs and secret APIs which were not public, and this was considered anticompetitive.


Only because they had the windows monopoly though, and were using it to build a monopoly in office apps.


I guess that's a valid defense at the moment

I'm curious: Does Apple sell any apps of its own in the App Store? And, if so, do they reject other apps for being similar?

(Being able to deny OpenOffice access to the Windows platform because it duplicates functionality in Notepad is the kind of power Microsoft can only dream of...)


apple does indeed sell apps of its own in the store:

http://itunes.apple.com/us/app/texas-holdem/id284602850?mt=8

it seems like they are for the most part playing fair: apple's apps don't use private apis, they are required to compete against other apps the same as the rest of us, and so on. if there have been any violations of that "gentleman's agreement," i haven't heard about them, and i pay a lot of attention to the blogosphere on this subject.

it seems to be only the apps that are installed by default on the device that get special treatment.


No they're not. Anything too similar to an apple app gets the boot.


Can you cite an example where an app has gotten the boot for being too similar to an Apple app that is sold in the store (i.e. one that does not come installed by default on the phone)?


"We received a very unfortunate email today from Apple stating that WiFi Where has been removed from sale on the App Store for using private frameworks to access wireless information," explains one developer, though Apple has apparently declined to explain exactly what rule the scanning applications are breaking.

So Apple told them the removal is due to the use of private frameworks, but they don't know what rule they're breaking?


I'm finding the way Apple handles the App Store less and less acceptable.


What is different now? They have never allowed apps that use private frameworks. Some slipped through the cracks and are now being removed. How is this becoming less acceptable? Or are you just buying into the media's knee-jerk reaction each time an app gets removed?


That's an awful lot of apps to slip through the holes. The disturbing part is not so much that apps that violate their terms get removed, it's that seemingly nobody is safe.

Take the recent removal of adult-themed apps for instance - they in no way violated Apple's developer terms, but were banned anyways. Apple is well within their rights to do it - you're on their platform, but IMHO this sort of thing will encourage developer flight if it continues.

If history is any indication, the best cause of dissent and rebellion is inconsistent governance - people may tough it out if there's a 100%-effective way to keep the gestapo from raiding your home at night, but if you introduce enough uncertainty they will run and/or fight. By encouraging this sort of seemingly arbitrary banning, Apple is risking the long-term health of the App Store.


No, applications using private frameworks are allowed on a case-by-case basis, e.g. http://arstechnica.com/apple/news/2009/12/steve-jobs-interve... and http://www.macworld.com/article/144963/2009/12/ustream_iphon...


I'm really not "buying" anything. I just don't think they banned those apps on technical grounds. What the hell does that even mean - "private frameworks" ? Isn't this exactly the kind of thing that got Microsoft into trouble ? They are just abusing a market position if you ask me. And hiding behind all sort of most absurd excuses (when they bother to give some at all).


if you don't know what it means, then there's not much point in arguing with you.


I love this kind of comments... it's like UK and France were talking about Germany before WW2 :))


Um... Godwinned?


    But now even those have vanished as Apple decided
    they were using a "private framework", and has 
    pulled them off the shelves without explanation 
    or apology.
Apple does not like you messing around with the private frameworks. If this is the reason, these developers should have seen this coming.


I'm not exactly sure what a private framework means. Is this like a shared library that they are all using? What is the problem with doing that from Apple's point of view?


It's a non-documented/non-public API. Typically these APIs are either likely to change without warning, haven't been fully tested for 3rd party app use, or can cause issues (battery life, interference with other core iPhone features, etc...). Whether it's the iPhone SDK, or your favorite web app dev framework, using non-public APIs is generally a bad idea.


I agree that it's probably a bad idea. However, coming from Windows, you don't really think twice about it. MSFT has a long history of continuing to support all APIs, no matter how you get to them, and not really caring what you do with them.

Heck, I remember arguments on the .NET framework team when 1.1 was shipping about how to handle third-party applications that had used Reflection to access private members of class instances and whether the data could be changed. In several cases, it was going to break a few widely-used or mission-critical apps.

I personally didn't even think twice and just went ahead and used private APIs, especially since they were literally direct copies of entry points available on OS X, just missing headers & an import lib.


Why not let the market decide? This autocratic policy of actually killing apps is bound to generate speculation, mostly unfavorable. What possible benefit outweighs that?


> Why not let the market decide?

Apple never lets the market decide. It hasn't since Steve Jobs came back from NeXT. "The market" is incredibly bad at spurring the kind of innovation Apple wants on its own. Because "the market" is largely composed of people who have no fucking clue what they actually want from technology. They couldn't tell you what they really want unless you trained them. Even then, they might not be able to.

"The market deciding" is what we've had pre-iPhone with the incredibly conservative and stunted market behind smartphones. Everyone—and I mean everyone in the mobile space—had the technology to create the iPhone. No one did. Why? Because the HTC Crapfest and the Blackberry Eyebleacher sold plenty well. Because instead of taking bold risks and trying for real innovation, companies like Palm and RIM crawled forward with a constant eye towards this quarter's revenue. It's a malaise that has infected so much of the world's business.

Apple's approach is frustrating and inconsistent, which is repugnant to the News.Y crowd (myself included). But it's allowed them to continue to shape the AppStore into something they want and something that moves product. It's the foundation for future products as well. So don't ask, "Why not let the market decide," because we all already know the answer. What Apple is doing may be a slipperly slope, it may be doomed to fail long–term and it may be infuriating and alienating to its developer base. But undeniably it's a business strategy that is at the heart of the ascendancy of their products onto a worldwide market.


QOS (Quality Of Service). Apple thrives on providing a high-quality service. It's nearly their entire business.

Using private frameworks / unpublished / not-locked-down APIs is a ticking time-bomb from a stability standpoint. What if it changes?


Apple has documented certain APIs. Others they have not documented.

They call all class interfaces and view hierarchies "private apis" and forbid access to those APIs by developers. If you use them and apple figures it out, no app store for you.

There is really little difference between the private and public APIs other than the fact Apple has or hasn't blessed them for use.


There's so many possible explanations for why these apps were yanked (battery conservation, legal concerns over war driving, compatibility issues) that the lack of clearly naming at least one is a little frightening. With Apple yanking political apps, scantily clad apps, and now Wi-Fi apps, I really don't get the rush by media companies to secure a place on it.


Well, they were told it's because they were using private frameworks. Which means not-locked-down APIs. That's just inviting them to be yanked at some point, as they're just waiting to break. Frankly, it's surprising they got through at all, Apple was being rather loose with their rules in this area.

Plus, they're duplicating functionality, which they've been rather explicit in the past about not allowing.


Not approving apps that are going to break because they use private frameworks makes sense, but pulling a wide variety in one genre after they've been published and found a foothold just sucks.

And while Apple has been "explicit" about not allowing "duplicate" functionality, that standard is incredibly vague in practice and incredibly arbitrary in enforcement.

In this case, one of what I presume is the banned apps (the article doesn't mention any, grr!) supported some non-duplicative features for war driving assistance, as well as a "radar" view. So yes, some features are duplicated, just like Pandora duplicates some features (playing, pausing music) that iTunes does.

WiFiFoFum's product review/description page on MacWorld, with 1,549 reviews: http://bit.ly/bF4gMP


Sucks, yes, I'm not defending the suckiness of the app store. Few can deny that.

But its purpose is not to lower suckiness for developers, it's to lower suckiness for consumers. They're merely being consistent in that goal.


If they were using private API's (as many here are claiming), then why didn't the infamous and lengthy app store review process find that before these apps made it to the market? If they can't even find out that an app is using private API's, what are they spending 7-8 weeks reviewing?


You're assuming that the reviewers are programmers; don't.

The review process was changed a month or two back; from something along the lines of "Will the app crash? Does it look like its doing anything evil?" to something closer to `automatically scans for private api usage` + "does the app crash doing basic tasks within the app".

The review process now takes a lot less than 2 weeks (or 2 months, at worst). I've heard stories of approvals for updates within an hour recently.


I'm certainly not assuming the reviewers are programmer. However, it'd be super simple to create an automated tool that would scan an app to see if it uses any private API's.

Am I suggesting Apple should do this? Not really. I don't actually see that much value in it. What I do think is interesting is that people often try to justify Apple's ridiculous, lengthy, and arbitrary review process by implying that the review process is someone keeping iPhone users safe from viruses or other malevolent programs. But clearly that's not the case. If the App Store approval process isn't sophisticated enough to identify apps that are using private API's before those apps are approved and released on the market, then clearly the approval process isn't going to identify malware of any reasonable level of sophistication.


"I've heard stories of approvals for updates within an hour recently."

For whatever this anecdote is worth: Within the past week I encountered this in the wild. I saw that an update for an app was available and immediately installed it. Later the same day, I saw another update was available for the same app.


This is an issue that needs more attention. The app review process gets plenty of attention as it is, and in this case, deserves more than it is getting.


It is not review process that gets attention but horror stories associated with it. Nobody cares and nobody talks about the apps which were approved quickly, but review gone badly get too much (imho) attention. Especially from those who most likely will never have to deal with it themselves.


I have authored WiFi Hopper for Windows (http://wifihopper.com).

iPhone development was in the pipeline -- not any more.


You should develop it for Android instead.


if you were planning to use the same private method, then you probably shouldn't have put it in the pipeline in the first place.


More details here: http://www.washingtonpost.com/wp-dyn/content/article/2010/03...

All apps using a technology called PlaceEngine to estimate location via wifi signals have been banned. Supposedly there's a statement on PlaceEngine's Japanese site (http://www.koozyt.com/?lang=ja) saying that Apple changed their policy regarding the way apps access Wi-Fi devices. I don't read Japanese, so I can't verify what it says. Does anything care to translate?


The sad part was that WiFiFoFum was a great app to diagnose problems with my work network. I really hope this one gets resolved somehow.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: