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 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 list a few wishes that 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 more flexibly.
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. Their compatibility could be better, 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 face the dilemma of competing with the gestures mentioned above.
These issues can be resolved only by providing comprehensive custom gesture capabilities early and unifying the gesture logic within SwiftUI.
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, increasing workload and giving up many excellent abilities provided by native controls.
Honestly, 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 the partial support provided by Text in the year when AttributedString was born, no improvements were made in the previous version. The text should provide more support for AttributedString attributes, especially for paragraph support. It is best to provide API for the custom Attribute display, allowing developers to expand on their own. In addition, TextField should also support AttributedString, so that simple rich text scenarios can be handled natively.
- A more unified state response logic is needed to avoid the state black hole.
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 still needed to be 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 must 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 benefit developers tremendously.
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 reduce Apple’s workload and give developers more choices. Why not do it?
I hope this article can be helpful to you. You are also welcome to communicate with me through Twitter, Discord channel, or the message board of my blog.
Top comments (0)