Does Apple allows any category of iOS application (i.e games or any type) to force users for new version update, without update later or cancel button (if user don't want to do or intend to do it later)
Apple used to reject applications on such scenarios, Please correct me if I am wrong.
An application which currenly forced me to update is as follows:
https://itunes.apple.com/us/app/farmville-2-country-escape/id824318267?mt=8
Please find screenshot attached.
After new version release whenever I open this application, it has only one button which says "Upgrade Now".
I am unable to use until I click upgrade button.
I am wondering is it mistake on Apple review process or is it really
allowed to do now?
This process never really went through the apple verification process.
The logic for this probably is...
-) On launch check for update
-) If a update exists, show prompt and lock the application
If the application was being reviewed, then the reviewer never saw such scenario. I am pretty sure if the reviewer saw such locking mechanism, they would simply reject the application. Either way if you really want to force a user to a specific version, this seems to be the best way forward.
Related
I want all users off my app to stay above a minimum threshold version. Is there a way I can configure it either in the code or app store that invalidates the users on a certain version and redirects them to the app store?
I assume you have already an application that in the production and installed to devices.
In this case, unfortunately you can't put version limit on them. The only way is, deprecating v1 APIs and creating v2 APIs. The older version app owners will get a warning (If you well made the error handling.).
Otherwise, you can add a new feature like checking the version on the startup of the application. And If it is older, you can show a message like "Please update the application." and put a button that redirects to the AppStore.
(The image is from a Medium blog post named "Mandatory Update for your apps".
I don't recommend forcibly redirecting users to AppStore. It is not a great UX practice. You can block the screen of the application with the warning but at least leave the basic functionalities open.
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.
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.
My iPhone app has now entered into a beta phase. I am using TestFlight to send the app to the testers. Everything works great, I publish the link, they download the app, no problem with any certificate or anything (true story, lol).
My only problem is I have absolutely no idea on how to send in-app updates. I saw on the latest SDK version that it's available, but I can't figure out how to do it ! Right now, if I upload a new build, and select "update & notify", an email is sent. How can I send a notification to the users, directly through my app, that a new version is available ? Right now I'm starting to think that this is not possible (if so, my bad). But I really thought I could do it !
As always, any help/link/doc is always appreciated ! :)
You can force an upgrade.
Go into settings in the upper right corner and select the "gear" then choose "Area 51" (this is the new features area, still beta). From there you can select to turn on "Forced Upgrades":
If you enable force upgrades on a build. The next time users open your build and there is an update available they will be forced to install the build before continuing.
You need to have different Bundle versions when uploading your app. You can set your bundle version in your apps info.plist under Bundle version. change that value to something else and you will be prompted now you open the app to upgrade or skip.
So far, my users where notified in the app without me having to do anything but call takeOff and (well here i'm not sure if this was necessary) use a few arbitrary checkpoints. They could choose wether or not they want to update their app now, later or never.
BUT apparently this has stopped working over the past few weeks, I'm receiving more and more feedback that the only way they got to know that there is an update available was through the email that is sent to them by testflight.
Is there a way to remvoe TestFlight apps from users that have installed them? Also is there a way that TestFlight can bake into the app some sort of password that the users all have to log in with (in case of a lost phone, we don't want our developement apps exposed).
If left untouched, the provisioning of your apps will eventually expire automatically. Even without the native ability to remove applications with TestFlight there is still something of an expiration date on the application.
That would still leave your question of a "baked in password prompt" and removing the application itself physically from the device.
The first part, the app checking for authentication could be solved by implementing a solution with a more robust SDK that happens to have that sort of security-minded approach. As far as I know, and based on TestFLight's feature grid, this exceeds the abilities of their tool.
The second part, removing the application itself from the device, would be accomplished by using a tool that has the ability to use MDM (Mobile Device Management) for device-level control. Specifically you'd want to look for something that can selectively control a single application, rather than having to apply a blanket MDM policy. Again based on knowledge of TestFlight and based on their web page this is also not something TestFlight is capable of.
There are solutions out there that will give you exactly what you are asking about - easy beta testing with the added ability to force the app to check in and re-authenticate as well as the ability to remove applications from the device when you're done testing. If you hit your search engine of choice you can find a few tools that will give you a "yes" to all of your questions here. The list is very short so they're easy to find. :)
If it is at all helpful to you, I am associated with one of those companies, AppBlade, and would be happy to answer questions about this sort of thing. We're at https://AppBlade.com and you're welcome to give us a call or even log into the tool to see how it works for yourself.
Unfortunately you can't delete apps that are already installed on the device via TestFlight, unless you do it on the device itself. As for the password, TestFlight doesn't exactly support that either. You could however put a passcode lock feature in all of the Beta versions of your apps through your code. Sorry thats probably not the answers that you wanted to hear, but TestFlight is still in its early stages.
You are not able to delete apps from a users device, however TestFlight is testing in their 'Area51' an option to force users to update to a new build if there is one available.
If you no longer want testers to access your app you probably could add a new build which justs shows some info screen.
There is a way to expire the builds in the app store connect when you click on build.
Another way if you want to get rid of it as a tested to open the app page and click on stop testing.