There are about 20 days left until WWDC in 2023. Every developer within the Apple ecosystem is eagerly anticipating what new things Apple will bring on that day. In this article, I will list my personal wishlist for SwiftUI and hope to see which wishes can be fulfilled.
If there is no limit on the number, SwiftUI developers may list a long wishlist. Here, I will only list a few wishes that I think are important and likely to be realized in the next year or two, to avoid disappointment caused by high expectations.
View association with attribute granularity
Urgency: 4 Feasibility: 3.5 (Total score 5)
Last month, the Swift community proposed SE-0395: Observability, which can be understood as an enhanced version of Swift’s native KVO implementation. If this proposal is approved in the near future, views in SwiftUI may be able to achieve dependency association with attribute granularity. This will greatly reduce unnecessary calculations when using reference types Source of truth based on the ObservableObject protocol, and developers will be able to organize Data flow in a more flexible way.
Unified Gesture Logic and Allow Creating Truly Custom Gestures
Urgency: 5 Feasibility: 2.5
In SwiftUI, it is difficult for developers to implement complex gesture logic. One of the main reasons for this is that there are currently two gesture systems in SwiftUI, and their compatibility is poor, with one being easily interrupted by the other. From the interface file of SwiftUI, it can be seen that controls such as ScrollView, List, TabView, Button, etc. all have their corresponding internal gesture implementations, which are different from the common DragGesture, TapGesture, etc. provided to developers. They have a higher priority and cannot coexist well with each other. This makes it impossible to deal with scenarios with complex gesture requirements (such as multiple nested scrolls) using native SwiftUI methods.
In addition, SwiftUI does not provide true custom gesture capabilities, and currently only supports combination functions based on the gestures already provided. If developers use custom gestures based on UIKit, they will fall into the dilemma of competing with the gestures mentioned above.
Only by providing comprehensive custom gesture capabilities early and unifying the gesture logic within SwiftUI can these issues be resolved.
More complete text input and display
Urgency: 5 Feasibility: 4
Compared to the initial version, the Text and TextField functions of SwiftUI 4.0 have been greatly improved. However, they still have a considerable gap compared to mature solutions. Many developers have to repackage the required display and input controls based on UIKit (AppKit) to solve some problems, which not only increases workload but also gives up many excellent abilities provided by native controls.
To be honest, it is not too much for Text and TextField to be enhanced to any extent. But for me, the following issues are urgently needed to be addressed:
- Provide better AttributedString support
Except for partial support provided by Text in the year when AttributedString was born, no improvements were made in the previous version in this regard. Text should provide more support for AttributedString attributes, especially for paragraph support. It is best to provide API for custom Attribute display, giving developers the ability to expand on their own. In addition, TextField should also support AttributedString, so that simple rich text scenarios can be handled in a native way.
- To avoid the state black hole, a more unified state response logic is needed.
Although the construction method of TextField follows the state-driven logic of SwiftUI well, this is only superficial. In many cases, it is just performing the corresponding relationship between state and display. Because of the secondary packaging, these controls often miss the correspondence with the external state in the internal implementation, resulting in situations that cannot be handled (cannot start from the state, and cannot find hack points inside).
This problem not only occurs in TextField, but also exists in many controls that depend heavily on the secondary packaging of UIkit. From the analysis of some bugs, it can be seen that some developers of the SwiftUI team have not completely switched to the thinking logic of declaration, state, and response. When packaging, they often miss synchronization with external states.
Stable and Efficient ForEach Implementation
Urgency: 5 Feasibility: 3.5
In SwiftUI, ForEach is a commonly used control, especially in Lazy containers. However, until version 4.0, its stability and performance were still not completely satisfactory. For example:
- When using the ID modifier in a subview, the optimization mechanism becomes ineffective.
- Not releasing memory in a timely manner can easily cause application crashes.
- Task decorator closure task cannot be called 100% (already fixed in 16.4)
- Secondary and lower-level subviews cannot maintain their state after onDisappear. (Two days before writing this article, I received a response from Apple confirming that this is a by-design behavior.)
This results in poor performance and user experience for SwiftUI-based applications when dealing with large amounts of data. As SwiftUI-based applications become more complex, the issue with ForEach needs to be addressed urgently.
Of course, it would be even better if a layout protocol that supports Lazy can be provided while improving the ForEach issue👏.
Forward Compatibility
Urgency: 4 Feasibility: 4.5
When developers saw that Swift 5.8 offered the @backDeployed feature, many of them were eager for Apple to apply it to SwiftUI to enhance the functionality of older versions and fix bugs. Every time a new version of SwiftUI is released at WWDC, developers feel both happy and painful: do we have to increase the minimum version requirement for our app again?
If Apple can fully utilize this feature, it will bring tremendous benefits to developers.
Conclusion
As the most important development framework in the Apple ecosystem in the next few years, SwiftUI should provide more native and stable low-level APIs, allowing experienced developers to add features on their own. This can not only reduce Apple’s workload, but also give developers more choices. Why not do it?
