Apple acquires Buddybuild
buddybuild.com
buddybuild.com
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'.
As for a shift in startup culture, what is more tempting than 5 to 10 years of hard work into billion dollar exits? Local governments could start offering tax incentives that build over time—or more aggressively, have steep disincentives on corporate takeovers.
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.
Look at air transportation. It was a series of fairly novel and innovative programs that took place to make a new transportation industry the safest by a mile. It was some serious hard work and innovation to make air transportation the safest and most stable way to travel.
You can purchases strata title triple A class office space in Vancouver for less than that.
http://www.cbc.ca/news/canada/british-columbia/unprecedented...
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.
Same boat here, we'd JUST started using BuddyBuild a month or two ago.
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.
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.
Think of it as an opportunity. Clearly this product has proved its usefulness, so there's a whole market to be served.
I don't recall many iOS and iOS only apps. There was just generally and Android time-tax that Android users had to wait through.
Its pretty low key lucrative too:
- iOS development is crowded, Android devs are more scarce and there are too many unrelated skillset paths to build a native android app.
- The APIs are already developed by the time you get there.
- The designs have already happened, for the most part. Its no longer a fact finding mission and instead a pure implementation mission.
- You make more money and have to deal with less company-wide fires in the process.
- Nobody bothers you. You get to be on autopilot.
- And its also pretty pointless. Most company's android apps are just a checkbox, store presence to show they haven't neglected it. Nobody is going to actually download it.
It was fun for a while, I got my funds up.
There is a ceiling you can make doing mobile dev, and companies don't make a return from pursuing it
React Native solves the needs of most companies' apps on both platforms, they'll figure it out all pretty quickly at the same time
Fwiw: We also wish there was a way to publish test/linting results (you can make it an artifact, but it won't load assets, so you're stuck zipping and downloading or publishing to your own managed Web server)
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.
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.
Tbh, I'm not sure how many use cases don't fit either React Native or Unity, I'd practically never choose to do an app another way these days.
IMO RN is no exception to the Simple vs Easy trade-off [1] Not to mention using RN gives FB a legal blank check from your company [2]
[1] http://chrisfrost.com/wp-content/uploads/SimpleVsEasy-478x51...
[2] https://medium.com/@raulk/if-youre-a-startup-you-should-not-...
I don't think you contradicted anything I said. I would say special camera apps, multi-threading etc. are not needed that often.
As for slower build times, that is the beauty of RN. Building is not needed most of the time just an initial build and a rebuild every time some of the base configurations change or you are creating code outside of RN.
Ah, thanks for the update, glad they did that
> are not needed that often
Right - statistically most apps are probably throwaway code for hackathons or demos. However, I'd venture to say that >50% of serious apps will end up needing performance boosts from native code.
> Building is not needed most of the time
You need to rebuild every time you make a change in native code (obj-c or swift). Hot reloading is cool for JS changes, but bloat from RN becomes a nightmare when debugging obj-c or swift issues.
You will have equal ROI, with the LTV being slightly lower on android but so too will the acquisition cost... overall profit being the same.
Speculation: iOS users may be running into app fatigue and just don't want to install new apps anymore.
Also I am talking about app that are well monetized and advertised so you have an level comparison instead of chart positions giving and sustaining a significant lead on one platform just by some fluke.
Solutions that support both are thus more popular and better idea - but Apple obviously is using all kinds of tactics to discourage development for competing platform. Even buying companies and shutting down their Android (TestFlight is another example).
Immediately killing all Android related functionality is to discourage that development though.
Why would Apple invest resources into making developer tools for other platforms? What's the real upside if Buddybuild continued as is and they tried to scale it up? Hundreds of millions in revenue per year? That's a drop in the bucket. Buddybuild's value is strategic, not because it was going to make a financial difference to Apple.
Couldn't they fork the project, keep everything but the name for themselves and set a single guy on maintenance; wouldn't that enhance their own developer tools just as much?
Noone remembers your app exists after a few months, why did you expect anyone to give a damn about your product after two whole years?!
During that two year delay we made the iOS version a quality product instead of having our attention divided by another platform that delivers less than 10% of the userbase. It was the right move.
Your attitude is very common among iOS developers and it's the main reason why you only have 10% of userbase on Android - companies that actually understand their audience have no issues reaching wide users and profits on both platforms.
If you deliver a subpar submarketed product on App store you will fail. If you deliver a subpar submarketed product on Play Store you'll fail as well. It seems you did the second thing.
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....
Note: I'm not affiliated with Buildkite.
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.
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.
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.
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.
Buddybuild and very few other CI systems have iOS and Android support.
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.
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.
I love how GitLab does it. It owns the parts watching your branches for commits and passing instructions to your machine, but the instructions themselves are a clean YAML file in the root of your repo, so if at any point you want to pack things and switch over to another provider it’s all right there in plain text.
Manual setup looked a bit daunting initially but turned out to be not that hard to wrap your head around and totally worth it, simple configuration with one runner has worked like a charm for months. Between ease of setup and zero lock-in this seems to strike a pretty good balance.
https://circleci.com/docs/2.0/testing-ios/
https://circleci.com/docs/2.0/language-android/
[disclaimer: founder of circleci, though I don't work there anymore.]
[Disclaimer: As I'm a PM on the AppCenter team I'll leave evaluation of goodness to others :)]
We use HockeyApp just now, and App Center's rather strange lack of Cordova support is a total deal breaker for us.
Added bonus: most of our tools are open source, e.g. you can use the same runner which we use to run the builds on our build VMs ( https://www.bitrise.io/cli ) to run the bitrise config/build anywhere the CLI can run. Happy to answer any questions!
I think Buddybuild was the only service with a free tier. For folks that aggressive bootstrappers (like myself), it's just another nuisance. And even for people who were paying -- they are still as equally as disrupted.
1. Vertically integrated
2. Horizontally integrated
3. Conglomeration (not integrated)
And there is a "strategy tax" in whatever method you choose.
Except for FileMaker and Beats, Apple is mostly a vertically integrated company. They have no real desire to be everything to everyone like Google. If they didn't play to their strengths and tried to service Android users, it still wouldn't be a great experience.
I have no problem with Apple deciding to abandon BB on Android. It would indeed make very little sense for them to continue to support this platform.
What I am complaining about is the shut off date, it is very close.
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.
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.
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...
But it's Buddy Build, the hosted Continuous Deployment platform - https://www.buddybuild.com
They have similar background gradients.
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.
> $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.
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.
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.
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.
Yes, their IDE was made for their platform. I'm not seeing why this is a problem.