Apple rejected iPad app for using pinch to expand gesture
So?
Perhaps the developer should have read the SDK.
Perhaps you should read the article.
Seriously, they didn't use closed APIs, they coded the gesture recognition themselves.
I think it's a harsh decision and also agree with a previous poster that Apple should be encouraging consistent gestures in software.
In some ways though this doesn't make sense, because several games use multi-touch. I think it may have more to do with Picassa being a google gateway, and the ongoing lawsuits around multi-touch. That may complicate things.
Apple rejected iPad app for using pinch to expand gesture
Apple likely is trying to patent the idea or it's already patented and they are licensing it for use only with their products and software, not third party.
Gestures for apple apps only? WTF apple, your whole platform is famous for the ability to use intuitive gestures. It's not like these developers are making their own OS. They helping you and your ecosystem to be more consistent and easy to use, or to put it more boldly, they are allowing you to move more hardware. Cracking down on developers for making apps better is not the right idea.
yeah, what's shocking is that the developer was "shocked" by the rejection.
The SDK terms of use do not have anything in there about "pinch to zoom" being only for Apple applications.
Likely Apple rejected it under the 7th prong, which basically states "We can reject your application for any reason we see fit". The other 6 prongs do not apply here, as the developer didn't do anything like use an undocumented API.
This is just another example of Apple being Apple?approving applications at whim, based on arbitrary rules.
The point is that the rules are changed mid-game in ways that are both arbitrary and unpredictable. This causes developers to waste huge amounts of time/money developing apps that fit the rules, but are nevertheless rejected.
Apple has lost several notable developer partners doing just that. It is not a simple "my way or the highway" situation. It is "my future way, which you cannot know" or the highway.
I am interested by this comment - which notable developer partners do you speak of ?
You guys really need to calm down. Developers aren't allowed to use the private APIs because they aren't READY yet. Watch this 60 second video on Bertrand Serlet on using Apple's private API's: http://www.youtube.com/watch?v=jd97us27eSg
Apple likely is trying to patent the idea or it's already patented and they are licensing it for use only with their products and software, not third party.
I was just about to say the same thing. If Apple is paying a license fee for the use of a gesture, that license might not extend to third party apps.
You guys really need to calm down. Developers aren't allowed to use the private APIs because they aren't READY yet. Watch this 60 second video on Bertrand Serlet on using Apple's private API's: http://www.youtube.com/watch?v=jd97us27eSg
He explains everything.
Whilst I agree re the access to the brightness controls surely this does not apply to the case where they coded their own routine to mimic a user interface look & feel ?
Apple likely is trying to patent the idea or it's already patented and they are licensing it for use only with their products and software, not third party.
This is the reason for rejection, I believe. I don't think it has to do with APIs, I think it has to do with Apple's multitouch patents.
If the developers had to write code to recreate the ability to do something (because they weren't allowed access to existing code), then shouldn't they have had a clue that it might be a problem.
I mean whether not allowing them to use the gesture is right or wrong on Apple's part, they still must have realized Apple didn't want them duplicating the function - otherwise Apple would have given developers access to it.
If the developers had to write code to recreate the ability to do something (because they weren't allowed access to existing code), then shouldn't they have had a clue that it might be a problem.
I mean whether not allowing them to use the gesture is right or wrong on Apple's part, they still must have realized Apple didn't want them duplicating the function - otherwise Apple would have given developers access to it.
...WTF apple, your whole platform is famous for the ability to use intuitive gestures. It's not like these developers are making their own...
It is no different than me deciding that I want to use cmd-Z for quit (instead of undo) or cmd-X to quit (instead of cut). The idea is to use a standard set of gestures for the same thing allowing a consistent user interface. If users are expected to use multi-touch successfully then there has to be a standard foundation not an ever changing foundation.
Consistency is why they had to detect and handle the gesture on their own - it is not meant to be overridden.
Take a look a Apple's HI Guidelines if you don't believe me. This is a big part of what made Apple's OS so successful on the Lisa, Mac, iPhone, Newton (oops, well no one is perfect). It is what they refer to as look and feel. This is why Windows apps (especially in the past) did not work - its like being in a pawn shop or flea market EVERYTHING is different just for the sake of being different.
This is a rare case where I actually side with the developer. Apple should *encourage* the use of consistent gestures to perform similar tasks throughout all apps running on the iDevices.
Look at it from the other side. those special gestures are what give Apple apps a potential edge. So of course they aren't going to let them go out.
Also, the API rule is known to all so why anyone would even try it is beyond me.
and frankly I don't see that this Picasa program is really inferior because you can only tap. It's a common and comfortable gesture for many
I am interested by this comment - which notable developer partners do you speak of ?
I had in mind the fiasco which was precipitated by the rejection of Google Voice apps. My recollection is that several prominent developers jumped ship. I'll take a quick look and see what I come up with for background info...here's a couple:
"Rogue Amoeba no longer has any plans for additional iPhone applications, and updates to our existing iPhone applications will likely be rare," said Kafasis. "The iPhone platform had great promise, but that promise is not enough,"
Is this only the case for iPad apps? The Facebook iPhone app uses pinch to zoom for photos.
they aren't talking about zooming a single item but the zoom flick gesture that has been highlighted on the ipad for opening and spreading out photos in an album
Seriously, they didn't use closed APIs, they coded the gesture recognition themselves.
I think it's a harsh decision and also agree with a previous poster that Apple should be encouraging consistent gestures in software.
In some ways though this doesn't make sense, because several games use multi-touch. I think it may have more to do with Picassa being a google gateway, and the ongoing lawsuits around multi-touch. That may complicate things.
Quote:
Originally Posted by skittlebrau79
The SDK terms of use do not have anything in there about "pinch to zoom" being only for Apple applications.
Likely Apple rejected it under the 7th prong, which basically states "We can reject your application for any reason we see fit". The other 6 prongs do not apply here, as the developer didn't do anything like use an undocumented API.
This is just another example of Apple being Apple?approving applications at whim, based on arbitrary rules.
There is no mystery here. iPhone/iPad apps are not bring your own. You either develop with the built in APIs, or you don't develop. Given that the gesture was not part of the gesture library, it goes without saying that developing your own gesture is not an option. It also does not coincide with the Apple mandates that all apps conform to iPad standards, and not create their own types of gestures and interactions. Including the mimicing of built in features that are not part of the SDK.
Reading the SDK would prevent 99% of App Store rejections.
Apple likely is trying to patent the idea or it's already patented and they are licensing it for use only with their products and software, not third party.
Apple purchased the entire multi-touch thing (Fingerworks), IP, patents and all and the fellow that did the original work is now an employee (last I heard).
They have some work to do with Elan Microelectronics but Apple's legal guys think it is theirs.
If the developers had to write code to recreate the ability to do something (because they weren't allowed access to existing code), then shouldn't they have had a clue that it might be a problem.
I mean whether not allowing them to use the gesture is right or wrong on Apple's part, they still must have realized Apple didn't want them duplicating the function - otherwise Apple would have given developers access to it.
Not really. The API's not being available could simply be because Apple's APIs are not yet ready for release. Nothing about that says it is then verboten to implement custom code to do the same thing.
Comments
Apple rejected iPad app for using pinch to expand gesture
So?
Perhaps the developer should have read the SDK.
Perhaps you should read the article.
Seriously, they didn't use closed APIs, they coded the gesture recognition themselves.
I think it's a harsh decision and also agree with a previous poster that Apple should be encouraging consistent gestures in software.
In some ways though this doesn't make sense, because several games use multi-touch. I think it may have more to do with Picassa being a google gateway, and the ongoing lawsuits around multi-touch. That may complicate things.
Apple rejected iPad app for using pinch to expand gesture
Apple likely is trying to patent the idea or it's already patented and they are licensing it for use only with their products and software, not third party.
yeah, what's shocking is that the developer was "shocked" by the rejection.
The SDK terms of use do not have anything in there about "pinch to zoom" being only for Apple applications.
Likely Apple rejected it under the 7th prong, which basically states "We can reject your application for any reason we see fit". The other 6 prongs do not apply here, as the developer didn't do anything like use an undocumented API.
This is just another example of Apple being Apple?approving applications at whim, based on arbitrary rules.
The point is that the rules are changed mid-game in ways that are both arbitrary and unpredictable. This causes developers to waste huge amounts of time/money developing apps that fit the rules, but are nevertheless rejected.
Apple has lost several notable developer partners doing just that. It is not a simple "my way or the highway" situation. It is "my future way, which you cannot know" or the highway.
I am interested by this comment - which notable developer partners do you speak of ?
He explains everything.
Apple likely is trying to patent the idea or it's already patented and they are licensing it for use only with their products and software, not third party.
I was just about to say the same thing. If Apple is paying a license fee for the use of a gesture, that license might not extend to third party apps.
You guys really need to calm down. Developers aren't allowed to use the private APIs because they aren't READY yet. Watch this 60 second video on Bertrand Serlet on using Apple's private API's: http://www.youtube.com/watch?v=jd97us27eSg
He explains everything.
Whilst I agree re the access to the brightness controls surely this does not apply to the case where they coded their own routine to mimic a user interface look & feel ?
Apple likely is trying to patent the idea or it's already patented and they are licensing it for use only with their products and software, not third party.
This is the reason for rejection, I believe. I don't think it has to do with APIs, I think it has to do with Apple's multitouch patents.
I mean whether not allowing them to use the gesture is right or wrong on Apple's part, they still must have realized Apple didn't want them duplicating the function - otherwise Apple would have given developers access to it.
If the developers had to write code to recreate the ability to do something (because they weren't allowed access to existing code), then shouldn't they have had a clue that it might be a problem.
I mean whether not allowing them to use the gesture is right or wrong on Apple's part, they still must have realized Apple didn't want them duplicating the function - otherwise Apple would have given developers access to it.
Finally the voice of reason!
...WTF apple, your whole platform is famous for the ability to use intuitive gestures. It's not like these developers are making their own...
It is no different than me deciding that I want to use cmd-Z for quit (instead of undo) or cmd-X to quit (instead of cut). The idea is to use a standard set of gestures for the same thing allowing a consistent user interface. If users are expected to use multi-touch successfully then there has to be a standard foundation not an ever changing foundation.
Consistency is why they had to detect and handle the gesture on their own - it is not meant to be overridden.
Take a look a Apple's HI Guidelines if you don't believe me. This is a big part of what made Apple's OS so successful on the Lisa, Mac, iPhone, Newton (oops, well no one is perfect). It is what they refer to as look and feel. This is why Windows apps (especially in the past) did not work - its like being in a pawn shop or flea market EVERYTHING is different just for the sake of being different.
This is a rare case where I actually side with the developer. Apple should *encourage* the use of consistent gestures to perform similar tasks throughout all apps running on the iDevices.
Look at it from the other side. those special gestures are what give Apple apps a potential edge. So of course they aren't going to let them go out.
Also, the API rule is known to all so why anyone would even try it is beyond me.
and frankly I don't see that this Picasa program is really inferior because you can only tap. It's a common and comfortable gesture for many
I am interested by this comment - which notable developer partners do you speak of ?
I had in mind the fiasco which was precipitated by the rejection of Google Voice apps. My recollection is that several prominent developers jumped ship. I'll take a quick look and see what I come up with for background info...here's a couple:
"Rogue Amoeba no longer has any plans for additional iPhone applications, and updates to our existing iPhone applications will likely be rare," said Kafasis. "The iPhone platform had great promise, but that promise is not enough,"
http://www.pcworld.com/article/16922..._look_bad.html
?"My decision to stop iPhone development has had everything to do with Apple?s policies.? ? Joe Hewitt"
http://techcrunch.com/2009/11/11/joe...s-the-project/
Is this only the case for iPad apps? The Facebook iPhone app uses pinch to zoom for photos.
they aren't talking about zooming a single item but the zoom flick gesture that has been highlighted on the ipad for opening and spreading out photos in an album
Perhaps you should read the article.
Seriously, they didn't use closed APIs, they coded the gesture recognition themselves.
I think it's a harsh decision and also agree with a previous poster that Apple should be encouraging consistent gestures in software.
In some ways though this doesn't make sense, because several games use multi-touch. I think it may have more to do with Picassa being a google gateway, and the ongoing lawsuits around multi-touch. That may complicate things.
The SDK terms of use do not have anything in there about "pinch to zoom" being only for Apple applications.
Likely Apple rejected it under the 7th prong, which basically states "We can reject your application for any reason we see fit". The other 6 prongs do not apply here, as the developer didn't do anything like use an undocumented API.
This is just another example of Apple being Apple?approving applications at whim, based on arbitrary rules.
There is no mystery here. iPhone/iPad apps are not bring your own. You either develop with the built in APIs, or you don't develop. Given that the gesture was not part of the gesture library, it goes without saying that developing your own gesture is not an option. It also does not coincide with the Apple mandates that all apps conform to iPad standards, and not create their own types of gestures and interactions. Including the mimicing of built in features that are not part of the SDK.
Reading the SDK would prevent 99% of App Store rejections.
Perhaps the developer should have read the SDK.
Does the SDK actually say that doing what they did is forbidden?
Apple likely is trying to patent the idea or it's already patented and they are licensing it for use only with their products and software, not third party.
Apple purchased the entire multi-touch thing (Fingerworks), IP, patents and all and the fellow that did the original work is now an employee (last I heard).
They have some work to do with Elan Microelectronics but Apple's legal guys think it is theirs.
If the developers had to write code to recreate the ability to do something (because they weren't allowed access to existing code), then shouldn't they have had a clue that it might be a problem.
I mean whether not allowing them to use the gesture is right or wrong on Apple's part, they still must have realized Apple didn't want them duplicating the function - otherwise Apple would have given developers access to it.
Not really. The API's not being available could simply be because Apple's APIs are not yet ready for release. Nothing about that says it is then verboten to implement custom code to do the same thing.