There already is apn_on_rails which I've used with success. It would be interesting to learn why this gem was written instead of using that one, it's been around for ages.
- We wanted something simpler: apn_on_rails is more of a "complete" solution than what we needed, including models for keeping track of devices that are registered with the app, etc. We already had infrastructure for handling all that, but just needed a bit of code to connect to Apple and do the notifications and read feedback.
- We needed to keep connections open. We send constant streams of hundreds-of-thousands of notifications per day. With this in mind it makes sense to keep persistent connections open to the service and stream data in.
- Both apn_on_rails and the original APNs gem have broken support for reading from the feedback service. We had to support this fully.
