Five rational arguments against Apple's 3.3.1 policy
37signals.com
Five rational arguments against Apple's 3.3.1 policy
1–10 of 93 posts
Re: Five rational arguments against Apple's 3.3.1 policy
#2All are good points, but number 2 is the big one for me. That was my first thought when I heard what Apple was doing, and I think it's important to keep that in consideration. While I don't always agree with DHH, he makes some good, rational points here. It should be noted that most of these arguments have been made elsewhere, but it's a great summation.
Re: Five rational arguments against Apple's 3.3.1 policy
#3It seems to me that part of number 3 (about private APIs) is bogus -- it's pretty easy to compare an executable against private API addresses to make sure it isn't linked to any of them. They likely have a tool and it likely results in an instant fail and I doubt there are any approved apps that use private APIs.
Re: Five rational arguments against Apple's 3.3.1 policy
#4The problem is Apple has no real competition. They can do almost anything they want without fear of retribution because your average consumer has no idea what any of this means.
That's bad news for all us pissed off developers since Apple's new platform will continue to be extremely popular in which case devs are forced to develop for it.
Google seems to be inching towards being a real threat but they also seem extremely unfocused. Does anyone really need a toaster running the latest version of Android?
Apple needs some competition in this space and Android-based mobile devices seem like a really distant second. It's time for Google to kick it up a notch.
Re: Five rational arguments against Apple's 3.3.1 policy
#5The web is not a carefully curated gallery of web pages and yet we're still able to find the good stuff all the time thanks to intermediaries of discovery
This is hardly a strong argument, as the main "intermediary of discovery" is Google, and most internet users are all too ready to give up their banking information to websites which have an official looking header on the page. Just because it worked for the web doesn't mean it'll work for Apple's AppStore.
Re: Five rational arguments against Apple's 3.3.1 policy
#6It seems to me that part of number 3 (about private APIs) is bogus -- it's pretty easy to compare an executable against private API addresses to make sure it isn't linked to any of them. They likely have a tool and it likely results in an instant fail and I doubt there are any approved apps that use private APIs.
I think you mean #3.
Re: Five rational arguments against Apple's 3.3.1 policy
#7The web is not a carefully curated gallery of web pages and yet we're still able to find the good stuff all the time thanks to intermediaries of discovery This is hardly a strong argument, as the main "intermediary of discovery" is Google, and most internet users are all too ready to give up their banking information to websites which have an official looking header on the page. Just because it worked for the web doe…
So you'd like for the web to be put back in the box and replaced with an AOL Walled Garden of wonder? Freedom can indeed be dangerous, but I'd rather be free to hurt myself than smothered to dead by paternalism.
Re: Five rational arguments against Apple's 3.3.1 policy
#8I hope #5 turns out to be bigger than I think it will be, but people end up sticking with what is popular (iPhone) even when it hurts to do so.
Re: Five rational arguments against Apple's 3.3.1 policy
#9It seems to me that part of number 3 (about private APIs) is bogus -- it's pretty easy to compare an executable against private API addresses to make sure it isn't linked to any of them. They likely have a tool and it likely results in an instant fail and I doubt there are any approved apps that use private APIs.
I think you mean #3.
Curse that 2 key, always next to the 3.
Re: Five rational arguments against Apple's 3.3.1 policy
#10It seems to me that part of number 3 (about private APIs) is bogus -- it's pretty easy to compare an executable against private API addresses to make sure it isn't linked to any of them. They likely have a tool and it likely results in an instant fail and I doubt there are any approved apps that use private APIs.
this is not completely true.. when google first released their search application, they were allowed to use an undocumented api (at the time), that detected when you moved your phone from your ear, and was allowed. Not sure if this is the same as a private api, but in general they do reject the use of private api's.