Phillip Caudell @phill@mastodon.notsobig.co

@BenRiceM the Moco Museum was fantastic.

I also fondly remember Tales and Spirits as a great cocktail bar (though admittedly I was off my tits)

The Creator was excellent and easily one of the most exciting sci-fi movies I’ve seen in a long time.

It felt like James Cameron and Spielberg made a film together. I can’t stop thinking about it.

Go see it in the cinema if you can!

@krzyzanowskim oh you get this effect if you set a material background with .onHover. It’ll get progressively slower with each extra view in the hierarchy.

@cabel the radio personality in question:

@BenRiceM can’t be any bugs if none can be filed

technology has peeked

@realmacdan so much to unpack here 😅

@giladronat 100%

Like I said I don't think it's something they would do. It's just hard not to draw comparisons to Apple's other OS efforts where it's been working out so well for everyone.

But who knows: they've surprised us before 😛

@giladronat @objc all very true and excellent points.

But I imagine just like Swift itself, you wouldn’t need to understand the source to benefit. Countless contributions from the community make it less likely for you to experience issues in the first place, either by direct fixes to the lang, or through the dissemination of knowledge.

@DanielBerezhnoy yup I talk about Airbnb a couple of posts down

@dominic I won't let the current build expire, don't worry!

@kaybutter @kkolakowski Sure, there were issues (see https://mastodon.notsobig.co/@phill/111108006903449808) but I would argue the severity (and recourse) were very different.

One objective measure: my first Radar/Feedback was 2012. Historically I've done one or two a year. This year I've filed 13.

@GiorgioRomano anecdotally it does seem to be the boundaries of UIKit/AppKit that have the most issues.

And you're right, it’s phenomenal for layout composition 🙂

@rabc You're absolutely right that UIKit is not without its faults: https://mastodon.notsobig.co/@phill/111108006903449808

But we're in year 4 and the fundamentals like List and Navigation are still having significant issues. That is different.

And look, Apple's frameworks have always had bugs. Many of us lived through UISearchDisplayController 💀

But there are two differences:

1. UIKit/AppKit's API surface is much larger. There are just more knobs and dials to turn when things aren't working. Abstracting complexity comes with a cost.

2. The frequency and severity of issues. It would be unimaginable if UINavigationController was left broken for several cycles, but that's exactly what's happened: https://mastodon.notsobig.co/@phill/110939609793823190

Airbnb's recent article highlighted something I think about a lot:

"While Swift and its surrounding foundation have been open sourced, SwiftUI’s implementation remains a black box. If SwiftUI were open sourced, we could better understand the framework and debug more effectively.”

I don't think Apple will ever do it, but boy that would go a long way in fixing many of the issues SwiftUI has today.

(The whole article is great read, btw)

https://medium.com/airbnb-engineering/unlocking-swiftui-at-airbnb-ea58f50cde49

No doubt you can ship amazing things with SwiftUI. I see many great examples of it.

But I also see many examples of developers pulling their hair out trying to understand why their app isn't behaving as expected.

Things that once worked now don't because of an OS update. Or some modifier begins interacting with something in an unexpected way. Or something isn't clearly documented.

Here's a prime example of what developers mean when they question "is SwiftUI ready for production?”

A simple menu. Left iOS 16.4. Right iOS 17.0.

One works. One fails. Same code.

I love SwiftUI, but it's this kind of thing that make me lose confidence in it.

https://gist.github.com/phillipcaudell/269e1d9abe1dea1709327fc95560760f

@constantine 👍

@alpennec there's no SwiftUI API. If you haven't already, here's my UIKit wrapper: https://gist.github.com/phillipcaudell/c7135ec8d7933e391fc6223448a6af0a