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.
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.
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.
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.
1. Customers don't rely on the service.
2. There are no customers.
Otherwise, why not leave the servers on for another month?
EDIT: 3. The service isn't automated enough to be run without human intervention, even for a month. Which would also likely create failure when it scales.
https://ship.io/ship-io-launches-out-of-public-beta/
I'm not in touch with the startup world but does that seem a short time to see if it sticks? Did they just have too short a runway?
Back when we started only a handful of CI services were available for iOS developers. One of them was CISimple which was later aquired and rebranded as ship.io . Our motivation to start our own service was that none of the available hosted services at the time were flexible enough to handle the projects we were working on.
Ship.io did improve a lot, allowing custom scripts to be executed, but, at least for us, they always seemed to be too locked down, too much of a black box.
This is exactly why we recently introduced our [open source CLI](https://github.com/bitrise-io/bitrise), so that you can run your CI and other automation configurations on your own machine if you want to, and of course in the (highly unlikely ;) case we would decide to close the shop you can still export your configuration and run it anywhere you want to.
I remember, just a few months ago, we felt that ship.io had a spy in our team, as they introduced new features almost at the same time we did (Slack support, Deliver support, ...).
It's surprising they closed so quick, they had quite an active marketing team and released new features frequently. I guess this decision was not up to the people who actually worked on the product, most likely they failed to meet the (monetary) expectations of their parent company.
Fairwell old friend, we'll always remember you!
Our builds were failing because even though we could check out our Git submodules fine, they could not. They couldn't resolve it and told us to stop using submodules instead.
Then our builds were failing because they weren't respecting our scheme's settings. First they didn't even understand the problem and told us to restructure our project, then when they did understand it, they didn't treat it as a bug report, but a feature request.
To be honest, it felt like we were just an inconvenience to them. We stopped using their service because they seemed more interested in us doing work to solve their problems than them doing work to solve our problems.
It's surprisingly (and sadly) non-trivial to make a sticky footer (that stays at the bottom of a page, even if the page's contents are not long enough to fill out 100% of the screen), but this is something I expect just about every experienced front-end dev to know by now.
For those curious about how you solve this (without flexbox, which is something I'd expect frontend devs to know/remember from repeated lookups): http://ryanfait.com/sticky-footer/layout.css
Comment is purely heavily downvoted passerby-opinion, not sponsored content.
