[lleger]

The point wasn't that those apps _don't_ have this functionality builtin, but rather that it's not an available API to developers. Marco had to implement a workaround in order to offer the brightness slider in Instapaper. It works, but it's not native functionality.

But those were just examples of a macro issue, so I really wouldn't focus on that too much.

[atom_robot]

I understand what you're saying. I read your reply after I had already posted. But Honestly iBooks is doing it wrong anyway.. It seems like it was put in as a hack, because it changes the systems brightness permanently whereas instapaper and kindle seem to be based on a percentage of the current system brightness. Which would make sense if it's a layer that they're changing the transparency of. I don't, however, think this is malicious in its intent, though it is a bit unfair. Same with the lock screen stuff. It is probably safe to say that this is something Apple will open to developers eventually... after they're done playing.

Apple should just flag apps that use private API's and call them out for it when the user upgrades the OS in an alert dialogue-like fashion when they launch the app (or on the applications iTunes page). "This app is using private API's and may not function properly with your current firmware." Instead of rejection. But it's probably easier to reject than to publish a "purchase at your own risk" disclaimer. All that's going to do is get a lot of people to not purchase your application.

The AppStore acceptance and rejection policys, though, should get fully investigated. I would like to get into iOS development, but trusting my livelihood on such a seemingly fickle process makes me really nervous.