Apple's APN Service Programming Guide in the Provisioning and Development section claims that "[t]he sandbox environment also acts a virtual device, enabling simulated end-to-end testing." However I couldn't find any information how this virtual device can be accessed (e.g. how do you get a device token, how do you check the status of notifications sent, etc.) Does anyone know if this information is valid and if it is how does one go about doing end-to-end testing using the sandbox as a virtual device?
Getting a device token works the same in sandbox servers as it does in production servers - you just get a development device token that can only be used when talking to their sandbox servers. However, just like the production servers, you can't check the status of notifications sent or anything like that.
The "virtual device" wording is confusing, because it's really just a separate set of infrastructure that only talks to development applications/device tokens.
So, just talk to the development servers while you're developing your app (that is, when your app is built with a development provisioning profile) and talk to production servers when the app is built in ad-hoc or production mode. The process is going to be same.
However, be sure not to mix development device tokens and production device tokens.
Also, push notifications don't work in the simulator, so you will need an actual device to test on. If you're testing on an iPod Touch, be sure to keep in mind that it will only check for messages every fifteen minutes or so if the backlight is off.
Hope this helps!
Related
I have a very unique situation here, I have to test devices with same specification. The application i have developed has push notification capability enabled. All configurations are done in server side i.e added device as development device, the device is added into provisioning profile, the provisioning profile is installed in phone and development machine as well. Now the problem is the application is installed in both the device in one device everything works perfectly fine the notification appears for every event, however in another device it doesn't.
I tried everything i.e checking the setting in device if for some reasons notification is not allowed or may be some settings. I compared all the settings in both the devices everything is same.
The error I get in server side is Bad Device Token for one device. I tried to delete the token from server side and got it again still same situation it works for one device but not for other.
Any help or pointer would be really appreciated.
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.
Is there a way could i delete my application from some users iPhone by sending a push notification?. The reason can be a security concern.
This can't be done for any iOS device, but it can be done for devices enrolled in Mobile Device Management (MDM). Apple has documented all of the available operations, including removing applications remotely.
An MDM server can manage third-party apps from the App Store, as well as enterprise in-house applications. The server can remove managed apps and their associated
data on demand or specify whether the apps are removed when the MDM profile is removed.
No. You can't execute any code in response to a push notification, unless your app is already running in the foreground. And you definitely can't programmatically delete your app in any situation.
Your best bet would be to have your app phone home when it starts, and not function unless it's supposed to.
You cant delete your application programmaticaly. But you can block some functionalities using client server communication. For example, Write in your code to send a request if security risks identified, and based on response you can control the program flow.
I am using APNS service in my universal app (iPhone/iPad) and i am not geting notifications on device. Previously i was getting notifications perfectly but now a days with the same code at server side and client, it is not working.
On server side notification status is delivered but i am not receiving it on my device.
I have checked most of the questions on stackoverflow but i was unable to find my question. one guy said that in development environment it may have delays, but my problem is that i am not receiving notifications at all.
Note: i am using sandbox environment not production.
Just in case you haven't found a solution yet, one additional thing you could check is if your device's date and time is properly set (in the OS). If your iPod, iPhone or iPad isn't set to the current date, we found that notifications are ignored silently. Of course, there are many other possible explanations as to why your service stopped working, but this is a simple thing to check when everything else appears to be fine.
Following are the things you can check
Check the entitlements while codesigning the app. (They can be seen in Xcode build log).
Check whether notifications are on for the device in the settings menu.
If you are using corporate network on the iOS device, the push notifications might be blocked. Try using a different network.
After launching the app, check the organizer for any logs with the reason why push notifications can not be enabled.
I hope some of this helps you out.
I just revoke my certificates
Uploaded new certificates deleted all provision from my organizer
and then created new provisions and installed them on my system.
At the same time I got my APNS working.
Today I walked to through the process of getting my iOS device connected to my computer and running my app. To do that, I had to...
Obtain a developer certificate
Assign the device to my team
Obtain my app ID
and create a provisioning profile
While I understand the process and was able to successfully get my device connected, I don't at all understand the point of all this. Can anyone explain the point of each step in that process and why Apple has us do this?
Thanks so much in advance for your help! It's important to me to understand this stuff at least at a high level.
Apple just wants to torture the developers :)
Joking aside, I don't know why. There's no official explanation why you need those steps, here's my speculation.
Apple wants to make sure that
only the developer registered to Apple can freely install
onto his or her i-Devices
applications of his or her own applications .
This is presumably to forbid the distribution of apps outside of Apple's own App Store. If any of these three steps is not required,
it's easy to imagine how you can "abuse" the developer status to install lots of apps without going through App Store.
This explains why you need to do 1, 2 and 3. In order for XCode and the i-Device itself to check it, you need a provisioning profile. This explains the point 4.
As a rough explanation.. the device only runs signed apps. Your developer certificate (along with your private key) signs your app so it can run on your device. (or other development devices of your nomination)
If you beta test, your Ad Hoc certificate + provisioning profile will allow all devices with their UDID in the profile to run that app. The beta testers don't need your developer certificate, just their device UDID embedded in the profile.
When you distribute to the app store, you use a Distribution profile (along with the team agent key), and that needs additional signing (co-signing?) from Apple before that code can run on the device. Because Apple signed it, the device doesn't care what UDIDs are allowed.
Apple has made a business decision to maintain tight control over developers and apps both during and after their app development. This means that at any given point in time, they have a tight connection between a developer, app, devices, and the app's users, be it through the adhoc distribution mechanism, or through purchases that users make in iTunes Store. We may only speculate what they internally thought that the goals and benefits here are, but as the market has shown, the outcome is beneficial to all parties, as they have shot from oblivion to one of the most popular smartphone platforms in a few years.
One quite straightforward goal is that they intend to maintain control of the distribution channel and make sure the app cannot be officially distributed through any side channels and they have control over all the money that moves, hence the 100-deviceIDs-per-developeraccount limit (so you couldn't distribute your app outside Apple's channel, yet the 100 devices should be sufficient for closed testing).