Comment by ben_w | Hacker News Reader

Comment by ben_w | Hacker News Reader

Parent Full thread

I think that's also true, but not the thing they're writing about.

My experience as an iOS developer has been mixed between places that use Interface Builder and those who create the UI in code. Something like Interface Builder is obviously a great idea for UI creation, which is why it survived so long and why Figma exists, but the actual tool itself (IB) isn't really useful for desigers who want one thing that works on all platforms. (Complaints like "xib and storyboard are hard to use with version control" miss the point; a UI designer shouldn't be seeing git-style text diffs anyway, they need a graphical diff).

Interface Builder is at least 5x faster than making the UI in code; one place in particular, I was making a native app by myself while a whole team was making a web app, and I wasn't simply keeping up with them, I also cought up the headstart they had built while I'd been assigned to a different project. The next place I joined a team and their app was a coded UI, and development was correspondingly slow. (Though how much of this is "teams are slower than solo developers" vs. my hypothesis is unclear to me).

My first coding job was before iOS existed, I was industrial placement student* in an academic research lab, and for that, my guess would be the best option mayhaps have been a mathematical formula WYSIWYG editor that output both latex and IDL.

* does this term get used outside the UK? What's the overlap between this and intern?

Haven't worked with the iOS interface builder but i worked with Delphi ages ago.

Question: how well does the interface builder thingy mix with interface in code?

Can you easily lay out the basics of an UI graphically and then add code where the builder is too limited for what you need?

Or it's the kind where if you start with the graphical builder you're stuck with just what the graphical builder can do?

A quick overview of Interface Builder is Steve Job's demo for NeXT --- perhaps:

https://www.youtube.com/watch?v=dl0CbKYUFTY

where they discuss how dragging/drawing allows one to make 80% of the app, and the balance of 20% is one's own code.

> What we found a long time ago was, the line of code that a developer can write the fastest, can maintain the cheapest, that never breaks for the user, is a line of code the developer never had to write.

> The goal here is to literally eliminate 80% of the code that every developer has to write for their app - because it's in common with every other app. And let them focus on just the 20% of their code that's unique and value-add to their app. That's what this is all about.

---

A video of historical interest - OpenStep's Interface Builder in 1997, the year Steve Jobs returned to Apple.

It shows how forward-thinking NeXT was. Many of its innovative user interface concepts are relevant and in use today in different guises and interpretations.

> Every single app on NeXTSTEP was built using Interface Builder. It is the frosting on top of this object-oriented cake that we have called NeXTSTEP.

In the demo, Steve seems to use the word "object" with a depth of meaning closer to what Alan Kay explained, like independent (or rather interdependent) "cells" of software that communicate to each other via messages.

> OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.

On the Meaning of “Object-Oriented Programming” - http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...

It's interesting that the Interface Builder was considered a "frosting" or visible representation of the underlying objects, which the users more or less directly created, edited, and connected together - without writing a line of code.

That ideal of user experience still hasn't been fully achieved to satisfaction, it feels. The ease and naturalness of creating software visually, as well as with other modalities, senses, medium of expression beyond text.

I'd give a lot to have a graphical development environment which:

- allowed drawing a user interface as naturally as I used to use Altsys Virtuoso (or Macromedia Freehand which I moved to when my Cube stopped working)

- allowed programming the UI as naturally as HyperCard (and to a lesser extent Lisp) "clicked" for me

- was as visual as Google's Blockly (which as BlockSCAD: https://www.blockscad3d.com/editor/ I've used a fair bit)

- exposed variables in a mechanism like to OpenSCAD's Customizer: https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Customize...

Currently plugging away with OpenSCAD Graph Editor: https://github.com/derkork/openscad-graph-editor but hoping that: http://nodezator.com/ will become a viable option (still a bit bummed that I rolled and crashed w/ https://ryven.org/ though in retrospect, maybe I should try to tie that latter in to: https://pythonscad.org/ )

If you haven't seen it, the Interface Builder got its inspiration from this Interface Builder written in Lisp: https://vimeo.com/62618532 The version in the video actually ran on a TI MicroExplorer Lisp Machine NuBus board in a Mac. There were other ports which ran directly on the Mac in Lisp.

The thing was shown to Steve Jobs and he hired its main developer, Jean-Marie Hulot.

Ah yes, I remember the funny guy facing various dramatic software difficulties in the first part of the video.

This builder does look like a precursor to NeXT's and HyperCard too. I like that the "toolbox" appears next to the mouse, instead of having to go to the top menu or sidebar to select a new tool and back to position to use it. I missed that it ran on a Lisp processor, very cool!

And that the main developer later worked at NeXT and Apple.

> Jean-Marie Hullot authored important programs for the original Macintosh, NeXTSTEP and Mac OS X platforms. These include SOS Interface for the Mac, which later became Interface Builder for NeXTSTEP (1985), and later still evolved into an important part of Mac OS X.

> He also came up with the idea of the iPhone and led the iCal and iSync development teams for Mac OS X (2002).

https://en.wikipedia.org/wiki/Jean-Marie_Hullot

..Searching for "SOS Interface for the Mac", I guess it's Sophisticated Operating System, "the primary operating system of the Apple III computer" released in 1980.

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

Let's not do the usual thing of allowing Jobs to get away with claiming other people's advancements. VB and Delphi by '97 already had that sort of interface builder - arguably much better ones. NEXT was trying to catch up with what Microsoft had already done on Windows by then.

That's great that VB and Delphi had one in 97, but the Interface Builder for NeXT was released in 1988.

Oh definitely NeXT was standing on the shoulders of giants, prior art, and historical precursors. He did present it well though, with a quotable and catchy demo.

It mixes well.

Apple has two UI frameworks, UIKit and SwiftUI, and Xcode's Interface Builder handles each differently. The Interface Builder for each is built into Xcode, but the UI they present when editing is quite different — I'm unclear if they're both officially called "Interface Builder" or if people like me stuck with the same name for the new one because it's a thing for building interfaces.

The older system is UIKit, where Interface Builder produces some XML files — .xib or .storyboard — and once those are loaded, they result in objects which are fully manipulable in code.

The newer system, SwiftUI, the source code is the source-of-truth for a WYSIWYG editor — any change made in the editor immediately updates the code, any change in code immediately updates the editor. That said, in my experience at least, this editor falls over quite often if you do that.

Mixes Well is an understatement. I couldn't imagine writing any more than a simple toy app without it. I've experimented with building an iOS UI purely in code, and while it is possible, it is a painful, masochistic, and slow way to develop.

The idea is to do everything trivial via the interface builder thing of the platform but not get limited by it when you want to customize the last 10%

> any change made in the editor immediately updates the code, any change in code immediately updates the editor.

Delphi memories :)

> That said, in my experience at least, this editor falls over quite often if you do that.

Not-Delphi memories.

Reply on news.ycombinator.com