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'.
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?
I wonder if Apple's satellite operations (like the Siri team in Ottawa, Canada, for example) might have some autonomy and self direction simply due to distance from the mothership.
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.
Steep incentives for corporate takeovers is a bad idea IMO - that lack of option in a liquidity event would make less companies receive funding. It would be even more risky to our venture capital behind a new idea.
It might be, but Apple, Google, FB, MSFT, etc, still have the ability to roll one of those giant mining dump trucks full of money up to the founder's doors, so you're always going to have the possibility that they just get bought out.
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.
There are innovations that happen all the time specifically around making things smoother and more stable.
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.
Testflight is extremely useful if you want to test your production build before releasing it to the public.
Before Apple bought it there was no way to test the exact same build before releasing it on the App Store.
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.
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.
>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.
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.
Have a look at App Center as well! https://appcenter.ms/ It is easy to setup and supports Android and iOS apps, as well as cross-platform ones. (Disclaimer: I am on that team)
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?
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 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.
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.
My take is that RN is great for demo apps or simple UIs, but I would not choose it for a production app where performance matters (ie. using camera, audio, custom controls, platform-specific SDKs, multi-threading, etc). You're definitely going to do heavy lifting in native code, and a hybrid app quickly becomes a mess. Dealing with multiple environments and super slow build times in Xcode will seriously slow down development cycles.
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]
That article is out of date. As of September 2017, FB has re-licensed React under the MIT open source license and dropped the patent stuff.
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.
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.
React Native is great for apps, and if it's a game, just use Unity. They're building up their internal CI infrastructure and it works better every month.
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.
That's interesting. I am admittedly using my recollection of data I saw a year or so back. Has the fraction of iOS users who pay gone down or the fraction of Android payers gone up?
Is this referring to free apps, paid apps, or both? I've had a paid app on both stores for about six years now and in my experience the iOS version makes about 10x the Android version every year. Many other developers have reported a similar discrepancy.
Sorry should have clarified, I am taking about freemium apps , both subscriptions and IAPs. Don't have data on paid apps.
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.
Bitrise has been great for us at work as well, but we're beginning to investigate Microsoft's CI platform since we build web/desktop apps as well, which aren't a first class citizen in Bitrise.
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)
Pretty much most larger apps/agencies do development for both platforms. iOS usually gets a bit of a higher priority, but Android is just too big to ignore.
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).
It's silly to think Apple buying Buddybuild is to discourage development for other platforms for the reason you stated, there are plenty of competitors to both TestFlight and Buddybuild. They bought these two companies because they want to enhance their own developer tools.
I don't believe that at all. The obvious reason why they discontinued Android support is because Apple isn't interested in continuing the existing B2B business. They're interested in the technology and the team and they're likely to integrate it into their own developer tools and offer them for free.
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.
Surely Apple are throwing away a lot of the value of what they just bought; does profiting from that harm their own developer tools. IMO that seems almost impossible, the only harm is to protect their eco-system from competition; ergo the reason to stop supporting other eco-systems is to harm the competition?
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?
I'm an Android fan/Apple hater but I could never recommend anything other than going iOS first for any business interesting in maximizing profit. I actually like to push react native just so clients won't completely ignore Android when see the cost of porting. But really, really I will push PWAs over apps whenever they are suitable.
First, but not exclusively. As a long time complainer about the iOS-first mindset I used to keep a spreadsheet actually of how long the Android versions of apps were delayed.
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.
I made a good career out of selling late-to-the-party native android ports for companies.
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.
my G!! lol....if Kotlin was available back then, I definitely would've jumped on that ship. Now it seems mobile isn't really viable in terms of money though
We put off an Android version of our app for nearly two years to concentrate development on the iOS version, and the numbers we get from our Android version - less than 10% of the market and 1% of the subscriptions - prove that was the right thing to do. We'd drop Android completely as the wasteland it is if not for the PR optics of having it.
Putting off the Android version for two years is a great way to have your potential Android audience move on to your competitors and squander any marketing and networking effect.
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?!
Our app is in the top 10 grossing apps in the Apple App Store and we market it aggressively. Android users are just not as lucrative or numerous as Apple ones.
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.
What does "top grossing 10" on App Store have to do with anything? Do you think Android users regularly check out Apple App store to look for your software? :P
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.
Actually, the apps are virtually identical, except for platform UI differences to cater to each group. The Android audience is just not as valuable, dollar-wise, as iOS regardless of market share. Our subscription numbers prove it.
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....
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.
The problem I've seen is it makes sense to the person who set it up but when they leave it's not as easy or obvious for the person who comes in later to maintain it. If you have left behind detailed docs that may mitigate the issue. Also in some cases there is good reason to do it yourself but in other cases some people have a strong NIH syndrome and the value in the end to the company is not necessarily higher with a custom setup. In the end if it ends up costing more to maintain the system it's a net loss.
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.
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 :)
> 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.
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.
Yay, glad to hear that. And we're trying to make initial setup easier with Auto DevOps https://docs.gitlab.com/ee/topics/autodevops/ providing a default implicit gitlab-ci.yml file
Initial setup? I was amazed when I simply put my .yml file into the root of my repo and pushed to gitlab. It just worked and the job was running. What other initial setup are you referring to?
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 list of random plugins.
I have used (and set up) Jenkins, Drone and GitLab CI, and the latter two are definitely my preference these days. Unlike Jenkins, the configuration for Drone or GitLab sits in the repo, so it's as portable as the code itself - you manage the CI process through PRs and merges, same as anything. I use GitLab for personal projects, and it's pretty nice in that it's also git hosting, but the runners can be finicky to set up, and even though I've set up a few, it can still be confusing (specifically, tagging runners for specific tasks). In general, I think the most flexible thing is the one that's configured on the fly in the project itself.
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.
Hard part in this case is not the actual build code or even the CI runners, its actually maintaining a mac server farm for your builds. None of the major cloud providers have mac hardware options.
Buddybuild and very few other CI systems have iOS and Android support.
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.
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.
What would it take to enable iOS builds in an open source project like drone? It is true that drone is primarily focused on container runtimes (linux amd64/armhf/aarch64 and windows) but perhaps we could have a separate yaml and agent that executes a pipeline on the host machine, perhaps using sandbox-exec for isolation.
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 tried to take a look but loading your site is really slow for me (from Europe) and at least in my case is fraught with rendering issues as elements on the page move around (images that don't have a set width and height mostly causing pages to reflow constantly as they're being loaded). You seem to be hosted on AWS though so you might want to consider deploying your site (and assets) to a few more regions. I'm probably overly picky about these things but when my first experience with a vendor is "stuff is slow" that weighs pretty heavily in making a decision to investigate further.
+1 from a customer! For general CI I'm a big fan of CircleCI, but for mobile builds and integrations to the relevant CD services Bitrise was much much easier to set up.
Our team uses Buddy Build currently. Interested in integrating Microsoft App Center. Would love to see a comparison of Buddy Build against the ms App Center service
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.
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.
> 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's another reason to not do business with smaller companies. Especially if their idea is good, you can only wonder, when will they be bought out and my workflow will be (temporarily) disrupted?
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.
Thank you for calling out a potential replacement service. Building iOS apps is certainly tricky (can't get Mac OS into the cloud easily), so these free-tier CICD services really are great for those creating new, smaller apps and are getting on their feet.
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 think its better to rip off the bandaid. I lived through the Facebook Parse shutdown with a production app where the drama was strung out over a year, resulting in service outages, poor messaging from parse/facebook, and a lot of general anxiety about migrating etc.
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.
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.
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.
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.
As soon as macOS comes into the mix, hosting (hence CI) prices go through the roof. Since they're not keen on bringing back Xserve or Mac Mini Server, I sure wish the macOS license would allow for it to be run on hypervisors on non-Apple server-grade hardware for CI uses.
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.
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.
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?
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.
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.
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)
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.
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.
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.
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'.