What a f'ing fantastic article. Thank you so much for writing this.
I spent a decent chunk of time last year building up a somewhat large Cocoa application (a telling synecdoche of how ambitious the app is: it integrates libevent with the Cocoa loop and involved writing a whole new evented Redis-backed HTTPS cache in ObjC).
But unfortunately, I got to the UI part of this project ("UI part", heh) thinking "this is going to be so much easier than webdev, look at all these tools!, and that was a crushing disappointment; getting anything reasonable on the screen has been intensely painful, and is if anything much harder than CSS3+JQ is on modern web apps.
I'm thrilled to hear that at least to some extent, it isn't just me, and making a good-looking Cocoa app (especially your first) is just very hard.
I had the same experience with my first Cocoa Touch/UIKit project. The GUI stuff far eclipsed the rest of the app in terms of development effort, which I did not expect. This hadn't been the case with previous GUI stuff I'd done (Windows apps, game UIs and the web), and took me completely by surprise.
The "no layouting engine" issue mentioned in the article applies to Cocoa Touch in the same way as it does to Cocoa, with the added wrinkle that if you want to support autorotation, this bites you even harder. Yes, there's the "struts & springs" system, but it's very limited - no equivalent to 'min-width' or 'max-width', and yeah I can't believe I'm citing CSS as a good example. It also doesn't help at all if you need to change the relative placement due to autorotation, or if you need to adjust positioning depending on content.
Styling is another issue - most UI elements can't even have custom colours. (this will improve with iOS 5, but not until iOS4 compatibility is no longer an issue) The default button looks awful. You have to come up with your own table view cells for pretty much anything but the most bare bones of lists.
In the end, I actually built my own fully fledged layouting system, which is content sensitive, has a fairly flexible elasticity system and supports a "flow" layouting mode which is somewhat similar to the way display:inline-block; HTML elements are laid out (but with grow-to-fit). I also built styleable versions of some of the views. If only I wanted to be in the business of building iOS apps, I'd be extremely well prepared at this stage. :-)
My recent foray into Cocoa on the Mac actually has been easier, but that's probably because you can get away with using the default widget styles. Apart from table cells anyway.
I'm not a web guy by any stretch of the imagination, as you well know, but I find doing webdev really easy compared to any GUI library out there. If I can say "ok, this is only going to work in embedded Webkit/Chrome/whatever", I can whip up something that's pretty and functional in no time at all. When faced with the same task in GTK/Qt/Wx/whatever, I fail miserably. I've done a good bit of both, but I doubt I'll ever go back to making desktop apps -- I can always embed a webserver into whatever I'm building, and do the UI that way...
When confronted with porting a previous Win32 app to the Mac, we ended up just rewriting every piece of UI we could in HTML+CSS. It was literally easier to embed Gecko into our app than it would have been to get the UI up and running in Cocoa.
HTML+CSS being easier and more expressive than Win32 didn't hurt either. Shared codebase!
I've had a similar shock getting into iOS development. I'd never done any Cocoa coding before but had heard it praised so highly over the years that I assumed it was going to be all rolling fields and sunshine. But it really does feel primitive in many ways compared to the modern web. Apple will address some of the biggest pain points (layouts, styling) in their next set of OS releases but it's made me appreciate what I've taken for granted for so long in web UI.
I haven't written any apps in Android yet but I've been studying their UI docs and it's clear that their UI kit was informed by the web. If you squint at their code samples they don't look all that different from HTML5 apps: layout in markup, wireup event handlers, go.
I had pretty much the same experience you did, except with Windows (and later on, iOS). It's jarring how, to get really good looking UIs, you often have to do custom pixel positioning and painting in code.
It's almost offensive after doing expressive layouts with html and css.
> Death of the SSH key. People should be able to connect to GitHub with their GitHub username and password.
This sounds like a wrong design decision. I wish nobody could log into my github account using anything but my SSH keys.
This is also true of my AWS account: my ec2 instances are protected by SSH keypairs, but if anyone gets my AWS password, he has full control over everything.
I'm not a security expert, but SSH keys feel way safer than passwords, especially with all those recents article showing how easy it can be to bruteforce passwords.
Holy crap, yes. This was incredibly alarming. SSH keys are far and away more secure than username/password. I would be far more comfortable if it were possible to use GitHub with nothing but my SSH key. The ability to create a passcode-secured key is vital to me, because the keys and the passcodes have to be stolen to be useful at all.
And if you use ssh-agent, I'm pretty sure it doesn't even send your private key; SSH creates a challenge that your key is used to compute, so even someone eavesdropping with a keylogger on the server won't be able to sniff your password.
Since GitHub launched, you've been able to access your repositories via username/password (and add/remove ssh keys via the web interface). But remember — we're talking about client security.
If someone steals/owns your personal machine it's actually much easier to gain access to SSH Keys than find your username/password (since an alarming number of people use passwordless ssh keys).
Aside from that though — SSH Keys are probably the biggest barrier to people being able to use and contribute with GitHub.
I think their goal was to make GitHub (and by extension git itself) more accessible to people who code, but are not familiar/comfortable enough with command line Unix or SSH to generate SSH keypairs. There are a lot of these people.
Although I agree that SSH keypairs feel more secure than a username/password, it would make setting up a new machine for development a lot easier than generating a new SSH keypair and adding it to my GitHub (or any other git server) account.
Without going into whether I agree with his assertions on Cocoa, if it seemed so much easier to do with web technologies, why didn't he just do it with web technologies?
Cocoa is probably the framework best suited for incorporating web views, and tons of apps do this: Mail.app, iTunes, Aperture, Colloquy, etc. etc. Use the right tool for the right job, if you have something that is going to have a lot of flow-based layout, then by all means use WebView.
It's kind of like refusing to use an NSTextView, then complaining about having to lay out text yourself.
Completely agree. Cocoa is appropriate for creating minimalist, system-styled UI. Not for rich flow-based content rendering. See Versions.app: native where it makes sense (filesystem treeview), Webkit elsewhere (history browser).
Great article for sure, but I take issue with these bits:
> Unfortunately for everyone involved, every OS X application that’s showed up over the years gave up and tried to turn CLI commands into buttons.
It's my understanding that for a really long time there was no linkable library for interacting with Git. So unless these devs wanted to first write said library they were pretty much left with putting buttons on the CLI.
You might say "Well they should have written one, then!" but that is quite a risky capital expense on a piece of software that could easily flop. GitHub did it (with Summer of Code's help), but they have umpteen uses of such a library even if nobody uses GitHub for Mac.
> It blows my mind that no one tried to do anything special. Git (and its DVCS cousins like Mercurial & Bazaar) provide an amazing platform to build next generation clients — and it’s like the entire OS X ecosystem left their imagination at home.
I dunno, I think GitX (especially its forks) does some pretty special things, including making it dead simple to stage/unstage/discard single lines of files.
His point was that the OS X applications he saw were just a thin layer over the CLI program - they provided no new abstractions. Whether the OS X application calls a library or calls the CLI program(s) is an implementation detail not relevant to his point.
There is no layout engine for Cocoa. If you want two elements to rest side to side, you’ll need to calculate the pixel size of the text, padding, borders, margins — then manually position the next element.
This is getting a lot better in Lion. If you browse the WWDC 2011 videos, look for Session 103 "Cocoa Autolayout".
As an aside, I really feel like Apple is losing the plot with their latest batch of UIs. Wooden end panels, birch bookshelves, the glossy reflective dock, leather-bound notebooks etc, all smack of a lack of imagination and an timid need to convey value in outmoded terms.
> Eventually, I (well, many of us) decided that better native clients (OSX, Windows, Linux, Eclipse, Visual Studio, etc) was the best way to grow GitHub.
I hope that means they plan to build a git GUI client for Windows, the poor bastard child of git support.
> Simplify the git fetch, pull (--rebase), push interaction. Synchronize — don’t make the user figure out what they need to do to get their local commits remote and remote commits local.
What about conflict resolution? That's one of the hairiest, least-user-friendly scenarios in my experience.
What if there was something like a git deploy command? Basically, when you don't actually care about git functionality on the remote (production/staging) end, that would actually change the remote files. (Yes, I know it can be done with a hook, but that's more of a power user solution, and it's still extra work to setup)
He makes great points about MacRuby. I started tooling around with it for an app a few months ago, and though it was a great interface, it didn't make working in Cocoa any easier, and I still had to learn a lot of weird technology choices in Cocoa.
Though, I think the difficulty of making a complex GUI in Cocoa shines in the OS X world. It's a lot harder to make a working UI, so you want to get the design right the first time, so you don't have to go back and re-do.
Well, MacRuby is a language on top of Objective-C. You can use Cocoa with it, but you should be able to use the Chameleon framework too, assuming it is GC-friendly (otherwise, adding GC support shouldn't be hard). His points don't make much sense to me.
I really like what GitHub do, though in this case I would say that the GitX client (forked one) is way more productive and overview:aböe IMO. I even managed to teach my MBA partner how to use it - this one is actually a bit more confusing than GitX interface. Abstraction is not always for the good, but a very good try at least.
I was excited when I heard about it, but after 5 minutes I was disappointed. Don't get me wrong, it's very well designed. But it didn't add value for me. I use GitX and I find it more useful, and has a better UI.
I think it's a great simple interface for, say, our designers who may need to interact with git but don't necessarily need or want to know more about it than absolutely necessary.
I've been using it for about five days and I keep it open alongside textmate. I'm a CLI diehard but I do still find myself using it for things like switching branches and checking what's in a commit. It really does add value as far as that's concerned.
I'm curious to hear from people who don't know - and don't want to learn - git on the command line. If this gets those uses checking their work into repositories, it will be a net win for version control.
Smartgit is an awesome client for mac and I love the diffs view. Git is complicated so does a simple client help or hurt? I think that's up for debate and different users are going to have different requirements but for me I feel Smartgit is simplistic, useful, and functional where as I think of the Github client as more of an RSS type application where I check the latest stuff that has been committed.
Just wanted to say thank you so very much! I'm just getting started on trying to build an iOS/Mac application system and while it's fairly straightforward to build it, the design of the user interface is what gets me. Going from ok to 'wow' is what really sets Mac applications apart from most PC applications.
On a related note, i've built a simple github browser for ipad that will never get approved on the AppStore due to paid accounts. If someone wants to play with it here's the link https://github.com/oscardelben/GithubBrowser
You can still create an account and provide the Apple reviewers with credentials to try it. This is what we did for an iPad project that uses Facebook photos, we provided Apple with login credentials to a facebook account with lots of photos in it so that they can test it, and the app was approved from the first submission.
This is so unfair. I finally mastered the GIT console pushing and pulling stuff around. And this awesome product comes and the console is now obsolete. Jokes apart, this is super tool that will bring new users that are still not familiar with the console. Great job guys!
I use SourceTree. It's not free, it's definitely not cheap, but it's badass. http://www.sourcetreeapp.com/ (I have no affiliation, just a happy customer)
I've been enjoying the app these last few days. Nice job! It's a great add-on to an already killer service. I'm quite happy to send the folks at Github some of my money each month, because they really earn it.
On the images/code drawing points: are there any benchmarks for this? I've been writing meticulous CGGradient type stuff recently, should I just make a gradient in Photoshop and call it a day instead?
Depends on how you handle the gradients - CG has some neat tricks about reusing gradient rendering if you don't instantiate the same one over and over.
[+] [-] tptacek|14 years ago|reply
I spent a decent chunk of time last year building up a somewhat large Cocoa application (a telling synecdoche of how ambitious the app is: it integrates libevent with the Cocoa loop and involved writing a whole new evented Redis-backed HTTPS cache in ObjC).
But unfortunately, I got to the UI part of this project ("UI part", heh) thinking "this is going to be so much easier than webdev, look at all these tools!, and that was a crushing disappointment; getting anything reasonable on the screen has been intensely painful, and is if anything much harder than CSS3+JQ is on modern web apps.
I'm thrilled to hear that at least to some extent, it isn't just me, and making a good-looking Cocoa app (especially your first) is just very hard.
[+] [-] pmjordan|14 years ago|reply
The "no layouting engine" issue mentioned in the article applies to Cocoa Touch in the same way as it does to Cocoa, with the added wrinkle that if you want to support autorotation, this bites you even harder. Yes, there's the "struts & springs" system, but it's very limited - no equivalent to 'min-width' or 'max-width', and yeah I can't believe I'm citing CSS as a good example. It also doesn't help at all if you need to change the relative placement due to autorotation, or if you need to adjust positioning depending on content.
Styling is another issue - most UI elements can't even have custom colours. (this will improve with iOS 5, but not until iOS4 compatibility is no longer an issue) The default button looks awful. You have to come up with your own table view cells for pretty much anything but the most bare bones of lists.
In the end, I actually built my own fully fledged layouting system, which is content sensitive, has a fairly flexible elasticity system and supports a "flow" layouting mode which is somewhat similar to the way display:inline-block; HTML elements are laid out (but with grow-to-fit). I also built styleable versions of some of the views. If only I wanted to be in the business of building iOS apps, I'd be extremely well prepared at this stage. :-)
My recent foray into Cocoa on the Mac actually has been easier, but that's probably because you can get away with using the default widget styles. Apart from table cells anyway.
[+] [-] daeken|14 years ago|reply
[+] [-] kevingadd|14 years ago|reply
HTML+CSS being easier and more expressive than Win32 didn't hurt either. Shared codebase!
[+] [-] cageface|14 years ago|reply
I haven't written any apps in Android yet but I've been studying their UI docs and it's clear that their UI kit was informed by the web. If you squint at their code samples they don't look all that different from HTML5 apps: layout in markup, wireup event handlers, go.
[+] [-] statictype|14 years ago|reply
[+] [-] gregschlom|14 years ago|reply
This sounds like a wrong design decision. I wish nobody could log into my github account using anything but my SSH keys.
This is also true of my AWS account: my ec2 instances are protected by SSH keypairs, but if anyone gets my AWS password, he has full control over everything.
I'm not a security expert, but SSH keys feel way safer than passwords, especially with all those recents article showing how easy it can be to bruteforce passwords.
[+] [-] koko775|14 years ago|reply
And if you use ssh-agent, I'm pretty sure it doesn't even send your private key; SSH creates a challenge that your key is used to compute, so even someone eavesdropping with a keylogger on the server won't be able to sniff your password.
[+] [-] kneath|14 years ago|reply
If someone steals/owns your personal machine it's actually much easier to gain access to SSH Keys than find your username/password (since an alarming number of people use passwordless ssh keys).
Aside from that though — SSH Keys are probably the biggest barrier to people being able to use and contribute with GitHub.
[+] [-] umjames|14 years ago|reply
Although I agree that SSH keypairs feel more secure than a username/password, it would make setting up a new machine for development a lot easier than generating a new SSH keypair and adding it to my GitHub (or any other git server) account.
[+] [-] brendoncrawford|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] tolmasky|14 years ago|reply
Cocoa is probably the framework best suited for incorporating web views, and tons of apps do this: Mail.app, iTunes, Aperture, Colloquy, etc. etc. Use the right tool for the right job, if you have something that is going to have a lot of flow-based layout, then by all means use WebView.
It's kind of like refusing to use an NSTextView, then complaining about having to lay out text yourself.
[+] [-] nfarina|14 years ago|reply
[+] [-] sant0sk1|14 years ago|reply
> Unfortunately for everyone involved, every OS X application that’s showed up over the years gave up and tried to turn CLI commands into buttons.
It's my understanding that for a really long time there was no linkable library for interacting with Git. So unless these devs wanted to first write said library they were pretty much left with putting buttons on the CLI.
You might say "Well they should have written one, then!" but that is quite a risky capital expense on a piece of software that could easily flop. GitHub did it (with Summer of Code's help), but they have umpteen uses of such a library even if nobody uses GitHub for Mac.
> It blows my mind that no one tried to do anything special. Git (and its DVCS cousins like Mercurial & Bazaar) provide an amazing platform to build next generation clients — and it’s like the entire OS X ecosystem left their imagination at home.
I dunno, I think GitX (especially its forks) does some pretty special things, including making it dead simple to stage/unstage/discard single lines of files.
[+] [-] scott_s|14 years ago|reply
[+] [-] tsetse-fly|14 years ago|reply
[+] [-] pohl|14 years ago|reply
This is getting a lot better in Lion. If you browse the WWDC 2011 videos, look for Session 103 "Cocoa Autolayout".
[+] [-] cageface|14 years ago|reply
[+] [-] andrewf|14 years ago|reply
http://speedbird.wordpress.com/2010/06/25/what-apple-needs-t...
[+] [-] RyanMcGreal|14 years ago|reply
I hope that means they plan to build a git GUI client for Windows, the poor bastard child of git support.
[+] [-] jkkramer|14 years ago|reply
What about conflict resolution? That's one of the hairiest, least-user-friendly scenarios in my experience.
[+] [-] TylerE|14 years ago|reply
[+] [-] cdcarter|14 years ago|reply
Though, I think the difficulty of making a complex GUI in Cocoa shines in the OS X world. It's a lot harder to make a working UI, so you want to get the design right the first time, so you don't have to go back and re-do.
[+] [-] lrz|14 years ago|reply
[+] [-] grimen|14 years ago|reply
[+] [-] chrismealy|14 years ago|reply
[+] [-] kenneth_reitz|14 years ago|reply
[+] [-] beck5|14 years ago|reply
[+] [-] waleedka|14 years ago|reply
[+] [-] msbarnett|14 years ago|reply
For power users, look elsewhere.
[+] [-] kneath|14 years ago|reply
[+] [-] pnathan|14 years ago|reply
I think it's a very simplified view of source control and badly needs to be iterated to appeal to power users.
That said, I'd recommend it for novices to source control.
[+] [-] sunchild|14 years ago|reply
I don't know why people are trashing this app. It's not exactly hard to use the command line if you don't like this app.
Using a GUI on git is just a convenience, and probably most useful for new git users.
[+] [-] ghotli|14 years ago|reply
[+] [-] RyanMcGreal|14 years ago|reply
[+] [-] atomical|14 years ago|reply
[+] [-] gawker|14 years ago|reply
[+] [-] oscardelben|14 years ago|reply
[+] [-] leviathan|14 years ago|reply
[+] [-] ttrashh|14 years ago|reply
[+] [-] vladocar|14 years ago|reply
[+] [-] swaits|14 years ago|reply
[+] [-] peteysd|14 years ago|reply
[+] [-] natesm|14 years ago|reply
[+] [-] theatrus2|14 years ago|reply