
Twitter’s updated Mac app wasn’t made by Twitter - coloneltcb
http://www.theverge.com/2015/12/30/10691290/twitter-mac-outsourced
======
drewcrawford
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.

~~~
yeukhon
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?

~~~
cballard
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.

~~~
virmundi
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.

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

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

~~~
derefr
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?

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

------
tolmasky
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?

~~~
dewitt
> … _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...](http://www.theverge.com/2015/10/21/9586084/jack-dorsey-twitter-ceo-
apology-developers)

~~~
hrayr
> _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](https://www.producthunt.com/live/jack-
dorsey#comment-202231)

~~~
BillinghamJ
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.

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

~~~
morgante
> 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.

~~~
golergka
> 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.

~~~
morgante
> 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.

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

------
santaclaus
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?

~~~
krschultz
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.

~~~
smackfu
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.

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

~~~
ajmurmann
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.

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

~~~
morgante
> 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.

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

~~~
morgante
Oh, in that case I completely agree.

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

~~~
ChrisClark
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.

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

------
nitin_flanker
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_

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

~~~
SyneRyder
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...](http://web.archive.org/web/20100922230053/http://blog.atebits.com/2008/12/fast-
scrolling-in-tweetie-with-uitableview/)

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

~~~
rloc
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).

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

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

------
flurdy
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](https://about.twitter.com/products/tweetdeck)

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

------
iamleppert
Is Twitter the new Yahoo!?

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

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

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

~~~
natch
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.

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

~~~
agiamas
I don't agree. As an example: Bootstrap, by Twitter -
[http://bootstrapdocs.com/v2.0.2/docs/](http://bootstrapdocs.com/v2.0.2/docs/)

------
forgingahead
Must be a slow news day

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

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

------
rocky1138
Why don't people just go to [https://twitter.com](https://twitter.com) in
their web browser instead?

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

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

~~~
mikeash
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.

