[pbiggar]

[Disclaimer: I'm founder of a competitor (https://circleci.com, which offers CI/CD for iOS and Android as well as web apps, open source, etc).]

I don't know why it shut down, but my guess: customers didn't want to use one CI system for their iOS builds and another for their server-side builds. This was one factor in CircleCI acquiring distiller.io (which was a ship.io competitor) last year.

The history here is very interesting:

The original ship.io product was built by CISimple, and the assets were sold to Electric Cloud after CISimple shut down in 2013.

Electric Cloud is a ~13 year old VC-backed startup that sells a C/C++ build distribution service (think distcc, but much faster and better). (Interesting side-note: EC was founded by prolific HN contributor jgrahamc, and by John Ousterhout, who created TCL and coined the term "scripting language".)

EC's customers are mostly very big embedded systems makers, so it's a very enterprisy market. This market was good but AIUI their revenue growth flattened out sometime after hitting $10m/yr in revenue many years ago

A few years ago EC branched out into the Continuous Delivery space to rekindle that growth. Their continuous delivery products are AFAIK being sold in the same enterprisy top-down fashion as EC, as opposed to the bottom-up developery approach that CircleCI, GitHub, New Relic, Heroku, etc, use.

Ship.io was, I think, the first of EC's products to be sold bottom-up, and that was aimed directly at developers. I believe this is the best way to sell into this market, so it seems ship.io was going in the right direction. In fact, I believe it even operated somewhat autonomously from Electric Cloud, with a separate team based in SF instead of Silicon Valley.

I would guess they shut down because they didn't get product market fit (which would be true if their customers wanted server-side CI in the same product). But it's also possible (pure conjecture here) that the bottom-up autonomous feel of ship.io didn't gel with the top-down enterprisy culture of the mothership.

[zacwest]

I use CircleCI for iOS CI/CD and one of the biggest reasons is it doesn't try to be an all-encompassing solution for what I need: it executes tests and reports results.

I wanted it to do more, so I wrote some simple tooling to do more. I wrote up in a blog post for ease of reproduction: http://zacwe.st/blog/automating-ios-builds/

I think for most users, just running the tests is a step in the right direction. Handling distribution (the CD part) is something you grow into if you haven't seen it before. If I have to think about how to configure every aspect, I'm probably not going to get very far into the setup.

[ShaneWilton]

I'm not terribly familiar with ship.io, but we use CircleCI at Tinfoil Security, and it's an excellent product.

If you're looking for a replacement to ship.io, it's definitely worth investigating. Their support is excellent, and I'm sure they'd be able to help you fill the ship.io shaped hole in your infrastructure.

[tauntz]

I'm the founder of http://greenhouseci.com and ship.io was a competitor with a product most similar to what we're offering.

I see the reasoning behind pbiggar's post but I have to say that from our experience (and our target market) there's not that much demand for a unified CI service that can build both server side and mobile apps. We've had this issue come up a couple of times but most of our customers are mobile app dev teams that have separate tooling from their backend teams and using different CI services for different teams isn't generally a deal-breaker.

What killed ship.io? I don't want to speculate and I hope that we'll see a post mortem from them in the near future.

[gratner]

I used to use Ship.IO even though we use Circle CI for our web builds. Unfortunately, Circle says that they are still don't have the capacity for additional customers to use iOS builds. Would love to change that :) (@GregRatner)