Abusing The Public API
It has been too long since I've posted to my blog, but things have gone extraordinarily well with Webmail++. It has kept me plenty busy, but more than that, it has taught me so much about iOS development. I'm prepping some major updates to the app, but the original implementation has given me a real eye opener into Apple and their relationship with developers.
I've had my fair share of app rejections, all because I've tapped into their so-called private APIs. These are API that, by rule, are disallowed for third party developers like myself to use. Apple disallows the use of these APIs under the pretense that they are 'under development', could change at any time without notification to developers that use them, and cause a bad user experience. Fair enough, but there are some APIs that they just do not want you to use, period, and have no intention of making public.
One of these is the private API for allowing users to accept invalid certificates for websites. There is a very good reason for Apple to disallow developers to programmatically accept invalid certificates: a malicious developer could redirect users to fake websites and users would be completely unaware. The flip side to this issue is that there are legitimate sites out there who don't keep up on their certificates (or are just flat out lazy to get a valid one for their site) and are blocked from using a third party application to visit them.
Another 'private' API involves progress information when loading a web page. This, too, is hidden from the developer, even though Apple clearly has the information tucked away inside a WebView
. So instead of leveraging what exists there, I have to 'abuse' the public API to be able to tease out the information needed to show progress to a user. Almost all apps I have seen just show a spinner to indicate to the user that the page is loading, but it would be really nice to be able to show that information back to the user, especially in cases where the internet connection might be abnormally slow. Abusing the public API involves the creation of a couple of different public objects, as well as complicated code, to accomplish the same, when Apple could just add a method to the delegate to cleanly give us that information. This adds additional resource overhead to the app, as well as adding unnecessary complexity to maintaining the code.
I'm sorry, but private APIs just suck. I'm glad Apple is looking out for good user experience, but I'm OK with the added risk of things breaking in the future if I can add a better user experience for my users now.