[an_opabinia]

Let's say I have an iOS app. Not a single thing changes in my repo. I would like to build and submit to the App Store every day. On how many days out of 100 does Runway successfully result in an app submission status of "Under review by Apple" or whatever, without any input from me?

[gsavit]

Interesting question :) Our "full autopilot" mode isn't yet launched but once it is, if you have a recurring cadence set up with scheduled kickoff and submit days, and if each release's interim steps/gates are green, you'd theoretically be able to submit 100 out of 100 with no manual intervention. The real-world limiting factor is that in App Store Connect only one submission can be in flight at a time, and they'd usually be in flight for longer than a day.

[an_opabinia]

> to submit 100 out of 100 with no manual intervention

Apple breaks fastlane automation at least once a quarter. I would expect about 5-20 days when submissions will fail.

However, if you could get that to zero, emphasis on no manual intervention, like not asking me for configuration changes or to approve something or change or check some box, that is easily worth $400/mo from me.

[gsavit]

Runway doesn't actually rely on fastlane, we're interacting directly with the App Store Connect API. So, to the extent Apple avoids breaking things on their own API, Runway should remain operational!

In terms of config and checkboxes through the submission process, Runway allows you to set defaults so you should be able to set and forget. Of course, Apple does sometimes introduce new requirements and new checkboxes - we plan to help surface those changes to teams.

[an_opabinia]

> Of course, Apple does sometimes introduce new requirements and new checkboxes - we plan to help surface those changes to teams.

People who got this far in the thread probably thought, "Yeah, but things like the Encryption Export Compliance checkbox, that's such a nuisance, Apple breaks your automation over stuff that is basically never material." Which is sort of the opposite of what's going on in the flows I saw on Runway's site.

Nevermind what your customers think. If there's a difference between having 100/100 zero intervention upload days, and 80/100, a clear metric, an obvious thing that is valuable - which checkboxes, really, do you think are material? You personally. Because personally, I find the vast majority of checkboxes to be immaterial. CYA and IDC are two sides of the same coin.

[gsavit]

I think it's a good point. Down the road it could be smart to explore an expanded idea of release defaults and the ability to assume away new questions about edge cases that show up in the flow. For now, we're committed to having Runway perform reliably and safely - which to start with means being explicit about options/changes that occur on a third party provider's side.

In general, my opinion (or Runway's!) isn't as important as factors on the customer side - types of apps, industries/verticals, team makeup - which are likely to make a difference in which checkboxes and options are considered important or not. It probably makes sense to include those factors when thinking about how we can further streamline everyone's release process in the future.

[estsauver]

I think that's a reasonable place to be. If you introduced a "Breaking build changes: New Checkbox Requirement" email most teams could just pipe that to pagerduty/opsgenie and have a reasonable way to ensure a working green deploy pipeline.