Twitter’s updated Mac app wasn’t made by Twitter | Hacker News Reader

Twitter’s updated Mac app wasn’t made by Twitter

theverge.com

155 pointscoloneltcb87 comments

You'd be amazed at how many companies don't write their own apps. I know, because often the people who write them is me.

The problem is that there's a fixed, small quantity of good, senior, Mac/iOS developers. A lot of them like being independent and flitting around from project to project because that is how you build an experienced developer to begin with.

Meanwhile there is all this demand for apps, and so agencies act as the "market-markers"–acting as the sales force, the marketing team, and playing the role of "nobody got fired for hiring $AGENCY" etc.–but the actual lead engineers are pretty much the same bunch of schmucks no matter whose name is on the contract. If you want to know who wrote it, check the names in the header files, and we all meet at the same bars on Thursday nights.

I always advise people to cut out the middle man and hire the indies directly (disclosure: that would be me) since it's the same thing anyway, except cheaper and with fewer games of "telephone". But the pull of the pretty logo and the rapport with the Account Manager is strong.

Black Pixel is better than most of the agencies in that they do a large amount of their work in-house. But their "in-house" people are often just good contractors taking a break from contracting so I'm not entirely sure what you've accomplished by doing that.

I'm not really complaining–agencies have historically been a reliable source of gigs for me, and so they are my friends; they provide me a valuable service.

But do they provide you a valuable service? That I don't know. I have been in situations before where no matter which vendor the customer went with, I would be an engineer on the project, and the customer sat down and agonized over who to choose. That just seems inefficient.

It's called "consultant." Companies like to hire consultants because they can get rid of these contractors through middlemen in a matter of a day to a few weeks. Of course, depending on which consulting agency. For projects you don't know the outcome yet it's better to write off your book that way, but for project that will last forever like Twitter App, yeah, just hire the damn team into full time already. Differently cheaper. Actually I don't understand why they can't just have the iOS team help with it anyway. If you are capable of writing a Mac App, how hard is it to learn making iOS one, and vice versa?

Twitter's employees are presumably all at-will, so they could get rid of any of them immediately, if they wanted to. It's probably harder to hire them in first place though, instead of just hiring an agency.

It's not free to terminate an employee in the US. The (former) employer pays for the cost of unemployment claims. A company like Twitter will likely also pay severance, because it makes them considerably less attractive to future hires if they don't, and also because it can be cheaper than dealing with a potential lawsuit from a terminated employee.

In the USA, or at least in California, the employer does not pay the unployement benefits to the former employee. The benefits are paid by the state, which in California is http://edd.ca.gov. The employer pays for unemployment insurance. If the employer has relatively few former employees filing for unemployment, that insurance rate may go down over time. The concern over covering the costs of unemployment benefits are related to a possible increase in unemployment insurance premiums.

Source: http://www.calrest.org/tips-for-protecting-your-unemployment...

Yes, in the US most corporations pay unemployment tax (apparently nonprofits and government agencies can get a special reimbursement deal where they pay directly for unemployment costs). As you noted, unemployment taxes increase for corporations with lots of former employees claiming benefits. The fact that it's not direct doesn't eliminate the cost.

While at-will seems like firing quickly is common, it's really not. In a large company there are often (not always) many HR hoops to go through in order to fire. Often these have to do with legal processes. For example, an employee might have developed alcoholism. A company cannot legal dismiss the employee if the employee is willing to go to rehab. They can fire a contractor/consultant (provided the contract allows for that).

It also has to do with morale. If Jim just disappears and he's a FTE, that makes people nervous. They might start looking at a different positions. If Sally the consultant is gone tomorrow, oh well. There is often an "us" v "them" relationship between FTEs and consultants. It's not necessarily antagonistic, but it's not as amicable as FTE to FTE.

I don't think you understand what at-will means. They can fire the employee for no reason at all, alcoholism or not.

IANAL, (nor am I the OP,) but my understanding is:

You can do X for no reason != You can do X for any reason

i.e. they can fire you when they wish to, but if you can demonstrate that the reason for firing was illegal, then it the firing is not for "no reason", but for an "illegal reason."

Can't they just fire the alcoholic because they don't like his tie, then? Or, say, assign him an impossible project and then fire him for not completing it?

> Or, say, assign him an impossible project and then fire him for not completing it?

What you're trying is in UK parlance called "constructive dismissal" and it's not good; many jurisdictions make this risky.

https://en.wikipedia.org/wiki/Constructive_dismissal

They can. At will means they don't have to provide a reason. It gets complex though when the fired employee claims he was actually fired for illegal reasons. E.g. they might claim they were fired because of their age, because they were a woman, etc. Since most companies like to avoid lawsuits (but win the lawsuits if they do happen) they typically have internal HR processes that make it much harder to fire people. These require managers to document everything so that when person X claims they were fired because of their age, the company can hit back with "no, actually we have this whole file documenting all the instances in which you screwed up".

Writing Mac apps and iOS apps is pretty different. I consider myself a pretty good Mac dev, but I suck at iOS. I thought it wouldn't be hard to do both, but everytime I tried I realised that a lot of the frameworks are so different that you basically need to learn them from scratch.

At least in theory, agencies also do a lot of account management legwork. Of which there is a lot for large clients. Which merits critical attention, but there it is for now.

I used to work at a big company's inhouse development. We had many developers coming from either consultancies or agencies. The department and the developers would have been happy to cut out the middle man but policy dictated using the agencies. In my opinion it has to do with the people making up the rules thinking of developers as interchangeable. So they want a contract with a firm, stating that this firm will provide a developer with skill X for duration Y.

Sometimes, like in the UK, the agency is used to avoid getting caught by employee regulation or IR35. When caught, the client is considered the employer of the contractor and the contractor an employee. That has costly consequences on both, hence the intermediary.

About the cost though, if you do the hiring yourself, the overhead is around 5%. Quite OK for insurance considering the agency also handle payment and invoicing (some big clients are bad at paying on time, but the agency will still pay you on time, weekly for example). If you use the agency for recruitment too, that jumps to 20% and much more depending how much service you require up to full outsourcing.

In The Netherlands this is the main reason why big companies use agencies as intermediaries. It makes it easy to get rid of people when required. I suspect the contracted developers are often of higher quality than your average dev, since they feel safe finding work without the security of a permanent job. Therefore, if the need arises to let people go, I doubt the contractors will be the first to leave unless absolutely required.

Disclaimer: I'm a Dutch contractor and while I don't think I'm an über developer, I do notice I'm more passionate about the job as most of my (ex-)colleagues with permanent contracts.

I believe that a lot of developers aren't very good at talking to customers. I've often seen developers advertise something like "Typo3 development services", but their prospective customers have no idea that this is what they are looking for. So the agency translates between customers and developers. It's common that devs think that the agency isn't necessary, but only devs that are really good at talking to customers actually succeed in cutting out the middle men. (And I presume that these people end up startimg their own agencies sooner or later)

The other important point that you mention is customer acquisition and trust. How should prospective customers find you? How should they evaluate you? From hiring designers, I know that portfolios are only part of the picture... hiring an agency at least gives you peace of mind that someone will answer your mails instead of ignoring you.

The nice thing about Twitter apps is you can actually say "I'm pretty sure if just one person who cared got put on it, it could be WAY better than what we have today", because unlike other apps that we all "couch architect", we actually have the proof of this being the case. We have numerous case studies of 1 person or very small teams making really great Twitter apps (apps that actually influenced iOS design!).

Twitter has a ton of employees. Unless you actively believe the Mac app will hurt your business there should just be one full time engineer on it, someone who loves ObjC and UI design, who can use Twitter as a testbed for crazy UX ideas. If its not important, than whats the worst that can happen, you generate a ton of developer respect?

> … there should just be one full time engineer on it …

Agree with everything you just said, except, please make it two engineers. Speaking as a prototypical eng manager who typically inherits these types of projects when "that one engineer" leaves the company, I strongly believe that any job worth doing is worth doing by more than one person. (Plus, a good peer, just to bounce ideas off of and do informed code reviews with, is worth their weight in stars.)

PS: I thought @jack was going to open the third-party ecosystem back up again. That also has the potential to help address this problem. Did that not happen?

[1] http://www.theverge.com/2015/10/21/9586084/jack-dorsey-twitt...

> PS: I thought @jack was going to open the third-party ecosystem back up again. That also has the potential to help address this problem. Did that not happen?

I asked Jack about the third-party ecosystem on his producthunt Q&A, he said Fabric is a strong offering and they're building more to repair relationship.[1] I don't know if them building developer tools is same as repairing relationships though.

[1] https://www.producthunt.com/live/jack-dorsey#comment-202231

Hmm, I don't know about anyone else, but personally I can't stand Fabric! It gets in my way far more than it helps, with the weird utility app they force you to keep installed, and a single dashboard which does lots of things, but none of them really well.

There are always two: a master, and an apprentice. :)

It's a bit naïve to think all it takes is one engineer. First of all, you probably need at least more than one to keep you honest. Then a designer. Then probably at least a PM.

When comes the time to ship, you need to involve release engineers and QA and...

Really not worth your time when the app in question is targetting a minuscule market (Mac OS) that's not part of your core business.

Better outsource, validate when they're done and ship it.

I generally try my best to avoid being snarky, but you picked a bad example here, given that the first (couple?) version(s) of the official Twitter for Mac...and iPhone...and iPad apps were all called Tweetie, and written by exactly one person: Loren Brichter.

So, no, it's not naïve. In fact, it would be entirely expected, given that that's how this app started out.

Yes, the first couple of versions can be done like that.

But when you're going to maintain and develop further for a long time, the game changes. You need sustainability. The one developer may want to have a longer holiday. She may be run over by a bus or get cancer or have a child, so you want to have another person who knows how to develop. When the app becomes more complex and there are multiple platform versions to support, it will require more QA than one developer can do. You will want to have more than one person to work on it, and you need structures for that.

Bureaucracy increases, productivity falls, your best people leave and you end up in a worse place than when you started.

"Your best people leave" is a much worse problem in the case where you have just one person who then leaves.

It depends on whats left behind, if you spend all your time on trying to make your organisation safe from every calamity that might befall it then you probably aren't going to be that competitive.

Well, you don't have to try to make your organisation safe from "every calamity", but it would be prudent to look at reasonable risks - like that your only developer becomes permanently ill, or wants to do something else at some point in his or her life.

It is possible that in some business your competitiveness cannot cover the cost of mitigating this kind of risks, but then it's not a very good business.

Two thoughts from this, first about this in general. Second is in regards to some comments I'm seeing posted here:

1.) I am surprised this doesn't happen more. You find a company that's excited to build it, let them run with it, then if it ever becomes a target you acquihire.

2.) Folks internally probably know a Mac app isn't a target. Thus, who would want to work on it? There are probably loads of more exciting projects that'll get recognition. It's not that they can't, it's that no one there (really) wants to...

Not bad for guesswork, as you are correct management never wanted to prioritize it, but w.r.t. devs, you are off the mark. Internally there have always been those who wanted to work for it. I have been privately told (in late October 2015) by a former Twitter employee who is, shall we say, intimately familiar with Twitter/Mac:

> Twitter has always seemed to hate the idea of a Mac app and has either tried to kill it or let it rot. At this point I think 3 generations of rogue devs inside the company have basically had to sneak around management to work on it.

> Interesting to see them publicly announce an update. Rumor is they've completely outsourced development though.

Thanks for the info! Interesting management was contemptuous of it. I wouldn't have expected that.

Though with that said, I'd like to lay a bit more guesswork down now.

Those devs were probably good, I'd guess too good (for these purposes), and that management wanted them focused on core products which serve their target better... Like iOS? So it is probably less about contempt for the Mac product and more about the best usage of resources.

I have a feeling the rogues at Twitter who want to work on this are in a pretty high pay grade, even compared to the folks at the shop that made it. So it even still probably saved money.

With all that, has Twitter made the best use of those developer resources? I have no clue.

I wonder what would happen if one of these large internet companies with top engineering talent would fire all their product managers and designers. That's how Google worked back when they had their period of highest innovation.

Weren't they quite aggressive with other people using their service and piggy backing something on it? They could have done like Reddit and waited for a dominant app and then acquihire the people who did the app.

This is exactly what they did? Twitter's mobile apps are distant descendants of tweetie, and the old Mac client was too

> 1.) I am surprised this doesn't happen more. You find a company that's excited to build it, let them run with it, then if it ever becomes a target you acquihire.

That's a valid strategy for why you would want an open platform, but it doesn't really apply to outsourcing. It's not the agency's product and you're handing over cold hard cash for their time. You're not going to acquire the agency if the app takes off... you already own the IP.

Really the only reason that you should outsource is if an area is not in your core competencies. If developing software for a major platform isn't one of Twitter's competencies any more, that bodes ill.

> You're not going to acquire the agency if the app takes off... you already own the IP.

Well I think you're discounting the value of their domain knowledge and their contribution vastly too much. It will take time and resources to bring a new team online. Often times, that time is greater than the business can allow. The cost of simply acquiring the company isn't going to be sufficiently high enough for the corp to even worry. As you said, they (Twitter) own the IP.

I think you're significantly downplaying the cost which could potentially come from acquiring an agency.

It would be quite different if this was done by a startup whose sole or primary purpose was making a Twitter app. But an agency has dozens of different projects and clients (up to hundreds) and most of their team probably wasn't even involved in the Twitter app.

If Twitter wants to refocus on Mac, they'll just hire a Mac developer or two and pay the agency to train them on the app.

I just don't think a company the size of Twitter would worry about a $5-$15 million expenditure to get access to the talent they want/need right then. Then have the rest of the company, which I am assuming (quite ignorantly) isn't that many people, finish out the rest of their contracts before giving 'em some golden handcuffs.

I could definitely be wrong, and perhaps the app just doesn't require that level of expertise. If you have any data, I'd be happy to look at it-- knowledge is power.

> I could definitely be wrong, and perhaps the app just doesn't require that level of expertise.

There are three categories of expertise required for this app:

1. Expertise with the Twitter "domain." Twitter obviously already has this more than any outside consultant.

2. Expertise with writing Mac apps. Twitter can easily hire for this if they need to spin up in the future.

3. Expertise at the intersection of the two, which is pretty minimal. At the end of the day, it's a pretty simple CRUD app. It's definitely not worth paying $5M to get the developer who made it, especially when you consider that Twitter probably provided most of the product direction.

> I just don't think a company the size of Twitter would worry about a $5-$15 million expenditure to get access to the talent they want/need right then.

First off, I suspect an acquisition of a successful studio like Black Pixel might be well out of that range. They have their own products, including NetNewsWire, as well as a healthy client roster. According to LinkedIn, they have 50-200 employees. Not a trivial or cost effective acquisition. [0]

> I could definitely be wrong, and perhaps the app just doesn't require that level of expertise.

I don't have the data on hand, but I'm sure you could find it in Crunchbase. In general, it's rare to see established design studios being bought by their clients.

[0] https://www.linkedin.com/company/black-pixel?trk=extra_biz_v...

> If developing software for a major platform isn't one of Twitter's competencies any more, that bodes ill.

Why? They aren't desktop software company. They're huge-scale services, social interaction and growth company.

"Software development" is too broad a field for even Twitter to specialize in. They don't write firmware for hard drives that spin in their servers either — and I'd say that skill of writing firmeare is as far from skill of writing high-load servers as skill of writing desktop software.

> Why? They aren't desktop software company.

They might not be a desktop software company, but they're also not really just a "services" company. If they were, I wouldn't have expected them to invest so heavily in developing and owning the mobile client experience. In fact, they directly sabotaged people from building third-party API clients.

Considering how close Mac app development is to iOS development (which remains, supposedly, a key strategic area) I'm surprised.

It happens all the time, though, especially when it's an off-label channel (Windows Phone, for example). It's not unusual for a company to decide that it's cheaper to fund CAPEX for a product than to spin up the managerial infrastructure necessary to handle what they see as a less-important area of development. Just fund the project and bring the vendor back in to keep it updated. (Other reasons: internal politics; belief that an outside vendor can innovate more effectively; multiple failed internal attempts; have some EOFY cash to burn; really really like the vendor's logo.) When the project works out, no one's (usually) the wiser. When it doesn't, you throw the vendor under the bus and let the media back over them -- part of their job is to be a flak jacket for the client.

Black Pixel is a very good studio, and it's too bad they have to take their lumps on this. Everyone has a bad project: political infighting, technical constraints, lowballed estimates, unfunded scope creep, failure to vet or make explicit all the necessary assumptions. Or maybe their architect got religion, decamped to a Moldovan monastary, and now refuses to communicate except by illustrated vellum attached to a carrier pigeon. All sorts of stuff can go wrong, but it's still your baby.

> It happens all the time, though, especially when it's an off-label channel

Yes, I know that. I guess I'm more surprised that Twitter now considers OS X off-channel enough to not keep a dev on it. It's pretty close to iOS development and seems like a good skill to keep in-house, if only as a testbed for new UX ideas.

> Black Pixel is a very good studio

Yes, they've done some great work in the past. I definitely don't hold this against them, especially when project failures can be just as much a problem of client communication.

The original Twitter Mac app wasn't made by Twitter either. It was made by Loren Brichter and sold as Tweetie, until Twitter bought it and just renamed it to Twitter for Mac with I think literally 0 changes.

I've seen one person Mac shops put out apps of way more complexity than a Twitter client -- could Twitter seriously not hire a single native Mac dev?

I'm not familiar with Twitter, but I've been in this situation before elsewhere. An independent developer can bang out a good enough clone for the app that works in 85% of the use cases. Most users would never know the parts that are broken.

An internal developer can't ship that app. The 15% of the cases where it doesn't match the desired business intent torpedo shipping it. Keep in mind the alternative option to the native app is using the web app which likely works in 99% of cases. It's unacceptable to whatever section of the company doesn't have their feature in the native app (but do in the web app) to 'lose' users.

Of course that last 15% of the features leads to a doubling of complexity.

For instance, none of the third-party Twitter apps show ads. And that's exactly the part of the app that would have a lot of A/B testing and new features.

I thought they had a dozen devs on the iOs client. Amazingly.

Far too much wasted space in the new UI - between icons, tweets etc.

I used to be able to see all my accounts on the left-hand navigation bar, and now I can't because the increased spacing pushes them off the bottom of the screen. Annoying, as this was what I used to see which accounts had updates.

That seems too be the general trend with UI design these days. Less and less content, more space and the little content that's there gets made less prominent with low contrast. I find it quite upsetting.

Why? This doesn't make logical sense. It's a large company with enough resources. I get that the Mac is a lower priority, but why put your name on anything this bad. It's pretty clear how you should approach this:

a) We're going to do this and we'll do it right. It might be a smaller audience, but if we release this product under our name it will be awesome.

b) This isn't a priority, so we're not going to ship something half baked and outsource it. Here's a link to TweetDeck and TweetBot.

> but why put your name on anything this bad

It's possible that someone signed a bad contract. I've seen terrible products worked on or released because certain rights were sold in ways they shouldn't have been sold. That's not an excuse as it should still never happen. But it can go down that way.

Totally, but even if it was say a 500k contract, you chalk it up as a loss and don't release it.

Sounds like a case where the incentives for the company don't line up with the incentives for an individual manager. The responsible person might have suffered greatly (or at least thought they would) if they had just declared that much money to be a lesson learned on a bad idea, even if that might have been best for Twitter.

> b) This isn't a priority, so we're not going to ship something half baked and outsource it. Here's a link to TweetDeck and TweetBot.

Since the API now effectively forbids third party apps, that doesn't seem like a viable option.

TweetDeck hasn't been third party since Twitter acquired it in 2011.

Oh, in that case I completely agree.

They should have just rebranded TweetDeck as the new official Twitter OS X client.

The old Twitter app for OS X wasn't theirs either, they just bought and re-branded Tweetie. So they could have re-branded TweetDeck even more easily.

I think this project was put into works > 1 year ago. It's obvious it wasn't designed to incorporate Moments, the no character limit for DM's and Polls (all new features from 2015). Building out a Mac app shouldn't be a top priority of any company today, unless you're into productivity (i.e. Sketch, Adobe).

I'm almost sure that Twitter was stretched thin with Obj-c/Swift engineers building out the iPad app and refreshing the iPhone app (Moments) this past year.

And thing that we can learn from this is that if everything goes right, companies because of matter of pride, don't disclose the outsourcing. But if anything goes wrong, they will make it a point that they are not the people who have developed the APP but this is that particular agency that did.

business

I really thought this app was made using some tool similar to Electron. I'm pretty sure you could achieve a similar result easily with web tech.

Not only with such tech Twitter could have leveraged their internal web expertise instead of outsourcing for this app but they would have gained the Windows Store version for 0 additional cost. I checked and the Twitter windows version differs and probably required another external company (or maybe Microsoft help).

I'm a web developer myself and was really impressed with Electron that I discovered very recently. I'll surely use it for the mac app store version. On windows there's already a way to package a web app in Visual Studio (pretty similar to Electron but uses Edge instead of Chromium).

There's more to it than that. You could build it with web tech, but the original Twitter apps (even from when it was called Tweetie) featured lots of performance optimizations [1] to make it blistering fast, designed specifically for Apple platforms. They (ie Loren Brichter) even developed their own Mac UI framework library twUI, which was open sourced in 2011. [2]

[1] http://web.archive.org/web/20100922230053/http://blog.atebit...

[2] https://blog.twitter.com/2011/fast-core-animation-ui-for-the...

But do we know if it's still in use in the new app (probably...) ?

The libraries were introduced a long time ago and were probably first developed for the iPhone. For this new app they outsourced the effort despite the fact that they acquired Tweetie and hired Brichter.

I understand the history of it but my point is I'm not sure this is all still relevant in 2015 especially if Twitter outsourced the effort for this new version. A chromium instance can have fast animations on a mac or windows machine with only web tech (a lot easier to maintain).

Can't really blame Twitter for estimating that the minuscule Mac OS market is not worth wasting their engineers on. Better outsource and get your own engineers to work on core business stuff.

It's sad that their apps aren't as good as they were years ago. Software is supposed to, you know, get better. Then again, Loren Brichter does set a really high bar.

What is the purpose of not sunsetting this app on the desktop? Twitter already owns Tweetdeck which seems like a major overlap.

https://about.twitter.com/products/tweetdeck

After all Twitter only list their IOS/Android apps and Tweetdeck in the footer on their about pages.

Is Twitter the new Yahoo!?

I crashed it within a few minutes. Clicked Lists -> Member Tab => Subscribed Tab ... beachball, crash.

I'm surprised in a way this is a native OS X App - from what I've seen of Node.js + electron something identical could have been written that was cross platform.

>said the developer is Black Pixel, a well-regarded digital studio

Not well regarded if you paid them money for their Kaleidoscope app, which is pretty poor quality.

Any suggestions for a better graphical diff tool for OS X?

There must be something better. Hard to be worse. But I don't know of anything.

If you can go non-graphical, there's rsync. Then for diffing inside files, if you have Xcode, there's FileMerge which is hiding in /Applications/Xcode.app/Contents/Applications/FileMerge.app

It's not an integrated solution, though, as Kaleidoscope aspires to be.

Lack of skill set. Twitter mostly has good backend engineers and never really focused on building a strong front end engineering and UX organizations.

I don't agree. As an example: Bootstrap, by Twitter - http://bootstrapdocs.com/v2.0.2/docs/

Must be a slow news day

Probably that's why the new app sucks... just like it's predecessor.

Lack of skills, and speed to market are two reasons I can think of

Why don't people just go to https://twitter.com in their web browser instead?

as a tweetbot* user, i can tell you that for me the native experience is way better than a web page.

edit: tweetBOT, not DECK, and we regret the error!

*tho it has which has its own frustrations, and totally apathetic devs :'(

Some people hate web apps.

Ads and general horribleness that is the Twitter UI, although that's an argument for using Tweetbot, not the bad official Twitter apps.

The browser has a lot of window chrome I don't need.

The browser window doesn't easily resize to a natural size for Twitter use. The browser either won't remember the size, or it will remember too well and start trying to apply that size to new windows that aren't meant for Twitter.

The browser won't put an icon in my menu bar to show when new stuff has arrived.

The twitter.com window will be mixed in with the others, so cycling through them with cmd-` will be annoying. Conversely, getting to that window specifically will require more work to find it among the others.

Basically, this is a microcosm of why people use native apps at all. The answer is pretty much always "they work a lot better."

The real question: why don't browsers support all of that through a new web standard? None of that is rocket science.

Even if you fixed the others, I don't see how the browser could fix window mixing. That's just a consequence of stuff being in the same app.

Personally, I'd prefer browsers concentrate on being better browsers, not being better at pretending to be real apps. Experience suggests that they'll never be very good at the latter no matter how hard they try, and we already have a perfectly good solution for building something that looks and acts like a native app: an actual native app.

I'm guessing you don't use the site that much? It's awful, and the apps are significantly better. I favor Tweetbot, but if it weren't available I'd use Twitter's OS X app.

Having it as a separate app allows me to do this: https://i.imgur.com/2b1rkb6.jpg

Reply on news.ycombinator.com