$500k Selling Camera+ politely pulled from AppStore with explanation, over deliberate attempt to circumvent ban on functionality that had been explicitly denied. An easter egg is putting a flight simulator in a spreadsheet program, this was just hiding a feature that had previously got the app rejected and then bragging about it.
That they did so after talking about how other apps tried to sneak things past and it was a stupid idea boggles the mind.
When Apple finds out about these incidents, they tend to crack down pretty hard on them, sometimes going so far as completely banning the developers from the App Store. So this is definitely not the smart way to go.
- http://taptaptap.com/blog/cameraplus-volumesnap-rejected/
I'm getting tired of these publicity stunts. Developers who knowingly try to pull a fast one should have all their apps pulled and their developer license suspended for a year. It's just too easy to leverage the review process to game the media.
Do you really think this is helping them more than it is hurting them?
I suspect the buzz they are gaining overlaps highly with people who have already been exposed to to taptaptap. This buzz isn't going to reach Grandma and cause her to buy that "rebellious software from that tappy place". Meanwhile, their app is no longer earning them money and Apple is going to be keeping a watchful eye on all of their subsequent releases.
Not to mention, the decay on this type of buzz probably has a half-life of 12 hours after it reaches its peak in one or two days. In two weeks nobody will think much of this story, and I doubt they'll have released anything to take advantage of the buzz.
Now, their buzz about earning $500k+ on the app, that was pretty helpful. Nothing sells a product more than press about how people can't get enough of it. Just ask Apple about that one.
I completely agree that pulling the app was justified, given Apple's stated rules, and also that it was incredibly stupid on taptaptap's part. They've managed to get their cash cow slaughtered for no reason other than perhaps getting some buzz -- though the people this buzz is reaching most likely overlaps highly with people who've already heard about the product, so I can't imagine it helping too much.
What I don't agree with is Apple's Iron Fist on products, and how they assume all of their users are fairly unintelligent and easily amused. My brother gave me an iPod Touch and I've just started using it. There's no icon to download apps, and to re-sync it (or whatever the hell I need to do) I have to download iTunes + quicktime + The Entire Archived Internet and go through an agonizingly long and painful process of clicking "no" everytime it tries to do me the favor of downloading album art for thousands of albums so that when I browse by album I will be able to see the ALBUM COVERS and it will look SO COOL. It "just works" entails iTunes spending days "determining gapless playback information" yet mysteriously having the "App Store Button" not present on the device and not telling me why. I found the answer on Yahoo Answers by somebody who I suspect was typing with their feet.
Assuming I go through the process of upgrading the Touch, which I probably won't, I'll need to provide my name, address, 3 credit card numbers, tag myself with a GPS transmitter, and fax them scanned fingerprints in order to download free Apps which they can assure me will not ever let my volume buttons be used for any other purpose, no matter how convenient.
Sigh. It's turned into a rant. The decision they made affects users as much as developers, it ultimately says: "You may want this feature, but you can't have it. Trust us, it's for your own good." Long story short, I personally don't care for that type of mentality. I won't deny the market loves it, but I'm not really sold. They're starting to appeal to me as the McDonald's of computers, only it's like the McDonald's in other countries where it costs more because it's a novelty and you're cool as long as you buy into the commercials and sports sponsorships.
Like when Yelp snuck in Monocole in before the iPhone 3.1 release? Except in that case, there was a very different outcome (they weren't removed from the store).
Maybe because they've already made bank and are sick of dealing with the app store? With those kind of profits, Apple should be accomodating them, not vice versa.
So Apple should abandon their rules and guidelines for popular developers? How is that fair to all the other developers in the app store? That's the exact opposite of what Apple should do.
Imagine if you were competing with Camera+ who, because they sell a lot of apps, were allowed to use the volume button as a shutter trigger. You come along with your camera app and try the same thing, only to be shut down by Apple just because you don't sell as many apps. That is definitively anti-competitive behavior and is the antithesis of what an app store should be.
No, they should abandon their rules and guidelines and trust consumers to make an informed choice.
If they really want to keep up with this nonsense they can make some sort of an "Apple Approved" logo that gives you better search rankings in the market if you get it. This draconian approval process is ridiculous.
Strawman alert. I never made the argument that they shouldn't run an unregulated app store.
Whether or not Apple should regulate app approval is a completely separate argument from the one presented in your original post. You stated that "with those kinds of profits", Apple should accommodate them. That implies favoritism. The only thing worse than a regulated app store is a regulated app store that exhibits favoritism.
It was a general statement. Apple makes profits off of developer sales, Apple should not be making developers' lives unnecessarily difficult.
Though I suppose yes, I would say that regulation based on sales is a much better metric than the capricious whimsy that currently governs the Apple approval process. (And yes, I'd call the HID standards whimsical, and although they specifically are not capricious, I'm again speaking in general.)
Although I generally dislike App Store model, I'd say this is a fair ban in the context of Apple's rules. They'd outlawed that functionality, so they removed the app when they tried to sneak it back in. This is perfectly logical.
However, if users want the functionality enough to bother going to secret URL to enable it, perhaps the rule is a bad one. Users clearly want something as simple as using a physical button to take a picture, but Apple won't let them because it violates their guidelines. On one hand, this means apps are consistent and follow Apple rules, but on the other hand, it means you simply cannot have a ridiculously simple feature simply because Apple says so. Would you rather have consistency or freedom?
I agree - the fact that you have to actively unlock this feature should mean that you are aware what you are doing and thus, the risk of confusion is not an issue.
Apple really goes out of their way to tell developers that they can be penalized for circumventing their restrictions, but if both developers and end users want to circumvent the restrictions you really have to wonder as a company if you are on the right path.
The bad press that Apple has gotten because of stuff like this in the last year is really starting to add up, and I think this is one of the best examples to date of why such control is wrong.
Strictly speaking this is not an 'easter egg' but a user interface policy violation, presenting it as an easter egg including a very difficult activation sequence should prove beyond doubt to Apple that these users are going to be perfectly happy with their volume control not working in the Apple dictated way. It is their volume control button after all (the users', not Apples).
if both developers and end users want to circumvent the restrictions you really have to wonder as a company if you are on the right path
And most people do wonder, and then they cave. Which explains the dynamic that drives 90% of the designs out there:
CUSTOMER: "I want to be able to receive email from inside my blog."
DEVELOPER: "No, really, you don't. Email is a complex beast. It will make your blog software much bigger and more complicated and fragile. You will spend a lot more to develop it and a lot more to maintain it. It will be hard to design in such a way that it's easy to learn and understand. And you may think you need it, but you don't."
[five minutes pass]
CUSTOMER: "The most important missing feature is: I want to be able to receive email from inside my blog."
DEVELOPER: "We talked about that five minutes ago. It is a really bad idea!"
[iterate fifty times]
CUSTOMER: "I want to be able to receive email from inside my blog."
DEVELOPER: "Okay! Okay! I want that, too, so that I can charge you money to implement it instead of fending off the request every five seconds."
[two months later]
CUSTOMER: "Why is my blog software so difficult for my new employees to learn, and why is it so complicated, and why does it cost so much to maintain?"
DEVELOPER: [stabs self with pen]
---
Design integrity is hard. Hard on everyone. Maybe that's why so few products have it.
Yes, but in this case the feature was dead simple, developers and users were on the same page but the vendor of the hardware (and the distributor of the software) nixed it.
Your example sounds like things I've been through multiple times, the best way we ever improved software was by leaving infrequently used features out. At some point we had blue-screening and stereo images in the webcam software, I don't think anybody ever used those except us for a demo of how cool the software was.
It made it quite difficult to get people back to 'normal' after a round of random clicking on settings to see what they do.
This sort of frustration is not just limited to the software world, in industrial design similar things happen.
Good design is usually tied to someone that knew as much or more about removing stuff than it is about adding stuff.
Personally I'm a big fan of the old 'Braun' designs. Someone ought to start using that sort of design for websites.
They do, it's called vitsoe.com. The thing is, the feature isn't dead simple. Implementing it would completely break a solid rule of the HIG of the iPhone. The quality of the UX on the iPhone exists because of those rules, just because something may seem like a good idea doesn't mean it is. Allow this and they're not volume buttons anymore, they're just general purpose buttons whose action is context specific.
I'd like to reduce the volume of my music but I'm in the NYTimes app so that will favorite the article instead.
> The thing is, the feature isn't dead simple. Implementing it would
> completely break a solid rule of the HIG of the iPhone. The
> quality of the UX on the iPhone exists because of those rules
I'm sorry, but if the HIG is Apple's 'ten commandments,' then they are guilty of multiple mortal sins. I can't comment much on the iPhone, but Apple has consistently (since the inception of OSX at least) broken their own HIG in their own applications. If Apple can't even play by their own rules, then why should everyone else?
It doesn't matter if it's something you enable explicitly, you're thinking about this the wrong way. Even if you enable it explicitly you have now compromised the uniformity of the utility of those buttons. There is now a cognitive cost of working out what that button is going to do every time you press it that didn't exist before, your quality of experience suffers. It's saving you from yourself.
Now you probably think that sounds anal retentive and patronising in equal measure but that's how you make good UX across a platform - by understanding the power of consistency to reduce the cognitive load of an interface.
Don't like it? You're welcome to go buy some random Android device with a random amount of buttons and widgets and d-pads and track balls that take a photos in this app and ring your grandmother when shaken to the left in the other app.
Personally however I'm glad this stuff is enforced. Sure, if it wasn't I could avoid apps that broke HIG, market forces and all that crap but that gets hard. I then have to try and find alternatives or put up with not having access to some functionality.
why does that only apply to physical buttons? The thing about the iPhone (and Android for the record) is that there are rather few interface commonalities between apps. It seems that everyone is designing their own widgets, styles, and creating vastly different affordances. The apps are all very flashy, but user interaction can vary pretty significantly from app-to-app.
I don't think that's necessarily a terrible thing. But why is that ok for the software (which is the bulk of the interface) and not the hardware?
So what happens six months after Apple greenlights a hypothetical "easter eggs can bypass stated rules" policy?
Do we see app instructions listing urls of unlocks right in iTunes? Is that a good place to be, with just about every new/updated app having an obtuse post-install 'enabling' process to achieve advertised features? (advertised, if not in iTunes, certainly by every review or word-of-mouth referral)
That doesn't sound like a remotely desirable situation to me. If a particular edge of policy is dumb, we should argue for it to be changed. Or flat-out argue for the removal of review.
Arguing for Easter Egg Bypass sounds like defeated bargaining.
I don't see how your link is not relevant, first of all.
(edit: eg, you could post links to lots of Flash, Java, whatever that run on OSX but aren't allowed in the App Store)
Also, I don't see how "developers and end users wanting it" changes anything, Apple is clearly not interested in letting developers and end users dictate how they operate, otherwise they would have been doing things differently from day one, and most obviously there would be Flash on the iPhone.
I think the point of his link was to show that OSX contains easter eggs, implying that Apple is being hypocritical by including easter eggs in their own software while rejecting iPhone applications that include them.
But this reasoning is flawed: Apple allows easter eggs in iPhone applications provided that the hidden behavior is revealed at review time. And running tetris in OSX's emacs is not an easter egg; tetris is a documented feature of emacs: http://www.gnu.org/software/emacs/tour/
When I saw the first pictures of the new iphone and heard about its camera, I looked at the volume buttons and automatically assumed that they would be used to take the picture; just like a real camera. The fact that you can't really baffles me. Touching a software button on the screen that you are trying to line up for a good shot is awkward and inelegant. Good for the camera+ guys for trying to include this feature. I only wish I had heard about it sooner so I could have gotten a copy. Maybe it is yet again time for me to jailbreak my phone.
Yeah, it basically kicks you out of whatever app you're in. Now, you can navigate back to apps once you're in the phone call, which could potentially cause a problem if both the phone app and the camera app are vying for the same control over the volume buttons, but Apple could just make it so the phone app always has priority over those buttons.
Your finger will already be resting on the volume buttons, just like they naturally would on any point and shoot camera. You just compress the button to take the picture and it won't jiggle. You're not awkwardly pressing down on the button with the tip of your finger like you're pressing an elevator button.
Untrue. Compressing the volume button of an iPhone 4 forces the bottom edge of the phone 2.5mm into the flesh of my thumb. (As tested with the thumb fully supported against a solid object. Free air is more complicated, since my thumb deflects backwards from the force
but my brain attempts to compensate for that.)
As for the screen touch, I find I hold the phone between the thumb and middle finger of each hand it is a "light grazing" with the index finger to take the shot… but I'd rather say "click"… usually.
While it was dumb of the developer to try and do it behind Apple's back, and they should have known they would get caught...
The logic behind Apple's rule that volume buttons cannot be used to control anything other than volume is that it may confuse users. Surely based on that, the fact that users had to go out of their way to enable the feature (more so than even changing settings within the application), the feature is only accessible to users who won't get confused.
Of course, once they discovered it, Apple did have to take the action they did (or risk opening themselves up to all developers taking the same risk), but they should consider allowing an exception to the rule for developers who make it hard enough to enable that kind of feature, while also providing users with valid warnings, documentation and an option to disable it again that is far easier than it was to enable it.
It's not an HTTP server, so that example wouldn't work. The URL needs to be visited (with an anchor or just by typing into the Safari address bar), and Safari will close and open the application associated with the URL scheme.
I don't know much about them specifically, but if they're anything like all the common schemes (http, ftp, ldap, etc), your application would be responsible for implementing a security policy.
For example, there is nothing about HTTP that implicitly prevents CRSF. However, web servers that speak HTTP pass information about the requester that can be used to prevent CRSF at the application layer.
This just goes to show how user-unfriendly Apple is. I understand why they have their HIG, and why they reject apps for breaking it. However, when a user goes to the trouble of entering in a secret URL they obviously want the secret feature very badly and are not going to get "confused" by it.
If the user can't buy an app the user wants to buy, then the user is being screwed just as much as the developer is. Maybe it's the developer's fault that the user is being screwed, but I argue that the developer was giving the users their most requested feature, and Apple is the one being user-unfriendly.
is there a legal requirement to have them in a particular order? Otherwise, I'm fairly sure you could have a mechanic do that, although it could end up being fairly expensive.
To extend your analogy to the issue at hand, Apple are in the position of owning every mechanic shop around, and explicitly forcing them not to offer this service or risk being shut down.
If you are screwed then you're up the creek without a paddle, in a hopeless situation. If you're being screwed then someone is taking the mickey, taking advantage of their power over you to your detriment.
Now, if someone is prohibiting modifications to your motor vehicle, then you probably are being screwed, though unless you have some health issue that prevents you from driving with the standard controls (or taking steady photos via an awkward touchscreen control) then you're likely not screwed by this imposition, just inconvenienced.
I really find it hard to wrap my head around that explanation.
Just to be clear, there is nothing wrong with monitoring and reacting to the volume control.
There is nothing wrong with taking pictures.
There is no "functionality" used that isn't permitted.
What they did was -- for users who overtly WANTED the functionality -- tie the volume control to taking a picture, only when their app is front and forward. Apple doesn't like this because they want to keep every app in the painted lines. However, yes, it's primarily a kick in the balls of every user who went out of their way, demonstrating that they wanted this usability. Apple has a stunning arrogance when it comes to how the product that you paid for should work.
They just cannot please everybody. There was a fuss when they were being arbitrary with their rejections and now there's a fuss when they reject an app for not following the rules.
Don't know and don't care much about it, but it says in the article that sneaking in undisclosed easter eggs is verboten and that is why [this version of] the app was rejected.
I assume the API provides notifications when the volume buttons are pressed so that an app that has music/sound can adjust it's own volume. Of course there is no way for apple to determine programatically that the app is using those notifications for some other purpose. So features like this end up being in the app, until a human spots it and rejects the app.
Huh. So you can access the volume buttons without using a private API? Or did Apple's tools somehow fail to pickup that the app was linking to a private API? That would be news!
I guess you can read the volume change without using a private API (like, a music player could use that function). If the volume changes, the user pressed the volume button.
Makes you wonder if this app also works with the volume on the iphone remote..
I want my volume buttons to always be volume buttons. I don't know if that's an unreasonable way of looking at the world or not. Having the ringer on/off switch helps but there are lots of times when you're wearing headphones that a sudden burst of loud sound (either on a call or un-normalized MP3s) is very uncomfortable. I don't want my SmartPhone to cause me pain.
If you want your volume buttons to stay volume buttons, I recommend not going out of your way to reprogram them. Or did you mean that you want MY volume buttons to stay volume buttons?
The policy outlined in the submission tip image seem pretty reasonable to me. With so many people building apps for iOS, one has to assume that some of them are malicious assholes.
What's interesting is that Apple's App Review process clearly did not know that that functionality is in the programme. I thought they were supposed to be evaulating and testing apps to ensure they are high quality?
Maybe it is shit, but it's also documented and the punishments for ignoring the policy are clearly laid out.
As much as you or I may think it's a bit dumb that Apple won't allow the easter egg, we can't be surprised by their reaction to it once they knew about it.
Apple will allow easter eggs, but you have to disclose them to the review team (they promise to keep them confidential). This "easter egg" wasn't disclosed, and was an attempt to get a feature into the phone that was rejected by Apple before.
Right or wrong, this violated Apple's documented restrictions--this shouldn't even be a story.
If people are interested in the issue then of course it should be. Just because a law or rule exists doesn't mean that people should be happy with it, or accepting of it. If my government passed a law that I didn't agree with and prosecuted someone for breaking it, then I'd be happy for that issue to be discussed in the media. It doesn't matter whether the person knowingly broke the law or not, I'd still want the issue to get publicity.
The story isn't about that though. The story is about how someone created an Easter Egg and Apple took the app down--exactly like they said they would.
If this story was "$500K worth of users want to use the volume button to take pictures, but Apple won't let us" now you have a story that might actually be worthy. Until then, no story.
I'm getting awfully annoyed at all these stories about how the App Store sucks, and the approval process sucks. Non-developers don't care about this. They buy the apps that are approved and follow Apple's guidelines. Apple doesn't care because its vetting process protects its users, and its brand. Only developers care. And if developers care, they shouldn't waste their time writing software for the platform. And they shouldn't use it either. Force Apple to change by voting against them. Until then, they'll only see it as good exposure, and find another app that users will tolerate.
I certainly thought it was a stretch to call it "backstabbing", but of course that's not Apple's choice of language. Really though, if you get rejected specifically for a certain feature, then secretly enable it anyway and try to slip it past the reviewers... obviously Apple cannot be expected to say that's okay. Even if you dislike the review process, surely you can't expect Apple's policy to be "it's okay to include functionality we've specifically rejected and hide it from us".
That they did so after talking about how other apps tried to sneak things past and it was a stupid idea boggles the mind.
When Apple finds out about these incidents, they tend to crack down pretty hard on them, sometimes going so far as completely banning the developers from the App Store. So this is definitely not the smart way to go. - http://taptaptap.com/blog/cameraplus-volumesnap-rejected/