I was talking to a friend of mine when I mentioned a third-party developer’s custom UI toolkit. When I mentioned it, my friend said matter-of-factly, “I’ve heard it uses private API.” Instantly (as often happens), a little scene played out in my head in response.
“I heard she uses private API,” Mabel said, divulging her unfortunate news to her concerned company. Her devious grin belied her worried brow.
“Mabel, please!” Ethel mock-scolded, returning Mabel’s grin.
“What’s that word?” Mabel asked. “The word the kids use? Skank, I believe it is. Gertrude is a skank.”
“Mmm,” Ethel agreed. “Skank.”
“Skank,” the entire gaggle echoed, snickering.
That’s when Gertrude walked in for her two o’clock perm and frost. She knew exactly what they were talking about. But she didn’t care. The private API was good to her …
Yes, I’m proud of this little gem. Come on, you know you chuckled.
From a technical standpoint, my friend is absolutely correct. Shipping an app that relies on private API is a calculated risk at best and a disaster waiting to happen at worst.
I’m not suggesting my friend and I were Mabel, Ethel, or the other … well … gossipy bitches. It was just a dramatic scene that popped into my head and amused me. Deeply. It’s the perception that I’m examining.
The gossipers’ disapproval isn’t unjustified, though. For Gertrude to go galavanting around with private API? Honestly! And at her age! Why can’t she find herself some nice, stable public API and settle down like the mature woman she is?
Fear is good, though. We’d do well to pay attention to it. Private API is private for a reason. It’s not been designed to be used and manipulated by others. Because of this, it’s free to be changed around without fear of losing backward compatibility. Just because something is “unlikely to change any time soon” doesn’t mean it never will, nor does it mean it might not change tomorrow. That’s its nature. That’s why it’s private API.
In defense of the use of private API, it’s not all bad. There are some parts (like NSButtonCell) that haven’t changed for a long time. This is good because the basic design of the Cocoa API is out there in open source form. If you want an example, search for NSButtonCell.m.
In terms of basic UI (like a button), with a generous sprinkle of guard code that falls back on system-defined behavior and looks, it’s unlikely that something Apple changes in the future will render the app useless or cause a crash. The most you’re likely to suffer is an uglied-up UI.
This goes for plenty of other examples in the API. With enough experience (and history) with the platform as a whole, as well as well-guarded code, you’re well-enough-armed to make judgement calls and bend things Apple says you shouldn’t bend.
Let’s give Gertrude some credit, shall we? She’s not a complete idiot. She’s well aware of the implications of the company she keeps. If she wants to stand by her private API, that’s her business as long as she’s aware of its history and keeps firm control of the situation. Basically, if she knows what’s up and isn’t deterred, who are we to judge?
Hi. I’m Josh. I’ve abused private API. It’s been a few years since my last lapse, but I fear may do it again …