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.
Um, there is a layout engine for Cocoa. It's called UIWebkitView... But the fact that you felt the need to write your own layout system instead of using the existing one suggests that generic layout systems don't give the needed flexibility, which means that it is more important for an API to provide the tools to build a layout system than to provide a layout system. Cocoa is one of the better frameworks for building layout systems in my experience (Java SWT, Cocoa, MFC - haven't tried .NET).
UIWebView is (presumably deliberately) pretty restrictive in its JS<->native bindings. Having to redirect to URLs which are then intercepted on the Objective-C side is pretty awkward. Then there's the fact that HTML/CSS aren't even that great for designing UIs, since they were created for document styling.
Any interest in either open sourcing said layout system or perhaps even selling it to those of us who struggle with these sort of problems (a la Sensible TableView)?
We've put some of the styling-related components online on http://appuicomponents.com/ but the layouting engine isn't there yet, I do feel it's valuable enough to productise eventually. The main problem is lack of polish right now. Interface Builder isn't much use once you get to that level of customisation - there's no way to set properties your subclasses introduce, let alone previewing the automatic layouting. I'd like to fix that at some point and have some ideas on how it could be done. Aside from that, I also still need to document the system, and tidy up the code implementing the layouting, as it's currently not the easiest to debug or find out why something isn't being laid out as you were expecting, even if the layout system itself isn't doing anything wrong.
Then of course there's the fact that I'm spending almost all my time on our startup, which is completely unrelated to iOS. (but it has a Cocoa-based Mac GUI, hence my recent Cocoa adventures)
Actually, if you're interested in the layout kit, go ahead and drop me a line (email on the website I mentioned, or in my HN profile) with what you're trying to do - if it does what you want, I'd be quite happy to progressively tidy it up and document it if I've got one or two users who are willing to put up with the rough edges initially, in exchange for some hand-holding.
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!
Absolutely. This is why I think native apps are going to hit an asymptotic growth limit eventually. Native will have its place but it's already so much easier to build a typical data-centric UI in HTML5.
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.
The Microsoft visual designers are really easy to use. I was able to figure them out when I was 15 or 16 or so. I can wire together stuff in the wx* toolkits in code by hand.
XCode Interface Builder baffles me still. It's really garbage compared to Visual Studio, IMO. Really a shame.
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.
Not sending your private key inherent property of public-key authentication, and is used in all instances of SSH key-based authentication. ssh-agent is merely convenient "keyring" type application so you do not have to continually re-enter the passwords for the on disk encrypted private key files. (You are encrypting your ssh keys with a password right?)
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.
> SSH Keys are probably the biggest barrier to people being able to use and contribute with GitHub
The barrier to entry of writing software doesn't need to be zero. If a person is going to write code, they should also learn some of the basic tools of the trade.
And I'd claim that an SSH key isn't one of them. There is only one platform (UNIX-based web applications with application servers) that actually benefits from them, and plenty that don't (Android, iOS, Mac desktop, Win32, this week's .NET desktop stuff, ASP-of-the-week, Windows Phone 7).
As a company that makes money from users, it's to GitHub's benefit to make it easy to use their stuff.
I use SSH keys to log into Linux and OS X boxes all the time, servers and otherwise. And boy have I wished there was an easy SSH server to run on Windows.
You have to log into remote boxes these days and SSH keys are the best way to do that.
(Until 1password gets iTerm2 integration anyway, but the 1password guys don't seem receptive to that idea)
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.
Couldn't the app use your username / password to connect to github the first time and then generate an SSH key pair which it would use from that point forward?
That seems like the best compromise of security and easy of use to me.
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.
What are these but misguided coddles, patronizing crutches, interactively horseless carriages?
Nailed it. Great article. Apple's hardware is as beautiful as ever but their software UI seems to have gone right of the rails. I wish Google's wasn't aping that dumb page curl effect in their own books app.
Howard Roark (of Ayn Rand's Fountainhead) would hate where Apple is taking their design.
From the book:
"His buildings are austere, logical, perfect, each a single thought in stone. He believes that buildings, like men, have souls, and that no part of a building should in any way betray its soul. No building should borrow its parts from others or apologize for its own shape. No building should present a false front."
And another quote:
"The buildings in these drawings are like none ever built on earth. They seem severe and simple at first glance, but closer observation reveals the strict tension of thought and method, a cold, beautiful logic behind each wall and pillar. Every building seems to have a soul."
I hope Apple turns down the woodgrain knob and cranks up the cold, beautiful, and logical knob in their future designs.
> 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.
What I think part of the problem people have with it is that it doesn't necessarily do what a seasoned git user would expect when syncing remote repositories, such as the fact that it pushes and pulls at the same time, and the pulls aren't normal pulls, they're rebase pulls.
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.
Tried that without success. Maybe it depends on the person examinating it. Btw it took them two months to reject the app so there must have been something going on.
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.
Xcode tracks files with an XML "project file." So if you add files in one branch and remove files in another branch, it often puts this project file into a conflicted state. Resolving conflicts in this file is really difficult — lots of confusing paths and SHAs all mixed together. If you don't resolve conflicts correctly, the entire project refuses to open.
Thanks, that makes sense. Is it often that these conflicts arise during development on a team of 1-3 developers? I'm also assuming you're referring to the package contents of the .xproj file (specifically project.pbxproj), correct?
I work on a project with 3 other devs; an xcode conflict is an "oh, bummer" moment, but not a hairpuller. 90% of the time we've both added files, and the merge is as easy as "choose both."
It's still the sort of thing where you want to check out, change the project, and check back in quick to avoid conflicts. I can imagine it getting worse with far-distance branches though.
It's not too different from a makefile, except you'll get a better error message when you muck up your makefile.
It's amazing, I thought I would come here to learn things, but instead I am teaching.
Branching projects is hard in XCode? Zip up the project files and back up the revision... in I don't know, a source code repository? LOL!
None of the re-writing is required in Xcode for your app. Design the app, then make it in Xcode. If you have to make revisions to the design of your app, go back to designing it. Most of the code can be re-used, but clearly you haven't finished designing the app yet...
Interesting take on the initial experience. But instead of casting about for blame, it might be better to ask why your processes are going wrong.
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.