The rules did not change. The developer was pushing their luck to begin with.
Exactly. The pinch to expand gesture is a private API, and not yet available for public use. Writing a code to circumvent the Apple's private API is prohibited.
Macworld just posted a great article that might help explain the issue. Not that most here will read and understand it.
Quote:
For its part, Apple has always been very clear on the fact that private framework usage isn't allowed?even going so far as developing automated tools that scan software destined for the App Store for the use of unpublished functionality. In fact, Apple's own use of private frameworks in apps that can be downloaded from the App Store seems to be limited to what is strictly necessary, with much of that functionality eventually ending up becoming public.*
And concludes with
Quote:
In its defense, it's worth noting that Apple does seem to keep an eye on what developers want from its frameworks and eventually makes more and more functionality available to them. For example, the camera access framework has been opened up considerably since the release of iPhone OS 2.1 to allow developers to create their own interfaces and augment the capabilities of the built-in Camera app. Similarly, a number of previously-private frameworks?such as those that allow a developer to tell whether a device is docked and how much battery charge remains?have been made available for public consumption, lending credence to the fact that Apple's motives are fuelled by a desire to control its platform rather than to necessarily maintain a competitive edge.
Moreover, with a sneak peek at the future of the iPhone OS just around the corner, it's highly likely that more functionality?much of it perhaps specific to the iPad and forthcoming models of the iPhone?will soon be released to developers. Perhaps, therefore, all that developers need is a bit of patience as the Apple development machine gets around to finalizing the private frameworks and opening them up.
In the end, private frameworks remain edge cases; the vast majority of apps that are submitted to the App Store are either approved or rejected on a basis other than private framework usage, and the numbers clearly indicate that this issue has not prevented the formation of a vibrant?and profitable?software ecosystem around iPhone OS.*
From what I am reading, the developer did not use private APIs. They wrote their own code to duplicate a function. So even if the API was changed it would not affect this application.
...That's my point, thanks for pointing it out?
Quote:
Originally Posted by Mooso
As far as I am concerned, it is Apple's ballgame, and they can make any rules they want and tell developers exactly how they can program for their devices. If the developers don't like it, go play somewhere else.
Obviously I'm talking to a brick wall.
I honestly find it depressing. If Adobe or Microsoft or Google pulled this kind of thing the response would be very different. It's no bloody wonder people think everyone with an Apple product is a coolaid guzzler when this kind of insanity is defended.
Edit: To quote the article;
Quote:
Originally Posted by Article
Sykora said Apple's application programming interface in the iPhone OS software development kit does not provide a way to do the gesture, so he and Kaneko coded it themselves.
Ergo, they did not use private APIs. So either they're lying (and unless Apple states so, it can't be proven) or they duplicated the functionality which is not against the rules. Just like Peeps and the CoverFlow shenanigans.
I honestly find it depressing. If Adobe or Microsoft or Google pulled this kind of thing the response would be very different. It's no bloody wonder people think everyone with an Apple product is a coolaid guzzler when this kind of insanity is defended.
Well I guess you didn't make your point very well. You have no idea what I would say if MS or Google did "this kind of thing". I'm sorry you find it depressing, maybe things like this shouldn't be so important in your life.
Why should you have the right to write software that does anything you want on Apple's phone, or MS's phone, or Google's phone, or whatever product from whatever company. If they want to allow that and accept the results, so be it. If they want to keep the experience up to their standards, it is their product.
If people don't like the rules, and stop developing for it, then it won't be around for long. Apple (or whoever) doesn't owe you anything.
Can't people read? These guys did NOT use a private API.
Quote:
Originally Posted by Mooso
Bottom line, because it is Apple's platform, and they make the rules.
But that's the issue - is there a rule that forbids doing this? Has apple actually TOLD devs they can't do this? Or is it just apple making up the rules as they go along without spelling them out?
Quote:
Originally Posted by irnchriz
They thought they were being smart asses by copying a gesture from one of Apples apps which Apple have kept the API for private.
And WHY would that not be allowed? Is it forbidden by the SDK? If it's not I don't see any reason to expect devs not to do it.
I don't really care whether this is legal or Apple is on moral high ground (seems shaky to me).
It just plain looks bad... it's unclear, goes against the platform and looks childish in my opinon.
I also don't see this decision being changed at all given their stance on HTC and multitouch; I fear this will erode Apples platform, which is sad, as they are the innovator here and everyone else are the copycats.
They could clear this up really quickly by providing an API to do this appropriately.
Functionality has nothing to do with it - Apple doesn't support applications using private APIs because they are not meant for developer use. They might change or be removed and do not want people to potentially have to remove an application from the store because it can no longer function or give the impression iPhone OS is unstable because applications relying on the private API crash.
If functionality was the issue, Peeps would not have been accepted on the app store for duplicating cover flow without relying on private APIs.
How is using the pinch gesture an "outside API"?
But they didn't do that according to the article. They wrote their own code that interacted with the pinch gesture. Apple does expose an API to pinch but it is intended for zooming the view not providing alternate functionality. This is where I think the developer got into trouble. Although Apple reserves the right to use the pinch gesture in any implementation they want, third party developers are restricted to using pinch only to enlarge the view not to trigger some other event. Also I don't think Apple wants developers to start interpreting raw touch events in their own code.
Well I guess you didn't make your point very well. You have no idea what I would say if MS or Google did "this kind of thing".
I made my point fine, you just felt the need to reiterate it for some bizarre reason. You said;
Quote:
Originally Posted by Mooso
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.
So according to you, every application that uses a custom view to replicate a default one should be rejected - and there are a lot of people doing this to speed up their apps. Every application that coded their own gestures to replicate built in ones for specific purposes should be rejected. Custom controls duplicate functionality of native ones. And so on. Your argument is asinine and a pretty blatant 'Apple can do no wrong'.
Quote:
Originally Posted by Mooso
I'm sorry you find it depressing, maybe things like this shouldn't be so important in your life.
Oh gee "get a life" card. Quite amusing from someone who's post history reads like a sycophant.
Edit:
Quote:
Originally Posted by mstone
Although Apple reserves the right to use the pinch gesture in any implementation they want, third party developers are restricted to using pinch only to enlarge the view not to trigger some other event.
If a user becomes used to, as an example, this pinch-to-expand gesture from Photos and sees a similar application, and then tries to use it the same way unsuccessfully - because the gesture is 'reserved' - who is at error? Just to note: I agree misusing gestures is absolutely a great reason to reject applications. This doesn't read like misuse to me.
Can't people read? These guys did NOT use a private API.
But that's the issue - is there a rule that forbids doing this? Has apple actually TOLD devs they can't do this? Or is it just apple making up the rules as they go along without spelling them out?
And WHY would that not be allowed? Is it forbidden by the SDK? If it's not I don't see any reason to expect devs not to do it.
I can't tell you if this particular thing was spelled out or not. But, it doesn't matter. If Apple changes the rules in the middle of the game, they have the right to do that (and I'm not talking things that might be considered legal issues). It may not be smart. It may not be good for business, but it is their right. If doing this frustrates developers, and they stop developing for the platform, then Apple will have to deal with the consequences of their actions (losing business, sales, etc.).
Why would that not be allowed? Because Apple created that action and has the right to allow it or not. People get up in arms "you can't patent a gesture" - they are really patenting what the gesture does as input for the computer. No, you can't patent pinching your fingers together, but why can't you patent pinching your fingers together on a touch screen to make a photo gallery expand in a certain way? That is what separates one product from another - the user experience.
I made my point fine, you just felt the need to reiterate it for some bizarre reason. You said;
So according to you, every application that uses a custom view to replicate a default one should be rejected - and there are a lot of people doing this to speed up their apps. Every application that coded their own gestures to replicate built in ones for specific purposes should be rejected. Custom controls duplicate functionality of native ones. And so on. Your argument is asinine and a pretty blatant 'Apple can do no wrong'.
Oh gee "get a life" card. Quite amusing from someone who's post history reads like a sycophant.
Edit:
If a user becomes used to, as an example, this pinch-to-expand gesture from Photos and sees a similar application, and then tries to use it the same way unsuccessfully - because the gesture is 'reserved' - who is at error? Just to note: I agree misusing gestures is absolutely a great reason to reject applications. This doesn't read like misuse to me.
Not capable of a civil debate, are you? Where exactly am I trying to please anyone in my posts - I simply speak what I have to say - and, unlike you, I can usually do it in a civil way (that can change).
The point is they are duplicating it exactly. Same gesture, creating the same action, for the same result. All they probably had to do was change the animation of the gallery to look different, so it wasn't a direct duplicate of Apple's software feature. I never said Apple can do no wrong, funny how you only saw Apple in their when other companies were mentioned. It may not be good for business, but Apple has the right to do what they want, as does every other company. That is the point you are missing, jackass.
IMO Apple should be actively encouraging the proper & full use of the multi-touch, not suppressing it.
What if, in 1984, Apple told developers "You cannot duplicate any functionality, including UI, that's already present in MacPaint, MacWrite, and Finder".
WTF?? The Mac never would've gotten off the ground.
Anyway I don't think we're getting the full story here; Apple should be thrilled that a developer would want to implement pitch-zooming.
Funny, you always cry when someone doesn't talk nice to you. But sure are quick to come to the aid of jackasses who are incapable of a civil discussion.
If a user becomes used to, as an example, this pinch-to-expand gesture from Photos and sees a similar application, and then tries to use it the same way unsuccessfully - because the gesture is 'reserved' - who is at error? Just to note: I agree misusing gestures is absolutely a great reason to reject applications. This doesn't read like misuse to me.
I don't think that the gesture itself is misused because it is the exact same functionality that Apple employs in the Photo App. It is more the implementation that was misused in their App. The API for interpreting raw touch events is already exposed and these guys didn't use it. It is sort of a case of undermining the API provided and finding a way to work around the methods approved by Apple.
There will likely be a public API for this functionality coming soon.
Exactly. The pinch to expand gesture is a private API, and not yet available for public use. Writing a code to circumvent the Apple's private API is prohibited.
Care to explain how writing custom code, that provides functionality missing from the published API is 'circumventing' their API? If the API doesn't do it, you really are left to do it yourself. Sort of the point of programming, no? If Apple hasn't made their API for this available, they will have their reasons. Perhaps it isn't ready, perhaps it will be in iPhone OS4. As far as it being private, then to a developer, it is though it doesn't exist. This then means rolling your own. That simple. This isn't circumventing anything. Not publishing an API is not the same as forbidding the function. Using the API itself if forbidden, but it is a leap to assume that means the functionality is...until now.
Quote:
Originally Posted by Abster2core
Macworld just posted a great article that might help explain the issue. Not that most here will read and understand it.
Unfortunately, for those of us that do understand it, we are left wondering why you state that it might explain the issue. The issue is writing custom code so as to specifically avoid using Apple's unpublished API. The article does a great job explaining why APIs might not be published and why devs shouldn't use them. Nothing at all to do with explaining if an API being private means never being able to implement custom code. Two very, very different things.
Care to explain how writing custom code, that provides functionality missing from the published API is 'circumventing' their API? If the API doesn't do it, you really are left to do it yourself. Sort of the point of programming, no? If Apple hasn't made their API for this available, they will have their reasons. Perhaps it isn't ready, perhaps it will be in iPhone OS4. As far as it being private, then to a developer, it is though it doesn't exist. This then means rolling your own. That simple. This isn't circumventing anything. Not publishing an API is not the same as forbidding the function. Using the API itself if forbidden, but it is a leap to assume that means the functionality is...until now.
Certain gestures are defined. Apple probably doesn't want defined touch events to be accessed any other way than through the API. So these guys are circumventing the pinch gesture by circumventing the touch API and gaining access to the raw touch events rather than calling functions in the UI library
Why would that not be allowed? Because Apple created that action and has the right to allow it or not. People get up in arms "you can't patent a gesture" - they are really patenting what the gesture does as input for the computer. No, you can't patent pinching your fingers together, but why can't you patent pinching your fingers together on a touch screen to make a photo gallery expand in a certain way? That is what separates one product from another - the user experience.
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.
Comments
Apple rejected iPad app for using pinch to expand gesture
So?
Perhaps the developer should have read the SDK.
Here here. Well said
The rules did not change. The developer was pushing their luck to begin with.
Exactly. The pinch to expand gesture is a private API, and not yet available for public use. Writing a code to circumvent the Apple's private API is prohibited.
Macworld just posted a great article that might help explain the issue. Not that most here will read and understand it.
For its part, Apple has always been very clear on the fact that private framework usage isn't allowed?even going so far as developing automated tools that scan software destined for the App Store for the use of unpublished functionality. In fact, Apple's own use of private frameworks in apps that can be downloaded from the App Store seems to be limited to what is strictly necessary, with much of that functionality eventually ending up becoming public.*
And concludes with
In its defense, it's worth noting that Apple does seem to keep an eye on what developers want from its frameworks and eventually makes more and more functionality available to them. For example, the camera access framework has been opened up considerably since the release of iPhone OS 2.1 to allow developers to create their own interfaces and augment the capabilities of the built-in Camera app. Similarly, a number of previously-private frameworks?such as those that allow a developer to tell whether a device is docked and how much battery charge remains?have been made available for public consumption, lending credence to the fact that Apple's motives are fuelled by a desire to control its platform rather than to necessarily maintain a competitive edge.
Moreover, with a sneak peek at the future of the iPhone OS just around the corner, it's highly likely that more functionality?much of it perhaps specific to the iPad and forthcoming models of the iPhone?will soon be released to developers. Perhaps, therefore, all that developers need is a bit of patience as the Apple development machine gets around to finalizing the private frameworks and opening them up.
In the end, private frameworks remain edge cases; the vast majority of apps that are submitted to the App Store are either approved or rejected on a basis other than private framework usage, and the numbers clearly indicate that this issue has not prevented the formation of a vibrant?and profitable?software ecosystem around iPhone OS.*
*http://www.macworld.com/article/1504...vate_apis.html
Macworld just posted a great article that might help explain the issue. Not that most here will read and understand it.
Thanks.
And, yes, you are, unfortunately, correct.
From what I am reading, the developer did not use private APIs. They wrote their own code to duplicate a function. So even if the API was changed it would not affect this application.
...That's my point, thanks for pointing it out?
As far as I am concerned, it is Apple's ballgame, and they can make any rules they want and tell developers exactly how they can program for their devices. If the developers don't like it, go play somewhere else.
Obviously I'm talking to a brick wall.
I honestly find it depressing. If Adobe or Microsoft or Google pulled this kind of thing the response would be very different. It's no bloody wonder people think everyone with an Apple product is a coolaid guzzler when this kind of insanity is defended.
Edit: To quote the article;
Sykora said Apple's application programming interface in the iPhone OS software development kit does not provide a way to do the gesture, so he and Kaneko coded it themselves.
Ergo, they did not use private APIs. So either they're lying (and unless Apple states so, it can't be proven) or they duplicated the functionality which is not against the rules. Just like Peeps and the CoverFlow shenanigans.
This is pretty lame of apple. These guys didn't use the API, they coded the gesture themselves.
Regardless of the sdk, I am so glad apple did not become that repressive company in the commercial they made back in the 1980's. Soooo glad...
...That's my point, thanks for pointing it out?
Obviously I'm talking to a brick wall.
I honestly find it depressing. If Adobe or Microsoft or Google pulled this kind of thing the response would be very different. It's no bloody wonder people think everyone with an Apple product is a coolaid guzzler when this kind of insanity is defended.
Well I guess you didn't make your point very well. You have no idea what I would say if MS or Google did "this kind of thing". I'm sorry you find it depressing, maybe things like this shouldn't be so important in your life.
Why should you have the right to write software that does anything you want on Apple's phone, or MS's phone, or Google's phone, or whatever product from whatever company. If they want to allow that and accept the results, so be it. If they want to keep the experience up to their standards, it is their product.
If people don't like the rules, and stop developing for it, then it won't be around for long. Apple (or whoever) doesn't owe you anything.
Regardless of the sdk, I am so glad apple did not become that repressive company in the commercial they made back in the 1980's. Soooo glad...
Some might advance the opinion that they have become far worse.
I'm pretty sure they can't do that eithier.
Based on what? Does the SDK say that?
Wanting instant release of these private APIs...
Can't people read? These guys did NOT use a private API.
Bottom line, because it is Apple's platform, and they make the rules.
But that's the issue - is there a rule that forbids doing this? Has apple actually TOLD devs they can't do this? Or is it just apple making up the rules as they go along without spelling them out?
They thought they were being smart asses by copying a gesture from one of Apples apps which Apple have kept the API for private.
And WHY would that not be allowed? Is it forbidden by the SDK? If it's not I don't see any reason to expect devs not to do it.
It just plain looks bad... it's unclear, goes against the platform and looks childish in my opinon.
I also don't see this decision being changed at all given their stance on HTC and multitouch; I fear this will erode Apples platform, which is sad, as they are the innovator here and everyone else are the copycats.
They could clear this up really quickly by providing an API to do this appropriately.
Functionality has nothing to do with it - Apple doesn't support applications using private APIs because they are not meant for developer use. They might change or be removed and do not want people to potentially have to remove an application from the store because it can no longer function or give the impression iPhone OS is unstable because applications relying on the private API crash.
If functionality was the issue, Peeps would not have been accepted on the app store for duplicating cover flow without relying on private APIs.
How is using the pinch gesture an "outside API"?
But they didn't do that according to the article. They wrote their own code that interacted with the pinch gesture. Apple does expose an API to pinch but it is intended for zooming the view not providing alternate functionality. This is where I think the developer got into trouble. Although Apple reserves the right to use the pinch gesture in any implementation they want, third party developers are restricted to using pinch only to enlarge the view not to trigger some other event. Also I don't think Apple wants developers to start interpreting raw touch events in their own code.
Well I guess you didn't make your point very well. You have no idea what I would say if MS or Google did "this kind of thing".
I made my point fine, you just felt the need to reiterate it for some bizarre reason. You said;
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.
So according to you, every application that uses a custom view to replicate a default one should be rejected - and there are a lot of people doing this to speed up their apps. Every application that coded their own gestures to replicate built in ones for specific purposes should be rejected. Custom controls duplicate functionality of native ones. And so on. Your argument is asinine and a pretty blatant 'Apple can do no wrong'.
I'm sorry you find it depressing, maybe things like this shouldn't be so important in your life.
Oh gee "get a life" card. Quite amusing from someone who's post history reads like a sycophant.
Edit:
Although Apple reserves the right to use the pinch gesture in any implementation they want, third party developers are restricted to using pinch only to enlarge the view not to trigger some other event.
If a user becomes used to, as an example, this pinch-to-expand gesture from Photos and sees a similar application, and then tries to use it the same way unsuccessfully - because the gesture is 'reserved' - who is at error? Just to note: I agree misusing gestures is absolutely a great reason to reject applications. This doesn't read like misuse to me.
Based on what? Does the SDK say that?
Can't people read? These guys did NOT use a private API.
But that's the issue - is there a rule that forbids doing this? Has apple actually TOLD devs they can't do this? Or is it just apple making up the rules as they go along without spelling them out?
And WHY would that not be allowed? Is it forbidden by the SDK? If it's not I don't see any reason to expect devs not to do it.
I can't tell you if this particular thing was spelled out or not. But, it doesn't matter. If Apple changes the rules in the middle of the game, they have the right to do that (and I'm not talking things that might be considered legal issues). It may not be smart. It may not be good for business, but it is their right. If doing this frustrates developers, and they stop developing for the platform, then Apple will have to deal with the consequences of their actions (losing business, sales, etc.).
Why would that not be allowed? Because Apple created that action and has the right to allow it or not. People get up in arms "you can't patent a gesture" - they are really patenting what the gesture does as input for the computer. No, you can't patent pinching your fingers together, but why can't you patent pinching your fingers together on a touch screen to make a photo gallery expand in a certain way? That is what separates one product from another - the user experience.
I made my point fine, you just felt the need to reiterate it for some bizarre reason. You said;
So according to you, every application that uses a custom view to replicate a default one should be rejected - and there are a lot of people doing this to speed up their apps. Every application that coded their own gestures to replicate built in ones for specific purposes should be rejected. Custom controls duplicate functionality of native ones. And so on. Your argument is asinine and a pretty blatant 'Apple can do no wrong'.
Oh gee "get a life" card. Quite amusing from someone who's post history reads like a sycophant.
Edit:
If a user becomes used to, as an example, this pinch-to-expand gesture from Photos and sees a similar application, and then tries to use it the same way unsuccessfully - because the gesture is 'reserved' - who is at error? Just to note: I agree misusing gestures is absolutely a great reason to reject applications. This doesn't read like misuse to me.
Not capable of a civil debate, are you? Where exactly am I trying to please anyone in my posts - I simply speak what I have to say - and, unlike you, I can usually do it in a civil way (that can change).
The point is they are duplicating it exactly. Same gesture, creating the same action, for the same result. All they probably had to do was change the animation of the gallery to look different, so it wasn't a direct duplicate of Apple's software feature. I never said Apple can do no wrong, funny how you only saw Apple in their when other companies were mentioned. It may not be good for business, but Apple has the right to do what they want, as does every other company. That is the point you are missing, jackass.
By the way, exactly how does a sycophant read?
What if, in 1984, Apple told developers "You cannot duplicate any functionality, including UI, that's already present in MacPaint, MacWrite, and Finder".
WTF?? The Mac never would've gotten off the ground.
Anyway I don't think we're getting the full story here; Apple should be thrilled that a developer would want to implement pitch-zooming.
By the way, exactly how does a sycophant read?
* apple polishing
* arse kissing
* ass licking
* bootlicker
* brown nosing
* crawler
* fawning
* flunky
* groveling
* hanger-on
* kowtowing
* lackey
* lickspittle
* sucking up
* toady
* yes man
http://en.wikipedia.org/wiki/Sycophancy
* apple polishing
* arse kissing
* ass licking
* bootlicker
* brown nosing
* crawler
* fawning
* flunky
* groveling
* hanger-on
* kowtowing
* lackey
* lickspittle
* sucking up
* toady
* yes man
http://en.wikipedia.org/wiki/Sycophancy
Thanks, Josh.
Funny, you always cry when someone doesn't talk nice to you. But sure are quick to come to the aid of jackasses who are incapable of a civil discussion.
If a user becomes used to, as an example, this pinch-to-expand gesture from Photos and sees a similar application, and then tries to use it the same way unsuccessfully - because the gesture is 'reserved' - who is at error? Just to note: I agree misusing gestures is absolutely a great reason to reject applications. This doesn't read like misuse to me.
I don't think that the gesture itself is misused because it is the exact same functionality that Apple employs in the Photo App. It is more the implementation that was misused in their App. The API for interpreting raw touch events is already exposed and these guys didn't use it. It is sort of a case of undermining the API provided and finding a way to work around the methods approved by Apple.
There will likely be a public API for this functionality coming soon.
Exactly. The pinch to expand gesture is a private API, and not yet available for public use. Writing a code to circumvent the Apple's private API is prohibited.
Care to explain how writing custom code, that provides functionality missing from the published API is 'circumventing' their API? If the API doesn't do it, you really are left to do it yourself. Sort of the point of programming, no? If Apple hasn't made their API for this available, they will have their reasons. Perhaps it isn't ready, perhaps it will be in iPhone OS4. As far as it being private, then to a developer, it is though it doesn't exist. This then means rolling your own. That simple. This isn't circumventing anything. Not publishing an API is not the same as forbidding the function. Using the API itself if forbidden, but it is a leap to assume that means the functionality is...until now.
Macworld just posted a great article that might help explain the issue. Not that most here will read and understand it.
Unfortunately, for those of us that do understand it, we are left wondering why you state that it might explain the issue. The issue is writing custom code so as to specifically avoid using Apple's unpublished API. The article does a great job explaining why APIs might not be published and why devs shouldn't use them. Nothing at all to do with explaining if an API being private means never being able to implement custom code. Two very, very different things.
Care to explain how writing custom code, that provides functionality missing from the published API is 'circumventing' their API? If the API doesn't do it, you really are left to do it yourself. Sort of the point of programming, no? If Apple hasn't made their API for this available, they will have their reasons. Perhaps it isn't ready, perhaps it will be in iPhone OS4. As far as it being private, then to a developer, it is though it doesn't exist. This then means rolling your own. That simple. This isn't circumventing anything. Not publishing an API is not the same as forbidding the function. Using the API itself if forbidden, but it is a leap to assume that means the functionality is...until now.
Certain gestures are defined. Apple probably doesn't want defined touch events to be accessed any other way than through the API. So these guys are circumventing the pinch gesture by circumventing the touch API and gaining access to the raw touch events rather than calling functions in the UI library
Why would that not be allowed? Because Apple created that action and has the right to allow it or not. People get up in arms "you can't patent a gesture" - they are really patenting what the gesture does as input for the computer. No, you can't patent pinching your fingers together, but why can't you patent pinching your fingers together on a touch screen to make a photo gallery expand in a certain way? That is what separates one product from another - the user experience.
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.