Scuttlebutt Regarding Apple’s Cross-Platform UI Project
There is indeed an active cross-platform UI project at Apple for iOS and MacOS. It may have been codenamed “Marzipan” at one point, but if so only in its earliest days.
[…]
I don’t have extensive details, but basically it sounds like a declarative control API. The general idea is that rather than writing classic procedural code to, say, make a button, then configure the button, then position the button inside a view, you instead declare the button and its attributes using some other form. HTML is probably the most easily understood example. In HTML you don’t procedurally create elements like paragraphs, images, and tables — you declare them with tags and attributes in markup.
[…]
It’s a 2019 thing, for MacOS 10.15 and iOS 13. I would set your expectations accordingly for this year’s WWDC.
Sounds like that‘s referring to a pair of separate projects (known alternately as “Amber,” “Infrared” and “Ultraviolet”) from the Swift team. Not the same as the iOS apps on Macs initiative. There are many moving pieces with a major multi-year, multi-step project like this.
This initiative likely intends to replace NIB files with Swift, linked to Interface Builder, which could allow developers to declare their UIs by hand or by using the existing visual tools, much like XAML on Windows.
A declarative control API, especially using a markup language like XML, opens up a lot of tooling possibilities. Apple could extend Interface Builder to create these declarative APIs, but I would love them to return to more powerful standalone UI tools. When Microsoft unveiled XAML, they also unveiled a tool called Sparkle, which eventually became Microsoft Expression.
Some kind of higher level declarative API atop Auto Layout sounds great. I really hope it’s not a markup language. That seems only marginally better than what we have now with nibs. The are pros and cons to using data vs. using code, but I think technologies like Auto Layout and Swift Playgrounds can eliminate most of the advantages of data, making it possible to unleash the power of code.
We don’t know what it is. But my guess — based on my 38 years of writing code for Apple computers — is that it’s something you can use along with UIKit and AppKit, and not a wholesale replacement.
Hmm. I’m inclined to trust @gruber’s sources here to a point, but I nonetheless feel like it’s suicidal for macOS to let this rumor be out there but not launch in 2018.
They could have made a more explicit attempt to tamp down that rumor at the time, for one thing - leak to someone like yourself that no, AppKit is AppKit and UIKit is UIKit and you should keep writing Mac apps.
In my experience they don’t do that. Because if they did that to handle false rumors they’d give away when rumors are spot-on with their silence. The only rational strategy is silence, with rare exceptions.
Previously: Apple Rumored to Combine iPhone, iPad, and Mac Apps to Create One User Experience.
Update (2018-05-01): Dave Winer:
Reading Brent’s piece about Mac development made me think about the ideal, what I really want from being a developer for as long as I’ve been a developer. The thing that got me started was the independence of it. I could have taken a job at Bell Labs or some big mainframe or minicomputer company, and had a nice career being pushed around by bosses at big companies. But I went for PC development because it was something I controlled. I could do what I wanted. Make my own art. The things I wanted to do were things no company would approve of, they had no way of understanding it. And at first it was lovely. Then the corporate bosses at the PC companies started pushing us around and it turned to shit.
Update (2018-05-02): Mark Bernstein:
When personal computing got started, you could make pretty serious money by creating a good tool that people needed. Dave did that with MORE. Dan Bricklin did it with VisiCalc. Mitch Kapor with Agenda. There were lots more. No guarantees, certainly, and some good and smart people never got the big payday, but it was a real possibility.
That’s gone. The real money in iOS software comes from writing frauds and manipulating sad psychological quirks; it turns out that just about nobody makes a living, much less a killing, designing great iOS software. The economics are better on the desktop, but not much better.
The big fear from the iOS-macOS rumor is that Apple will destroy that, that they’ll cripple the Macintosh so badly that we’ll be left with a complete wasteland of 99¢ junk apps. There’s no place to run, no other viable desktop with a future.
See also: Accidental Tech Podcast.
10 Comments RSS · Twitter
If they're talking about generating UI elements from a data file, how is it really different from a NIB? Or from the old Classic Mac resources for that matter? They may change the file format, but people are still going to edit the content with specialized editors of one kind or another because the underlying data file (even if it's in a human-readable markup language) will likely be too complicated to try and edit by hand, for all but the simplest constructs.
If they're talking about generating UI elements via code, that's different. But that opens up a whole different can of worms and it is hard to see how that would be an advantage over using NIBs (or some hypothetical enhanced-NIB). Especially when one can always write code to manage UI elements if there is something that can't be done comfortably with NIBs.
@David It would be different because it would be more friendly to version control and because I don't think it has to be too complicated to edit by hand. I see code as an advantage. I would love to think that “one can always write code,” but there is actually already at least one case where iOS prohibits that and requires a storyboard file. Core Data also has some features that could easily work with code but which they decided to require compiled model files for.
"I see code as an advantage."
That depends very much on the language. A declarative relational DSL would hit the spot for binding controls to models and vice-versa. (What Cocoa Bindings should have been.) But that assumes Apple has the talent and the will to create the solution to fit the problem, as opposed to dive in their grabbag for something they can stuff in the hole. Seeing how both Swift and Cook come from the latter, dominant, school of product design, I won't get my hopes too far up.
What is the difference between the modern programmer and stone-age man?
One recursively constructs a rich and sophisticated set of life-enhancing tools, while the programmer just keeps banging the rocks together.
(Ingenious buggers, our ancient ancestors: stones are shaped into knives… which cut wood, bone, sinew, and skin… which become spears, bows and arrows, fire-making tools… yielding leather, threads and needles, cooked food… enabling the crafting of clothing, tents, and fine French cuisine… and so on, and so on. Alas, it's pretty much been downhill since then—bloody irony.)
@has Binding controls is the easy, less important part. Creating the view hierarchy in a properly abstracted way is where IB and likely a DSL would fall down. Even though HTML and CSS are declarative and reasonably well designed, we often end up relying on code to generate them.
Binding's the tricky part from the user POV, as that's where you get all your synchronization issues and boilerplate bloat, when all you really want to say is A = B. (Not to mention error-plagued impedance mismatch of Cocoa Bindings' untyped IB-based construction.) A smarter, dedicated language would look after all of that.
As for how controls get placed on screen, that's mostly orthogonal to the bindings issue, and ideally should be well decoupled too so that different control types/layouts can be used according to device needs without having to build a complete set of bindings for each. Though again, the wise thing to do is to use a declarative text-based DSL; preferably something Lisp-derived, so it can just as easily be read and written by humans as by machines and tools. (Avoid XML/JSON/etc as they're purely machine-to-machine transport formats and suck for humans to read/write; xibs being the obvious example.) Compositional construction: achieve more with less.
A wonderfully rich and tasty tool design (and product marketing!) challenge for the right kind of people (I love this type of problem, as you can tell), but like I say I just don't think you'll find those people in Apple (not in any position to make it happen, anyway) as programmers typically hate disruptors even more than MBAs do.
As Mark and Colin mention above, Microsoft has had this declarative approach for years in the form of XAML. They also have LINQ for more declarative-style data binding for C#, and a functional-first language in the form of F#. And Xamarin for cross-platform shared-code development.
Sad to say, but it seems like for everything Apple is trying to do or might try to do in the future (Swift, Marzipan, declarative UI), Microsoft already has something that 1) already exists, and 2) is much more stable and mature, and 3) generally ready for Apple developers to use, instead of relying on vague rumors about future frameworks that may be years away from release and require even more years to stabilize and mature (e.g. Swift and Auto Layout).
[…] did, as rumors suggested over a year ago, introduce a declarative views library. I correctly surmised that Interface Builder XML would be […]
[…] did, as rumors suggested over a year ago, introduce a declarative views library. I correctly surmised that Interface Builder XML would be […]
