距离 2023 年的 WWDC 还有约 20 天，每个苹果生态的开发者都在期待苹果会在当天带来哪些新东西。在本文中，我将列出个人对于 SwiftUI 的希望单，期待着看到哪些希望能够完成。
假如不限制数量，SwiftUI 开发者或许会列出一个长长的希望列表。在此仅列出几个我以为重要且近一两年内有望完成的希望，防止期望过高而带来的绝望。
原文发表在我的博客wwww.fatbobman.com
欢迎订阅我的大众号：【肘子的Swift记事本】
以特点为粒度的视图相关
急迫性：4 完成或许性：3.5（ 总分 5 分 ）
在上个月，Swift 社区出现了一个提案 SE-0395: Observability , 简略来说能够将其理解为 Swift 原生的 KVO 加强版完成。假如这个提案得以在近期通过，那么在 SwiftUI 中，视图就有或许完成以特点为粒度的依赖相关。如此一来，在运用根据 ObservableObject 协议的引用类型 Source of truth 时，不必要的计算将大大减少，开发者将能够用更自由的方法来安排 Data flow。
一致的 Gesture 逻辑、答应创建真实的自定义手势
急迫性：5 完成或许性：2.5
在 SwiftUI 中，开发者很难完成杂乱的手势逻辑。其间一个重要原因是 SwiftUI 现在存在两个手势系统，并且两者的兼容性很差，其间一种很简单被另一种打断。从 SwiftUI 的 interface 文件能够看到，ScrollView、List、TabView、Button 等控件都有其对应的内部手势完成，这些完成与常用的 DragGesture、TapGesture 等开放给开发者的手势在很大程度上不同。它们在优先级上更高，并且它们之间也不能很好地共融。这就导致无法用原生的 SwiftUI 方法应对有杂乱手势需求的场景（例如多重翻滚嵌套）。
此外，SwiftUI 并未供给真实的自定义手势才能，现在仅支撑根据当时已供给手势的组合功用。假如开发者运用根据 UIKit 的自定义手势，则将落入到上文说到的手势之间相互竞争的困境中。
只有尽早供给完善的自定义手势功用，并在 SwiftUI 内部完成手势逻辑的一致，才干解决这些问题。
更完善的文字输入和显现
急迫性：5 完成或许性：4
相较于最初版别，SwiftUI 4.0 的 Text 和 TextField 功用已经有了极大的增强和改进。然而，与老练的解决方案相比，它们仍有相当的距离。许多开发者为了解决某些问题不得不根据 UIKit（ AppKit ）重新包装所需的显现和录入控件，这不只增加了工作量，也放弃了许多原生控件所供给的优秀才能。
说实话，无论 Text 和 TextField 增强到何种程度都不为过。但对我而言，现在急需解决的问题有以下几点：
- 供给更好的 AttributedString 支撑
除了在 AttributedString 诞生的那一年 Text 供给了部分支撑外，上一个版别中没有在这方面做出任何改进。Text 应该供给更多对 AttributedString 特点的支撑，特别是针对阶段的支撑。最好还能供给自定义 Attribute 显现的 API，给开发者供给自行扩大的才能。此外，TextField 也应该支撑 AttributedString，这样就能够用原生的方法应对一些简略的排版场景。
- 为防止状况黑洞，需求更一致的状况响应逻辑。
尽管 TextField 的结构方法很好地遵从了 SwiftUI 由状况驱动的逻辑，但这仅仅表象。实际上，在许多情况下，它仅仅在表演状况与显现一一对应的联系。因为经过了二次包装，这些控件在内部完成时常常遗漏与外部状况的对应，然后出现无法处理的情况（无法从状况下手，也无法从内部找到 hack 的点）。
这种问题不只出现在 TextField 上，许多首要依赖对 UIkit 二次包装的控件现在都存在相似的问题。从某些 Bug 的分析中能够看出，SwiftUI 团队的部分开发人员也没有彻底转换至声明、状况、响应的思想逻辑上。在包装时，他们常常会遗漏与外部状况的同步。
稳定、高效的 ForEach 完成
急迫性：5 完成或许性：3.5
在 SwiftUI 中，ForEach 是一个常常运用的控件，尤其在 Lazy 容器中。 然而，直到 4.0 版别，它的稳定性和性能依然无法彻底令人满意。例如：
- 在子视图运用的 id 润饰符的情况下，优化机制失效
- 内存释放不及时，简单导致使用溃散
- task 润饰器闭包任务无法 100% 调用（ 已在 16.4 修正 ）
- 二级及以下子视图在 onDisappear 后无法保持状况（ 在写本文前两天，收到苹果的回复，证实此为 by Design 的行为 ）
这导致在数据量较大的情况下，根据 SwiftUI 的使用性能较差，用户体会不佳。随着根据 SwiftUI 的使用越来越杂乱，ForEach 的问题急需解决。
当然，假如在改进 ForEach 问题的一起能供给一个支撑 Lazy 的 Layout 协议那就更好了。
向前兼容性
急迫度：4 完成或许性：4.5
当看到 Swift 5.8 供给了 @backDeployed 特性时，信任许多开发者都迫切希望苹果能将其使用于 SwiftUI，以增强老版别的功用并修正 bug。每次 WWDC 推出新版别 SwiftUI 时，开发者在快乐的一起也会感到痛苦：莫非又要提高使用的最低版别要求？
假如苹果能充分利用该特性，将为开发者带来巨大好处。
最终
作为未来数年中苹果生态中最首要的开发结构，SwiftUI 应该供给更多原生、稳定的底层 API，让有经历的开发者能够自行添加特性。这样既能够减轻苹果的工作量，又能让开发者有更多的选择。何乐而不为呢？
写出你的希望单，赢取
假如你对 SwiftUI 5 有什么期望，请在此 推文 下回复。获得最多 ❤️的 7 个回复者，我将送出一箱大连 。
向大众号的读者道歉，昨天我本打算在大众号上举办这个活动，结果宣布文章后才发现，我的大众号没有评论功用。只能把原来预备给大众号的两箱樱桃也放到 Twitter 上了。
原文发表在我的博客wwww.fatbobman.com
欢迎订阅我的大众号：【肘子的Swift记事本】
