What is Apple's policy with regards to disabling old versions of an application? - app-store

My employer has a free iOS app in iTunesConnect that was originally released a couple of years ago and has received various updates over time. They now wish to stop supporting older versions of the application (1.x) and disable these older versions of the app.
My questions are:
Can we stop users from re-installing old versions of the app? If yes, how?
How do we disable/remove old versions of the app in iTunesConnect?
What is Apple's policy regarding disabling/removing old versions of applications?
I'm not an iOS developer and am unfamiliar with the whole Apple application development process. I have searched the web as well as the Apple developer centre and I've read through the Apple Developer Program Terms and Conditions but I haven't been able to find answers to any of my questions.
I have managed to find information about removing an application from sale but this removes the entire application, rather than just specific versions. (Deleting a free app from iTunesConnect)
David Smith's article (http://david-smith.org/blog/2012/06/20/hacking-paid-upgrades/) on Paid Upgrades mentions the ability to provide fixes for previous versions if they're not deleted from iTunesConnect. When I log into iTunesConnect, I only see the current version of the app listed so I'm assuming prior versions have been deleted already. I would, however, like to confirm that users can no longer download old versions of the app.
This article mentions users being able to download old versions of apps from iCloud (http://www.macrumors.com/2011/06/09/icloud-supports-re-downloading-some-discontinued-apps/) - can we prevent this? One option would be to mark the the version as having a "legal issue" but what ramifications does this have? and if I can't see the app in iTunesConnect then how do I do it?
I found a post asking about how to force a user to upgrade the application every time a new version is released but this doesn't answer my questions either. We want the users to upgrade but we're not wanting to force it programmatically. (Can I force an iPhone user to upgrade an application?)
I've also found lots of posts asking how to revert to previous versions of an app in the app store but again, this is not what we're wanting to do. We're wanting to disable older versions of the app but leave the most recent versions alone.
Before the flame wars begin:
Users that are unable to update to the latest version of the app for whatever reason are able to use a mobile website in place of the app. The website has the exact same functionality.
Can answers please be kept on-topic rather than getting into great debates over whether one should/shouldn't maintain legacy versions.
Thanks in advance :)

Users can typically only ever download the latest version of an application. There are a few ways I think they can get around that but in general only the latest version is available to users via the normal means.
If, however, you absolutely must prevent the old versions from being released you can do so when submitting a new update. Right after you say "Ready for Upload" you will be asked a question about if this update was for a 'legal reason' if you click YES then you will be given the opportunity to disable old versions of the app from download.
As to Apple's policy on this...I have no idea. But I can't think of any policy that would require you to support older versions moving forward.

Related

Flutter auto-update app when a new version is released

I wonder how to make my application (which is already published on play-store and app-store) updates automatically when a new version is released.
I have found some packages that support similar thing like: https://pub.dev/packages/new_version and https://pub.dev/packages/upgrader but the issue is that all these packages display a dialog when a new version is detected. But I am asking about making it completely automatic without any dialogs appearing.
I also knew about https://pub.dev/packages/firebase_remote_config but it doesn't answer my question about releasing new version.
I see this feature in a lot of apps but I don't know how it's made in flutter.
Unfortunately you can't auto-update.
Auto-update strategy depends on user settings
You can only ask user for update
It is not possible that the Application gets automatically downloaded and installed. Both ways are also not allowed from the AppStore and PlayStore Agreements.

Can't update iPhone apps

After making an update to an iPad app I released some time ago, I've been getting reports that people are unable to actually update the app without deleting and re-installing. However, as far as I know, nothing in the update should be causing this. (All the update deals with is letting people email PDF documents, nothing major.) When people attempt to update, they're asked for their iTunes password, but after entering it, it merely goes back to the update screen and nothing happens. Additionally, it would seem that this only happens with my app, the people in question aren't having any issues with the other various apps on the App Store. Does anyone know what might be causing this and how I could fix it?
Thanks in advance!
(Also, if it matters, the app is a custom B2B app, the general public can't purchase it.)
I'm removing the text of my answer because it's so inaccurate it's embarrassing. I mistook "B2B" for "Enterprise" and answered based off of that. To make up for it, I'll look into the problem a bit more and if I find anything I will edit this answer accordingly.
Edit:
Okay, I can see why you put a bounty for this question on SO; there's not really any data on a problem like this anywhere. Frankly, there's not much available information on B2B in general. I'll post what I found anyway, in case it can be of any help to you.
I found the details reason behind Maggie's question, there. Per Editing and Updating App Information:
Updates keep the same Apple ID and bundle ID, which means they are
associated with your first version and free to your customers
Also, apparently, "You can't change the CFBundleIdentifier of a released app if you want to release updates for it, the App Store will automatically reject it when you upload." which is something I can vouch for, having experienced this with a normal app. I do know that for a B2B app you do have to submit it to Apple for review, but I can't tell from the documentation I found if you need to actually submit it to the App Store, so it may not go through the various checks that normal apps go through, so this could be your problem.
Aside from that, according to the VPP guide, if your customers are installing the apps on the devices with Apple Configurator (broken right now, per app store reviews) the updates also have to be done with the Configurator. You haven't said that Configurator was involved, but I did find this tidbit.
• Use Apple Configurator to install apps on new or supervised devices.
Apple Configurator on a Mac makes it easy to mass configure and deploy
devices that are centrally controlled. Redemption code spreadsheets
acquired through the Volume Purchase Program can be imported by Apple
Configurator, tracking the number of apps installed on each device. To
update deployed apps using Apple Configurator, you must reconnect to
the same Mac from which the apps were installed. Learn more at
itunes.apple.com/us/app/apple-configurator
Anyway, good luck. Wish I could be more help.
What you are describing (assuming that it is accurate) would certainly be a bug on Apple's side. If users are trying to update the app and the update is not being processed, then in one way or another that is a bug that Apple needs to address. Nothing that you do as a developer should be able to cause that situation to happen. I would suggest contacting Apple and possibly filing a bug report.
It seems that apple wants you to develop the Iphone apps in the latest build. Sometimes this cause issues between realeases (diferent versions of Itunes, OSX, IOS, etc) when you try to update your apps.
Try to publish the app in the latest version of xcode.
That happens a lot in iphone development testing.
Hope this help.
When updating an app, iOS looks for the bundleId and if there is another app with the same bundleId, it updates the app with the highest version number. Maybe the version number is not set correctly or maybe people have issues because an other app (from the AppStore or an other B2B app) have the same bundleID but a higher version number.
I'm by far not an iPhone expert, but it seems something related might have been fixed in iOS 6.0.1.
Fixes a bug that prevents iPhone 5 from installing software updates
wirelessly over the air

App Store - Best way to merge a paid and free version into a free version with IAP

My company currently has two applications in the app store: a full, paid version that includes two ebooks, and a "lite" version that does not include both books. We've just developed a new version of the app that instead implements the two books as IAPs, with the intention of merging the two apps into one. I'm at the point where I'd like to submit the app, and I'm not sure of the best way to proceed.
Current plan:
Update free app to the new version with the IAP books.
Rename the free version, removing the "Lite".
Delete the existing paid version from the app store.
Potential problems with this plan:
Those who've already paid for the existing full version might feel ripped off, since their version won't be receiving any of the other updates in this new version.
There will be a name conflict, since we want the new app to take the name of the old paid one (removing the typical "- Lite" signifier). This won't be much of an issue in the App Store if we immediately remove the paid version from the store, but can make for a confusing user experience if a user downloads the new version alongside the old paid version.
Along the same lines, if we delete the old paid version as soon as we upload the new free version (with the same name as the old paid version), it's easy to imagine some confused users of the old paid version deleting their existing paid version and downloading the new free version, only to realize they'd lost the books they'd already paid for, with no way of re-downloading the old paid version.
My questions:
From a real high level, are we handling this the wrong way? I've Googled and Googled, but I haven't been able to find much guidance on how to combine paid and free version of apps into one.
Is there any way for me to determine who's already purchased the paid version, and "gift" them the book IAPs in the new free version? If we thought this threw sooner we could've logged the unique IDs of all of those paid versions, but I do believe that's against the rules now anyway, correct?
What other sorts of issues might arise by giving the "- Lite" version the same name as the old full version?
Thanks in advance for any and all assistance or feedback.
We just did that with our FileApp Pro and the free FileApp. We got rid of FileApp Pro and now the new FileApp has In-App Purchases. However we wanted to have all users that bought FileApp Pro to have all In-App purchases of FileApp for free.
Here is the method we used:
We are sharing flags between FileApp and FileApp Pro using the iOS’ “Keychain sharing entitlement” which allows two apps to share the same keychain data. This allows FileApp to know that FileApp Pro is installed. Then we wanted to make sure that FileApp Pro privileges remain available in FileApp through the iTunes account of the user so we used a free In-App purchase to do that. The FileApp Pro user when launching FileApp for the first time is asked to purchase a free In-App purchase so all his privileges remains across devices even if he reinstall FileApp.
You will find a complete article on our bog describing the method:
http://blog.digidna.net/post/74246563623/how-to-release-a-whole-new-app-and-keep-all-things
Edit: Here's the archive link to the above post that doesn't seem to be available now: https://web.archive.org/web/20160309135133/http://blog.digidna.net/post/74246563623/how-to-release-a-whole-new-app-and-keep-all-things
I would think it might be best to turn the paid version to the free so at least your original paid customers are taken care of the most. Depending on your user base you could even ensure the original paid users aren't shown any ads or other restrictions by doing an intermediate release to have those users save something to user defaults. Then you could provide an update to the free version with a UIAlertView that asks them if they want the full version for free and direct them to the app store to download it. I assume you have many more free users but you would probably upset less people with this path.
I know two apps that did something very similar. The Economist, and USAToday app, which literally alerted the user to ditch the current app and download the new one. (Not sure why they had to do it that way though). So I am quite sure you are not the first one thinking of doing this.
If there is an option for you to provide account+sync capabilities, that'd be the best way to merge both the apps. One of my favorite apps, Gas Cubby, handled this pretty well. Gas Cubby has a free and a paid version. If you want to upgrade your from free Gas Cubby to paid one, you download a different app, and then sync data.
For your worries about how to restore content for the paid customers in your Lite app, you can use a URL scheme in the Lite app, which, when called by the current paid app, will enable those books for free.
As #rooster117 says, its best to turn the paid version free, and ask the lite version people to move to the paid-turned-free version. Of course put hard stop date in the app that you'll discontinue, so that all those who use it will move to the one app of your interest.
Your Problems:
This is going to happen regardless, you can't make everyone happy
I would go with removing the Free version of the App although, but before you do send a push notification to all the "Lite" version holds saying support for this app will be discontinued and direct them to the paid version
To continue on from #2 if possible, before discontinuing the "Lite" version if you have an account system setup to a server of yours release an update for both versions that syncs all of their books with your own server (not iCloud). This way when they download the new version (after the Lite is discontinued), the app will automatically sync the books back to the device.
Your questions:
As you relise there is no real way to merge two apps, from what I've seen from games to utilities is to remove the "lite" version as some point all together and if the user wants future content updates then they have to download the app still on the App store.
Refer to my Answer to Problem #3
I believe it will be out right rejected by the App Store review process, primarily due to the fact that they both perform the same function, i would suggest to remove the free one altogether

Concrete info on iOS app upgrade process

Can someone provide concrete info on how the app upgrade process works on iOS as far as the developer is concerned? I've been rummaging through Stackoverflow only to find hand-waving explanations and no links to official documentation. Google search results only led to Cisco's IOS and the end-user upgrade process. I'd like to know the following:
How does the App Store know when you've provided a new version? Do I have to implement something in my app, which the App Store pings? Or do I set things up stuff through the Apple Developer website? I've been waiting 2 months for developer approval and have no idea what's going on behind those doors because I get access-denied messages when trying to read official articles.
Is there any Objective-C code I need to write for an upgrade to be possible? Any plist I need to edit?
How is payment affected when version 1 of the app is free, then version 2 is paid or version 1 is paid and version 2 changes its price.
Does Apple allow me to do forced upgrades? All the answers on Stackoverflow have been, "I think this is bad business logic" or "I think Apple forbids this, but I don't have the official documentation to prove it." At a certain point, very old versions will be too time consuming to support. You don't see Microsoft still supporting Windows 95, do you?
You just submit the new version to Apple. When it's approved, it will appear in the App Store.
Same as above, Apple pretty much does it all for you.
If you transition from free to paid, everyone that has downloaded the app for free will not have to pay to upgrade to the paid version.
IIRC you cannot force users to upgrade, but you can display a notification within the app to alert users that an update is available. To implement this, I would just have the app request a file on your server that tells the app what the current version number is. You do not need to support users on old version, if they have problems with an old version, it's fine to tell them to upgrade.

Downgrading to a previous version of an iphone app

I have an app on appstore.
I uploaded a new version and it was published. But, just after that I realized an important bug in my app. Since the approvement process takes a long time, I want to downgrade to the previous version until the fixed version is approved by Apple.
Are there any way for that?
Thanks
The only way to downgrade is to resubmit the previous version with a new version number, or a new fixed version, and wait until it is approved. If you put a note in the Demo Account section saying this is a rollback or a critical bug fix, there are reports that Apple may perhaps expedite the review. If the bug is bad enough to create very unhappy customers, you can warn customers not to download it in your update notes, and/or you can set the availability date of the current broken version into the future, until your fix is accepted.
Unfortunately not, Apple doesn't provide a means of rolling back to previous versions. If you have the source code, you could always just increment the version number and upload the old version again.
like the other answers have said - unfortunately, Apple does not provide a way to rollback once you've released the app.
The way many major apps deal with this is by instrumenting their app ahead of time with feature flags (https://martinfowler.com/articles/feature-toggles.html): ways to enable/disable features and codepaths from the server.
Granted that implementing feature flags requires foresight and planning (it's unlikely you'll capture every codepath). Fwiw, I started my current company (https://screenplay.dev) out of this frustration; you can read much more on this approach here: itunesconnect App - Revert to previous version :)