I also get why you shouldn't use private APIs, but when there's a bug this big with no workaround (other than to code everything yourself, apparently) then I think it's a big mistake to reject apps over it... Unless you can promise a bugfix with a timeline.
on the other hand, what if every application using that private API call was broken by a new firmware update that fixed the bug they were trying to work around? then the users suffer and that's the whole point of rejecting applications in the first place.
Agreed. When you make an exception for developers to rely on a private method, you "promote" an implementation detail to its public interface. Now you can never remove the method, change its signature, or change its behavior. Nevermind that when the bug in the public method is fixed, you now have two methods to accomplish the same task. You've introduced cruft, or legacy code you need to maintain. Ick.
Firmware updates break/change public APIs too so that excuse doesn't work for me. Even more fun is when public APIs silently change so scanning the change log becomes useless.
Modal Form sheets are by definition supposed to keep the keyboard displayed even when there's no first responder, so I don't understand why the author thinks that's a bug. That behavior certainly is not going to change.
99% of the time when I suspect there is a bug in an underlying library, it turns out the problem is me not really understanding how that library works.
