Apple Acquires BuddyBuild. Oh, My Xcode Server!

i didn't expect that this would be my first blog post of 2018. on my holiday, i read the tweet that "apple buys buddybuild" and it raised my eyebrow. i blinked and read the tweet again. i quickly checked buddybuild's twitter handle, but there wasn't any tweet. i googled it and found that tech crunch , cnbc , and the buddybuild blog confirmed this news.

this news is certainly exciting news for me considering the work i am doing on ios devops and ci/cd. i picked up the phone and congratulated dennis on twitter.

it wasn't too long ago that i met the buddybuild team in person and got a pack of t-shirts delivered to me for my work on the ios ci olympics 2017. i had a conversation personally and on twitter with dennis, chris, and alysha at the london buddybeers meetup in october 2017.

i got in touch with buddybuild when i was running the ios ci olympics 2017. being passionate about ios continuous integration and continuous delivery, i have conducted olympics of top 5 cloud-based ios ci services with 20 different criteria and buddybuild was the winner. you can read series of blog post here

the final medal looked like this: bb = buddybuild, br= bitrise, tc= travisci, nc= nevercode, cc= circleci

during this evaluation, i got huge support from the buddybuild team to understand the key concepts and workings of buddybuild. as buddybuild became the winner, they posted the results of the olympics on the buddybuild blog: ios continuous integration & deployment comparision .

buddybuild sent me some t-shirts that i distributed to my colleagues at yoox net-a-porter .

although i liked buddybuild a lot, i never tried to use it for the projects i am working on because we use travisci and i have set up a fully automated end-to-end pipeline to deploy ios apps straight to itunes connect using fastlane. recently, i set up some xcode server bots to ios to get ad-hoc builds on devices and run xcuitests on real devices. we keep looking for a new build system, but my love for apple developer tools never takes me outside of xcode server. i love xcode server a lot, i hate xcode server a lot...either way, i was hooked into xcode server. that's because of all my love towards apple developer tools. i did lot of things on xcode server, like

• wrote ansible role for xcode server to manage mac minis. read the detailed post here .
• integrated xcode code diagnostic tools with xcode server. detailed post here .
• integrated slack with xcode server bots. detailed post here .
• wrote the detailed guide on setting up over the air installation. detailed post here .
• complained about its pitfalls on twitter and submitted bugs to apple. read about the limitations here . apple closed my bug report on pull request testing on xcode server as a duplicate and never gave me the details of the original bug.
• after the wwdc 2017 talk on xcode server, i immediately published a blog with the latest xcode server features. read the xcode server + xcode 9 blog here .

all these things i have done so far look like they were in vain. i don't know what's going to happen to xcode server now. in reality, xcode9 and xcode server are really playing well, apart from pull request testing support. almost everything, from code signing to automatic device registration, real device testing, and over the air installation all became so painless. it was doing way better than jenkins, teamcity, and other self-hosted ci solutions, apart from pull request testing.

now i am keen to see what apple will do with xcode server. will they kill it completely? or will they keep still keep it as a self-hosted ci solution and make buddybuild a cloud ci solution? exciting times ahead!

the latest xcode server almost removed the need for fastlane as everything is inbuilt in the xcode server. buddybuild guesses everything looking at the xcode projects in the repo and does its own things, which hardly need fastlane. however, it works well for setting up scripted pipelines on travisci or circleci successfully, as they don't guess anything. everything has to be scripted. the annoying thing about fastlane is they are trying to do too much, really really too much- almost publishing a new version every day, always chasing apple, chasing google, chasing third-party integrations, etc. stay calm, fastlane!

nowadays, the swift version of fastlane is an incredibly crazy swift wrapper to execute ruby commands. i wrote about my first impressions of fastlane swift here. it would be interesting to see how fastlane will perform in the competitive ios ci/cd world.

this is purely my personal opinion, but i feel that apple is not a problem, not the third parties. the basic problem remains in the amateur world of ios developers. i am not saying all, but most of the ios developers only know xcode and a few apple frameworks; they can write complex objective-c/swift code but can't run a single command from the terminal. how do you expect them to learn the underlying tools that xcode uses to perform all the ios development activities like building, testing, and archiving? how do you expect them to script ios ci/cd pipelines using tools like codesign , xcodebuild , plistbuddy , and agvtool ? these lazy buggers want xcode to do all these things for them, and if something goes wrong, they have to put their blood and sweat into it. some experienced developers whose beard goes grey by doing ios development still find it hard to deal with code signing activities. some developers are great at scripting and understand all these tools- they won't ever face these problems, or they won't need any automatic solutions to deal with ci/cd. they should understand the simple fact that knowing uikit and some apple frameworks doesn't make them good ios developers. they should also learn command line tools and scripting languages to deal with ci/cd-related issues. they should take control of scripts and do whatever they wish rather than someone guessing what's on their mind and doing the stuff for them.

i am sure apple knows this problem, that ios developers want everything in xcode, and didn't want to use scripting or command line tools. every year, apple puts new buttons in xcode that do something under the hood. when it comes to the server, everything has to be scripted. xcode server is the one tool to allow developers to perform ci from xcode itself. they introduced and solved the pain of code signing with the automatic signing feature in xcode. in short, apple is trying hard to make them happy. the acquisition of buddybuild is another step to handle everything from xcode.

it will be very exciting to see what will be announced at wwdc 2018. there are certain possibilities that might happen:

• apple will keep xcode server as a self-hosted ci sevice and buddybuild as a cloud ci service.
• buddybuild won't support open-source projects, so prepare to migrate to travisci, circleci, or bitrise.
• apple might kill xcode server completely and support only one ci service. if you are running xcode bots with multiple mac mini servers, then prepare yourself for other self-hosted ci solution like jenkins, teamcity, etc.
• expect cloud xcode server or similar at wwdc 2018.
• there might be a device lab for running tests in the cloud on real devices. no ci has devices attached to the cloud at the moment. we have to use some sort of services like aws device farm, saucelabs, etc.
• forget about infrastructure as code. assume that you won't have control on ci/cd pipelines. let them guess your xcode project and do the stuff. or, depend on a ui configuration browser or xcode.
• be ready to drag your development and distribution certificates from finder to xcode or the browser. don't worry, someone else will take care of code signing activities, which will be amazing.

buddybuild acted as the market leader by providing great services to the customer and a great product. this bunch of nice and talented people have now become part of apple. i wish them good luck and expect some great products this year. congratulations to dennis and the team for such a great achievement. we all are excited to see what you build this year!