I know Bob Swart asked about this in the past (as have I).
_*Trying to get Apple Push Notifications up and running. However, there is a definite problem with the way UIApplicationDelegate is currently designed.*_
It seems that the *applicationDidReceiveRemoteNotification* delegate is commented out. And, the reason is pretty clear. *The signature for this delegate conflicts with applicationDidFinishLoadingWithOptions!!!!!*
I tried to change the signature of applicationDidReceiveRemoteNotification to take a pointer instead of an UIApplication parameter. But, when trying to recompile, this change affects FireMonkey for iOS.
There doesn't appear to be a build script to recompile Firemonkey (in the registered version....not trial) to rebuild FireMonkey propery so that the iOS side of things reflects the changes. If there is and I am missing it, please let me know.

Well, it would seem that there IS a way to facilitate APNS messaging through another mechanism. See Ander's Blog. There is a great video with source. Unfortunately, the video is in Spanish. Still...very cool.
  Having a new problem though. The solution requires a change to entitlements.plist associated with the build. Delphi keeps overwriting the changed file making the deployment cumbersome.
  Also, when debugging, it would be nice to be able to specify the app's development provisioning profile. Doesn't seem possible in Debug...only in AdHoc and Distribution. But, then, I guess I lose the ability to debug.
  Anybody else have an issue (and a solution), to the entitlements.plist being overwritten?
  (snip)

Hi,
  Take a look to http://www.tmssoftware.com/site/tmsfmxcloudpack.asp maybe it
  helps.
  Omar Zelaya
  

Not really interested in purchasing at this time.
    A demo was posted on Anders blog that I hoped would solve my dilemma.
    My XCode project works with my sender. However, the code that Anders referred us to has some issues.
    I can see that it is registering for APNS correctly and I receive an APNS device token.
    But, it is not detecting my APNS message.

Charles Stack wrote:
      (snip)

I've attempted to watch the video, i.e:
      http://www.youtube.com/watch?v=nYdyhVz-NY4
      However it's way too "fuzzy" to tell what's going on. I'm especially
      interested in what is happening at 3:27 - 3:51. I have no idea how to

Charles Stack wrote:
      (snip)
If it's not calling didReceiveRemoteNotification at all, it is likely
      that the APNS is rejecting the message. Do you check for a response in
      your server?
      --

(snip)

My Objective-C app written using XCode is receiving and displaying my APNS messages just fine. And, yes, my server checks the responses from the APNS server and also retrieves data from the feedback server. That is a proven commodity.
        So, my guess is that the problem is with how Delphi is or isn't using the provisioning profile in Debug mode. Given that there doesn't seem to be a clear cut method to associate a provisioning profile in Debug mode, I am not sure the iOS app is even trying to use my profile.
        In fact, in Debug mode, it seems that Delphi is using some sort of default provisioning profile. This is why, I suspect, that the demo apps work. But, you can't deploy those apps in either Ad-hoc or to the store without a real provisioning file (which you MUST specifiy along with the iPhone Distribution certificate). The Debug and Simulator seem to get by with just the iPhone Developer certificate.
        When I get home tonight, I will try this process again but with an ad-hoc profile and sign with my iPhone Distribution cert and test my theory.
        The solution Louis presented is more of a hack than a real solution as it requires changes to the FMX_Platform_IOS.pas file to work. The place it SHOULD reside is in the ApplicationDelegate interface in iOSAPI.uiKit.pas. If we could specify the provisioning profile, I bet the entitlements would work and this solution would work well enough until a permanent solution is offered.

Charles Stack wrote:
          (snip)

I'm wondering whether it matters where the procedures are that become
          delegated, however I agree that he shouldn't have needed to hack
          FMX.Platform.iOS.pas. Hopefully we'll see this corrected in an update.
          (snip)

Where would the provisioning profile be specified, exactly? I ask only

Charles Stack wrote:
      (snip)

Can you check in your Notifications settings on your iOS device that it
      registers for Banners, Badges and Sound? Mine just says Banners. I
      suspect the registerForRemoteNotificationTypes call isn't passing the
      right value, and I'm not sure how to rectify it.

(snip)

In the implementation of Louis' code for FMX.Platform.iOS.pas, look for the function applicationDidFinishLaunchingWithOptions().
        Inside that function, you will see the declaration of a variable called NTypes: NSUInteger; He is using it as a bit map and sets all three types when he executes:
        NTypes := (1 shl 0) or (1 shl 1) or (1 shl 2);
        The next call is to registerForRemoteNotificationTypes.
        BTW, I am cleaning up my APNS Sender code. My original app won't compile as is using DXE4 as it uses KControls. In particular, I was using KHexEdit to display the messages as both Hex and Text (it's REALLY good for that). If the author rewrites KControls (and KHexEdit) to work with DXE4, I will incorporate it back into my demo app.

Charles Stack wrote:
          (snip)

I did look at all that. Your reply didn't really answer my question,
          but given your answer I'm guessing that it does register for all 3 for
          you, so I'll be googling for possible reasons why it doesn't for me.
          --

Charles Stack wrote:
          (snip)

Incidentally, this article:
          https://www.pushlayer.com/blog/2013/03/12/ios-push-notifications-best-practices
          Suggests that registerForRemoteNotificationTypes should be called in
          applicationDidBecomeActive. Read the article as to the reasons why.

(snip)

Frankly...I don't where it is called from at the moment ( lol )....I just want the dang thing to work!!!!
            Still getting the error of no entitlements when using an ad-hoc profile as well.
            Have you fared any better?
            Here's a couple of questions....Delphi has it's own "default" provisioning profile, right? Where is it? I don't see it in XCode Organizer. And, if there is one, what entitlements does it have?
            

Charles Stack wrote:
              (snip)

It can make a difference as to how everything is handled. If
              registerForRemoteNotificationTypes is called from
              applicationDidFinishLaunchingWithOptions, it happens before the main
              form is created, whereas applicationDidBecomeActive is called after

Thing is, the APNS token hardly ever changes. I have the received the same token for over two years. It really does not need to be called each time the application is made active.
                applicationDidFinishLaunchingWithOptions is called when the app has been loaded into memory and ready to begin execution. You have a finite time period (I think 20 seconds) for the application to fully load - this is the primary reason to move it to another event. You can always check for reachability in applicationDidFinishLaunchingWithOptions. In fact, every article I have read that was written by experienced iOS developers implements the logic in the ...WithOptions. This is when and where I implemen
                t my APNS registration logic as well in Objective C.
                In fact, when does the Activate event get called? Is it every time you start or bring from the background? If so, it is overkill to register for remote notifications.
                What is important is that a failure to register for remote notifications should NOT prevent you application from working correctly in most cases. However, your application will be incapable of receiving events when terminated or in the tray. Whether this breaks your app or not is really dependent upon how important that is to your app's functionality.

Charles Stack wrote:
      (snip)

I'm having that issue, i.e. the iOS app is registering, however it is
      not detecting the APNS message.
      Admittedly, the iOS app does not register correctly; for some reason,
      it just shows "Badges" (ie no Sounds or Alerts) in the Notifications

Dave Nottage wrote:
        (snip)

Ignore that; I suspect I had certificate issues. I regenerated them and
        now my SSL test connect (from the command line) isn't working. It may
        not have been before, however I hadn't noticed the error (error 20).
        I need to go back over the certificate generation process.

David,
          I would be willing to send you my APNS sender code - I KNOW it works and you can examine the format of the messages. My sender will even generate for Newstand. There were some tricky parts in setting up the header of the APNS correctly with byte ordering and stuff that might be tripping you up. You just need to generate the PEM certs for your dev and production environment (I can give you instructions on that too).
          As for the client side - I STILL can't get it to work. There doesn't appear to be a way to specify our own provisioning profiles that incorporate the entitlements and we are stuck using the "default" version in Delphi which does not have the entitlements. Additionally, to send to a client using the Delphi defaults would imply that we have the ability the download SSL certs for that provisioning profile - which we do not.
          Ad-Hoc provisioning profiles seem to be limited to Distribution cert only (no longer Developer). I want to verify this again....as having an Ad-Hoc profile with the entitlements signed using the developer cert might make a difference.
          Or...can we somehow use a development cert and provisioning profile via the Ad-Hoc signing mechanism in delphi? So, far, that has not worked for me.

Charles Stack wrote:
            (snip)

That would be great, thanks. My address is davidnottage at gmail period
            com.
            --
            Dave Nottage [TeamB]

*I have push notifications working!!!!*
              Here is what I did to get it working...
              1. Download Luis Gonzalez's source code. I suggest you view the video (it is in Spanish, however).
              http://lfgonzalez.visiblogs.com/2013/05/delhi-xe4-ios-adicionando-soporte-a-notificaciones-remotas-video-y-codigo-fuente/
              2. Create your own application and incorporate the ApplePushNotification.pas and FMX.Platform.iOS.pas files as per the Luis' example.

Charles Stack wrote:
                (snip)
Fantastic!
                (snip)
I'm yet to review all the steps, however I believe I've done 1 thru 5 the right way.
                (snip)

That part is interesting. Does that avoid having to modify it every time you deploy?
                (snip)

Steps 9 thru 12 are even more interesting, as I haven't come across those before, and they don't appear to be in the

Yes...
                  Adding your entitlements file to deployment (and disabling the other) does prevent you having to make the change each time around. It works. Really.
                  The part about changing the CFBundleIdentifier and CFBundleName....Ander's confirmed he had to do the same (see his blog entry). You need to do this or you won't be able to receive any messages.
                  It wasn't mentioned in the video. But, then again, it was signed using the debug certs in Deploy mode. Unless you look carefully, you won't see this change. It was a precanned demo he was demonstrating - Luis may have simply forgotten to mention it (or, maybe said it in Spanish?).
                  With the approach I outlined, you can debug as well. Just make sure your entitlements.plist file doesn't have any CRLFs...LFs are okay...so as not to confuse the digital signing process.

Charles Stack wrote:
                    (snip)

I've just finished implementing the missing steps, and it works!! I'll take your word for it about the entitlements
                    file, but I guess I'll soon find out anyway :-)
                    (snip)

Indeed, that appears to be what was missing. It makes sense, though. One thing I still notice is that the notifications
                    settings still just says "Banners", i.e. no Alerts or Sounds. You can check this in the devices Settings, under

Charles Stack wrote:
    (snip)
D'Oh! I wish I had seen that when it was first published; would have
    saved me a few days work.
    --
    Dave Nottage [TeamB]

Did you get it to work?
      I am running into problems with the Entitlements.plist being overwritten every time I compile - thus losing the changes. And, it doesn't seem to want to work with my provisioning profile despite it working fine with my XCode version.
      (snip)

      
      

Charles Stack wrote:
        (snip)
I've only been working on server side at the moment, and I'm not quite
        ready for that as yet. One thing about that, though: on reading Luis'
        code, the data it is sending isn't quite of the same format as here:
        http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/CommunicatingWIthAPS.html#//apple_ref/doc/uid/TP40008194-CH101-SW1

I wrote:
          (snip)

As you may have guessed, I'm still going; too many irons in the fire
          (eg creating a cross-platform version of a fairly complex existing
          app), and I'm enhancing the server side to cater for associating
          deviceToken with login credentials.

Dave Nottage wrote:
            (snip)

So I've reached the point where I want to start building the client,
            and I'm looking at what Luis has done, however I'd like to be able to
            pull apart the payload (being returned in an NSDictionary) first.
            If there's some existing Delphi code for doing this it would save me a

I wrote:
              (snip)

On second thoughts, I may be able to nut this one out.
              --
              Dave Nottage [TeamB]
              

(snip)

I still can't get he client code to work - it doesn't see my entitlements for APNS. Yes, my provisioning profile is correct as my Xcode version works just fine. It may just be a matter if settings. Anders suggested that I remove the default entitlement file from the deploy and provide my own. That hasn't worked yet. I am suspecting it has to do with setting things up for debugging and specifying the provisioning files in Delphi for debugging. Why is this so difficult??? Am I the only one who wants
                to debug with my own provisioning file?????
                As for processing the response, Dave. See how he handlers are implemented to return the JSON in the message box as a string. Then use Delphi's JSON parser (or, 3rd party). The structure is very simplistic and no need to do it in Obj-c (unless your client is in obj-c). :-)
                
                

Charles Stack wrote:
                  (snip)

No, since I do, too. I'll let you know how I go when I am at that point.
                  (snip)

Ok.. I haven't looked at the video yet, so I didn't know the
                  description is the JSON string. It should be simple then, thanks.
                  --

Simple...I would think so. The trick is actually getting the client code to work so you CAN process the response!
                    On day 1, I managed to get the app to register with APNS. I compiled the code, modified the entitlements file and then deployed. It worked for a little while and then, abruptly stopped working. At no time, however, did the code respond to a message sent from my sender (which, as I mentioned, I KNOW works). The device token is the same one I have received from other app (which, is removed during this testing) so I know it WAS registering correctly.
                    What I find perplexing is that if we do an Ad-Hoc or Distribution build, we can specifiy the provisioning profile. Yet, while developing, a development provisioning profile may still be needed. *So, I question why the capability to specify a provisioning profile during debug wasn't provided in the current release?* Let's hope they fix that in the next update.
                    Regarding the need for Entitlements.plist (the name AFTER deployment)...I am getting the impression that this isn't needed at all - that XCode (and Delphi) generate the empty shell. This is a change in later versions of XCode. The entitlements are actually taken from the provisioning profile. *Can anybody confirm this?*
                    Tonight, I am going to try this again...using an Ad-Hoc provisioning profile vs a development profile and update my SSL certificates accordingly. Unfortunately, I would have to believe that this would preclude my being able to debug this code on the device.

Charles Stack wrote:
    (snip)

I'm at the point where I am having this (very annoying) issue. No
    solution other than to modify it again before "deploying".
    --
    Dave Nottage [TeamB]

Hello Charles,
  Thanks to you, Anders and Luis, I have an (almost) fully functional APNS-app now :-)
  Though one small problem remain: If the alert message contains any other character than ASCII (i.e >127), the message will not show on the device.
  My guess is that the TCPClient is the problem, but haven't found any solution yet.
  

Torje Rørvik wrote:
    (snip)

I suspect you'll need to encode those characters.
    A couple of clues:
    http://stackoverflow.com/questions/14809162/apple-push-notification-hebrew
    http://stackoverflow.com/questions/12704638/apple-push-notifications-with-foreign-accent-characters-not-receiving

(snip)

Thanks,
      After two days of googling and 200 failed push notification tests, I gave up the encoding-part and went for an facepalm solution :-)
      function StringToHex16(str: string): string;
      var
      i:integer;

Dave Nottage wrote:
      (snip)

Yes. TEncoding can do UTF7 too, AFAIK. So he could encode to UTF7
      before transmission and decode to Unicode after transmission again.
      IOW, TEncoding.UTF7.GetBytes(UnicodeString) to encode and
      TEncoding.UTF7.GetString(Bytes) to decode.

Torje Rørvik wrote:
        (snip)
I'm wondering whether that compromises the payload size with longer messages
        --
        Dave Nottage [TeamB]
        

Total payload size is limited - but, the conversion to hex is not the limiting factor. Encoding, if I recall correctly, is UTF8.
          (snip)