Apple rejected iPad app for using pinch to expand gesture - Page 5

If there is a reason why you can't copyright gestures and what they cause a program to do, this would be part of it: http://en.wikipedia.org/wiki/Lotus_D...nt'l,_Inc..

Obviously, it would need to be tested as to whether this principle (which applies to keyboard interfaces) transfers to touch interfaces. But if it holds, Apple doesn't have a legal justification for preventing similar gestures in the copyright sense. Patent sense, obviously another issue.

Good link. Thanks.

I really think it may have more to do with the execution of the display of the gallery. Kind of like they may be able to protect the genie effect in OSX.

The 3rd Party Developer API is still subclassing Private API calls while overriding whatever base functionality that API provides and through reverse engineering you can determine that whatever you call your methods, if you call the SuperClass and send the following messages knowing it will respond to do as you desire you are in effect leveraging Private super class APIs that aren't meant to be used.

When Apple releases these API calls to the Public API frameworks it will be amazing how the exact method behavior of that third party developers framework mirrored that of the Private API.

Can a gesture even be patented? IF so that means I can patent the smile and frown and everybody would have to pay me everytime they do that ?

Also Tv shows have been doing pinch zooming and gestures long before apple was doing it. I dont understand how apple can even enforce this?

It's good to be the king

While I am a big fan of Apple products. I am at times wondering why they pick the silliest battles in the war. I would probably say they have become far worse.

Maybe they feel they have the patent on finger gestures. Good thing the one finger salute is open source.

So they aren't circumventing anything then. Unpublished means doesn't exist for developers. Filling gaps of functionality that an API doesn't provide is not circumventing the API.It doesn't mean they have circumvented the touch API either. They might simply be extending functionality on top of the existing API.

Not publishing certain parts of the API means you aren't to use those APIs. It does not mean you can't write code to fill the gap of these missing APIs.

Apple is very clear about not using undocumented APIs, so I don't feel sorry for these developers at all. When and if the APIs are ready Apple will release them.

Also it is complete BS for a developer to say that not being able to copy Apple makes his app inferior. Sadly I really think these guys are just milking the system for free advertising. What is even worst is people and forums are so gullible to lap it up. I mean really violate the SDK agreement and then whine publically about it. Nice!


Dave

So as far as you're concerned Apple can do anything they like at anytime and never mind if you've invested money based on assumptions that they aren't going to screw you over in the end. Business model kind of doesn't work if they keep doing this and in terms of fairness this is just wrong. I'm not prepared to give Apple a pass just because I might own Apple stock or what them to survive. There's behaviour that stifles competition and that is bad for customers.

I guess that would be a key point, if any of us knew they were using an unpublished API....since we do not and they seem to state that they specifically wrote their own code just to avoid a violation of using the unpublished API, then it really isn't a 'key point'.

Wouldn't make a lot of sense to use one unpublished API for the sake of avoiding using another unpublished API...but no, the article doesn't say explicitly that they did not use private APIs.

"raw touch events"..... that's available with published API no? So why is that a problem?

Some of the excuses people come up with are quite funny.

Put into context the call they made is either in a header or it isn't. If it isn't then they deserve rejection if though it was in a header published by Apple then Apple is in the wrong rejecting their application.

Of course there's no room for whining. In fact, quite literally developers agree NOT to whine or discuss these sorts of things. Remember when that article spoke about how the developer's agreement was picked apart? That was one of the items they spoke about.

Look, what you say is true, but the fact is this app was rejected because of Apple's own hubris and nothing more. Then what's funny is news like this comes out after people get into a big discussion over why people shouldn't jailbreak their iphones and ipads in another thread.

Oh well. Who cares? It's a good thing Apple protected it's users from this horrible app isn't it?

You sound like another banned alias. Clueless arrogance like that doesn't develop with only 9 posts.

we are stll waiting for Cover Flow!

To all those trying to "explain" why the app was rejected: Shouldn't that be Apple's job in the first place? If people need to explain Apple's explanation, then perhaps Apple did not provide a very good explanation to begin with. It appears that boilerplate, copy-paste rejection letters are not a substitute for detailed explanations written by someone who actually spent more than 1 minute reviewing the app.

Pinch to expand, pinch to zoom, whatever. Could be either or, since Apple has no patent on either that can be enforced. My bad. No reason to be a douche and accuse of trolling.


The end user license agreement that every developer must agree to include 7 criteria (or prongs in legal parlance, since that term has apparently irked you) that Apple will use to judge App Store submissions. The first six cover things like porn, malware, undocumented APIs, etc. (although the first six are in their own right ill defined, as has been proven beforewhat Apple considers "porn" can be wide ranging, from a wiki page about sex to hardcode skinimax). The last criteria is basically "Anything else not covered above is subject to Apple's discretion". There have been apps rejected based soley on this as well:
http://www.tipb.com/2009/06/12/apple...ection-policy/


Because I can't, due to Apple's retarded SDK NDA policies. You can only view the criteria for App Store rejection if you are part of the iPhone Developer Program. Disclosing the terms of the EULA agreement are a violation of the NDA. You can basically guess the rules but the "exact" rules are under NDA. That's why Apple has censored the notices that people get back from App Store rejections; posting the e-mail you received explaining why your app was rejected is also a violation of the NDA.
http://www.techradar.com/news/portab...rejects-470545


As I said, nothing I see in the EULA I see violates what this developer has stated, as long as he isn't using private APIs. But Apple can reject it for no reason, as I stated before, and as they have done before.

I think this may be my favourite post of the lot in this discussion!

I agree that the whole thing does seem rather silly. The guys who wrote the rejected app seem to be ingenious hacker types - much like Wozniak!

I still remember the guy who rolled his own custom "Cover Flow" from scratch, only to have his app rejected because Apple's review team thought he was using the private API. In the end he made his point and got approved.

I wonder if this time's rejection has anything to do with the devs using Picasa... Paranoid much?

I'm sorry, but "they didn't use an API"? Really? Are we to assume they hardcoded it? The article may make it somewhat apparent (Not completely) that they didn't make use of an undocumented API, but it is vague about how they actually achieved the result. I think it's possible they used a hack based on the publicly available pinch-to-zoom gesture. Apple would have likely deemed such a hack liable to breaking come OS 4 or some other update, because they would only be testing the API for pinch-to-zoom with pinch-to-zoom, not the hacked up pinch-to-zoomExpand.

Bear in mind though, the article doesn't give us all the facts, so that's just a guess.

At the end of the day, this is a drop in the bucket even if it is wrong on Apple's side (For example if a mistake was made by whoever reviewed the App). These complaints get so much coverage BECAUSE these problems are so rare. There are over 160,000 Apps available, and many more coming or rejected and we have heard of probably less than a hundred cases of seemingly unfair rejection.

Face it, you're better off playing in Apple's playground than elsewhere. It's huge, cohesive and it works. I think people forget how much of a mess mobile software was before the App Store. It was a nightmare! There was nowhere to go to find all the Apps, there was no easy way of monetising them, exposure was hard, accountability was nil...App Store has done vastly more good than harm. That's why every other platform has tried to copy it. But if you don't like playing by Apple's rules - possibly because you want unfettered access to do whatever you like, fine. Android exists, go use that. Windows Phone 6.5 is out, you could make Apps for that - or WebOS. God knows those last two need some Apps badly.

Just don't then complain that your Apps aren't as successful as those on iPhone OS.

If you watch the video of the app before they changed the functionality in question you will see that it's not the "pinch to zoom" feature that's the problem. It's the "pinch to peek" into the stack of photos which looks exactly the same as the Photo apps implementation. In fact, they did a really amazing job of duplicating it. I'm personally not surprised that they would reject it.

The amount of misinformation over 200+ posts is really sad.

Perhaps I can help:

1. The is no such thing as a 'Pinch to Peek' gesture.
The gesture is 'Pinch' and is one of 6 common gestures that are built in. Apple seems to have a problem with what the pinch was used to do...even though it isn't remotely hard. See below.

2. No undocumented methods are needed to read a pinch

3. Apple is essentially stopping these developers from doing math.
This so-called magical, Apple-only thing is essentially no different than a 2-D explosion, in simple math terms. There are a bunch of stacked windows and a bit of x+/- y+/- math going on here, modified by the distance between the two fingers. Most people can work something out like this on a piece of paper.

Basically, Apple wants to artificially claim that only they have the...whatever...to do simple multiplication.

Based on the above three pieces of information...how exactly is this either right, or defensible?

An aside: this forum form entry is horrid on an iPad.

What's speicial with Apple's platforms is:
1. Apple sets an example/ a standard of how things ought to work.
2. Developers are inspired and follow their example.
3. Apple's platforms are sport quality user interface across all apps.

If Apple breaks #2 there might not be a #3. Be careful Apple.

That said, this album looks like a direct copy of the built in Photo album. Hard to tell the difference, to be honest. I think if Apple should nag the developers it's not about the pinch-expand, but rather about the whole look and feel of the app. Hadn't Apple made their photo album first - this web album app probably would have looked totally different.

Then I apologize for jumping on you. But I was being sarcastic with that question (obviously not enough that you could tell)- and I thought you were doing the same in your reply. I tried to make it clear in my first sentence that I knew what he meant.

The only reason it was illegal for Microsoft was because it was found to be a monopoly. When you are a monopoly you are bound to more strict rules. Apple has never been found by the government to be a monopoly. It, however, should tread carefully.

Well said.

Btw, you think the text entry here is bad on the iPad, try doing it on the iPhone.

I do not see a problem with Apple's position. Apple probably has or is tying to get a patent on the gesture. In the very least it is trying to establish rights to the look and feel of it's touch screen devices. Apple's Bertrand Serlet is on a YouTube video explaining Apple's approach to private API's. Makes sense to me. In a nutshell, Apple essentially keeps them private until it has tested the API itself in it's own applications and is happy that it isn't going to want to change the APIs. So eventually Apple will probably make this API public. It likely will have little problem with the developer using the API at that time.

If my understanding is correct, the developer here bypassed the need for Apple's API by directly writing the code into the software. Apple wouldn't be happy with that because of the prior mentioned reason. Apple is likely claiming IP rights to the gesture. It is willing to allow the developer to use the functionality on it's platform when it opens the API, but it doesn't want the developer to incorporate the functionality directly into the application. If Apple allows that, it is essentially telling the developer it is OK to claim some sort of ownership in what Apple thinks is Apple's IP. Specifically, Apple would be worried about a developer using that gesture on another platform. If the code is in the developer's software, as opposed to in Apple's OS and merely accessed by the software, the developer can easily port the application containing that code to another platform violating what Apple thinks is it's IP.

You are right, and that is what makes this so odd. Apple has always encouraged consistency. Though even they have not always been consistent with their UI, it has generally been a hallmark of the Mac experience. So, when a developer tries to abide by the rules of the SDK by avoiding the use of prohibited APIs and tries to emulate Apple's example, it is puzzling that they get their wrist slapped.

Imagine if Apple forced all third party apps to use different inputs and gestures to implement cut and paste or forbade devs from using two taps to zoom.

Well said, but a couple points.

If Apple was trying to protect their IP on this gesture to prevent it from being used elsewhere, they should have included that in their rejection notification. Otherwise, what is stopping the dev from implementing it on another platform right now? Sure, Apple could then sue them, if it is an IP issue, but it would have been a lot easier to just explain it now. Otherwise the devs are left making assumptions one way or the other.

Also, I wouldn't describe it as bypassing the need for Apple's API, as much as using custom code to fill a gap in the published API. Doing anything not available in the published API involves custom code, so why is this being treated differently? Some explain the rejection as being because they used Apple's private API. This doesn't seem to jive with the available facts, though it is possible. Some see it as protecting Apple's IP on the gesture. This is also possible, but if so, it was not handled well. The article implies that the only reason given was that the gesture is reserved for Apple apps only. While it is possible they mean only until the API is finalized, it could also mean permanently. Either way, it means apps accomplishing the same thing but requiring different actions to get there. Enforced inconsistency seems un-Apple.

Then it was a good day

With that, I think I will bow out of this thread. What should have been simple discussions by everyone about something we don't have all of the details about, has turned a little sour!

I'm actually doing an exercise in the book iPhone SDK Programming (from Pragmatic Programmers) right now and on page 383 it shows the code to implement pinch to zoom - so, hardly forbidden then! Also as someone else has pointed out, Apple are making standard consistent gesture recognition even easier to implement.

So, it seems here that with a little information about an app rejection we have 6 web pages of surmise, speculation, innuendo, mud slinging directed at Apple, developers, 'idiots' who should know more about Apple's SDK and NDA and who knows who and what else?

What was that old (English) saw? "Send three and fourpence, we're going to a dance" as the mistranslation and Chinese whispers version of "Send reinforcements, we're going to advance".