We have implemented several push servers and all of them following the old tuple "socket-certificate".In Java (1.5 - 1.7).
To work with certificates has some disadvantages. For instance, we need one for each environment (test, pro, etc). You have to be methodic at managing them or it's quite easy to end up with the wrong cert in pro. Or to forget its renewal (they also expire).
Related to the socket, this approach requires having opened a specific range of ports in the firewall.
Related to the whole protocol of communication. You get so little info after pushing messages. It's hard to figure out what happened with the messages. The only way is to retrieve messages from the queue of responses. A queue which orders is not guaranteed. Neither when APNS is going to put the responses onto it. It might not happen at all.
Compared to GCM (Google cloud message which runs via HTTP), the "socket-cert" of APNS is a pain in the ...
My suggestion is to get focus on the HTTP 2 - JWT protocol. This is a very common implementation of security in client-server communications. You will find many more references about http2 and JWT than looking for APNS sockets and Certs.
Security via JWT is commonly implemented these days. There is full support from the community.
Moreover, If they have planned to drop the support to the current implementation, why even to dare to try it? Why spend time and money twice?
Be preventive. Implementing HTTP2 - JWT approach will save you from further code reviews and refactors. In any case, it's a work to do, so better have it done sooner than later.
Related to the library CleverTap. Well nobody is stopping you from implementing your own client! Suited to your need and requirements.
This has been our case with our current engine. We discarded all the 3rd party implementations and built our own. So far I know it keeps working perfectly... Till Apple drops the service.
(If we didn't move yet to HTTP2 - JWT is due to time and money)
There's perhaps alternatives. Google Firebase Cloud Message is multi-platform. So you can push messages to Android and iOs devices from the same service. It works over HTTP and API keys (tokens). I suggest to you to take a look.
Best Answer
Polling is always acceptable when real-time isn't a necessity. What you have to ask yourself is why would you use one instead of the other?
The purpose of a push service is a couple things; it can be considerably less traffic for you to deal with if your pushes are broadcasts and a 3rd party provider does the broadcast - this allows you to send one message and have thousands receive it. But as you note, the biggest boon of a push service is the realtime nature that allows for immediate updates to reach your consumers. However when doing pushes you really don't ever want to be pushing large data sets if you're broadcasting, and you're also at the mercy of the third party push service you utilize (if you utilize one).
The purpose of a poll is to check for data differences periodically, where the update period can have an acceptable SLA of inaccuracy up to a certain time period. A poll will require all your clients to request the data periodically which will mean a connection being requested for every running client, and the necessity of a live service able to monitor that data accurately to serve it up to the pollers. Having accurate data to serve up means some data persistence which will take up disk and maintenance time.
So from this we can see that if you have concerns about network traffic or the maintenance of a service (which means possibly authenticating/authorizing requests, logging them which takes up disk space, all the normal requirements of maintaining a service) then you don't want to force clients to poll. However if the use case requires transmitting a particularly large data set or you can't be tethered to a third party's API which may change in time as well as their SLA or charges, then a home grown polling system may be applicable, though the maintenance overhead may be significantly more. Alternatively you may already be running service and have the data persisted such that the polling is a light addition to already in-place infrastructure, which makes polling more desirable.
Though to the central point you make you are correct; if real-time is necessary, polling will not do. If it is not, then you just have to do the math on how periodic the data can be checked multiplied by your client base multiplied by your data set size to decide if the network cost is going to be worth it, or if a push service would be better where you can always just push a change event that let's them request the large data set in a secondary step (though atomicity of these steps may be something you need to be careful of depending on the criticality of the data).