Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Bringing Pull Requests to Ship, a macOS native client for GitHub Issues (realartists.com)
89 points by kogir on July 5, 2017 | hide | past | web | favorite | 49 comments

Before you try it out, just know that it will install a webhook on every single one of repositories that you have permissions on, not just the ones under your personal account, but all the organization ones as well. And GitHub doesn’t seem to have a way to easily remove them all at once, even after the app's permission has been revoked.

EDIT: as pointed out by Prefinem below, using the "Logout" feature uninstalls all webhooks: https://www.realartists.com/docs/2.0/uninstall.html

Sorry you were surprised. Just to check, was the Privacy Notice displayed before you logged in? It looks like this: https://s3.amazonaws.com/support.realartists.com/PrivacyNoti...

We do plan to make repository selection for sync configurable in the next release.

I was too eager to try it out that I did not read it carefully enough. Completely my fault! Yeah repository selection would be nice!

Ran into this same issue.

Read here: https://www.realartists.com/docs/2.0/uninstall.html

It uninstalls them if you logout

Oh nice. Thanks!


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!

Regarding the pricing model and server usage:

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.

I completely understand. Realtime is incredibly nice and offloading work does cost, which makes a subscription model required.

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.

This also makes it impossible to use for Github Enterprise because the installation is (usually) not available from the public internet and most enterprises won't be cool with the data being accessed/stored by a third party.

It's too bad, it looks like a cool product.

I think a standalone product would probably be a lot more powerful from a security standpoint if possible.

The security aspect of this application is what turned me off. I'd love to use Ship, but being greeted with this[0] OAuth confirmation when logging in really turned me off. I was expecting something that reads the API and alerts of new issues, but the sheer number of highlights of the word 'Admin' made me shudder. If they provided a convincing argument as to why they needed as much access as they do, before I began to log in, maybe I would have been a bit more trusting.

[0] - 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.

We can support GitHub Enterprise with a self-hosted appliance. If you're interested I'd love to talk.

That self-hosted appliance would have to undergo a year-long security review process. Basically we'd have to know all the internals, how things are implemented, with which libs, which versions, how it gets updated...

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.

I wonder, would you be able to check if the self-hosted appliance is making requests to IPs other to the one that hosts your Github Entreprise instance? If you can check for this, you can be more confident that your data is not being sent out to machines you do not control.

That would help build a case for mitigation, but it would still have to undergo the entire scrutiny process.

That's going to pretty much be a non-starter for most people. I'd like to use this software and I might be able to get a couple more people at my company interested, but that's not going to be enough to convince anyone to set up an on-premise server to manage the app.

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 also ran into a problem when trying to create a milestone for a repo

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.

Thanks for looking into it. Like @NegativeLatency said, it would be nice for the UI not to lock up and if it does error, to a) let the user know, b) allow cancelling out or retrying.

I ended up having to Force Quit the app

That's absolutely a problem we need to fix. Thanks for letting us know.

No problem.

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.

The ui probably shouldn't lock up though

About Hooks: When the last user using an Organization or Repository logs out of Ship, we do clean up the hooks. See more details at https://www.realartists.com/docs/2.0/uninstall.html

Without the explicit logout, Ship has no way of knowing you're done.

Just a side note,

It seems that if I manually remove them and then reinstall the app / reauthorize the app, the webhooks are not recreated.

We actually handle that as well. If we’ve not heard from a hook we think we’ve installed for a while, we’ll ping it.

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.

Awesome. You guys are spot on

Wow... thanks. I feel silly now.

I'll preface this by saing: I'm not a Mac user and am unlikely to ever use this or any other tools built for macOS.

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.

Out of curiosity, why did you feel the preface necessary? Your point seems to stand without it just fine.

I really like this app, but I don't think I will buy it.


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.

You are being downvoted but I agree. Not everything should be a never ending monthly fee. I'll pay for a good app and happy to buy the next major release if I think it offers enough functionality to upgrade.

In this case, maybe an annual fee might be better... but it seems like the application itself requires a server component (that they host) for webhooks from gh and push notifications to their client ui.

Ah...got it. If they are relying on their infra to provide services that makes sense.

I really like the look of the app. It's nice to see established well developed desktop interface concepts applied well.

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.

Good point. I updated the link.

James and I have put a ton of work into this since we first showed you Ship six months ago. We've fixed many bugs, improved fit and finish, and even lowered the price.

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.

I'm excited to give this a try, as it's downloading, is there support for:

- 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)

Yes, yes, yes, and yes :)

@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.

I don't use GitHub anywhere near enough to warrant using this anyway, but it's sad to me that true native app development (a rare and positive thing these days, it seems) is shackled with what I consider the scourge of the modern app landscape: monthly subscription pricing, justified by a man-in-the-middle server(s) for reasons that are in no way logical.

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".

When we initially started development, the application directly synced with GitHub. Turns out, to accurately reflect the current state of Issues on GitHub, you need to poll multiple resources per repository every minute, in addition to subscribing to hooks (hooks alone don't cover everything). Even if those requests are all 304 Not Modified responses, they add up in size, number, and time. Furthermore, some views, like Issue details, actually require tens or even hundreds of requests to refresh completely.

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.

Not to contradict what my partner, kogir, is saying here, but I think the benefit, as a Ship user, for subscription pricing goes even further than any discussion of the server.

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 [1]. 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 [2] or Beyond Compare [3]). 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.

[1] https://github.com/blog/category/ship [2] https://www.kaleidoscopeapp.com [3] http://www.scootersoftware.com/shop.php

I'd pay $40 for this. Can I pay you $40 once instead of $5 a month?

I can't wait for a Visual Studio Code implementation of this...

Any plans for bitbucket?

Sorry, not at the moment. We're all in on GitHub right now.

Any support for iOS (Ipad Pro) down the road?

Maybe. We did iOS support on Ship 1.0, and I think it turned out pretty well. For Ship 2.0, the Mac app is a Cocoa app, and the codebase is already factored into UI/non-UI areas, so it's somewhat portable, but of course much of the UI stuff has to be rethought to work well on iOS.

Is it just me or do none of the links work?

Sorry, I was doing something dumb with javascript on those, so if you were browsing with it off or were blocking resource loads from ajax.googleapis.com, it wouldn't work. I think it's fixed now.

Here's a direct link to the app: https://www.realartists.com/builds/2.0/Ship.app.zip


Please don't be mean on HN.

We detached this comment from https://news.ycombinator.com/item?id=14705626 and marked it off-topic.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact