Push Notification on published app only works on non-development device - iphone

I have an app in the store and push works for anyone having bought the app, no problem there.
But it does not work on the two phones we used for development.
How do we solve this?
tunebot for iphone

With regards to push notifications, you have two different servers with two different certificates for the notifications. One of those is a test/development server, which has one set of permissions. The other is a production server with a different set. If you go to the iOS Provisioning Portal and click on App IDs, you'll see that the second column has two rows, one for development PN and one for production. Start here and make sure your development ones are configured properly.

Related

Automatic OTA updates in an ios app which is locked down with guided access

My client needs to find a way to automatically push app updates to a number of iphone 3gs devices remotely. These devices will be in guided access mode so the users will only be able to access the app in question.
I believe we have two option for distribution:
B2B custom app via the Volume Purchase Program
In-house app released with the Apple Enterprise Program
Having researched our options I can see that over the air app updates can be achieved by either:
Building an in-app update functionality to check for new updates (Enterprise only I am guessing?) and automatically update and restart the app
Using an MDM such as http://www.air-watch.com/ (as I understand Apple Configurator must have devices plugged in via USB to work?)
I am wondering if anyone can tell me whether either of those options are possible with the devices being in guided access mode?
Or are there any other solutions, which I have missed, that can automatically manage the app remotely while the device is in guided access mode?
You can solve this with an Enterprise distributed app.
App only. Update check for an OTA-Update from your app when the app is coming to the foreground (or some other metric at your clients leisure, like added time delay, etc). Basically self explanatory; you implement a call to your clients/your API to check the version and inform the user of a new one. The update can either be optional or mandatory (preferably announced by the API and changed when needed); present the user with an alert about it. The user acts upon it and you OTA install via an ITMS link provided by your API call. And that's it.
MDM. Tbh, I'm a bit on shaky ground here. Theoretically this is all possible via MDM too, however I am not sure if it is the (varying) MDM solutions or some misconfigurations, but clients usually seem to lose control after some time.
Both. Yes, you can perfectly well live with both. MDM while everything is fine, and as a backup a well structured App+API mechanism to push the OTA updates out. This is especially useful if you have customers where some departments are under MDM and others are not. So, some may get it via MDM (and if all else fails via the App itself), the rest will get it via the App.
The tradeoffs are a matter of personal preference, if there is a fully working MDM solution in place the update will be pushed out and the user however 'malicious' can do nothing against it. But the same is true for the 'App only' solution, as you have the option to not let him use the app if he does not update (either by not providing a cancel button or, as you are in an enterprise environment and there it is allowed doing an exit(0)).
From experience I prefer any solution that has the 'App only' option as it is the last fallback if anything on client side fails. Whatever may be added on top is just sugar to the cake.
While not strictly relevant, the 'App only' solution always goes well with Push Notifications when an update came out.

Only one developer is getting push notifications

I'm using APNS-Sharp to send push notifications. Everything seems to be working fine for me, who has a developer provisioning profile.
I'm using a distribution profile for everyone else, and they are not getting push notifications.
My question is, does each provisioning profile have to be enabled for push notifications?
I think there are different push servers, one for development and one for production. Have you switched over to the appropriate server? gateway.push.apple.com:2195 and gateway.sandbox.push.apple.com:2195.
Do all profiles and your dev and prod build have the same bundle identifier? Make sure the bundle id is correct and not a general bundle id.

Mass beta testing of application

I have a beta application that I want to show to 100+ people and I can't figure out how I can do it without the app store. The thing is with the app store it's a beta. In the app it has pages that do nothing because I want to show the people what I'm working on next.
What adds to the problem is that the application is Push notification enabled.
I'm guessing if I sent the files of the code that the certificates would change because they would have to make a new provisioning cert.
http://testflightapp.com is a great tool for distributing beta tests. As for the 100+, it will only support 100 a year as per Apple's ad-hoc constraint, up to 200 devices. To test with more people, you'll need to sign the app again with another developer account and distribute to a second list. Other options include enterprise deployment or having some testers build and deploy for themselves, signing with their own developer account.

Using a single xcode proj for iphone and ipad- can I use same push notification certificate?

I am looking for extending my current iphone app for iPad-specific UI. For the same Apple has mentioned 3 ways, however I am using the method where a Single XCODE proj is used for having 2 targets- iphone & iPad. There are a few queries:
two binaries will be created , which I can price differently for selling. Will they need 2 have different certificates from Apple ?
My app has Push notifications. So will i require 2 different certificates ?
Your app's will require unique AppID's to appear as separate apps in the AppStore - thus requiring separate certificates.
I guess that you would be able to install both app's on an iPad at the same time which underlines the need for two separate AppId's and distinct push notification certificates.

What's the point of App ID's and Provisioning Profiles?

As I understand it, an App ID is an code that's unique for an single application. Every time I start developing an new application, I have to create a new App ID.
But I don't get it what's up with that "provisioning profile". Do I need one for each single app? What's that for?
It's to protect the end users, by having a way to validate apps and their origin. It also serves as a centralized system to control development. On windows most apps use GUIDs for this, but they don't have any centralized info about them. Apple does, which is a pain at times, but it's a valid effort in the end.
The provisioning profile contains a list of devices that are allowed to run or debug your code. Everything is verified with a digital signature, which ultimately lets Apple control distribution. This is why you need to jailbreak in order to get apps from sources outside the App Store.