The last two days of work have been pushed this thing for a good while, fortunately after the "tireless" efforts to understand the principles. Most apps currently use a third-party integration, with official code, so it's very simple to write. Here are some of the things that are unavoidable, and some of the problems that may not be mentioned in the official documentation.
First people to understand the use of 2 certificates, One is an open certificate, and the other is a production certificate . In general, the use of third-party integrated push libraries will require uploading these 2 certificates that have been converted to . Pem format . The former is used in the test phase, in the test push on the real machine, remember to choose the development mode, and remember the current cell phone registration token value copied to the test machine's token value bar , or push is not acceptable, although the web can see has been pushed to APNs on the , but APNs can't find the token value on your current phone, so it can't be matched. This is a point worth noting. Then in turn, the latter is used in production environment, that is, the app is on the shelves to download to the mobile phone, this time the default use of the production certificate, this time to choose the production environment push, the test version is unable to receive the push, only the official version will be received.
General push and return will be given an alias for you to set, then you can be based on this alias for a single account push. Note that if the user is not logged in, try not to set the alias in advance .
The above 2 points are my formal and testing some of the problems encountered, although not a big deal, but still delayed me a lot of time, in this record, so as not to be repeated later.
This article is from the "11562149" blog, please be sure to keep this source http://11572149.blog.51cto.com/11562149/1782879
The mistakes in the IOS push notifications that you deliberately make