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.
The Weather Channel app seems to be able to do pinch to expand (although it does not work exactly as you would expect). I wonder how they did that...
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.
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.
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.
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.
Quote:
Originally Posted by PaulMJohnson
Wasn't this one of the things Microsoft were getting in trouble for (the idea that there were hidden API's that things like Microsoft Office could use, but others couldn't). I might be wrong, but I thought that was part of the anti-trust ruling?
If I'm right, why are Apple allowed to get away with 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.
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.
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.
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.
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.
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 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.
On the bright side, I now know what the word sycophant means
On the bright side, I now know what the word sycophant means
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".
Comments
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.
The Weather Channel app seems to be able to do pinch to expand (although it does not work exactly as you would expect). I wonder how they did that...
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.
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.
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.
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.
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.
Wasn't this one of the things Microsoft were getting in trouble for (the idea that there were hidden API's that things like Microsoft Office could use, but others couldn't). I might be wrong, but I thought that was part of the anti-trust ruling?
If I'm right, why are Apple allowed to get away with 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.
Well said.
Btw, you think the text entry here is bad on the iPad, try doing it on the iPhone.
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.
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.
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.
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.
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.
Based on the above three pieces of information...how exactly is this either right, or defensible?
The only cogent defense I have heard so far is that Apple can reject any app for any reason, and the developers knew that going in.
Right? Defensible? Dunno.
But that is the deal, and some think it is OK.
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.
On the bright side, I now know what the word sycophant means
On the bright side, I now know what the word sycophant means
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!
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".