Last week was kind of crazy. Apple announced the public release of iOS14 on the day before, triggering a major Twitter-meltdown among developers. Thanks to the quick response of our team, just under 20 hours later we were able to release the new Xcode 12 stack on Bitrise.
Now that the dust has settled, we have the time to do a short recap and talk about what happened last week and how our team handled all that. We figured we would approach this by setting a scale.
1- cute and positive, avoiding the topic of how crazy that release was
10 - instead of a turkey, serving a roast Apple on Thanksgiving this year
In the end, we decided to go with a solid 5 — an interview with three members of our response team, Product Manager Botond Csomortani, and Software Engineers Laszlo Meszaros and Sandor Feher.
— To quickly recap, why did the announcement cause such an upstir in the development community?
Botond Csomortani (BC): To submit an iOS 14 app to the App Store, you need to build it on an Xcode 12 Golden Master (GM) which is usually released 1-2 weeks prior to the iOS update. App developers usually take this opportunity to prepare their apps to ship with the new functionalities on release day, and potentially leverage the free press that comes with being an early-adopter. Somehow, Apple forgot to be charitable to their developer community this time, releasing iOS 14 along with the new Xcode stack that is required to even start building. The Xcode beta was available for some time now, but apps built on that stack can’t be submitted to the App Store either — even the most prepared developers were left scrambling to update and push their apps to reviews.
Even Nintendo had to warn Pocket Camp users to wait with the update. Yes, that Nintendo — they needed around 48 hours to release a fixed version of the app.
— So, what did you do (besides freaking out)?
BC: We were watching the live event with the team, waiting for the new Xcode version during the announcement. We started the download in our datacenters immediately — we have an automated pipeline for this process up until the automated tests, which runs without any issues on better days. We weren’t so lucky this time as there were two available Xcode build versions.
Sándor Fehér (SF): The majority of our team is located in Budapest, which means that Apple updates are released when we are off the clock, usually at night. One of our main team objectives is shipping these updates to our users as soon as possible, so we started the Xcode update immediately.
Disclaimer: Not our words.
— How did it go?
Laszlo Meszaros (LM): The biggest issue we (and everyone else) faced was that at first Apple distributed a wrong version of the GM and we had to try several times to get the correct one, essentially losing more time.
— Why is it important to release so quickly?
LM: The adoption rate among iPhone users is very high — as soon as the new iOS version is released, users start updating their phones to it. Apps can crash and break when they are not prepared for an OS update. The developers are more likely to take the hit as a mistake like this will impact their app store reviews and might even cost them a significant amount of users who uninstall their broken app.
BC: Our number one priority is helping developers during the transition between Xcode and iOS versions. We need to release fast so that our users can start building in the new environment, even if this means that sometimes what we put out is not entirely perfect yet. We are still doing tweaks here and there to increase performance.
While we can't fix Apple's process around these releases, we can make it a lot less stressful for iOS developers by ensuring that we provide the tools they need, when they need them. As a mobile-first CI/CD platform, we are prepared for events like this, and prioritize shipping the newest version to our users as soon as possible.
