Last I checked the average review time for app submission is about 3 days (from ) http://appreviewtimes.com/ TL;DR (because you need to get back to that YC/500 application) 4 Changes to the submit script and process than can save at least a day of the developer’s time Add sanity checks eg. nm check for symbols,functions the app is not allowed to use Check for DOA builds, basically the app crashes on start Streamline the two step submission (1) from xcode and then (2) from itunesconnect Remove the build version restriction which forces one to update the build version every time you submit, even within the same “submit cycle” average review time for app submission is about 3 days (from ) http://appreviewtimes.com/ On face value, this is great. Our app has been in review for 3 weeks at one time. So a lot of credit goes to the review time. They have staffed up and they have servered up (got more machines). The averages used to hover at 8 days for the last couple of years. So you would think 3 days is great right? Not if you are the who has to push the code and wait for all the green. If this was the only thing you were doing, great! Time to go for a quick trip to Hawaii right? But that’s usually not the case. Your “ ” team has 10 experiments lined up that need to be done yesterday. Your bug triage is basically becoming a carnage of broken promised and unfulfilled wishes. And that doesn’t even come close to how your personal life is faring. developer growth hacking A real story So here we are, we submitted the latest version of our . Lots of cool features and more importantly a critical bug were in the mix. We submit Tuesday evening. Come Thu morning(around 7AM Pacific), the app is in review. yay!! After about 3 hours, we get this message on the dashboard. The app has been rejected because of “Performance” reasons (They probably should reword this a bit considering lots of iOS developers are guys with bruised self images). yogatailor app Turns out we are using an API called setCompletionDelegate. A quick check in our code — nope, we don’t use this function. We then looked at all the libraries. Everything was great. And then we finally looked at the Pods and voila, good old Branch API was using this function. A quick chat with the good folks of Branch.io , turns out we were 3 versions behind! After a brief wrestle with “pod update” and “pod install” and “pod unistall” and “pod wtf”, we got everything updated with Branch. So we run QA, archive, submit and…. Waiting for the Sun You see the timestamp there? It says upload date Sep 16, 2016 11:56 AM. Guess what time it was we were looking at it? It was 2pm (all times pacific). A good 2 hrs after we submitted. So finally around 2:30 pm, the build is available to be submitted. We click through all the screens where they ask you about export stuff. Minor thing here, but why can’t these be pre-filled with previous settings? Anyway, a few hrs later, rejected! yet again. This time it was because the app had a missing asset for iphone 4 and was crashing. I mean, this is our bad. But who supports iphone 4 anymore? Granted we didn’t update our QA scripts for iphone 4 in 6 months. But still, come on! We are a tinu, puny startup with super limited resources. Where do we go from here Here are a few things that I think can help expedite the app submission,review process. Feel free to add to this list either by highlighting and commenting right here or adding to the comments at the bottom. Maybe we can send a compiled list to Apple and they always listen to developers. Have the submission script run a few checks on the build, simple “nm” check on functions,symbols that are offlimit would be great Right now, the app submission is broken into two parts. We submit from xcode. we then wait for a hr or two for the build to “process”. And then you go to itunesconnect, select this build and then submit. Why not remove the step. Basically it is one submission and it goes through by default. If the developer thinks something is amiss, she can go interrupt the process. Check for DOA submissions right away. I thought this happened. Apparently not What’s with the annoying “feature” where itunesconnect rejects the build because the version has not been updated. The developer has already upped the build version on itunes. Now , the developer has to up the version within the build every time they archive and submit. How much time do you guys/gals waste because you submitted something, realized you missed something simple, made the fix, archived it and then it gets rejected because itunesconnect wants the buildversion to upped too. I find it annoying. I should really be spending this time on the YCombinator application. Maybe I am using this as an escape from another onerous process. Maybe I am doing this because Apple cares.
