
Apple acquires Buddybuild - uptown
https://www.buddybuild.com/blog/buddybuild-is-now-part-of-apple
======
st3fan
I'm happy for the founders, this is probably a good and profitable exit for
them. But as a customer I am really sad and disappointed.

Apple has a very bad reputation when it comes to taking over products like
this. TestFlight is the prime example. TestFlight basically disappeared for a
year until coming back as a more limited and slower Apple branded service. And
by slow I mostly mean, it takes 6 months for bugs to be fixed or for exciting
things to happen. Agility and innovation of a startup basically ends when
Apple assimilates a service.

From the blog posting it is also not very clear what will happen to existing
iOS customers. Can I upgrade my plan? Can I expect service? Will the existing
infrastructure be maintained?

I'm excited about what this could mean in terms of Xcode and Xcode Server
improvements. Or maybe even a hosted CI service at Apple. But that it all long
term 'maybe'.

~~~
pm90
Apple is notoriously bureaucratic. So its not surprising that innovation is
stifled. I really hate this duality b/w innovation and stability... perhaps if
more startups were focused on longer term survivability, it would be better
for society overall?

~~~
skywhopper
Innovation and stability are tautologically in opposition to each other, alas.

~~~
rtpg
I've found that this doesn't have to be the case.

Continuous deployment is a good example where this doesn't hold. You roll out
things more quickly... and you experience less issues!

When issues happen, the cause is easier to isolate. After all, you only had
one day's worth of changes (and not one year's worth). The previous state is
more knowable. Testing is more concentrated.

Apple's new OS releases are the opposite of this. They release 30 different
major changes at once, they all collide, and we end up just assuming that .0
releases will be broken.

In an alternate universe, Apple just releases updates to parts of software
when it's ready. They don't pin Safari to the OS (because there's not much of
a technical reason to). They could pinpoint _when_ "Month 13" started showing
up everywhere beyond "when everyone downloaded that 7 gig update".

It takes some effort and tooling, but if you're expecting to make changes, a
lot of times making the changes piecemeal will mean that post-release
stability will increase in many cases.

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

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

~~~
swozey
I'm sure your team had an incredibly productive December and are ready to get
migrating on the double! Oh, wait, you're probably catching up from a month
full of time-off and holidays and were planning on hitting it hard on new
features in Jan..

Same boat here, we'd JUST started using BuddyBuild a month or two ago.

~~~
noarchy
>I'm sure your team had an incredibly productive December and are ready to get
migrating on the double! Oh, wait, you're probably catching up from a month
full of time-off and holidays and were planning on hitting it hard on new
features in Jan..

You nailed it. The last thing we want to be doing right now is have to tinker
with finding a new CI system. There's too much real work that we have to do.
It always takes time to set these things up properly, and reliably. We've used
buddybuild for more than a year, and we've long had it to the point where it
just worked, and worked reliably.

~~~
j4ship
why not just deploy .... the only thing a CI system does is run a bunch of
scripts ... build a bash script and deploy by hand.

Theres an 80/20 rule here, you can get 80% of CI features in 20% of the script
you create

Also if you turn down your deployment cycle (once a day, twice a week , etc)
you will lessen the problem of lack of a tool , until you find one

CI for me has always been about deployment organization and automation. Its ok
to have a bug be fixed by end of day, it doesnt have to be deployed in 15
mins.

------
mullingitover
And just like that, by dropping Android support, Buddybuild goes from viable
solution to total non-starter. Does any serious mobile app development these
days really go all-in on one platform?

~~~
sidlls
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).

~~~
Pharaoh2
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 its more, implement first on the platform you are comfortable
with but don't forget about the other platform because there is a equal amount
of money to be made there...

PS: Data excludes low end iOS and android devices. (< SE, old iPads/iPods, old
and cheap android devices). These devices have extremely low conversion on
both platforms anyway.

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

~~~
jjeaff
In my opinion the new logic is build in React Native (unless your app fits in
the 10% of use cases that won't work well with RN), then deploy to both at
once. We have had excellent results.

~~~
rimliu
I'd say RN won't work well in 99% cases.

~~~
jjeaff
I'd say you are probably using a lot more React Native apps than you realize
right now.

------
jakobegger
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, migrating all your data and
processes. And once that is done, you can start to retrain all your employees.

And you always have to be ready for that scenario, at two months notice....

~~~
favorited
I've built several Jenkins-based CI systems at work. Once you know how to not
shoot yourself in the foot, it's really easy. I have 2 cardinal rules:

1) Don't run any jobs on the master box – master is just a web server + master
Jenkins app server 2) All build scripts should be part of the project, not
configured CI

#2 is the more important. Jenkins jobs at my work used to have tons of
configuration and plugins, because the person setting up the CI would see (for
example) an "Xcode plugin," and (naturally) decide to install and use that.
That was a nightmare because of transient dependencies (and conflicts), and
now configurations like "project file name" were spread across multiple jobs.
Now we just have similar build scripts in each project, which has the
additional benefit of letting developers run builds and tests locally the same
as they run in CI. Jobs are tiny, and all the CI configuration has to do with
CI things, like schedule, branch, archiving, notifications, etc.

~~~
peteretep
At that point, is there much point in using Jenkins? Aren't there much lighter
weight alternatives?

~~~
favorited
If you know a good one, definitely let me know. Generally the only constraints
are open source with a permissive license & on-premises installs.

One benefit is it can already integrate with whatever else is out there. When
we switched from GitLab to GitHub Enterprise at work, our CI environment just
needed to point somewhere else.

~~~
sytse
Why did you switch from GitLab? What should we improve?

~~~
favorited
Nothing! GitLab was great. But we had several GitHub, GitLab, & Stash
instances, and there was a push to consolidate onto one platform. Not sure why
we consolidated onto GitHub over others, but that was above my pay grade :)

------
CameronBanga
If anyone has a good Android (or even iOS) replacement, share here? I know
myself and likely many others will be looking to migrate this month.

~~~
JoshuaWeberMSFT
AppCenter.ms has many similar features and supports iOS, Android, Windows,
ReactNative, Xamarin, and others.

[Disclaimer: As I'm a PM on the AppCenter team I'll leave evaluation of
goodness to others :)]

~~~
CameronBanga
Any plans to add Gitlab support to roadmap? Dealbreaker on our end. Email in
profile if you'd rather not answer publicly. :)

~~~
siminuk
Yes! GitLab support is on our roadmap.

~~~
sytse
Awesome! Please let us know if you need any help. Best is to email
eliran@gitlab.com

------
api_or_ipa
What a shame for some, but I'm happy to see a Gastown company succeed. The
tech hub around Victory Square is such a great little community.

------
Y7ZCQtNo39
2 months is not enough time for people to find alternative solutions.

~~~
gk1
I was doing marketing/growth consulting for FoundationDB when they were
acquired by Apple. The product was shut down overnight. Compared to that, a
two-month notice seems generous.

~~~
wwilson
(Former FoundationDB employee).

Where did this dumb meme come from? First of all, FoundationDB was not a
service, so there was nothing to "shut down".

It's true we stopped selling the product to new customers, and we no longer
offered free downloads under the community license. However those with
existing licenses were able to continue running the product (and in fact some
of them do to this very day).

What's more, the Community License was explicitly written to be valid in
_perpetuity_ , precisely to protect customers in this sort of instance.

Many people were disappointed by the way Apple handled the acquisition,
including me incidentally, but your comment is mostly FUD. If you really were
doing consulting for us, then I'd expect slightly better treatment of a former
customer.

~~~
gk1
> I'd expect slightly better treatment of a former customer.

1) Apple--who I assume made the decision to end the service abruptly--was not
my client.

2) I'm making objective statements. I'm not making a judgement of whether it
was smart, foolish, fair, unfair, etc. Actually I was very happy for the FDB
team and stay in touch with some of them.

------
robmaceachern
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...](https://developer.apple.com/library/content/documentation/IDEs/Conceptual/xcode_guide-
continuous_integration/index.html#//apple_ref/doc/uid/TP40013292-CH1-SW1)

------
4ndrewl
I thought it was something to do with Buddy, the hosted Continuous Deployment
platform - [https://buddy.works](https://buddy.works)

But it's Buddy Build, the hosted Continuous Deployment platform -
[https://www.buddybuild.com](https://www.buddybuild.com)

They have similar background gradients.

~~~
BugsJustFindMe
Well, if names are any indicator, one of them builds, but the other one
actually works. ;)

------
ajeet_dhaliwal
Curious how those of you who knew about buddybuild heard about it? Seems I
hear about companies for the first time when they are either acquired or
shutdown.

~~~
Pharaoh2
It was one of the few CI providers that supported MacOS.

Since iOS apps can only be legally built on apple hardware, if you were an iOS
developer and didn't want to maintain your own mac minis, you knew about them
and the few other providers.

~~~
birmacher
You can use Bitrise.io ( CEO here ) as well to build your macOS app. Give it a
try and let us know how you like it! We’re glad to help with setup too.

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

~~~
st3fan
Totally worth it.

~~~
toddgower
I will second that. My iOS team was 1 person strong so we could get by on the
startup plan at $80 a month (1 build at a time). The gain in productivity was
huge.

------
toddgower
I've been a Buddybuild user for the past couple months after watching the
founder, Dennis, give a talk at a meetup. Great product with a super easy
setup. Really bummed that I'll likely have to find a new solution after only
two months (though I understand the founder's decision). Can anyone recommend
a product with a similar ease of setup?

Buddybuild was my first foray into mobile CI. Have not seen the need since our
iOS dev team is one-person strong (me!) but once I've realized the benefits,
there's no going back.

~~~
kristiansagi
We at nevercode.io wrote an overview of our platform for BuddyBuild users for
easy migration. Have a look :) [https://nevercode.io/welcome-home-android-
developer/](https://nevercode.io/welcome-home-android-developer/)

------
v1c
There's always Jenkins with Fastlane as an alternative, then again Apple
offered the guy that created Fastlane an internship. Maybe Google will put
something together for the Android crowd?

~~~
Sujan
Fastlane has pretty good Android support (equivalent to iOS).

And the guy that created it, @krausefx, now actually runs it as a Open Source
community project - from within Google where the Fabric team landed after some
time at Twitter.

------
emdowling
Seems pretty clear to me that Apple is doing this to make Xcode for iPad
viable. For vaguely complex apps, the iPad still wouldn’t be fast enough to do
compilation in a reasonable time frame. By moving compilation (or at least
some of it) and release processes (archiving, signing, etc) to the cloud,
Xcode for iPad becomes much more streamlined and capable of building larger,
more complicated apps.

------
skocznymroczny
When can we expect a "it's been an incredible journey" blog post?

~~~
sireat
It's already up:
[https://ourincrediblejourney.tumblr.com/post/169262039243/bu...](https://ourincrediblejourney.tumblr.com/post/169262039243/buddybuild)

------
devscreen
That is an aggressive timeline to drop android support!

------
justonepost
Wow, looks like a great opportunity to create a competing service that
supports iOS / Android.

~~~
tauntz
There are quite many competing services that focus exclusively on iOS and
Android (nevercode.io, bitrise.io and others). Buddybuild wouldn't have sold
to Apple if they saw that there's still more untapped opportunity in this
space. It's a crowded market.. (disclaimer: I'm the former CEO of Greenhouse
CI)

------
trevor-e
Apple needs to drastically simplify how Xcode builds work instead of acquiring
more companies. For example, provisioning profiles solve a problem that
doesn't exist while creating a dozen more. Xcode is still limited to macOS.

On the deployment side iTunes Connect is possibly the worst website that I've
used. It's incredibly slow (both the front and backend) and has limited
options for phased releases.

~~~
s73ver_
"Xcode is still limited to macOS."

Yes, their IDE was made for their platform. I'm not seeing why this is a
problem.

~~~
trevor-e
Yes, it's totally within their rights to do so, but the walled garden approach
is getting old. Microsoft is at least starting to learn to this. If they don't
want to port over all of Xcode, at least port xcodebuild and allow us to
connect to physical devices. macOS does not make a good build server. If they
did things right then companies like Buddybuild and fastlane wouldn't need to
exist.

------
vivekmgeorge
Personally, I think this is the fairly useless move by Apple. Being able to
build apps easier will not change this dead ecosystem. Easier ways to market
apps, get them into the hands of users, and remind ppl to use the apps they
downloaded is what's needed. Facebook, Google and Apple consume all free of
users.

