Apple Removes Wi-Fi Finders From App Store

jasonbrown writes "Apple on Thursday began removing another category of apps from its iPhone App Store. This time, it's not porn, it's Wi-Fi. Apple removed several Wi-Fi apps commonly referred to as stumblers, or apps that seek out available Wi-Fi networks near your location. According to a story on Cult of Mac, apps removed by Apple include WiFi-Where, WiFiFoFum, and yFy Network Finder."

Comments

Re:walled garden

[nmb3000]

So what it really comes down to is whether one really wants (in this case) a WiFi finder. I certainly won't miss such apps.

First they came for the VoIP apps, and I did not speak out--because I had unlimited minutes;
Then they came for the erotic apps, and I did not speak out--because I am religous;
Then they came for the WiFi stumblers, and I did not speak out--because I do not need one;
Then they came for my app--and no one spoke for me because 'Apple knows best'.

A little melodramatic, maybe, but still somewhat apt I think. Apple has shown they have no qualms about removing entire categories of applications for the iPhone, all without provocation, explanation, or compensation. Anyone who depends on (develops for or uses) the iPhone in a serious business or financial sense is crazy.

Re:walled garden

[fuzzyfuzzyfungus]

Unfortunately, what you say isn't quite true. If it were, the problem would be self-correcting.

In order for app development to be financially viable, it has to possess a risk/reward ratio that compares favorably to other possible investments. Apple's trigger-happy tendencies raise the risk; but their install base and user willingness to shell out keeps the reward high. The real risk is not that they'll drive out app developers; but that they'll manage to preferentially drive out the good app developers.

If I am running some cookie-cutter app sweatshop, churning out masses of crap under one or more company names that are little more than reskins of one another, with slightly different content packs(here's an app with twenty fart noises, here's another one with the same noises that we had the intern spend ten minutes tweaking with audacity and the buttons reskinned to look more like mucus blotches! Here's 50 pictures from the cheapest softcore porn back-catalog that we were able to licence. Hey, here's the same app with 50 different pictures! And so on and so forth), all I need to do is make money on average. If some of my apps never get approved, some get sacked 18 months in, some do OK, some prove PT Barnum right yet again, I'll come out just fine. By making so many crap apps, each one representing a small investment, I spread my risk out substantially(and, since the iPhone is the hot thing among well-heeled and app-happy cellphone users, getting merely average results will probably be satisfactory, particularly if I'm paying offshore rates for my dev time).

On the other hand, some classic Mac indie dev house, pouring their heart and soul into one or two apps at a time, faces a very different situation. Their apps are substantially less likely to get shitcanned for sucking or for being tasteless; but their costs per app are comparatively huge. If an important patch update gets stuck in review hell for three weeks, while they rack up negative reviews, they are sunk. If their brilliant little gem happens to be a little too close to something Apple has planned for iPhone OS v. 4, it'll simply be murdered in the cradle without useful comment. Those odds are considerably less compelling.

Re:walled garden

[mjwx]

PCs you assume everyone has a pointing device and a keyboard, but with phones they may have a touch screen, or lack a touch screen. There might be an accelerometer, or it might not be there. You may be able to have a physical keyboard, but a lot of Android phones don't.

I dont think you understand Android development at all.

I'm not having a go at you but you seem to miss important points which are massive flaws in your arguments.

Android much like Windows has certain minimum hardware requirements (pointing device, x number of physical buttons, display device with minimum resolution). Much like Windows I can have additional or disparate hardware (D-pad vs trackball, higher res screen) but the API's are still meant to interpret the minimum standards of input so text from a soft keyboard is treated the same as text from a physical keyboard, the d-pad on a Droid/Milestone acts the same as the trackball on my Dream/G1 from the perspective of the application as that input is coming from the OS (HAL) not the HW directly.

Your issue hinges on a program which require specific hardware to be present, if a developer has this requirement then they've made a conscious decision to use a specific platform and has to deal with the problems that arise from that. This is a conscious decision on the part of the developer, not a flaw in the OS.

A program like APNDroid will work the same on all models as it was developed to use Android API not vendor specific hardware. The same as in Windows where a game (Half Life 2 for example) will work on a Logitek keyboard as well as it would on a Microsoft keyboard because it uses the Windows API for input, not hardware specific vendor drivers.

The problem you describe is exactly the problem Operating Systems, or more specifically the HAL (Hardware Abstraction Layer) were made to solve. It's a 25 yr old problem, with a 24 yr old solution.