I am planning to build a prototype iOS application over the course of the next few months--let's say until October 1st--that will need frequent updates for iteration and user testing. After the application is approved for Testflight for the first time, I understand that it will be online for 90 days. I need closer to 140 days.
Firstly, what is the best way to update a build without triggering a few review? My understanding is that updates would not require a review and would take 1-2 hours to become visible, but I'm not sure what process is necessary for this, and what the limitations are. Do I need to update the version number and upload in a specific spot? How do I make sure users can download the new build? Should I delete the old one?
Secondly, how do I extend the time limit beyond the 90 days?
The answers might be related.
My question is similar to this old one, but no-one answered it.
You can make "test builds" available immediately via TestFlight for Internal Testers only.
If you're trying to get it to "outside" testers, then updates will have to go through Apple review.
From experience -- if you include enough information in the Reviewer Notes field, and you are only doing incremental changes, reviews can get done very quickly.
Note that if you are "updating" a test build with a whole new section to your app, yeah, the reviewer will likely put it through its paces.
Side note: I've also found it never hurts to begin your Reviewer Notes with something like "Hi Reviewer!! Hope you're having a great day! This is a minor update for our testers, fixing a couple layout issues, typos, etc."
For your other questions... just update the version number and archive / upload it as normal. It should automatically replace the current TestFlight version (for your testers to download).
Related
im aware this is a small question, but I cannot actually find much answers on it.
I would just like to confirm that even if i want to change just one line of code, I have to make a new archive, upload a new build, make a new submission in Itunes Connect, wait for review, then finally its live?
Or is there a quicker way to make small changes to apps?
No matter how large or small the changes are that you make to your app, you must go through the same complete set of steps to have your update pushed to the App Store.
Apple has no way to know the scope of your changes so the app must be reviewed again each time.
Your best option is to avoid such trivial changes. Fix a bunch of issues in each release or add new features. The best thing of course is to thoroughly test your app before submitting it to Apple. A few extra hours of your own testing will save you days of waiting and it will make your customers happier and it avoids wasting the efforts of the Apple review team.
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.
My first iOS app is currently at the "Waiting for Review" stage on iTunes Connect.
Now, we are working on some bug fixes and I need to upload a new build, however, I would like to release the app as soon as possible.
My question is after an app is accepted, how long approximately does it take for Apple to review a new build / version for an app ?
Also see http://appreviewtimes.com to get an idea of current waiting times, based on developers self-reporting on Twitter.
Same as always, 7 to 10 days. Except when you ask for an expedited review, but then you should have a really good reason (and a really popular app ;-).
Any time you change your binary you go back to the end of the review line. The time varies depending on how busy the review team is.
The bulk of the time seems to be in "waiting for review." The actual review process seems to be pretty quick, assuming they don't need more info from you to make their decision.
The process of getting fixes to a rejected build seems to be faster than the original review process.
I would suggest planning on an app review taking 10 days. It might take less time, but that seems to be fairly typical.
94% of all iOS app updates are reviewed within 5 business days at the moment.
You can always check https://developer.apple.com/support/app-store to get the latest info on that.
Currently an update to my iPhone application has been in review for over 10 days!!!
In that period of time I've been able to work out a few bugs and even add some small new features to my application. I know that it is possible to reject your binary, but I would rather go a head a publish my application then send apple a better version 1.1.1...
So basically my question would be if I rejected my apps binary and submitted one right after would my app get pushed to the bottom of the review pile or would I keep my spot in line (since I've already been waiting for 10 days)?
No, rejecting a binary and immediately resubmitting a new one will not maintain your place in line: you would be knocked back to the start of the queue. I base this on my own experience, having rejected and resubmitted binaries a few times in the past.
Now, you might be thinking: "OK, what about the expedited review process?"
I can share some experience with that: With my latest app, I was in the same position you were in but I decided to go ahead and release 1.0 and then submit 1.0.1 soon afterwards. When 1.0 was approved and released, Apple chose it for the "New & Noteworthy" section. All of a sudden the app was getting a lot of exposure—and complaints about a bug that I had fixed in 1.0.1. I submitted 1.0.1—and as well as a request for expedited review—which was approved. 1.0.1 was released about 24 hours later.
So, you'll have to weigh the pros and cons for your own app, but I hope this info helps. :)
Yes it would, rejecting and resubmitting the binary will place you at the bottom of the review queue. It's unfortunate, but there is no work around.
If Apple allowed that then many devs would start uploading their beta version while trying to fix those last few bugs.
I had the same issue. I had submitted my app and it was in review. I was asked to change some metadata and resubmit the app. While doing that, I discovered a UI issue and fixed it. I was in a dilemma as to keep the current binary and release a version 1.01 or upload the new version. I did not want to send my first app with an issue so, I went ahead and rejected the binary and uploaded the new one. I immediately contacted Apple developer technical support. They claim that "The review time will not be affected and that our internal systems do have process your build before it can be reviewed (verifying it’s general correctness and resigning your app for the store), which can add some delay. However, that delay is fairly small and is only a minor factor in review time. More to that point, any delay here is much smaller than the delay of a new submission." I hope that is true and hope my app is not stuck in the "waiting for review or in review" limbo :(.
What are some things and techniques I can do to minimize the time it takes for my apps/updates to be approved for the App Store? Do smaller updates generally take less time, and do paid applications take longer than free ones? What about the size of the binary?
In my experience, everything takes exactly the same amount of time. You sit in the queue for 6 days, then they review it for an hour or so (much less for updates), and you're either in, or rejected. If you are rejected, it will take a few more days to work through whatever the issue was.
So the only way to take less time, is don't be rejected. :) Seriously, though, go read the developer agreement and the "do this and we'll reject you" document.
They aren't even looking at your app for that 6 day "cooling off" period, so I can't imagine what you could do to make it go faster. (Although I've heard that there is a mechanism for expedited updates in emergencies; but I have no first-hand experience with that).
I cannot post a comment yet, so I am posting this as an answer to your question based on my experience submitting new apps, as well as updates to existing apps in iTunesConnect.
Unfortunately there really isn't anything you can do to speed up the process, aside from fixing the issues in your app if it gets rejected, and re-submitting asap.
Apple allows you to request an expedited app review.
https://developer.apple.com/contact/app-store/?topic=expedite
Please note: If you're facing extenuating circumstances, you can request the review of your app to be expedited by completing the form below. Expedited reviews are granted on a limited basis and we cannot guarantee that every request will be approved.
I have personally used it twice. Once for a cosmetic issue in an app, which was rejected. Another time for a critical bug fix, which was accepted. I wrote a very detailed explanation of what my application did, what the bug was, why the bug was important to our (Mine and Apple's) customer.
One thing I have found is that free apps versus paid apps sometimes take different amounts of time.
For example I have a paid and free version of the same app. I submitted an updated for both one right after the other. First I submitted the free version, then I submitted the paid version immediately after. For some reason the paid version went into review, and was approved a day later, where as the free version is still waiting for review even know I submitted it first. I suspect that free and paid apps have different 'queues' or 'priorities' over at apple.
You can request an expedited review in emergencies. I used it once and the update was available about one or two days later.
However, they say, the expedited review will only be granted in limited cases. So I wouldn't use it if not absolutely necessary.
You can request the expedited review in iTunes Connect. I think the option was on the detail page for an app which is 'Waiting for Review'. There was also a list, in which cases an expedited review can be granted.
App approval times will vary depending more on what else is going on, and can otherwise vary for no obviously predictable reason. I've seen a small update to a simple app take longer to approve than a new large app with lots of features.
Maximum app review times seem to be around the days that lots of other developers are submitting apps, near some major holidays, shopping seasons, or when Apple has just released some OS update, app service or new device. Shorter wait times can sometimes be had by avoiding these longer review time periods. There are services that track the number of new apps introduced per week. Look for the nulls.
Staying well away from any hint of violating any of Apple's App store rules or guidelines, or anything else that can be seen as controversial, also helps not getting hit by a long (additional time required) review time. Other factors seem to make less difference.
Take a look Apple review support
Once you've submitted your app for review, you can view its status in the My Apps section of iTunes Connect or on the iTunes Connect App for iPhone and iPad. Review times may vary by app. On average, 50% of apps are reviewed in 24 hours and over 90% are reviewed in 48 hours. If your submission is incomplete, review times may be further delayed or your app may be rejected. Once your app has been reviewed, its status will be updated and you will be notified.
I tried to use the expedited review for an app for a skistation, so it would be available before the winter season started and it was declined.
You need obviously a very good reason like a big security issue etc to get a expedited review.
Step 1:
Related to your project, note what is the third party libraries are involved and make a note what makes it rejected in apple store.
Step 2:
Make your code stable and keeping in mind about rejection points which you cant keep
(i mean like really stable no warnings, no chance with wrong icons, no chance with mistakes).
Step 3:
Finally, then decide to send for review
That will at-least speed up your process. once you get rejected then its a bad, you have to really wait longer. (from experience saying)