We have an iOS app available on the App Store.
We want to release an update of the app but we want the release to happen in a phase wise manner i.e. the updated app should be available to only 10% of the users initially. After some time, say 1 week, it should get available to 20% more users and so on.
I was told this is possible on Android.
Can it be done for iOS apps as well? I tried to search (including this link as well) but could not get concrete answers.
Thanks in advance!
Unfortunately, we cannot do this in AppStore. If you want to do A/B testing(https://en.wikipedia.org/wiki/A/B_testing), then there are several tools in market to assist you with that. If you want to do beta testing, then TestFlight is the one to go for.
https://itunespartner.apple.com/en/apps/videos#testflight-beta-testing
You can use TestFlight where you send you test subjects the app to their email, and then they open your app with the apple TestFlight app. The limit is 2,000 people I think.
Currently this is possible for both iOS and Android
Apple phased release
If you choose this option, your version update will be released over a 7-day period to a percentage of your users (selected at random by their Apple ID) on iOS with automatic updates turned on. Users are not notified that that they are in a phased release of your app.
Android staged rollouts
You can release an app update to production using a staged rollout. With a staged rollout, your update reaches only a percentage of your users, which you can increase over time.
For (beta) testing there are different options. You could create specific groups within TestFlight and rollout to them or share your app over DIAWI with the people you want to reach. For production - let's say AppStore - it's not possible to do a partial rollout or update cycle.
Related
I've just published an app on Apple's store and I'm wondering about having multiple versions of the same app for testing on TestFlight. Of course dev doesn't stop when publishing... from now on I'll have to update the app store version (v1.0.0) with bug fixes (v1.0.1, v1.0.2, ...) and before doing so I'd like to check them in test flight to ensure the fix was appropriate.
My problem is that I'm already starting to develop the next version with further functionalities of the app which will become v1.1
So ideally I'd like to have my app available both for my bug fixes, for instance v1.0.2 and also my next version v1.1.0 (this will include all bug fixes made to the store version and also many new features, refactors, redesign, etc)
I know that if I build and upload to the apple store connect a build with v1.1.0 (next version) I won't be able to upload one for a built with a bug fix on the current app store version (v1.0.2) since this version would be lower than the one I uploaded (next version)
Is there a way to accomplish this? I've read this article https://savvyapps.com/blog/using-testflight-to-distribute-multiple-versions-ios-app which solution is to create extra applications in iTunes with different app ids and bind them to different certificates. But what will happen when the next release is ready to be in the store? I would have to release it and then disable the previous one? How may this affect my users? Will they have to re-install a new app rather than updating it?
I really need to start testing and checking the next release of my app in TestFlight and also support the current one with updates if something pops up. Thanks in advance!
I am able to upload multiple versions of the app to TestFlight. Each upload requires a higher version/build number, but you can switch the TestFlight test version between them as need be for testing.
Once I submit a particular build for release, however, I seem to lose the TestFlight access to the old builds.
In short, you can have many builds available in TestFlight, but once you submit the app for release, you have to start over making builds for TestFlight.
You keep talking about numbers like v1.0.1. That looks like a public-facing version string, with a major, minor, and patch number.
But that is not what TestFlight cares about. Well, it cares to some extent. But all TestFlight really cares about is that every new build you upload has a new build number. This is just an integer which you simply increment every time you submit a new build.
So you could have v1.0.1(23) on the App Store, and then on TestFlight you could upload v1.0.2(24) which starts moving forward toward version 1.0.2, but also upload v1.0.2(25) which is actually an attempt at a prospective version 1.1. TestFlight doesn't know or care what these different builds signify. They can all exist simultaneously on TestFlight. Keeping them all straight and on their individual trajectories is up to you.
Our Daily New User-count from Fabric is consistently bigger than the App Units per day that we get from iTunes Connect.
Fabric defines Daily New Users as
The number of new app installations across all devices seen on a given
day.
And iTunes connect defines App Units as
The number of first-time app downloads made on the App Store using iOS
8 or tvOS 9, or later. App updates, downloads from the same Apple ID
onto other devices, and redownloads to the same device are not
counted. Family Sharing downloads are included for free apps, but not
for paid apps.
What can cause this discrepancy? I can see many reasons for how Fabric could report a lower number (such as users downloading the app but never opening it, or waiting too long to open it), but not the other way around. Our average send-usage-to-developers opt-in rate is 23%, but that does not affect the App Units number if I am not mistaken.
Is your app available on both iPhone and iPad? If so, then the fact that, as you point out, Apple doesn't count downloads from the same Apple ID onto other devices might be causing this discrepancy? You can install iPhone apps on your iPad even if it's not officially supported, so the rule might still be affecting your app. Also, if your app is a paid app, then the Family sharing rules would also affect the numbers. I've actually wondered how iTunes counts new users, so thanks for that info!
I'm not sure why the numbers are consistently bigger for you on Fabric, because for my app they alternate a bit.
I hope you might have got the answer. If not follow the link below http://help.apple.com/itc/appanalytics/#/itc7bea1545f
It seems there are users who don't opt-in app analytics data.
Apple only shows data from users who have agreed to share their
diagnostics and usage information with app developers.
I need to run a beta test for an iOS 8 app through Apple TestFlight. Is it allowed to upload 2 versions of a beta app for an A/B test? (I would like to switch the app icon and some other things to check what works better for the users.)
Notes on bounty:
Especially interested if there are any experiences with submitting two
similar builds for external testing, as builds have to go through the
(albeit lighter) review process.
I would presume it would be OK, as one can submit freeform notes for
the reviewers and explain the situation—AND because, in any case,
externally tested apps have to go through the normal App Store review
process before going live; so acceptance in external testing wouldn’t
be a free ticket to App Store.
But these are just my assumptions and hence the bounty. Has someone
done this? With negative or positive results? Or both—review processes
are notoriously independent and, at times, arbitrary.
I’m not interested in interpretations of review
guidelines,
but how they are executed in practice.
Or should this all be handled inside the app with some A/B testing
framework? (Which is unfortunately more work than just creating two
bundle IDs… And this wouldn’t help in testing the app icon)
In order to have 2 active builds in test you need 2 apps (different bundle ids), the only choice you have is either through the same account or different accounts. It's easier to handle in the same account, less context switching for management.
We did both successfully without any issue raised from Apple. We did not put any special mentions in the review notes either.
Eventually you end up with more dead projects in your account but its only an issue for you, Apple wont complain.
Why tough
A/B testing can be done in the same build except for some things like you mentioned (app icon). Usually this is handled through surveys tough.
The only advantage of having 2 apps is that all users can test both versions in your A/B test mitigated by their willigness to spend time testing both.
Disadvantages that jumps to mind:
sooner or later you will kill one of those version, potentially loosing some of your beta testers that chose only that version. Mitigated by the fact that you may not need beta testers after you release your appstore version
you wont be able to control who has which version to insure proper distribution and move users from one to the other unless you are ready for lots of hands on communicating with your beta testers.
I have not been able to have multiple versions in TestFlight. If I were to do this I would use a separate provisioning file and iTunes Connect account. There are a few steps to change the provisioning account and the app name so it is unique, but I think that is the only way to get around it. However to use external testers (since internal testers are limited to 25) you will have to go through the review process. Apple might object to having to review the same app twice if they caught it. I would advise rereading the Terms and Conditions, remembering you are submitting for Beta App Review.
As of April 11, 2017, Testflight allows you to you can distribute and test multiple builds at the same time.
https://developer.apple.com/news/?id=04112017a
You can upload multiple builds but you can test only ONE at a time and there is no way to do what you want unless you make a new unique app identifier and upload the same app on the new app identifier APP.
It is possible to upload more than one builds of same version!!! Just change the build number. Example, 'version 1.0, build 1.0', 'version 1.0, build 1.1'. You can see different builds in Test Flight.
I am publishing my first iOS app to the App Store. However, the company that hired us wants to see the app work before we publish. Is there a way under the $99 developers plan to allow them to see the app work on a real iPhone?
For completeness there is another way. Although I've used TestFlight very happily for years, it can prove to be too complicated for some testers!
If your app has been approved by Apple (but you've set release date in the future), you can give people promo codes (which you can get from iTunesConnect) and they can download the unreleased app. This is great for getting your app to reviewers.
From iOS Developer Library:
Promo codes apply to a specific app version, so when users redeem
promo codes for a version of an app that hasn't been released yet,
they download the prerelease version.
https://developer.apple.com/library/ios/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/ProvidingPromoCodes.html
Obviously in your case, you probably want to get your client's approval before even submitting to Apple, therefore #Anil's answer is better for you.
This is possible through multiple platforms.
iOS 8
As mentioned above, refer to the following link:
http://blog.thebetafamily.com/2014/09/10/testflight-beta-testing-ios-8/
iOS 7 and below
Test Flight - https://www.testflightapp.com (Acquired by Apple and available on iOS8 as described above)
Hockey App - http://hockeyapp.net
Test Flight is free and simple to use. All you need to do is upload the certificate and it'll take care of the rest. Test Flight used to support other OS like Android. But after the acquisition, I think it only supports iOS.
Hockey App is also simple. But only supports certain numbers of builds or projects for the free version. Hockey App provides direct update during the app launch if a new build has been uploaded.
I would like to put a free version of my ios app on appstore. This is a data driven app that remembers events on certain past dates. Can I limit the time of past event to ,lets say, 2 weeks? And if the client want to see the events added more than two weeks ago, he has to upgrade to full (for a fee) ? Is this possible, or will the app be rejected by the apple review process?
You'll probably be able to get away with this. You'll likely want to use an In-App Purchase mechanism to unlock archived events as opposed to having separate free and paid versions of the apps on the app store.