Josh Shaffer

Come check out SOTU with us! So much exciting stuff to talk about.

@qalandarov @elizablock I can definitely see why that’s surprising! Thanks for the report. The explanation: without the dot you have an infinitely recursive view. Swift’s implicit self means that’s: ZStack { Button(…) self.animation(…) } It’s nesting infinite ContentViews within itself

Already submitted as a bug-report. @joshshaffer @elizablock you might find it interesting

The SwiftUI Previews team is hiring! We get to provide the preview experience for Xcode and Swift Playgrounds. We love sitting at the intersection of tools, languages, frameworks, and the system. If this sounds interesting, please apply or DM! jobs.apple.com/en-us/details/…

@ChristianSelig @zmknox It most definitely didn’t come off as you promoting anything! I was just surprised I never thought to try it.

@zmknox @joshshaffer I feel kinda bad about that in a way! I was honestly just curious if there was a cool widget out there I was sleeping on, hope it didn't seem promotional!

@twostraws @jacobx Thanks for joining Paul! That was really fun. Hope you enjoyed it!

30 minutes from now @joshshaffer and @jacobx are holding a Q&A in the SwiftUI digital lounge as part of #WWDC21. Not just technical answers, but also back story and context! This ought to be a real highlight of the event – don't miss it! 😎

@dasdom Thanks! If you reply with the bug report number I’ll check in on it

@dasdom I certainly appreciate the frustration when something breaks, but could you please file a bug? Seeding helps find things we may have missed, and if we broke something for you it likely impacts others as well.

Yes, I do usually stand at my desk at the office. In general it’s a bit higher than the one in SOTU, so my wrists aren’t in as much danger as it would seem. I appreciate the concern though!

@_mchristensen Weird, that’s distracting? Do you only keep 20 in your fridge?

I’m doing my best to listen to what @joshshaffer is telling me about what’s new in Swift but I’m sorry is that…40+ rack mounted Mac Pros in a fridge behind you‽ #WWDC21

@rhysmorgan @johnsundell It even supports embedded interactive links, all from one line of code in your Text initializer. For localization check out the automatic pluralization and gender agreement attribute too!

There's now a first-class Swift type for attributed strings - and it's a value type - and it even supports Markdown - and you can pass instances of it directly to SwiftUI's Text view! 😀 #WWDC21 developer.apple.com/documentation/…

@leogdion @mecid @CameronBardell @simrandotdev It’s difficult to be specific given the abstract question, but you should really be able to call async functions without wrapping anything in Futures. For example, use .task { } to execute async work when a view appears, or Task { } to do so in a callback (async { } in Seed 1)

@mecid @CameronBardell @simrandotdev yeah exactly async/await is essentially a Promise so you should probably still wrap it in a Future

Why I feel so bad for the Combine framework?

Looking forward to talking with many of you at #WWDC this year! Of course there’s lots of great stuff in the sessions, and although we’re not together in person I hope to see you in the digital lounge

@mpweiher @tammofreese @steipete The part that’s conceptual and not just an optimization is that body must always return the same structure. It’s a compile error for two branches to return different view types. That it’s code building the description is a huge convenience, but it’s just as static as XML

@joshshaffer @tammofreese @steipete I understand your claim that this specific optimization, because it is done at least in part by the compiler and the type-system somehow changes the conceptual model. I am skeptical of that claim, to me it looks like something that is implementation-specific, not conceptual.

I have to admit I am somewhat surprised that the inherent UI instability that I thought of as a theoretical problem actually manifests itself so visibly.

@mpweiher @tammofreese @steipete I agree with your statement. I’m just saying that SwiftUI isn’t a fundamentally unstable model, because the type system brings the same stability you’d have if your view hierarchy description was instead provided in XML

@joshshaffer @tammofreese @steipete And note that my claim is not “you cannot build stable UIs because of the architecture", but “with a conceptually unstable model, you are more likely going to have flickering bugs and/or bugs are more likely to manifest as flicker” I don’t see why this should be controversial.

@mpweiher @tammofreese @steipete There are a great many differences between SwiftUI and react, but the fact that SwiftUI doesn’t do a tree diff and guarantees a stable view hierarchy is a major one. It shares more lineage in that regard with things like WebObjects which used XML for hierarchy description

@joshshaffer @tammofreese @steipete I believe that you believe that. However, considering these issues appear to be typical for SwiftUI and also for React, which shares the same underlying conceptual framework, I consider it unlikely that this is just a coincidental bug that has nothing to do with the architecture

@mpweiher @tammofreese @steipete I obviously see there is a jump in that video, I’m just saying you’re reading too much into it. The design of SwiftUI guarantees a stable view hierarchy without tree diffing. Certainly there can be other bugs, but it’s not the specific deep architectural issue you’re describing

@joshshaffer @tammofreese @steipete So you're trying to tell me that the compiler/type system mean that this cannot and does not happen. 👍 twitter.com/steipete/statu…

@mpweiher @tammofreese @steipete There is no tree diff in SwiftUI to determine the shape of the resulting UIView/CALayer hierarchy. That’s statically encoded in the type system by the return type of your body method. SwiftUI doesn’t need to diff to determine structure

@tammofreese @joshshaffer @steipete Conceptually. Then they have to do the diff stuff to make it work.

@mpweiher @tammofreese @steipete The fact that the view hierarchy is encoded in the ‘some View’ return type means the resulting shape of the hierarchy can’t change. It’s not just an optimization that initWithFrame isn’t called again when inputs change, it’s 100% guaranteed it won’t need to be

@joshshaffer @tammofreese @steipete Not quite. It's a conceptually a setNeedsLayout / layoutSubviews that always recreates the subview hierarchy from scratch (initWithFrame:, addSubview: time) and is called every time you'd otherwise get a setNeedsDisplay:

@mpweiher @tammofreese @steipete It’s conceptually the same as if UIKit had a setNeedsUpdate that triggered an updateView, and you’d put all your property updates in there. Similar to setNeedsLayout/layoutSubviews. It’s basically just enforcing that you actually build all your layout and update code that way

@mpweiher @tammofreese @steipete SwiftUI’s view hierarchy is fundamentally stable. The type system encodes the hierarchy, and it will not change as inputs change except where conditional differences are specified explicitly by the developer. The “rebuilding” SwiftUI does mostly just updates view properties