Wishlist for WWDC 2021?

[sindresorhus]

What is your SwiftUI wishlist for WWDC 2021?

Mine:

• Bug fixes!
  • WWDC21: Time will tell.
• More comprehensive documentation.
  • WWDC21: The docs has improved a lot this year.
• Improved performance on macOS. SwiftUI is much slower than on iOS.
  • WWDC21: One of the highlights for macOS was better performance.
• Selectable text. (FB7875429)
  • WWDC21: Fixed in macOS 12: https://twitter.com/sindresorhus/status/1402214297673998337
• Focus API for macOS and iOS.
  • WWDC21: https://swiftwithmajid.com/2021/06/08/what-is-new-in-swiftui-after-wwdc21/
• Search bar on List.
  • WWDC21: https://swiftwithmajid.com/2021/06/08/what-is-new-in-swiftui-after-wwdc21/
• Pull-to-refresh on List.
  • WWDC21: https://swiftwithmajid.com/2021/06/08/what-is-new-in-swiftui-after-wwdc21/
• Make TextEditor much more configurable and powerful.
• Alert with text fields or just the ability to add any view.
• macOS status bar items in SwiftUI.
• Custom swipe actions for List rows.
  • WWDC21: https://swiftwithmajid.com/2021/06/08/what-is-new-in-swiftui-after-wwdc21/
• Support links in Text.
  • WWDC21: You can use Markdown in Text now with links.
• Support for multiple selections in Picker. (For example, multiple checkboxes)
• WebView and SafariView component.
• MediaPicker component.
• Support for visual effects materials.
  • WWDC21: https://swiftwithmajid.com/2021/06/08/what-is-new-in-swiftui-after-wwdc21/
• Capture a view to an image.
• Modify List row separators.
  • WWDC21: There are now .listRowSeparator() and .listRowSeparatorTint() modifiers.
• Make Text as powerful as attributed strings.
  • WWDC21: Text got support for attributed strings: https://swiftwithmajid.com/2021/06/08/what-is-new-in-swiftui-after-wwdc21/
• More types supported for @AppStorage. Ideally, any Codable type.
• Make matchedGeometryEffect() work with NavigationLink and .sheet().
• More layout-related components. HStack and VStack are surprisingly powerful, but they don’t solve everything.
• @SecureStorage for accessing the keychain.
• Enter/Done button on the numpad keyboard style.
  • WWDC21: submitLabel(_:)
• Window handling improvements. (FB7868792)
• Enhanced Color manipulation. (FB7551832)
• Open/close the SwiftUI Menu view programmatically. (FB8530113)
• isHighlighted EnvironmentKey for whether a Button is highlighted. (FB8075582)

[j-f1]

• real Share Sheet API (not a UIViewControllerRepresentable)
• easy way to render SwiftUI children inside UIView*Representable views
• enlarge the tappable area of a menu/button without making it larger on screen
• modifier to programmatically make a text input become/resign first responder
• better menu support (destructive actions, customize the view that’s shown next to the menu when long pressing)
• Color shortcuts for UI colors (system backgrounds/fills)
• improved pointer support (I tried to enable it on one of my apps but the options either didn’t work or didn’t let me customize it to my liking)

[jottenlips]

• A tall order, but it would be cool to have SwiftUI for Web and Android 😅

Something like: https://github.com/SwiftWebUI/SwiftWebUI

• State hooks like react would also be a nice addition

https://github.com/unixzii/SwiftUI-Hooks

[markmals]

FWIW, the SwiftWasm folks have a great SwiftUI-compatible framework with Tokamak, which works on modern browsers and GTK and Android rendering back-ends are being worked on as well.

[kaouzz]

What's the main difference between the two? Just started fiddling with SwiftWebUI, but get the impression it's dead (?) and that Tokamak perhaps is a better alternative.

FWIW, the SwiftWasm folks have a great SwiftUI-compatible framework with Tokamak, which works on modern browsers and GTK and Android rendering back-ends are being worked on as well.

[helje5]

SwiftWebUI is not "dead", it just is what it is, as shown in big letters on the front-page (actually even twice :-) ):

Disclaimer: This is a toy project! Do not use for production. Use it to learn more about SwiftUI and its inner workings

It was never meant for actual use and I actually do think that it makes little sense to do a "real" SwiftUI for browsers for various reasons. I think that's the main difference, the Tomakomak people think that it does make sense :-) (AFAIK it also works differently, i.e. is not driven by a NIO server like SwiftWebUI, but by Wasm running in the browser).

P.S.: I do think that rendering web content using result builders does make sense, but it would be very different to SwiftUI. Here is a write up on it for people interested: https://forums.swift.org/t/swiftui-like-templating-for-server-side-swift/34519

P.S.2.: SwiftBlocksUI is also something along those lines, but even simpler, because it only has to generate the Slack JSON: https://www.alwaysrightinstitute.com/swiftblocksui/

[kaouzz]

Thank you for the explanation. Will definitely keep my eyes on SwiftWebViews!

[GalCohen]

My biggest frustration is that I just can't get Previews working on a large project. I know there could be many reasons, but one of the selling points here is the quick iteration that Previews gives, and I get none of that. I gave up on em completely. It recompiles, which takes like 20-30 minutes and errors out on architecture issues. It's probably somewhat related to the latest xcode, misconfigurations of the project, maybe poorly configured cocoapods, I don't know. But it's opaque, not well documented and slow to debug, so there's room to improve here.

[ladislas]

I share your frustration with Previews. They take a while to load.

Up until a week or two ago, compilation also took several minutes for the project. Then out of the blue Xcode asked me to activate (or reactivate) incremental builds. And now it only takes between a few seconds to 40 seconds max. Might be worth checking that in your settings.

[sindresorhus]

I'm in the same boat. Previews almost never work for my macOS app.

[mortenbekditlevsen]

Over the past month or so, we have restructured our code base at work to build with SwiftPM.
This allows us to create ‘features’ as local SwiftPM packages - each with a UI target, a ViewModel target and an implementation target.
The ViewModel target contains an ObservableObject class with inputs and outputs.
The UI target only depends on our ui component library and the ViewModel. This means that it’s very fast to build and works excellent with Previews.
The ‘implementation’ target also depends on the ViewModel target and subclasses the ObservableObject from that target. We use use RxSwift at lower levels, so we have made ‘binder’ functionality to easily bind an Rx Observable to a @published property.
So the implementation is the only target that has dependencies on our model and services and what not.
We have only implemented a few features using this style so far, but it has been great to work with.
We have plans to blog about it and share more details. Like for instance how we keep localizations with each feature and use custom swiftgen templates to get strongly typed localizations in SwiftUI.

[mobilinked]

1. Collection View (More than the simple grid)

• Support customized CollectionViewLayout
• Better performance and bug fixes for bi-directional grid

2. Document-based app:

• Be flexible to add a welcome window
• Multiple DocumentGroup support

3. Interact with UIKit and AppKit

• Window's style
• Toolbar
• ...

4. Performance

[mobilinked]

BTW, for "Focus API for macOS and iOS", we have a temporary solution (before Apple's solution) at https://github.com/mobilinked/MbSwiftUIFirstResponder/

[LinusSkucas]

• Just better macOS support in general
• Better Previews
• First Responder thing (It's going to be the third year, they probably have been working on something like that)
• Something like Core Data that's swifty and works well with SwiftUI and syncs with CloudKit well.

[TofPlay]

Something like Core Data that's swifty ...

I made myself a package on SQLite I use instead of CoreData. If that can help you here it is: TStorage

[LinusSkucas]

Woah @TofPlay that looks great! I'll try it out soon.
(Sorry this is so late, it got caught in a backlog of notifications)

[woodfairy]

definitely status bar item support for SwiftUI! NSPopover just sucks!

[CypherPoet]

More features and upgrades to Swift Playgrounds on Mac. I love Xcode Playgrounds, but I want to love Swift Playgrounds even more 😄 . And I think if Apple invests in it enough, it could evolve into something like a Jupyter Notebooks on steroids.

[Runrioter]

I also love Swift Playground.

[tbrodbeck]

I would love an adaptive search button/bar in the new toolbar

[markmals]

Combine Publishers for permission requests (and maybe something to make them easier to use with SwiftUI like property wrappers?)

[CypherPoet]

Some way to write iMessage apps in SwiftUI would be awesome.

It would also advance the paradigm that, IMO, WidgetKit was meant to start of having SwiftUI be the defacto tool for developing app extensions.

[helje5]

Like in SwiftBlocksUI :-)