About Me!
This blog is about my musings and thoughts. I hope you find it useful, at most, and entertaining, at least.
Other Pages
Presence Elsewhere
APNS Woes
Date: 2014-06-29
Tags: programming software apns apple ios
I’ve recently been working on interfacing with APNS and have found it to be a terribly desinged API. It doesn’t feel like what I expect from an Apple product.
APNS a completely binary protocol, meaning that you can’t use any of the nice, well tested, battle hardened HTTP libraries out there (like you can with GCM). Being a binary protocol in-and-of-itself isn’t that bad of a thing, but it does feel awkward for the decision to be made to transport JSON via a binary protocol in 2009.
The worst part is that it’s not synchronous. You’re expected to throw packets at the service until the service kills the connection, possibly sending you an error packet before it does so. For the feedback services, you’re expected to just listen if there’s anything and disconnect. I don’t believe it would have been that difficult to, and would have the usage process much, much nicer, if the protocol would respond consitently. For instance, if I say I’m going to send 10 packets, it could wait until it’s recieved those 10 packets to send an “All Good!” or “Error: xxxx” packet. Or when connecting to get feedback, tell me that there is no feedback.
The whole system seems to be designed to be as “efficient” in terms of bandwidth as possible, but then duplications tons of fields, e.g. when setting the Device Token in a Notification packet, you need to add a Device token section that has a header and the token length, both of which are rednundant because the token is always required and always the same length. Also, being bandwidth eficent to save possibly 100s of bytes, at the expense of a crappy development experince seems very un-Apple. As much as I dislike IDEs, XCode is much much nicer of an experince to work with then Visual Studio was and the Apple Docs often feel much better than MS’s docs.
The efficiency may be warranted on the phone’s end, but a simple HTTP endpoint for sending notifications and getting feedback would have made the development process at my organization much more streamlined and quick.
APNS just feels like a quick project done by someone using vastly underpowered hardware and kind-of became a bigger thing, but that was never cleaned up. Part of me feels that it’s designed so that people refrain from using it; it feels that awkward, especially when you’re not use to dealing with raw sockets day-to-day.