一个Swift开发者的WWDC梦想

吴欣
86 阅读10分钟

随着WWDC21开幕在即，我想继续我在2019年开始的传统，并分享我对今年大会的一些最大希望和梦想。

请注意，这些真的不是预测，也不是基于任何种类的内幕信息。这只是我与你分享一些我个人与Swift相关的WWDC梦想。

强大的SwiftUI定制功能

我非常喜欢SwiftUI（以至于我有点想 把它移植到网上），但这并不意味着它是完美的。事实上，在这一点上，它只有不到两年的历史，仍然是一个非常年轻的框架，还没有变得像UIKit和AppKit这样的工具那样功能完整、灵活和强大。

我希望在今年看到的关键改进之一是，苹果公司为该框架的整套系统视图添加适当的、完全出炉的定制化API，这将释放大量的额外力量和灵活性。

例如，就像我们在"封装 SwiftUI 视图样式 "中看到的那样， ButtonStyle 协议已经使我们能够在涉及到Button 视图的样式时执行非常定制、精细的自定义:

struct ActionButtonStyle: ButtonStyle {
    func makeBody(configuration: Configuration) -> some View {
        configuration.label
            .foregroundColor(.white)
            .font(Font.body.bold())
            .padding(10)
            .padding(.horizontal, 20)
            .background(Color.blue)
            .cornerRadius(10)
    }
}

使用上述协议定义的样式之所以如此强大，是因为它们可以一次性应用于整个视图层次结构--这使得我们可以非常整齐地将应用程序的样式和主题代码与每个单独视图中的具体逻辑分开。事实上，如果我们愿意，我们甚至可以通过这样做来为整个基于SwiftUI的应用程序中的所有按钮设置样式:

@main struct MyApp: App {
    var body: some Scene {
        WindowGroup {
            RootView().buttonStyle(ActionButtonStyle())
        }
    }
}

然而，虽然SwiftUI已经配备了许多其他的造型协议，其工作方式与ButtonStyle 完全相同，但其中许多协议目前还不能供我们第三方开发者实施。以NavigationViewStyle 协议为例。如果我们在Xcode中通过命令点击看一下它的公开定义，我们会看到的就是这个:

public protocol NavigationViewStyle {
}

其他类似的协议也是如此--包括ListStyle 、MenuButtonStyle 、PickerStyle ，等等。因此，我希望苹果能够开放这些协议，这样我们就能够为或多或少的任何内置的SwiftUI视图编写自定义样式，而不仅仅是为少数选定的视图，如Button 和Label 。我认为这可以解决很多开发人员（包括我自己）在应用中采用SwiftUI时遇到的与样式有关的问题，这些应用需要更多的自定义UI的外观。

例如，上述的定制化 API 可以让我们对导航栏和标签栏进行样式设计，（最终）能够移除列表单元格的分隔符，并执行其他类型的常见调整，而 UIKit 和 AppKit 让这些调整变得超级简单，但 SwiftUI 目前却让这些调整变得几乎不可能（除非诉诸某种形式的UIAppearance 或子视图 hacking）。

我认为SwiftUI在支持的视图类型方面已经有了相当广泛的覆盖面，所以（至少从我的角度来看）苹果今年把重点放在深度上会有很大的意义--使SwiftUI已经提供的视图更加灵活、强大和可定制。

异步/等待所有的东西!

由于并发性是Swift 5.5的重点（一旦我有机会使用它来编写适当的生产代码，我会更详细地介绍），我很乐意看到苹果更新许多作为其SDK一部分的异步API，以充分利用像async/await 。

例如，想象一下，能够像这样执行基于URLSession 的网络调用:

let response = try await URLSession.shared.dataTask(for: url)

或者像这样请求推送通知的权限:

let center = UNUserNotificationCenter.current()
let isAuthorized = try await center.requestAuthorization()

虽然Combine已经让我们能够以非常强大的方式执行许多种类的异步任务，但如果苹果能够完全接受Swift新的一流的并发功能，我认为这将成为社区学习的好榜样，也会让我们在自己的代码中更容易采用这些功能。

此外，这些新的API很可能是对现有API的纯粹补充，这意味着（就像Combine推出时一样）我们可以按照自己的节奏，逐件迁移到这些API上。

交互式部件

说iOS 14引入WidgetKit是成功的几乎是轻描淡写的--新的主屏幕部件得到了非常广泛的采用，不仅在开发者和技术爱好者中，而且在更广泛的iOS用户群中（这在很大程度上要感谢Widgetsmith创建者David Smith的惊人工作，我很荣幸地在前一段时间的播客中与他交谈）。

然而，就其目前的形态而言，Widget在接受何种用户互动方面是相当有限的--与主机应用程序的深度链接是实现自定义互动逻辑的唯一真正途径。现在，我完全理解苹果公司为什么做出这个决定。毕竟，就像伊丽莎-布洛克去年做客播客时解释的那样，一个小部件的用户界面实际上并没有在主屏幕上持续运行，而是由系统根据存储在磁盘上的序列化快照进行渲染，这主要是出于性能和能源效率的考虑。

因此，如果系统本质上是将所有的小部件渲染成完全静态的视图层次，这些视图层次是预先计算好的（由小部件的后台TimelineProvider ），那么苹果如何能让我们在这种背景下编写自定义的交互代码，而不从根本上改变小部件的工作方式呢？

我想到的一个想法是，可以引入某种形式的基于事件的消息传递系统，这将使一个给定的小组件的时间线条目视图能够触发自定义事件，例如使用类似内置的EventButton:

struct ArticleWidgetEntryView: View {
    var entry: ArticleEntry

    var body: some View {
        VStack(alignment: .leading, spacing: 5) {
            Text(entry.article.title)
                .bold()
            Text(entry.article.description)
                .foregroundColor(.secondary)
                .font(.footnote)
            EventButton(
                systemImage: "heart.fill",
                event: ArticleWidget.Event.toggleFavorite
            )
        }
        .padding()
    }
}

由于上述做法不涉及响应用户交互而执行任何任意的视图级代码，它仍然可以让系统保持对所有widget UIs的渲染和生命周期的完全控制。

因为WidgetKit是Swift(UI)-only，上述Event 类型很可能被主Widget 定义和它的TimelineProvider ，以一种完全类型安全的方式引用--而不是在周围传递原始字符串或userInfo-style字典。

例如，也许TimelineProvider 协议（或者它的专门版本）可以获得一个新的方法，该方法将被传递给任何被触发的Event （以及触发它的条目），这反过来将让我们运行完全自定义的代码来响应它，同时仍然使系统能够继续使用其基于快照的渲染策略。

坚如磐石的工具

尽管自Swift语言首次推出以来，其工具的整体质量和集成到Xcode的方式肯定有所改善，但它仍然是Swift整体上最重要的缺点之一。在2021年，自动完成完全停止工作，语法高亮消失，以及在编译失败时显示晦涩的错误信息--即使是在相对简单的项目中，仍然非常普遍。

我意识到这些问题并不容易解决，尤其是考虑到Swift的整体复杂性和非常快速的发展，但如果我可以从这个梦想清单中挑选一个项目，那就是这个项目。关于Swift、UIKit、SwiftUI以及苹果的其他框架和SDK，有很多值得喜欢的地方，尽管有很多缺陷，但我认为Xcode实际上是一个非常棒的开发环境，我只是希望基本的编辑体验能够提升到我对苹果产品所期望的高质量水平。

这并不是说Swift的所有工具都是有缺陷的。以Swift软件包管理器为例--总的来说，它是迄今为止我使用过的最稳定、最容易使用的依赖性管理系统（我并不是说要侮辱其他的软件包管理器）。基本上，当使用SwiftPM时，依赖性管理已经成为一个已解决的问题，至少对我和我工作的团队来说是这样。它快速、可靠，而且功能强大。现在，Xcode的新构建系统以及为苹果平台开发应用程序的整体体验的许多其他部分也可以说是如此。

因此，我所希望的是一些粗糙的边缘被磨平，我相信有一天我们会达到这个目的。让我们看看Xcode 13的发布日是否会是那一天。

剩余的2020年的梦想

最后，我还希望看到我剩下的一些2020年的梦想最终成为现实。

**iPad上的Xcode**是我长久以来的愿望。我知道不是每个人都想在iPad上写代码，但我真的想，尤其是在旅行或在户外工作时。这并不意味着我将停止使用我的M1 Mac mini，如果Xcode的iPad版本将在下周发布 - 这只是意味着我将有一个额外的设备，我和其他人可以在上面构建应用程序和库。

Swift Playgrounds是一个了不起的学习、原型设计和实验的工具--但它不是一个构建适当的应用程序和Swift包的IDE，而且它从未打算成为一个IDE。我认为在其生命周期的这一点上，iPad应该成为一个不仅能够运行应用程序的计算平台--它还应该使我们能够构建和部署它们。

端到端的Swift，或者某种形式的基于Swift的云功能，也是我2020年的梦想之一。如此多的应用程序需要运行服务器端的逻辑，但并不是所有的应用程序都真的需要一个完全定制的服务器。当然，有很多第三方工具可以让我们部署单独的逻辑片段，比如Cloudflare Workers（这就是本网站搜索功能的动力），但如果看到苹果公司提供一个完全集成的、基于Swift的无服务器系统，让我们完成类似的事情，那将是不可思议的。

我还非常希望能够**使用Swift Package Manager来定义整个应用程序项目**，而不仅仅是库和命令行工具。就像我之前提到的，SwiftPM是Swift整个工具链中我最喜欢的部分之一，所以我很高兴看到它在今年扩展到更多的使用案例。

总结

这些就是我对WWDC21最大的与Swift有关的梦想。你怎么看？你是否与我有同样的梦想，或者还有其他你希望在下周看到的与Swift相关的公告？请通过Twitter 或电子邮件告诉我。

如果你喜欢这篇文章，那么一定要看看《桑德尔和朋友们的WWDC》，在这篇文章中，我和我的一些朋友将在会议的整个一周内详细报道WWDC21。

谢谢你的阅读!

avatar
文章
阅读
粉丝