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.
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.
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.
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.
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.
Sorry.
You're the one who asked, and I didn't really know the answer, so I looked it up.
I didn't really mean to come to his aid, but instead, I just meant to answer your question.
Some might advance the opinion that they have become far worse.
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.
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
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.
Just like before, the APIs are probably not ready for primetime, once Apple feels that the APIs are good and ready I'm sure they'll release them.
They may release them in 4.0, I don't believe Apple will keep them "private" for too long.
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!
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.
Quote:
Originally Posted by Quadra 610
Who's to say SJ is leaving anytime soon?
And who cares if Apple rejected this? Apple has rejected apps before. Life goes on, and Apple certainly goes on, and keeps getting better.
Is it going to be news each time a developer gets their app rejected, when we have over 100,000 apps on the App Store??
Why are YOU so insulted? Did Apple reject YOUR app? Why should you care? This has no real effect on you, the consumer. If anything, the consumer keeps benefiting from Apple's products. We keep getting great stuff almost yearly.
The reality is that developers are *staying* with Apple, and so are consumers. These piddly rejections here and there amount to next to nothing in the grand scheme of things. Developers know that the best platform to develop for bar none continue to be Apple's i-devices. As a developer, if your app is rejected, then fix the damned thing and find another way for it to be competitive before someone else steps in and does what you were't capable of. Apple's ecosystem is a developer's gold mine and there is simply no room for whining.
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
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'.
The article is completely ambiguous on this point. Obviously, they used some APIs, otherwise they are writing directly to the hardware, which is unlikely to say the least. The question is, exactly which APIs did they use? They seem to have not really answered this question, or the reporting just isn't clear.
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.
Quote:
Originally Posted by mstone
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
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.
Quote:
Originally Posted by Tulkas
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.
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.
And who cares if Apple rejected this? Apple has rejected apps before. Life goes on, and Apple certainly goes on, and keeps getting better.
Is it going to be news each time a developer gets their app rejected, when we have over 100,000 apps on the App Store??
Why are YOU so insulted? Did Apple reject YOUR app? Why should you care? This has no real effect on you, the consumer. If anything, the consumer keeps benefiting from Apple's products. We keep getting great stuff almost yearly.
The reality is that developers are *staying* with Apple, and so are consumers. These piddly rejections here and there amount to next to nothing in the grand scheme of things. Developers know that the best platform to develop for bar none continue to be Apple's i-devices. As a developer, if your app is rejected, then fix the damned thing and find another way for it to be competitive before someone else steps in and does what you were't capable of. Apple's ecosystem is a developer's gold mine and there is simply no room for whining.
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?
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.
In the first case, the issue has nothing to do with "pinch to zoom" which isn't actually patentable. They are talking about the new gesture Apple introduced with the iPhoto app on the iPad.
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.
Quote:
Secondly, what the heck are the "prongs" of which you speak? I can find no reference to them anywhere online.
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 before?what 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:
Instead of people saying "this is/isn't allowed by the SDK, why not actually state what you're talking about?
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.
What part of the SDK supposedly forbids this? For those arguing it should be okay, maybe post the part of the SDK that makes you think this is true? All this he said/she said is a useless waste of time without some facts.
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.
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.
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?
Comments
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.
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.
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.
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.
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?
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.
Sorry.
You're the one who asked, and I didn't really know the answer, so I looked it up.
I didn't really mean to come to his aid, but instead, I just meant to answer your question.
Some might advance the opinion that they have become far worse.
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.
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
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.
Just like before, the APIs are probably not ready for primetime, once Apple feels that the APIs are good and ready I'm sure they'll release them.
They may release them in 4.0, I don't believe Apple will keep them "private" for too long.
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
Who's to say SJ is leaving anytime soon?
And who cares if Apple rejected this? Apple has rejected apps before. Life goes on, and Apple certainly goes on, and keeps getting better.
Is it going to be news each time a developer gets their app rejected, when we have over 100,000 apps on the App Store??
Why are YOU so insulted? Did Apple reject YOUR app? Why should you care? This has no real effect on you, the consumer. If anything, the consumer keeps benefiting from Apple's products. We keep getting great stuff almost yearly.
The reality is that developers are *staying* with Apple, and so are consumers. These piddly rejections here and there amount to next to nothing in the grand scheme of things. Developers know that the best platform to develop for bar none continue to be Apple's i-devices. As a developer, if your app is rejected, then fix the damned thing and find another way for it to be competitive before someone else steps in and does what you were't capable of. Apple's ecosystem is a developer's gold mine and there is simply no room for whining.
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
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'.
The article is completely ambiguous on this point. Obviously, they used some APIs, otherwise they are writing directly to the hardware, which is unlikely to say the least. The question is, exactly which APIs did they use? They seem to have not really answered this question, or the reporting just isn't clear.
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.
Some of the excuses people come up with are quite funny.
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
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.
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.
Who's to say SJ is leaving anytime soon?
And who cares if Apple rejected this? Apple has rejected apps before. Life goes on, and Apple certainly goes on, and keeps getting better.
Is it going to be news each time a developer gets their app rejected, when we have over 100,000 apps on the App Store??
Why are YOU so insulted? Did Apple reject YOUR app? Why should you care? This has no real effect on you, the consumer. If anything, the consumer keeps benefiting from Apple's products. We keep getting great stuff almost yearly.
The reality is that developers are *staying* with Apple, and so are consumers. These piddly rejections here and there amount to next to nothing in the grand scheme of things. Developers know that the best platform to develop for bar none continue to be Apple's i-devices. As a developer, if your app is rejected, then fix the damned thing and find another way for it to be competitive before someone else steps in and does what you were't capable of. Apple's ecosystem is a developer's gold mine and there is simply no room for whining.
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?
"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.
You sound like another banned alias. Clueless arrogance like that doesn't develop with only 9 posts.
Just like before, the APIs are probably not ready for primetime, once Apple feels that the APIs are good and ready I'm sure they'll release them.
They may release them in 4.0, I don't believe Apple will keep them "private" for too long.
we are stll waiting for Cover Flow!
What are you even talking (trolling) about here?
In the first case, the issue has nothing to do with "pinch to zoom" which isn't actually patentable. They are talking about the new gesture Apple introduced with the iPhoto app on the iPad.
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.
Secondly, what the heck are the "prongs" of which you speak? I can find no reference to them anywhere online.
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 before?what 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/
Instead of people saying "this is/isn't allowed by the SDK, why not actually state what you're talking about?
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
What part of the SDK supposedly forbids this? For those arguing it should be okay, maybe post the part of the SDK that makes you think this is true? All this he said/she said is a useless waste of time without some facts.
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.
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.
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 wonder if this time's rejection has anything to do with the devs using Picasa... Paranoid much?