[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.

[gsavit]

Or Runway will take care of the piping! Integrations with PagerDuty et al are certainly on the roadmap :)