Live data from Hacker News

Launch HN: Runway (YC W21) – Easier iOS and Android app releases for teams

news.ycombinator.com

11–20 of 32 posts

Re: Launch HN: Runway (YC W21) – Easier iOS and Android app releases for teams

#11
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?

Re: Launch HN: Runway (YC W21) – Easier iOS and Android app releases for teams

#12

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?

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.

Re: Launch HN: Runway (YC W21) – Easier iOS and Android app releases for teams

#13
This is a really cool project. When I worked at Uber, the team built a custom release train called Metro, automating as much as possible, integrating with various internal tools and touchpoints. It worked really well: except if you want this, you need to build it yourself.

When I researched my book Building Mobile Apps at Scale [1], the best advice I could give for large teams and release trains is… maybe build one yourself? Given I didn’t know of any products that would work from medium to large teams.

It’s great to see someone tackling this problem space. You should talk with Uber’s mobile platform for some hard-learned lessons when building Metro.

[1] https://www.mobileatscale.com/

Re: Launch HN: Runway (YC W21) – Easier iOS and Android app releases for teams

#14
Neat! Looks like a great release tool.

I'm wondering whether there is a specific reason to mobile apps?

Would be nice if all releases (web, mobile, etc) can be going through the same pipeline. After all, those "people-centric" tasks are generally applicable to other projects as well.

Re: Launch HN: Runway (YC W21) – Easier iOS and Android app releases for teams

#15

This is a really cool project. When I worked at Uber, the team built a custom release train called Metro, automating as much as possible, integrating with various internal tools and touchpoints. It worked really well: except if you want this, you need to build it yourself. When I researched my book Building Mobile Apps at Scale [1], the best advice I could give for large teams and release trains is… maybe build one y…

It's definitely a problem area that's currently tricky to tackle properly for all but the largest of teams/orgs. Building in-house is often a luxury, and one which requires a big investment not just up front but into the future with upkeep and support. Of course it's nice to have a custom solution, but we've been working hard to make Runway flexible and able to adapt to every team's specific workflows and processes.

PS - thanks for the kind words - we're big fans of the book! Maybe you can squeeze us into a second edition? :)

Re: Launch HN: Runway (YC W21) – Easier iOS and Android app releases for teams

#16

Neat! Looks like a great release tool. I'm wondering whether there is a specific reason to mobile apps? Would be nice if all releases (web, mobile, etc) can be going through the same pipeline. After all, those "people-centric" tasks are generally applicable to other projects as well.

Some aspects of mobile (e.g. deploying binary, dealing with app stores) make it a more gated and complicated process. That, coupled with our team's domain experience in mobile, led us to focus there to start with. But you're totally right - there's a lot of overlap with any kind of deployment and we have an eye towards a future where Runway is the single place where teams ship everything they need to ship. Plus, there's extra value to unlock in coordinating releases across platforms - e.g. coordinating backend changes with app releases, or sync'ing product launches across web and mobile.

Re: Launch HN: Runway (YC W21) – Easier iOS and Android app releases for teams

#17
post #12

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?

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 us…

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

Re: Launch HN: Runway (YC W21) – Easier iOS and Android app releases for teams

#18
post #12

Earlier quoted context omitted.

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 us…

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

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.

Re: Launch HN: Runway (YC W21) – Easier iOS and Android app releases for teams

#19

Neat! Looks like a great release tool. I'm wondering whether there is a specific reason to mobile apps? Would be nice if all releases (web, mobile, etc) can be going through the same pipeline. After all, those "people-centric" tasks are generally applicable to other projects as well.

In my experience, mobile is a completely different beast compared to web thanks to things like: - You ship a binary that you cannot revert. Mistakes are very expensive: which is not the case for web. - The App Store review process. - Localization often being shipped with the binary (and you can’t fix it once shipped) - The business impact for mobile apps can be large: your highest value customers often use the native apps

There are similarities, but web has the massive advantage that you can deploy a fix anytime, for your whole user base. With mobile, you need to tread much more carefully.

Re: Launch HN: Runway (YC W21) – Easier iOS and Android app releases for teams

#20
post #18

Earlier quoted context omitted.

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

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 -…

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

Post reply on HN