3 ms·

https://developer.apple.com/appstore/resources/approval/guidelines.html https://developer.apple.com/appstore/resources/approval/guid... You need to be an iOS D

https://developer.apple.com/appstore/resources/approval/guidelines.html https://developer.apple.com/appstore/resources/approval/guid... You need to be an iOS Developer to login. Unclear if it's under NDA or not, but I'm sure this document will leak out eventually. There are 22 categories of potential violations, and most rules end in "will be rejected."

ben1040 16y ago
You know, while Apple's rejections seemed to be arbitrary at times, I was surprised that my reaction to reading this was that the vast majority of these rules are pretty sensible. A lot of them come down to "your app must not crash or be full of bugs, it must do what it says it does, and it cannot be malicious." For all the hoopla, I expected this list would read like a crazy list of charges handed down by a kangaroo court. The thing on here which I really strongly disagree with is the ban on making apps that replicate functionality shipped with the phone. If users want an alternate mail client that supports IMAP IDLE for example, it should be up to the user to download that.
- loire280 16y ago
  I expect the idea behind that is for the user experience. A non-Apple mail client, for example, won't have the level of integration into the system (send mail from apps/camera/etc., notifications, background process that never quits) that Apple's will, and they seem unwilling to expose that level of functionality to developers. There's plenty of things wrong with that kind of thinking, but it's consistent with Apple's philosophy about core functionality. It's also beneficial for things like the browser and email client to be consistent, so that services targeting iPhone have an easy testing platform. As a web developer I like knowing that every iPhone is using Safari and renders HTML email using the mail app. I already have enough platforms (4 versions of IE, Firefox, Safari, Chrome, Opera, iPhone, Android, Blackberry, WinMo) without the mobile platforms becoming fragmented.

ben1040 16y ago

You know, while Apple's rejections seemed to be arbitrary at times, I was surprised that my reaction to reading this was that the vast majority of these rules are pretty sensible. A lot of them come down to "your app must not crash or be full of bugs, it must do what it says it does, and it cannot be malicious." For all the hoopla, I expected this list would read like a crazy list of charges handed down by a kangaroo court. The thing on here which I really strongly disagree with is the ban on making apps that replicate functionality shipped with the phone. If users want an alternate mail client that supports IMAP IDLE for example, it should be up to the user to download that.

loire280 16y ago
I expect the idea behind that is for the user experience. A non-Apple mail client, for example, won't have the level of integration into the system (send mail from apps/camera/etc., notifications, background process that never quits) that Apple's will, and they seem unwilling to expose that level of functionality to developers. There's plenty of things wrong with that kind of thinking, but it's consistent with Apple's philosophy about core functionality. It's also beneficial for things like the browser and email client to be consistent, so that services targeting iPhone have an easy testing platform. As a web developer I like knowing that every iPhone is using Safari and renders HTML email using the mail app. I already have enough platforms (4 versions of IE, Firefox, Safari, Chrome, Opera, iPhone, Android, Blackberry, WinMo) without the mobile platforms becoming fragmented.