Thread by @chockenberry

If you don’t see the SwiftUI DSL as an awesome way to build HTML, CSS, and JavaScript, you’re not looking at the abstraction closely enough.

The web is just another surface to render on.

Of course this might lead to a situation where the easiest way to build an Android support would be with Xcode on your Mac.

Think about all the effort that Apple has put into getting things like iWork in a browser.

They’re thinking about this, for sure.

Being free of how things are represented visually, and instead focusing on how things function, opens us up to a wild new set of possibilities.

Now think about AR and voice…

The more I think about it, the DSL will be the part that gets open source, the platform-specific ViewBuilders may or may not. (Anything that ends up in a CALayer won’t.)

And that’s fine — the real value is in the abstraction.

Don’t underestimate what is going on here: I haven’t been this excited about how we make products since the Carbon to Cocoa transition.

This is an absolutely fundamental change that we’ll be using for decades.

I wrapped these thoughts up into a blog post: furbo.org/2019/06/07/the…

I had some more thoughts about where SwiftUI could be going in the future, so let's make this long thread even longer!

Apple has learned a lot from WebKit being open source. I'm guessing it was the inspiration behind doing the same thing with Swift.

WebKit certainly had benefits for Apple, but it also had benefits for it's competitors: every mobile platform uses it in some way (Blink's heritage is WebKit.)

Has this been a threat to Apple's products or market? No.

It's because Apple adds a ton of value on top with Safari.

Things like industry-leading security, improved battery life, iCloud tabs, etc.

I see something similar happening with SwiftUI. How you render content isn't as important as where you get it or how you market it.

Apple doesn't have to concern itself with who uses ViewBuilder.

Say you could use SwiftUI to make an Android app.

Is that app going to be able to use the iCloud, News, Music, or any of Apple's other services? Maybe, maybe not.

It's Apple's decision and where they have control over content & market. SwiftUI doesn't matter.

Remember that Apple already has an Android app for Music.

play.google.com/store/apps/det…

Would they like to have a cross-platform story there? Minimize the development effort and lag between the two major mobile platforms?

Oh yeah.

I hope this vision of SwiftUI comes to pass because it will let EVERY developer, including Apple, focus on products rather than how you implement them. That's a revolution.

/cc @tkremenek

The work with DSLs will also go far beyond work with user interfaces.

Anyone who's dealt with inputImage/outputImage chaining in Core Image will immediately see how a declarative and functional construct would be 1000% better.

Think about Core Data models in a DSL. Maybe with Combine to deal with propagating changes through that model.

SwiftUI is the first, but I doubt it's the last.

One thing to be careful of with DSL: getting too abstract and magical.

I've recently been working on some Ruby/Rails code that used DSLs and I had no idea how it functioned.

The fact that SwiftUI shows you when the DSL is modified is super important.

I hope this trend of seeing the DSL work while you edit continues.

Think about how much easier it would be to work with Core Image and Core Data with this kind of feedback. You learn as you do.

Holy shit. The idea of rendering SwiftUI as HTML, which started this humongous thread, has been implemented by @zhuowei:

https://twitter.com/zhuowei/status/1137233777137078272

Another day, another extension to this long ass thread.

Let's think a bit about how Catalyst fits into this new SwiftUI world. To do this, I'm going to reminisce a bit about Blue Box.

The fact that you probably don't know about this early Mac OS X component is instructive.

Blue Box was an environment where you could run classic Mac OS apps on the new version based on NeXTSTEP.

It was a compatibility layer that let developers run code on the new system with minimal changes. It made things easier at first, but eventually became a burden for Apple.

Classic was an environment that EVERY developer used, including Apple. It kept important parts of the system available during a transition.

en.wikipedia.org/wiki/List_of_m…

But then things like new processor architectures came along and made it a pain in the butt.

My guess is that the Catalyst emulation layer will suffer a similar fate. It's enabling some development to get off the ground quickly (like having a UIView for SwiftUI on macOS.) But eventually SwiftUI will mature to the point where it's working directly with CALayer.

At that point, Catalyst becomes a liability. Updating AppKit and UIKit only benefits old code. And we all know how Apple likes to move things forward.

We're certainly many years from that point, but I'm fairly certain it will come.

The fact that your only choice on watchOS is to use SwiftUI means that for one of Apple's platforms, that day has already come.

The eyeballOS for AR glasses will have these same restrictions for the same reasons.

I also can see Apple taking this platform abstraction beyond UI and views. NSApplication and UIApplication could be abstracted into a SwiftApplication class. Or maybe Environment adapts to different platform use cases.

Either way, I get the feeling we're just at the beginning…

I'm also wondering if this thread will ever end :-)