chrisstott

I just wanted to extend congratulations from the team at buddybuild!

It's awesome to see the mobile developer tools ecosystem as a whole expanding.

It wasn't too long ago that mobile teams had to use web CI products, awkwardly repurposed to build & deploy their iOS and Android apps - imposing on them a huge maintenance burden and slowing down the development of their apps.

Great tools help build great products, and the future for mobile development tools is very bright today.

You might be interested in buddybuild's beta distribution which does automatic UDID management.

It basically makes it so neither the developer nor the tester ever have to worry about UDIDs ever again. Instead you can send a build to a new tester & trust they can immediately install it.

[Disclaimer, I built that feature at buddybuild]

This is one of my favourite quotes about pricing ever.

I think Unity is something we'd love to support in the long term. I don't know what the timeline on the would be though.

We already have people who are using buddybuild to co-ordinate deploying mobile and server apps (either a full environment or something like Parse's Cloud Code). I've also seen people spin up a local server environment for running iOS Simulator tests against, so their entire stack can be tested.

We take this very seriously.

At a high level, our front end servers can write credentials, but never read them.

Only the build machines (which are isolated from the public internet) can decrypt and use them... and only for a short duration during a build.

A good portion of our infrastructure is built on AWS - where a majority of our team had worked to build services with similar secure environments.

We don't think of it as an either/or (In fact, buddybuild supports deploying directly to Testflight as well).

Buddybuild's deployment really comes into its own earlier in the dev cycle - when you want to deploy to your internal team (who might want to jump to old builds or different branches) - when you want to schedule deployments (every evening for example) - or when you want to send a build very quickly to someone.

We've made the onboarding experience for new testers very simple - automatically handling adding UDIDs to provisioning profile. Also, not having to install a separate app is very appealing to some people.

We show off that part in our demo : http://www.buddybuild.com/demo

Testflight works really well for very large external test groups.

We use the spaceship gem, but none of the fastlane cli tools.

One of the things we really wanted to enable was an incredibly simple set up process, but while balancing that with giving a developer the ability to work in the way they want to work.

So while we automatically handle most of the common situations, there's always the ability to run custom scripts and do whatever you want to do. Many teams are doing interesting things like this.

[I'm a co-founder at http://www.buddybuild.com - we're a cloud platform for building and iterating on mobile apps]

Awesome write up. I've always been a huge believer in having a great workflow.

Before starting buddybuild, last year, we were going through similar pain trying to set up CI for an app with things like jenkins and travis - so we could work in the simple way our team wanted : eg. One of us hits 'git push' - the team's devices get updated with the newest build, and we all had a quick way to give feedback on the commit.

We realised that, like us, most app developers want a great workflow, but didn't want to have to spend a lot of time setting it up and maintaining it.

With buddybuild, we've been working with hundreds of open source apps and iOS / Android developers to make sure we can automatically understand and build their apps. The setup experience is usually just selecting the repo, and we'll figure out the rest.

Our goal has always been as close to zero configuration as possible. I'm a firm believer these things should just work, and the experience should be, essentially, magical.