Live data from Hacker News

Apple acquires Buddybuild

buddybuild.com

41–50 of 170 posts

Re: Apple acquires Buddybuild

#41

I recently posted an „Ask HN“ asking for a flexible CI system. Most of the suggestions were proprietary hosted SaaS solutions. I was sceptical, and things like that keep me sceptical. Sure, setting up a CI system yourself is maybe a bit harder than using a hosted solution. But if the provider decides to change their offering, you are in big trouble. You‘ll need to spend a lot of time switching to a new sevice, migrat…

I’ve been using drone, which is open source. It’s the only CI tool I’ve found writing pipelines in to not be painful. Need a test DB? The syntax is just docker compose so you already know how to get yourself one.

People who cared about BuddyBuild probably don't care much about Docker or "generic" CI services. There are plenty of those.

The thing about BuddyBuild was that it was "iOS Specific". You could point it at a repo and you would have your project building, signed and ready to install, in minutes. This was pretty unheard of. And still is. Trying to get iOS projects to build and sign on generic CI services like Travis, Circle or Drone means hours of pain to get it going and to keep it going. Been there done that.

Re: Apple acquires Buddybuild

#42
Holy shit. Was looking at the pricing.

> $1,037/mo

> Billed monthly​

> 10 Concurrent builds

That’s A LOT for 10 concurrent builds... I am sure the product is great, but that pricing is just a jaw drop. Probably a sign of “we are confident this price is worth it.” Anyway, congrat.

Re: Apple acquires Buddybuild

#43
Congratulations to the buddybuild team. I've used buddybuild since 2015 and it has streamlined a lot of problems with building, signing, and distributing dozens of iOS apps I've worked on over that time.

It will be interesting to see how (and when) Apple integrates this into Xcode, iTunes Connect, TestFlight, and the rest of their development portal. I don't really see Apple running a hosted continuous integration system, but maybe they plan on investing more effort in Xcode Server[1] to sell some new Mac Pros, whenever they're ready.

[1] - https://developer.apple.com/library/content/documentation/ID...

Re: Apple acquires Buddybuild

#44
post #42

Holy shit. Was looking at the pricing. > $1,037/mo > Billed monthly​ > 10 Concurrent builds That’s A LOT for 10 concurrent builds... I am sure the product is great, but that pricing is just a jaw drop. Probably a sign of “we are confident this price is worth it.” Anyway, congrat.

Totally worth it.

Re: Apple acquires Buddybuild

#45
post #4
post #2

Goodbye Android builds. edit: yup; On March 1, 2018 buddybuild will stop servicing apps on the Free Starter Plan. Also on March 1st, the buddybuild service will stop supporting Android apps for all plans. Any historical data related to those apps will be deleted from the service at that time.

This gives my current team two months to find a new solution. Buddybuild, aside from the odd issue from time to time, had been a great solution for us. Now we're suddenly wondering where to go next. Not to mention, we now face the question of whether to move our iOS apps off buddybuild as well.

If you wish, you can keep paying them as a reward for the amount of work it'll cost you to fix your non-iOS development.

Re: Apple acquires Buddybuild

#47
post #27
post #13

Earlier quoted context omitted.

There is Buildkite, which a hybrid server side / client side solution. This has worked extraordinarily because one of the most frustrating parts of setting up a CI service is setting up a long-lived, reliable server.

Buildkite also offers free accounts to open source projects along with awesome email support. After years of Jenkins, followed by a couple of months trying to cherry pick CI parts of GitLab and make them play nicely with GitHub, Buildkite has been a breath of fresh air. Their service has allowed us to version control pipeline configs, test GitHub pull requests, and provide all core features without having to curate a…

We’re working on making GitLab CI work better with GitHub. I'm sorry to hear it will be too late for you.

Re: Apple acquires Buddybuild

#48
post #15

Earlier quoted context omitted.

If I were to seriously attempt to commercialize the toy apps I build for my kids/family I'd go iOS first easily. People with Apple devices are far likelier to pay, and Android development is, in my view, an inferior experience (although Kotlin makes it marginally less so these days).

This may have been historically true, but our internal data shows us that starting early 2017, people in tier 1 countries were equally likely to pay and have comparable LTV on both platforms. And if you also going to launch in EU/Australia/Canada, you will have a nearly 50-50 split of ios and android users on a platform neutral app. So the classical logic of implementing on iOS first doesn't really apply anymore. Now…

The logic still applies.

1. Start with platform you're most comfortable with. 2. Iterate on product until you have a winning formula 3. Replicate on 2nd platform to double revenues

Building is a lot easier than identifying what to build, better to speedily experiment on one platform.

Re: Apple acquires Buddybuild

#50
post #33

Earlier quoted context omitted.

This is where open source projects with open governance offer peace of mind over proprietary offerings. Community stakeholders get a say in how the project evolves -- decisions are not made solely on what offers the best value for the platform's investors.

Far more nuance is needed here. There are plenty of open source projects where the decisions and roadmap are decided in private and based on financial motivations. In fact most of the company sponsored projects are like this eg. Spark, Cassandra.

> Spark, Cassandra

I'm a former Apache board member, and I've worked with contributors to those specific projects on governance issues. I stand by what I said.

When it is possible for users to become contributors and gain a governance stake, projects tend to become more dedicated to preserving backwards compatibility. People who are counting on the software get in a position where they can raise a big, loud stink when their interests are threatened.

Sometimes projects break compat anyway, but only after traumatic debate. And depending on how the open governance is set up, it can be nearly impossible for the project to be sold out from underneath its users.

Post reply on HN