Slashdot Mirror
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."
I just ran a search for WiFi in the app store, and plenty of free finders appeared.
Was there something about these specific apps, or is this just about those apps using reserved (ie subject to change) frameworks?
In short - let's not panic just yet, hm?
Is Apple actively trying to destroy any developer relationship that they had, and are they trying to show the community that they are not up to the challenge of hosting an app store?
As a software developer that owns an iPhone 3GS owner, and a first generation iPod touch, I feel like I am reminded every day as to why I do not drop $100 and write an application for my own phone.
if it's for using private API's, avoiding the MS bad publicity. everyone worked around MS bugs and Microsoft couldn't make needed changes in their OS's due to developers complaining it was going to cause them to write code. in Vista they had to pull a new anti-virus API because of this.
Apple is just forcing everyone to follow the rules in the developer agreement. last thing Apple wants is to release an iPhone OS update and to have thousands of apps fail due to private API use and then all the devs will complain how it's Apple's fault
Apple has NEVER permitted the use of private frameworks in iPhone apps. My company had to rewrite an app we were trying to deploy because we were using some undocumented features for still frame capture from the camera device. We almost made it through the authorization process, then Apple shot us down at the last second because of it. We had to wait a few more minor releases before the functionality we needed was exposed through an approved interface. It had nothing to do with our application, but rather, the way it was implemented.
In general, the use of undocumented APIs is frowned upon throughout the industry, as it makes for flaky application and reverse-vendor-lockin, when an extremely popular application relies on undocumented APIs, the APIs change, then people come bitching to the platform manufacturer for "breaking" their applications. There's nothing weird about this, whatsoever. Chill out, folks.
Ah yes, greater variety in fart generator applications is really high on my list of features I want from a phone.
"linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
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.
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.
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
no shit?
rewriting history since 2109
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.
Ah yes, greater variety in fart generator applications is really high on my list of features I want from a phone.
Out of curiosity, did Final Fantasy make it to Android?
Yes. Every NES, SNES (I think), and Genesis game is on Android via emulators. Here's a review of a NES emulator: http://www.crunchgear.com/2009/05/26/quick-review-nesoid-nes-emulator-for-android/
I guess it's not legal, but if you're willing to go the emulator route you pay only $2 for thousands of NES games instead of the $9 I just spent on Final Fantasy on the iPhone.
"I zero-index my hamsters" - Willtor (147206)
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.
Calling someone a "hater" only means you can not rationally rebut their argument.