I've just finished my app, and so I am now getting ready to submit. But I need to change my developer Push certificate to Ad Hoc to test it with a Production Push certificate.
I thought I had it all figured out, but when I build the app, I get the error:
"Failed to get the task for process 2023" (The number changes every time I build.)
I have created my provisioning profile, and I am able to navigate to my Project's Build Settings and set the app to use my Ad Hoc profile. However, when I attempt to set my Code Signing Identity to "Apple Production Services..." all I see is my Distribution Certificate, not the Push Certificate.
What is going wrong?
I found the problem. I actually did have everything done correctly the first time. I just didn't know that I couldn't build on my phone through Xcode using an Ad Hoc provisioning profile.
So I ended up testing it by downloading the Beta via iTunes.
First of all, when you transfer all the Development Certificates to the Production you cant build the project from Xcode.
No one see push certificate in code signing identity.
You only see Either Development certificate or Distribution certificate depending upon the provision profile you have selected. You don't have to worry to choose Push notification certificate in Xcode, coz its managed by Apple once you enabled the push Notification service to the app by enabling it with unique bundle identifier in developer account. https://developer.apple.com (Only you have to give the merged version of that APNS certificate and distribution certificate in .pem format to web developer )
For Adhoc You have to generate Ipa of your project form xcode and install in you mobile through external link like http://www.diawi.com, if you import Ipa into your device from iTunes remote push notification will not arrive.
Related
I am using Parse.com to send client push notifications, from one iDevice to another.
It works well with the 'development' setup, i.e. with
- the Push Notification Setting of the appID set on 'Development'
- a development SSL certificate
- a development provisioning profile
With this setup, I managed to send a push notification to myself (sender = receiver = my device).
Now I want to test the communication between 2 different devices. To do so, I use TestFlight (because this is the way I usually send updates to my client).
I followed all the recommended steps to move from Development to Ad Hoc :
updated AppID settings to 'Production' Push Notifications
created a production SSL certificate, uploaded it to Parse Server
generated a new Provisioning Profile set for Ad Hoc Development, and installed it on the iPhone (checked on Organizer Library). This Ad Hoc Provisioning Profile is named : 'PushMyMoving_Push_Production_Profile'
updated the Project/Target build settings under 'Code Signing' to tell Xcode that it should use PushMyMoving_Push_Production_Profile (and the corresponding iPhone Distribution Certificate) for now on.
The issue : the build is successfully submitted, but as soon as it is, Apple sends me this e-mail :
And, naturally, I can no longer receive/send push notifications. Here's what I tried so far :
I opened the PushMyMoving_Push_Production_Profile to see if the Push Notification Entitlement was missing. It isn't. So my guess is that Xcode doesn't submit/archive the build with the right Provisioning Profile, although I'm telling it to do so in the Build Settings!
Actually, I noticed that whenever I submit the build, Xcode automatically selects a wildcard provisioning profile :
I tried to delete all the wildcard provisioning profile from Member Center & my Mac, but (annoyingly!) Xcode automatically re-creates them whenever I refresh the Provisioning Profiles Panel under Xcode>Preferences>Accounts. Is there a way to completely erase wildcard profiles ?
This thread : XCode 6 and Ad-Hoc distribution without XC: provisioning suggests that it can be that the "ad-hoc profile doesn't contain all of the devices on your team" but I carefully checked ALL the devices I have when I generated the Ad Hoc profile.
I've also tried to edit & re-generate, re-install the provisioning profile (a common advice apparently) but Xcode still does it its way.
Any help would be much appreciated! I have been struggling for days, it is really frustrating when the problem does not come from the code !
Thanks
Thanks Rhythmic Fistman for the help. I found the answer today : I was submitting my build to TestFlight with an Ad-Hoc provisioning profile, instead of an AppStore Distribution Provisioning Profile. I had read somewhere that Xcode was creating a Ad-Hoc provisioning profile behind the scenes while submitting to TestFlight, so I thought that the Ad-Hoc profile was appropriate. But since TestFlight runs like the AppStore, not having registered the subscribed devices UDID in advance (as with Ad-Hoc distribution) it makes sense to use a "broader" profile such as an AppStore Distribution Provisioning Profile.
So for anyone using Push Notifications with Testflight, you do need an AppStore Distribution Provisioning Profile. Then Xcode will automatically picks it for the submission phase.
Expunging wildcard provisioning profiles from Xcode and the developer portal can be done, but you can probably fix your problems by explicitly setting your Release Provisioning Profile to the correct Ad Hoc profile in your build settings:
This should stop Xcode getting too creative when Archiving.
I recently implemented in an app Push Notifications. We also use an instance of Xcode Server to make automated builds for our QA.
When I updated the app id to support push notifications, I regenerated the provisioning profiles for both development and production.
I also enforced in the build settings to use the regenerated Dev prov. profile for debug builds and the Prod prov. profile for release builds.
But after this, the server didn't succeed to sign the archive anymore because for some reason, the server automatically creates a Team provisioning profile. I tried to force it somehow. I also tried to move prov. profiles in the folder where the server stores them. I also tried exporting/importing private keys. No success. I changed the build settings and went back to "automatic" rather than forcing a provisioning profile.
When I install a build from my local machine it signs with the manual prov. profile. And push notifications work.
If I install a build made with the server, it doesn't work. In the console here's the message:
SpringBoard[53] : No valid 'aps-environment' entitlement
string found for application 'myApp': (null). Notifications will not
be delivered.
When I take a look in the Apple Developer account, the provisioning profile used by the server says that IT HAS push notifications enabled. I can't edit it because it's managed by Xcode.
What to do?
Are you sure you updated also on server side the Certs? Looks like "current Provisioning Profile does not contain APNS information, as the Provisioning Profile is created BEFORE creating the APNS certificate." see here No valid 'aps-environment' entitlement string found for application on app store
I'm following Parse's Push Notification Tutorial for setting up my Parse app to now be able to send Production push notifications, rather than Development ones, so I can get it ready for the app store. This is covered in section 7.1 in the tutorial.
When I attempt to create an AdHoc provisioning profile, it only works if I create an iOS distribution certificate, when I create an APN production certificate, which is the correct one for this purpose, it shows me this:
If I decide to go ahead and use the iOS distribution certificate from this list instead:
The provisioning profile is successfully created, but again, it's not using the correct certificate for push notifications. Likewise, because I had to use the distribution one to create the profile, I therefore would have to use the certificates .p12 file when connecting my Parse Notification settings to this profile. When I attempt to do this, I unsurprisingly receive the following error:
because I'm uploading the .p12 of an iOS Distribution certificate, and not the APN Production iOS certificate. When I try uploading the .p12 of the APN Production iOS certificate to Parse, it works, but my test iOS device doesn't receive push notifications, because the provisioning profile doesn't use that certificate, as I mentioned earlier.
Am I following the directions incorrectly? Why can't I make a provisioning profile using a Production APN certificate, so that it can work with Parse Push Notifications?
I have never used parse, but you have two exact production certificate.
This is an issue, revoke one of them and try again should work!
the provisioning profile doesn't use that certificate
I think you are misunderstanding what you need to do:
delete the app from your device
Build your app signed with distribution certificate
Install the ad-hoc version of the app on your device
Here is an image to illustrate how the provision profile works:
It's a good idea to check apple docs out
Also very important to check which provisioning profile you have used to sign and build the app.
Turns out my error was forgetting to set the code signing settings in both Project AND Targets.
I was testing push notifications on developer certificate and everything worked fine. After switching to distribution certificate and publishing the app notifications are not working.
Tokens are generated because my database is filled with them, but still notifications are not recieved.
Is there a way I could test out distribution build (signed with distrubution certificate)? I've build the app for ad hoc development signed with distribution certificate but I can't install it on any device, neither by iTunes (process is stuck on installing after clicking reyed out icon on device) or iFunBox.
I've checked the code signing and development was signed with develompment profile, and distribution with distrubution profile. But there also was provisining profile selected. I've readen that there should be selected "none". Could that be the reason?
I can't afford waiting another 6 days for approval not being sure that this time it works perfectly.
When you run PUSH notification with distribution certificate you have to set sandbox=false at your server side .
For testing distribution build I just deployed it for AdHoc deployment. It helped me to veryfi if it works on distribution;
SUMMARY:
Push notifications always work perfectly if my app is installed via XCode, but if installed via iTunes then they if they work or not depends upon the profiles used to sign the distrubtion.
BUT some profile combinations which used to work no longer do, and some which didn't now do.
My primary question is which combination of profiles should be used to sign an ad-hoc distrubtion that uses push notifications, and secondary question is why have I observed inconsistency in behavior over time.
DETAILS:
I am developing an app that uses APNs and have been having problems getting the notifications to arrive when the application is distributed as an ad-hoc app and installed via iTunes. The problems are obviously related to it not being signed with the correct profiles but some observations over the past few weeks have left me confused as to what profiles I am supposed to be using to sign the distrubtion.
I had been under the impression that the ad-hoc profile should be used at both phases where signing is required - firstly setting it as the code-signing identiy within XCode as the Archive is being built, and then secondly to sign the distribution. I've been doing it this way and its been working - devices have been able to recieve the push notifications.
Then a few weeks ago the devices stopped receiving push notifications, though there were able to receive them if the build was signed with my development profile and installed via XCode, it was only the ad-hoc distributions that stopped receiving them. After a couple of days of trying everything I eventually deleted the push and ad-hoc profiles and created new ones and everything was working again ... until a couple of days ago when the same thing happened.
I created a new ad-hoc profile again but I still couldn't get the ad-hoc distrubtions to receive the push notifications (though the devices would once again still receive them if the app was installed via XCode). Eventually I changed from signing the distribution with the ad-hoc profile to using the apple push profile and things started working again.
So now I am confused:
- am I supposed to sign ad-hoc distrubtions using a) the ad-hoc profile for the archive and then ad-hoc profile again when signing the distribtion of the archive or b) the ad-hoc profile for the archive and the push profile when signing the distribution of the archive?
For XCode installations I set the code signing identity to my development profile. For ad-hoc distrubtions I set the code signing identity for the archive to the ad-hoc profile, then at the distrubtion part of the archive sign it again with the ad-hoc OR the push. The OR is there because sometimes one combination works sometimes the other combination works, my whole question therefore is which combination SHOULD it be and why have I observed inconsistency in which combination works and which doesn't.
Thanks
EDIT:
This is a list of the profiles there are, i.e. if I logon to the Apple provisioning portal then click on the provisioning tab then the development tab it lists these:
1) Apple Push Profile - needed to enable APNs
2) NNN Development profile (where NNN is the name of the project)
3) iOS Development profile
4) iOS Team Provisioning Profile
If I click on the provisioning tab then on the distribution tab it lists these:
1) Ad-hoc
In all my extensive searches of books, documentation, forums over a period of many months I have yet to find definitive explanation of which combinations of the above should be used under what circumstances and which take push notifications into consideration.
A problem is that most documentation and examples do not take push notifications into consideration and this is crucial omission because without the right combination of profiles in the right order the app can install onto the device but push notifications will never be received.
I've had some similar pain.
I response to the following:
am I supposed to sign ad-hoc distrubtions using a) the ad-hoc profile for the archive and then ad-hoc profile again when signing the
distribtion of the archive or b) the ad-hoc profile for the archive
and the push profile when signing the distribution of the archive?
Signing the archive build with ad-hoc or development does not matter.
What makes all the difference is the signing at the time of the distribution button in Organizer-Archives.
Sign it with a development provisioning identity. Not ad-hoc.
I have found signing confusing because there are 2+ places to define signing actions. But in this specific case I've done controlled tests, and sending out ad-hoc distributions, I don't even know if it's possible to get remote notifications into those apps before the app is officially released and can be pushed using the production gateway.
Still, I believe pushing to ad-hoc distributions prior to app-store release should be possible.
Well after two days trying to figure out what was wrong with the same problem, i found out that when installed via xcode the notifications worked with the development (gateway.sandbox.push.apple.com) url. Exporting it as an ipa (ad-hoc) and installing it manually needed notifications to be sent from the production url gateway.push.apple.com (including the production key). So having created both keys, i managed to send notifications with the development url when working on xcode and with the production when installing from exported ipa.
If you are in a development stage using development application certificate and provisioning you should also generate a development certificate for PUSH notifications that must be installed on the server to authenticate with apple test APNS.
If are in pre production or production stage you should sign you app with distribution certificate and ADHOC or APPSTORE provisioning you should also generate a distribution PUSH certificate that must be installed on the server that communicate with apple's APNS.
I can suggest you to keep an eye on firewalls blocked ports (such a pain also because apple's apns has a wide ip ranges) and pay attention that apple ID's of your application must match the once used for generating push certificates.
Hope this helps,
Andrea