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.
Related
I have a Flutter developed App that I want to upload for App Store Review.
The App has been successfully uploaded through Xcode as you can see here— https://prntscr.com/26m7w94
Sadly, the Build doesn’t appear in my App Connect Build section as you can see here— https://prnt.sc/26no755
When I try to re-upload, it let’s me know that the Build is already uploaded to App Store Connect as you can see here— https://prnt.sc/26no84v
I have written to Apple and I don’t understand the answers they are giving me. They are just talking off-point.
Now I have waited for 8 days for this build to appear, but this uploaded build is not appearing.
Without this Build appearing, I cannot Submit to App Store Review.
Everything in the App Store Connect Form has been completely filled. Only Build remains to be added as you can see here— https://prntscr.com/26no94s
I can’t figure out what to do next, and this is 8(eight) wasted days gone by, with me not knowing what next to do.
Has anyone here faced this kind of problem before? How did you solve it?
Regards
Check in the TestFlight section. There might be a yellow triangle next to your build. You may need to answer some additional questions such as encryption usage etc. Just click on the triangle to answer and your build should be available afterwards.
Sometimes the answer to this issue is that there is actually a problem with App Store Connect (like right now).
You can check for issues on the Apple Developer System Status page.
For me changing the version from X.X.X to X.X.X+1 (2.2.2 -> 2.2.3) fixed the issue.
Sometimes it happens and I have also faced this problem .I successfully uploaded my bundle from Xcode but not found in connect.
I waited 30 minutes and refreshed .Then my bundle came in App Store connect.
Solution 1 : wait for some time & Refresh ,
Solution 2 : Create another Bundle and push to connect using Transporter (You can download transporter from appStore)
If the build doesn't show up on App Store Connect. You may want to check your email (the one you used as your Apple Id when uploading the build).
In my case Apple sent me an automatic email telling me that my build had some issues. Xcode didn't complain about anything and neither App Store Connect.
UPDATE: This might have boiled down to timing. After changing the version number to 1.0.0, that build showed up immediately. Half an hour later, the 0.0.1 build appeared out of the blue as well.
If you've set your version number to 0.0.1+X because you thought that makes sense while the app is still under development, change that back to 1.0.0+X. The upload will succeed, but app store connect won't list the build without a leading "1." in the version number.
Make sure no webviews are used in your app. It will not show builds in App Store Connect and neither XCode nor Apple will say that anything is wrong.
This may sound paradoxical. My goal is to find a tool which automates the process of logging in to App Store Connect, and click the Make App Available button. This is because my team has an internal process of releasing changes to our products. There are a lot of things to do but we also have tools to automate all of those. So I'm looking for something to append to our release automation tools so the whole release process is completely automated.
Problem statement
Because we need to have full control over the release time. Sometimes, in a company environment, after all the testing is done, we want to release the app, and start monitoring usage on that day. On Google Play, this is not a problem. We can expect an app we submit for release to go live shortly after the submission. But on App Store Connect, with the current submit for review process, we have no control over the review time.
Using Fastlane, setting the automatic_release flag to true, it would mean the app could go live at weekends. If a problem occurred with that new version, no ones would be on hand to quickly fix the issue.
Or the other option, setting the auto_release date, we could still run into the same problem if the review process took longer than the defined release date.
Is there a way to submit for review with the "Manually release this version" option, then, after the approval, have some tools/apis that would log in to App Store Connect and press the Make App Available for us?
You can list all available Fastlane actions on GitHub.
If you can't find a predefined action for your need, it's worth to check Fastlane Spaceship module for low level API calls:
spaceship exposes both the Apple Developer Center and the App Store Connect API. It’s super fast, well tested and supports all of the operations you can do via the browser. It powers parts of fastlane, and can be leveraged for more advanced fastlane features.
While searching in the Spaceship source code I found that app releasing is already added:
for phased release use: release
for immediate release to all user, use: release_to_all_users
I don't have a chance to test this, but the following snippet might help to start if you're not familiar with Spaceship. Put this in Fastfile then call it from where you need:
lane :release_app do
require "spaceship"
Spaceship::Tunes.login('email#example.com')
app = Spaceship::Application.find('com.example.app')
app.release_to_all_users
end
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.
Over the past two years, we've had around 3-400 beta testers. After Apples update to TestFlight the summer of 2017, we've had problems with nearly all our TestFlight-uploads. Sometimes our beta testers receive email/notification about "a new build is ready to test" 90 days too late, at the exact time the build expires, and sometimes they don't receive notification at all. Just a handful of times it works as expected, that they get notified when we the build is available to test.
Is there a secret trick to managing TestFlight?
I upload the build, click "provide export compliance"-thing, add my internal and external group, and click "Start testing". The build automatically gets available for internal testing, and is sent to beta-review for Apple for external testing. They approve it within 24h, and the build is available in the TestFlight-app for all our beta-testers. But none of them got a notification saying there's a new build..
Followup: How can we fix this now? Do we have to upload a completely new build, or can I remove the "external testers"-group from the build and re-add them again. Will they receive a "new build available"-notifications?
Will they also receive "Build is no longer available for testing" at the moment I remove the external group from the currently active new build? Meh..
Ok. It baffles me how extremely bad Apples dev-websites and services are.
So, in my newly uploaded build, there are two "groups". One called "iTunes Connect Users", which are the internal users who are invited to the developer team. They got an email and a notification immediately when I clicked "Start Testing", because a review is not needed for internal testing.
The other group is called "External testers". The build is available for them, but they didn't get notified when the build was approved by Apple.
I was considering removing the "External testers"-group from the build, hoping for a notification when re-adding the group. But, I also thought the group might first receive "This build is no longer available for testing" or something if I removed the group from the build.
I figured I wanted to test this first, to see if testers receive a notification when I remove their group from a build, so I created a new group (called "ExternalTest"), added one single (new)test-member, and added this new group to the same active build, so that there are three groups under that build.
At the very moment I clicked "add group to build", all of our test-devices here, and apparently every single beta-tester, received a push notification from TestFlight, saying that the new build is available to test. Now, our "installed"-number is skyrocketing, as people are updating.
What the hell, Apple?
I agree with you, #Nitish, TestFlight sucks badly.
Having the exact same problem - a build was approved for external testing by Apple yesterday, but no one received a notification. I created a new group now, added my private email to it, and then added the group to the build. Swoosh! All out test devices received the push notification about the new build. Thumb down emote from me, Apple.
I myself have encountered the same problem. My client who is added as a Beta Tester receives a notification when a build is uploaded. (Never reached a state where he would need a notification where build has expired after 90 days). However, his further client is also added as a Beta tester. But doesn't receive notifications.
This is where I would like to say keenly, TestFlight sucks badly. I would suggest, the best way to track this is to check the status of Build installed or not. Usually Apple reviews the Beta build within 24 hours. At that time, make sure to check the above mentioned status. Re-invite the tester if it still doesn't work.
That's the lame way to get along this, unfortunately.
Otherwise, I would suggest going for other libraries such as Hockey or Diawi.
This is the best I can offer :)
I had a go round with the TestFlight crew a while ago about how bad their interface was. I wanted them to have a simple list that you filled out and a Save button so that you didn't have to do it all at once. Then there should be another button, Send To Testers, that you touched when done. Simple, no? Nah, they rejected my suggestion. I pointed out that when you submit an app to iTunes that's exactly how you do it. Nope, we're doing it this stupid way.
The best I can figure out is that you should walk down the left hand list in the TestFlight section one at a time starting with Builds/iOS . When you reach the bottom and fill out App Information/Test Information hitting Save sends out the invitation. Maybe...
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.