Delete Existing iPhone App - ios

I have an iPhone app that now needs to be removed. I can do this by following the steps in iTunes connect:
Untick all territories in pricing and availability
Then in Additional Information : Delete App
I have completed step 1 and am about to follow step 2 but I have a question that I cannot find answered on any of their help/docs nor online elsewhere. Once I delete the app - it will get removed from the app store, but will it still stay on all users iPhones that have already got the app downloaded and installed on their phone? Or will it automatically be deleted/removed from all phones?
Ideally I need to remove the app completely so that it can no longer be used be new or existing users even if they already have it on their phone.

It will stay on the user's phones.
In your case even worse for you: If they backed up/synchronized the application LOCALLY via iTunes, they got a local .ipa-file (an instance of your app), which they could even restore, after they setup the device once again.
For the users this is a pretty convenient way. So, if you want to delete your application. Inform users about that step and if you have a good exit strategy, users will adopt this and will delete it on their own.

The app will stay on the users IPhones. There is no way to remove it remotely.
The only thing you could do would be to release new version with a lock but then you will probably get trouble with Apple.

Related

How to Test an iOS App as if First Time, Each Time?

Here’s my situation:  I have an iOS app in development.  To thoroughly test each new beta version, especially the content purchase process which happens after the initial app install, I need for my device (iPad) to forget it has already seen and purchased the content of the app before.  Once I purchase, though, each subsequent download automatically activates the previously purchased content, so I don't get to start fresh.
As a solution, I was going through the laborious process of creating a new iTunes account, doing a factory reset on my iPad, adding the new account as a new tester in the iTunes Connect Test Flight system, and testing that way.  It worked a few times.  What I just discovered, though, is that Apple only allows three different accounts to be registered on a single device over the course of a year, so that plan is no longer viable.
My question, then: How are developers testing apps that need to load as if for the first time in a device, after the app has already been perviously loaded and tested?
Stumped on this, appreciate any help.
Cayce
The app's data should be deleted by just deleting the app. If it is storing data elsewhere on the device then you can go to Settings-General-Reset-Erase All Content and Settings.
That should do it.

What is the UX when I add additional builds to an existing external beta test in iTunesConnect

I currently have an app on iTunesConnect with a few hundred external beta testers using it. Important to note, we will have 2000 testers by the end of the month. I want to push new builds to this app- and this, I know how to do.
What I don't know is, what is the expected behavior for my beta users when I add a new build?
Our company cares a lot about user experience, and we don't want to have our current testers of our current build open the version that they've already installed, only to see it crash because I added a new build that i'm hoping will just update their current version automatically.
Apple does a good job of making a developer think this might happen. I've searched everywhere to find this answer in the docs- please help! After selecting a newly approved build to switch to in the External Testing portal, upon selecting Save, this alert appears:
(405 is the first build, 407 is the new build)
So, what happens when I save this- will users be notified that they need to update the app?
Will the "update" happen automatically for them if they've already installed the first build?
If they open the already installed version, will it simply crash?
If so, what can I do to prevent this from happening?
My team will likely want to send out 1-2 builds / week (of the same app, with fixes and improvements) to the same group of testers until we're ready to officially launch the app. I'd hate to think this would crash the app on them every time. As far as I know, there is no way for me to test this before performing this action- I'm already added as an Internal Tester, but that's a completely different UX in TestFlight (builds are made available to internal testers immediately after uploading)
If you think this has been asked already:
This is not a duplicate of this question- because I haven't attempted to send out the build yet. I want to make sure that linked issue does not happen to my testers!
My question is unlike this one where the user did not know how to properly increase his build number, unlike this one, referring to testing a new build of an app that already has a version in the app store, unlike this one which refers to a bug in the app store where a user couldn't initiate an external test after uploading a build, and unlike this one where the user just didn't know how the iTunesConnect portal works.

Decommissioning an iOS app

Hi we have an iOS app in itunes which have more than 20,000 downloads.
since we have re-branded our company we have developed a new app which includes extra features than the existing app. New app is with new name and Bundle id.
So now rather than taking out the existing old app, we want to redirect all the existing users to our new app. How can we do that ?
what we did was , we updated the existing app version with the popup, which says this app no longer available please download our latest app. but this got rejected by apple.
Any best practices to decommission an ios app
Thanks
Apple will not allow you to completely drop all of the features in an app - they want users to still be able to use the app. Imagine if all of a sudden Facebook make it so no one could use their app, and forced everyone to download a new app. It probably wouldn't turn out too good for them.
What you should do is just make an update to the old app. All of the users will be able to update easily, with no hassle, and you won't lose and users.
Another way to do this is by calling your new app MyAppName 2, although this will really only look good if you're developing a game.
If you would really like to get rid of your old app, I would recommend removing it from the app store and contacting Apple (You'll have to give them a good reason. Wanting people to pay for a new app doesn't count as one)
What many developers do, is add code to an app that checks a specified endpoint for instructions at each launch. The instructions are either, run as usual or, display this message and URL.
Personally, I would do this, and also update the old app as a freebie teaser for the new app. Apple pays less attention to reductions in functionality than they do to "kills".
Run the teaser for a year or so, then kill it.

How to auto-update apps managed by MDM?

I'm building an in-house app that is distributed via the AirWatch app catalog. The app always runs with Guided Access enabled and all devices running it are managed by AirWatch. My questions are regarding auto-update:
Is there a way that AirWatch can force the update immediately or as soon as the device comes back online, without asking for the user's input? If so, how does the app being open affect this behavior? How does guided access being enabled affect this behavior?
Is there a link from AirWatch, perhaps an itms-services:// link, that the app can call to install the new version if a web service had indicated that it's no longer the latest version? If so, how does Guided Access being enabled affect this behavior?
Is there any other good model for remotely updating the app that will spread the update as quickly as possible and under the above conditions? The solution can be using MDM or a custom web service or both combined.
Thanks a lot for your help!!
If your devices are running iOS7 and you have your app Deployment settings set to "Auto" (as opposed to "On-Demand") the device will automatically take the update once it processes the APNs notification to do so. If the device is locked/offline it will typically check for outstanding APNs messages within a minute or so of being unlocked or coming back online.
What I don't know is since your app is in guided access mode if you're receiving a pop-up to install the new version. I've seen previously where if the app that requires an update is open iOS will prompt. What we have done to battle this is embed a check in the app that phones home to see if the app is current. If the app is NOT current the user can't do anything until they update their app.
Regarding a direct-link to the App Catalog to update the app that might get tricky with guided access enabled. Before you even try to tackle that issue understand that the app catalog webclip URL contains the UDID of the device as of AW7.1 (I think). Since the UDID is no longer programmatically accessible code-side AirWatch allows you to push the UDID upon app installation in the Deployment/Application Configuration section. You can embed {DeviceUid} into the key share on the device which will make it accessible for that applciation, hence allowing you to create the appropriate App Store URL within your app.
Good luck
honestly I didn't work with AirWatch. But I don't think that Apple provides a way for automatic update of ad-hoc or enterprise apps.
Well, I can describe a solution for an enterprise app I developed last year. Hope it will help you somehow.
First of all, I made it as a part of our secure website. (a little test flight)
Here's how app update works
When the app launches it sends special request to a server asking if
it is outdated and a new app version is available. (+ servers sends
url for new version installation (with itms-services://))
Then
if update is required, app fires alert with description of new
version, if user taps update, the app opens Safari where the user
is able to install a new version.
We made to different kinds of alert, optional (minor version change) and compulsory(major version change). With later variant user is unable to get rid of alert view, so he has to update the app.
You can update your internal app through the AirWatch Console and applications versioning.
I never used it but I imagine that at the end of the new version process, there is a way to push the updated app to the related devices. If the Push Mode is set to Auto, the user won't have to do anything and the app should be updated. If it is On Demand, the use will have to initiate the process from the App Catalog. From for the latest option, you have the solution to send a notification to the user.
It is also possible to retire or inactivate older versions to only keep the newest one.
If you have access to AirWatch Online Documentation, I recommend you the page Using Add Version for Applications. If you don't, contact your administrator and ask for all the pages located in Mobile Application Management -> Internal Applications and the page Using Add Version for Applications.
You should try it with a single device though ;)

I need to check the itunes store to see if a user has bought a subscription in the past version of my app

I'm rolling out a new version of an iPad app, and you could buy subscriptions on the old version. However, the new app has different subscriptions than the old one did, but I still need to know if they used to have a subscription, so I can apply it to the new app.
So, how can I check the iTunes store to see if they bought a certain product in the past when they load the app? From what I can tell it should be possible to do because it is the same app and connected to the same app ID in the iTunes store.
I'm trying to get some sample code to put in here but I have literally no idea where to even start.
You can use the SKPaymentQueue's -restoreCompletedTransactions to restore everything apart from non-recurring subscriptions. Your observer should get then receive every relevant transaction since the beginning of time, each with a state of SKPaymentTransactionStateRestored.
Apple requires you to support transaction restoration so hopefully your old version's code should have this built in somewhere, behind a 'restore' button or similar.

Resources