Pardon all the italic shouting. Just trying to emphasize key points. Please note that the existing post iOS app submission and beta review process does not answer this question.
The following sequence of events does happen and it's what I expect:
Create a new version (number) of app in iTC
Archive and upload app to iTC
Internal testers get notified to download with TestFlight
Submit for Beta Approval (critical for next step)
Now all testers (inside & out) get notified to download
But next:
Create a new build (number) in Xcode
Archive and upload to iTC
Only internal testers are notified. ⬅︎ unexpected
Do I need Beta Approval every time I want the external testers notified? I could swear this has not been the case. But of course things may have changed. Or it's just my bad memory.
Do I need Beta Approval every time I want the external testers notified?
NO
I could swear this has not been the case. But of course things may have changed. Or it's just my bad memory.
It's just that:
1) there's a short delay (5-20 minutes) before you can send to external testers
2) from time to time Apple's servers are screwed, and the 5-20 minute delay becomes "many hours".
Change the version number - you have to wait for a (presumably human) approval: takes 1-2 days
Change the build number - only a short delay for a (presumably) automatic check.
And don't forget you have to manually release to the external testers each time!
You need to approve first build of every new version.As Apple mentioned" A review is only required for the first build of a version. Subsequent builds may not need a full review.."https://help.apple.com/itunes-connect/developer/#/dev3bfa33892
Beta review is only required for the first build and the first build send in after a 90 day period.
Related
I am experiencing a strange issue.
New app version was released to appstore, containing new variable stored in user defaults and some minor updates. technically, we are creating new variable, which is an array of values in user defaults, and appending some items in the array. For append, we are using values which were already in place in the previous version (e.g. user_id, device_id and one more string parameter, all 3 were received from backend on 1st registration).
It was (obviously) tested before release. Testing strategy:
A. We were building adhoc old version (say #1) and new version (say #2), installing v1 on the devices and updating it to v2 (by simply downloading new adhoc v2 and installing it on top of v1).
Then, we published v2 to appstore, and issued one more test:
B. We were building same adhoc old version (say #1) installing v1 on the devices and updating it from the appstore, by
B.1 in-app update functionality - following the link to appstore and
B.2 just downloading most recent version from appstore.
Both were fine and both are still fine. Works perfectly.
Now, users are reporting old appstore-installed v.1, updated from appstore to v.2, is crashing after update (almost immediately when it is started).
Only difference we can observe is that when tested, appstore version was installed over adhoc, and now it is appstore over appstore.
Was anybody ever facing the same issue? What is the difference in update process "adhoc -> appstore" versus "appstore -> appstore"? Could it be related to the fact that appstore update is cleaning up all the info from user defaults and thus we need to repeat the application reg process (get all the data again like in the first clean install)?
I still have no crash reports in hand, so I am asking for some advices which can help me to solve the issue faster.
Thanks everyone in advance!
...looks like the issue is linked to GoogleUtilities: we have v7.2 in our current build, however previous build was of v7.4, and - as I found out recently, there is an issue related. TWIMC see https://github.com/google/GoogleUtilities/pull/37 for details.
It is still TBC now, we'll be checking in the next 1-2 days, and I will post some updates here. If indeed related to library version, then it has nothing to do with the app distribution (whatever if it is adhoc or appstore based).
I need to know if I have to wait for another review proccess after I already did it and my app is now in Pending Developer Release.
The point is I need to keep it in [PDRelease] mode until my testers say everything is ok, publish it.
But it has no sense if the app is approved and waiting "manual release" and then I need to resend it to another review or better called: "Beta testing review".
Thanks!
As far as I know that is correct, they are two separate workflows... If you had submitted the build to be approved for public beta testing and submitted it to the store at the same time you would be in a different place. Whether or not behind the scene it checks the work flow value to see if its pending release and short circuits the review is completely opaque as far as I know.
I don't know if this began commensurate with the release of iOS 9 or Xcode 7.1, but for the past week or so, my app updates (which I am beta testing through TestFlight) that I upload to iTunesConnect are not being automatically pushed out to my test team. Anyone seen this as well?
Update 1: I don't know if it is coincidental, but when (and only when) I go to iTunesConnect, select the app I am testing, then select the TestFlight tab, does the update get pushed...huh?
Just wanted to chime in and say that this is also occurring with some of my applications. We had one application test build not go out for 2 days because we didn't try to login to iTunes Connect.
Not entirely sure what is going on at Apples end, but it's definitely a weird bug...
The Apple servers have been slow the past couple days effecting many different areas such as submitting apps, etc.
Lets say I have a build uploaded to iTunes Connect that has had a status of "Waiting for Review" for 10 days. If I submit a new build will my app go to the back of the line and have to wait another 10+ days or will I still be in line to get reviewed very soon?
Yes, after you Reject Binary then upload a new one, this puts your app to the back of the line again.
Edit: see this answer, this answer, the later answer on this question and Apple's own dev guide.
Removing a build removes your app version from Apple’s review queue and changes its status to Developer Rejected. When you resubmit your app, the review process starts over from the beginning.
I've also experienced it myself, although that was years ago.
If you reject your binary, you will remove your app from the Review queue. If you then submit a new build, you will unfortunately be placed at the end of the line.
We know this from experience, and it's also indicated by Apple (emphasis mine):
Removing a build removes your app version from Apple’s review queue and changes its status to Developer Rejected. When you resubmit your app, the review process starts over from the beginning.
The new iTunes Connect distinguishes between the internal testers (maximum of 25) and external testers (maximum of 1000).
At various points they say that newly uploaded builds are automatically distributed to internal testers via the test flight app, and this has usually been my experience. But sometimes I see a menu like this, indicating that I need to select "Invite Testers" in order for it to be visible to internal testers:
What causes this?
When it does this, I cannot distribute my build to my internal testers, and it seems like iTunes Connect is failing to recognize that my project already has internal testers.
We've been experiencing this too. A hack that works for us sometimes is turn the TestFlight Beta Testing switch off, then wait for that to take effect, then turn it back on, and it usually pushes the latest out to the internal testers.
Turning the "Test Flight Beta Testing" switch off and back on will indeed change the "Internal" column to Active. As #will suggests. The problem is that if you are already approved for External delivery, this will also cause the external testers to go back to the Submit For Beta App Review again, so use this work-around with care.