EDIT: as pointed out by Prefinem below, using the "Logout" feature uninstalls all webhooks: https://www.realartists.com/docs/2.0/uninstall.html
We do plan to make repository selection for sync configurable in the next release.
Read here: https://www.realartists.com/docs/2.0/uninstall.html
It uninstalls them if you logout
Like another use said, I would rather pay once and receive updates than a monthly subscription. I know that you are using your own servers to pull information, but I don't know why that is even necessary. I would rather have an app that doesn't pass any information through a third party server.
I also ran into a problem when trying to create a milestone for a repo (this was the second milestone I was creating with the app) and it locked up.
Other than that, it's extremely nice, and if you ever made it into a one time purchase, I would probably pick it up right away.
EDIT: Just a couple of notes. I tried out a couple of other applications to compare features (since I can see how nice managing issues, etc from a single app is compared to the website) and I have to say that Ship is by far the nicest out of the bunch.
As posted below: https://www.realartists.com/docs/2.0/uninstall.html
T̶h̶a̶t̶ b̶e̶i̶n̶g̶ s̶a̶i̶d̶, w̶h̶e̶n̶ I̶ w̶e̶n̶t̶ t̶o̶ c̶l̶e̶a̶n̶ u̶p̶ /̶ r̶e̶v̶o̶k̶e̶ a̶c̶c̶e̶s̶s̶ t̶o̶ a̶l̶l̶ t̶h̶e̶s̶e̶ a̶p̶p̶s̶ t̶h̶a̶t̶ I̶ j̶u̶s̶t̶ a̶l̶l̶o̶w̶e̶d̶ a̶c̶c̶e̶s̶s̶ t̶o̶ G̶i̶t̶h̶u̶b̶, I̶ f̶o̶u̶n̶d̶ a̶ t̶o̶n̶ o̶f̶ h̶o̶o̶k̶s̶ o̶n̶ n̶o̶t̶ o̶n̶l̶y̶ t̶h̶e̶ o̶r̶g̶a̶n̶i̶z̶a̶t̶i̶o̶n̶ l̶e̶v̶e̶l̶, b̶u̶t̶ e̶a̶c̶h̶ r̶e̶p̶o̶ l̶e̶v̶e̶l̶. I̶ k̶n̶e̶w̶ t̶h̶a̶t̶ y̶o̶u̶ w̶o̶u̶l̶d̶ h̶a̶v̶e̶ h̶o̶o̶k̶s̶, b̶u̶t̶ I̶ a̶s̶s̶u̶m̶e̶d̶ t̶h̶e̶s̶e̶ w̶o̶u̶l̶d̶ b̶e̶ o̶n̶ t̶h̶e̶ o̶r̶g̶a̶n̶i̶z̶a̶t̶i̶o̶n̶ l̶e̶v̶e̶l̶ o̶r̶ r̶e̶p̶o̶ l̶e̶v̶e̶l̶, b̶u̶t̶ n̶o̶t̶ b̶o̶t̶h̶. E̶i̶t̶h̶e̶r̶ w̶a̶y̶, i̶t̶ t̶o̶o̶k̶ m̶e̶ a̶r̶o̶u̶n̶d̶ 1̶0̶ m̶i̶n̶u̶t̶e̶s̶ t̶o̶ c̶l̶e̶a̶n̶ u̶p̶. N̶o̶t̶ s̶u̶r̶e̶ i̶f̶ y̶o̶u̶ h̶a̶v̶e̶ p̶l̶a̶n̶s̶ f̶o̶r̶ a̶u̶t̶o̶ r̶e̶m̶o̶v̶a̶l̶ o̶f̶ w̶e̶b̶h̶o̶o̶k̶s̶, b̶u̶t̶ t̶h̶a̶t̶ w̶o̶u̶l̶d̶ b̶e̶ a̶m̶a̶z̶i̶n̶g̶ i̶f̶ y̶o̶u̶ d̶i̶d̶.
Either way, I will be keeping my eye on Ship because I really enjoyed it for the most part and it is better than the alternatives I found IMO. Keep up the good work!
A major design goal for Ship is to have everything you see be live. I love it when a colleague updates something from the web, or the app, and I see it instantly on my screen. Receiving real time updates from GitHub requires us to have a server on the public internet listening for events from them.
I also personally care a lot about CPU use and battery life on my Mac, and being able to offload a lot of work to a server is a benefit. Ship needs to consume basically every bit of information that GitHub makes available, and just the overhead of doing the http requests to GitHub is noticeable if you run that locally.
I hear what you're saying about the benefits of a one time purchase app that doesn't require any third party server, and I've spent a good amount of time thinking about how to make that work, but I feel like I'm not able to offer the user experience I want with that model.
That being said (and this might not even be feasible from a cost / benefit view of things) but my use case would mostly be opening the app once a day to check for new issues or see what I need to work on next and then past that would be posting comments on issues, etc etc. Realtime isn't really a concern and my response times are the speed of me getting an email and then responding. So, point being, a non realtime / standalone product has value to me personally. Just to give you another perspective.
I probably wouldn't be saying this if my company used Github for managing things instead of just my personal projects, in which case, realtime would be very handy.
It's too bad, it looks like a cool product.
 - http://cloud.selectivebyt.es/0I1t0N20372v
edit: I took that screenshot on the 28th of May, and it appears that Ship now does explain a little better why it requests the access it does.
For something that really should be a piece of desktop software, that most likely won't fly.
I understand your business decision to go for a SaaS model instead of a fixed price, but the added value of the service (vs. a product) doesn't justify it on the user's side.
Perhaps you would consider a hybrid approach where the actual app connected to the API and set up the required webhooks, which your server could then use to notify the app?
I think I was able to find this failure in our logs, and api.github.com returned a 504 GateWay Timeout. Not much we can do in that case except fail.
I ended up having to Force Quit the app
I should specify. I did get an error the first time it happened. Then, when I tried again, it failed and that's when I came across the issue stated above. I tried Force Quitting and trying again twice. It seemed like something got hung and it couldn't make the request after it failed the first time.
Without the explicit logout, Ship has no way of knowing you're done.
It seems that if I manually remove them and then reinstall the app / reauthorize the app, the webhooks are not recreated.
After three failed pings (spread out over an hour or so), we’ll delete our record of the hook and attempt to recreate it the next time an administrator logs in.
But, it's really great to see work being done on an intuitive native interface for this sort of thing. Major props for the write-up on the security of the tool, too. Lots of transparency there as to how the tool works under the hood, and it sounds like you've put a lot of thought into how that should work.
It is the monthly subscription fee. If I stop paying then I lose functionality. I'd rather pay $50 or something and get regular updates and continued functionality than $5 a month.
Yes, I know, I already pay GitHub $7/mo, but I can't get paying monthly for a client app.
The first link in the blog post should really link to the home page. A download link is unexpected and unwelcome for someone who's trying to figure out what Ship is for the very first time.
Trials have been reset, so if you looked at Ship earlier, feel free to give it a fresh look on us!
We'll be in the thread and would love to hear your feedback.
- Approving / rejecting on the PR as a whole?
- @ mentioning
- Assigning team members to a PR
- Viewing a subset of the diff (i.e. all changes since my last review, or even better all changes between these two commits)
@mentions are an aspect of the product that's a little weak right now. There's a lot more we can and should do with it. We plan to improve this in a future release.
How many email "clients" have launched in the last few years, only to be shutdown without any future use possible because they all had a hidden server component?
So you get to pay almost as much as most people will pay for all of GitHub, for an app that's tied to another company being around, with the bonus that they get to see all your private repos?
I know a lot of people won't see any issue with this, and that this is "normal" for them, but this is most definitely not "normal" for me, and it pains me that so many people accept this as "normal".
The server component can quickly make needed requests in parallel over a reliable, high bandwidth, low latency connection. Then, once the changes are known, the server streams them down to the app as deduplicated, compressed, incremental changes. This allows the application to sit idle, using essentially no CPU, network, or battery resources.
It's unfortunately the only way to provide a good user experience.
Imagine that a future GitHub API v5 is perfectly suited to the feature set and user experience that we want to offer with Ship. That's great, now we can happily delete our server.
But, GitHub itself is a subscription service that is not a fixed target. They routinely introduce new features and APIs, in fact nearly weekly . Our app is only valuable as long as we provide utility to you beyond what you get by just using github.com. When GitHub adds a new feature, and your collaborators start using it, if it isn't usable in Ship, then Ship now has negative utility compared to loading up github.com in your browser. This isn't just hypothetical either -- we do a lot of work to keep up with GitHub's pace of development.
Imagine you sign up today and then 2 months from now GitHub makes a change that substantially reduces the utility you get out of Ship, or Nick and I go out of business. With the current subscription pricing, you will have spent $10 for 2 productive months with the app, and you can go back to using GitHub in a web browser with no downside, because Ship (intentionally) doesn't have any lock-in.
Now contrast that with a model in which we ask for $70 up front for Ship. I think this is not unreasonable considering the pricing of standalone dev tools of similar utility (for example, consider fancy diff tools like Kaleidoscope  or Beyond Compare ). As I'm sure you know, most indie Mac software has a sales curve that starts off with a big spike over the first week or two after a release and then it trails off pretty sharply. That's fine for an offline app, but I hope you can now see how the subscription pricing model is a better fit for Ship, both for us and for our users, given the large surface area and fundamental nature of our integration with GitHub.
Here's a direct link to the app: https://www.realartists.com/builds/2.0/Ship.app.zip
We detached this comment from https://news.ycombinator.com/item?id=14705626 and marked it off-topic.