S4E5: 你能不能就…？

欢迎收听《Swift Over Coffee》第四季第五集。我是Mikaela Karan。

Welcome to season four episode five of Swift Over Coffee. I'm Mikaela Karan.

我是Paul Letson。

And I'm Paul Letson.

在这一集中，我们讨论了如何编写出色的网络代码。

In this episode, we discuss how we're writing great networking code.

你必须把它做对，而做错的方式却有太多种。我们分享了你们对于Xcode、SwiftUI、SwiftData以及更多方面希望看到的重大改进的想法。

You've gotta get it right. And there are so many ways you can get it wrong. We share your thoughts on the major changes you're hoping to see in Xcode, SwiftUI, SwiftData, and more.

总会有那么一件小事让我们都在想，他们为什么就不能这么做呢？

It's always that one little thing that we're all like, why can't they just do this?

我知道。然后我们才发现，

I know. And then we figure out,

哦，这就是原因。另外

oh, that's why. Plus

没错，没错。哇哦，好吧。最近我们俩都很忙。

Damn right. Damn right. Oh, wow. Okay. So it's been a busy time for both of us.

对吧？我们刚都参加了北极会议，是这样吗？

Right? We just both got back from Arctic Conference. Is that right?

是的。我现在此刻还在赫尔辛基，但等我们录完这个节目后，我就不再这里了，我会去另一个完全不同的国家和时区。

Yeah. I'm still at the moment in Helsinki, but literally after we record this, I will not be here anymore and I'll be in a completely different country and time zones.

你总是独来独往，我喜欢这样。但最近真的非常忙乱。首先，这是一个很棒的活动，我想我们俩都玩得很开心。

You you hang around with no one. I love it. But it's been really frantic. It's it's a great event for a start. We think we both enjoyed it very much.

不过对我来说这段时间确实非常忙碌，因为我还去了中国参加 Let's Vision 活动，在这中间还有 Unwrapped Live，同时我还发布了全新的 Ignite 版本。这些现在都已经完成了，我的应用也已经上线了。

But it's been a really frantic time certainly for me because I went to Let's Vision in China as well. I had Unwrapped Live in the middle of those two. I put a major new Ignite release at the same time. That's been finished now. And my app is out.

虽然我现在被锁定了，所有应用暂时都无法登录。

Although I currently got locked out. Apps all connect temporarily.

哦，不会吧，你被锁定了？

Oh, no. You got locked out?

是啊，提示说请稍后再尝试登录。你发送了太多次双因素验证码了。但问题是没有说明到底“稍后”是多久，就只是“稍后”。

Yeah. It was like, please try logging in again later. You've had too many two f a codes sent. And there's no no mention of what later actually means. Just like later.

好，一小时吗？不。一天？

Okay. An hour? Nope. A day?

苹果说的“稍后”，通常是一周以后。

It's Apple later. A week.

对吧？我知道，是的。“今年晚些时候”。

Yeah. Right? I know. Yeah. Later this year.

我们走着瞧吧。总之现在我的应用已经上线了。我突然想到，麦肯纳，你是不是还在做另一个应用？

We'll see how it works out. So so now my app's out. I'm just thinking, wasn't it was there another app you're working on, McKenna?

我不知道你在说什么。

I don't know what you're talking about.

合理的否认。

Plausible deniability.

是的，这是我的应用。我非常努力地开发，几乎完成了整个项目，现在只剩下最后一个功能需要调试，之后就可以进行beta测试了。我会把它发布出去，并且发给所有人。当大家第一次查看它的时候，我会完成最后的一些细节，真正地将它发布出来。

Yes. It's my app. I really worked really hard to almost get it out, and I literally have a single function to debug and then it's ready for like the beta test. I'm gonna put it out and actually send it to everybody. And then while people are kind of looking at it for the first time, then I'll like finish up the last little bits to actually release it for real this time.

朋友们，听一下。你们已经听了很久了，一直在关注Kayla的工作进展。我真心希望你们一路见证了这个应用的发展过程，能够提供一些良好的测试反馈意见，这真的很重要。

And folks, listen. You've been listening to this for a while now. Listening to Kayla, working this for a while. I really hope you've seen the development of the app along the way and you could provide some good test like feedback. It it makes a big difference.

所以这一集有很多新闻。第一件事就是令人遗憾的消息：苹果公司正式推迟了Apple Intelligence功能的推出计划。随后，John Gruber发表了一篇相当激烈——我不知道该用什么词来形容——近乎咆哮、带点脏话的博客文章，说库比蒂诺那边出了问题。但总的来说，朋友们，事情是这样的：苹果公司原本雄心勃勃，却不幸未能如期实现Apple Intelligence的目标。他们想在规定的时间内交付的内容远远超过了实际能力。

So there's a bunch of news this episode. The number one thing is the sad news that Apple have officially delayed the sort of context to where Apple intelligence roll out. And this was followed up by a fairly I don't know how to describe it other than aggressive discussion, rant, expletive almost blog post from John Gruber about something being rotten in the state of Cupertino. But broadly speaking, folks, what's happened is that Apple has aimed for the moon and sadly fallen short with Apple intelligence. They want to ship far far more than they could in the time frame they were allowed.

这很难得，对吧？我们其实很少看到苹果出现这种情况，不是吗？

And it's hard. Right? We don't actually see that very often from Apple, do

是啊。最近很多东西都变成了“今年晚些时候”或者“最终会发生”，但我们根本不知道那到底是什么时候。但我同意你的看法，我宁愿它真正发布时表现良好，按照我们期望的方式运行，而不是一上线就遭到大家讨厌，然后引来大量负面报道而不是正面报道。

we? Yeah. It's it seems like lately, a lot of later this year is one time or is eventually going to happen, we don't know when that will ever happen. But I I agree that it's I'd rather have it actually like ship and do good and like actually work the way we all expect it to work rather than everybody hating it like immediately when it's released and then we get a ton of bad press coverage rather than good press.

没错。我是说，苹果并不想这么做。他们希望第一次发布就能做到优秀，把事情做对。而公开承认失败，说：“听着，我们搞砸了。”这种想法

Yeah. Absolutely. I mean, look, Apple did not wanna do this. They want to ship something great first time, get it right. And the idea of backing down from that publicly and saying, listen, we got it wrong.

对苹果来说简直是禁忌。我认为坦白讲，这是他们最不愿意做的事情。但我还是尊重他们的决定。真该死，能说出这样的话：“听着，我们要做这件事。”

That's that's anathema to Apple. That's the worst thing they can think of, I think, quite frankly. But I respect it. Damn it. To be able to say, listen, we're gonna do this thing.

我们已经尽了最大的努力。但对我们来说还不够好。我们会继续完善。当然应该这样。

We've tried our best. It's not quite good enough for us. We're gonna hold on to it. Damn right. Damn right.

如果更多人能这么说，我想我们的世界会快乐得多。所以坦白讲，我对苹果说“不”的决定充满敬意。他们会暂时保留这项功能，把它做好，而不是为了赶时间或让John Gruber高兴。你知道的？不管怎样，他们还宣布了一个新的API即将推出，这对苹果来说很不寻常。

If more people said that, we've been a much happier state, quite frankly. So I I have nothing but respect for Apple for saying no. We're gonna hold this one back and get it right rather than rush rush out to make John Gruber happy. You know? Anyway, they also announced the coming of new API, which is unusual for Apple.

他们通常不会提前公布API。但这次是关于年龄验证系统的。作为一个已经经历过孩子年幼时使用iDevice阶段的人，我庆幸自己已经过了那个阶段。但以前总是这样，比如小猪佩奇运动日之类的，或者汪汪队立大功之类的内容。然后总会弹出一个问题：你是成年人吗？

They don't often preannounce API. But this is one for age checking systems. Now as someone who's been through the whole young kids with iDevices stage already, I'm thankfully past that now. But it was like, you know, Peppa Pig does sports day or whatever, you know, Paw Patrol whatever stuff. And it was always like, are you an adult?

解决一个简单的数学题。比如三乘四等于多少，才能进入应用内购买界面之类的。对吧？每个开发者都得自己设计这样的功能，总是搞一些愚蠢的小测试来确认你是不是成年人。

Solve this easy mathematic sum. What is like three times four, whatever, to get to the the in app purchase screen or something like that. Right? And everyone had to make their own thing. Always make their own silly little are you an adult test.

这东西真的很奇怪。苹果终于意识到这一点了，你知道的，也许我们可以做得更好些。

And it was the weirdest thing. And Apple of Vine is saying, you know, no. May maybe we could just do this better.

这确实很有趣。我自己没有遇到过这种需求，但这是一个值得思考的问题。因为通常情况下，如果你必须输入生日，任何人都可以随便输入一个日期就完事了。

That's really interesting. I don't have experience with needing this as something, but it's an interesting, issue to solve because it's always like, oh, if you have to enter your birthday, anybody can just throw in whatever date and call it a day.

没错。而且你知道，苹果早就知道你孩子的年龄。如果你有家庭账户的话，他们就知道你孩子的年龄是否为13岁左右，因为这些信息是通过屏幕使用时间等功能控制的。所以他们并不是不知道这些信息。

Yeah. And, you know, Apple has long known the age of your children. Have have a family account. They know, you know, age 13 or whatever for your kids because it's controlled through screen time and similar. So it's not like they don't know this stuff.

但我猜现在在应用层面上获取这些信息后，他们可以说，大概知道你孩子的年龄段。我想这个数据应该还是匿名化的。不会具体到你的孩子正好13岁，而是类似10到15岁之间的年龄段。但这让我能够直接允许孩子访问屏幕内容，而不用我自己再做一个傻乎乎的计算器测试。

But I guess getting it at the app level now so they could say, okay, roughly, here's your kid's age. Because it'll I think I think it's anonymized still. It won't be like, oh, your kid's exactly 13. It'll be like, you know, oh, they're in a 10 to 15 bracket something. But then it allows me to say, yes, they can have access to the screen immediately without having to make my own custom stupid calculator thing instead.

是的，谢谢，谢谢，谢谢。虽然晚了十年，但我还是接受它。

Yes. Thank you. Thank you. Thank you. Ten years too late, but I'll take it.

在Swift的世界里，我们也迎来了一个新的测试工作组。你觉得怎么样，Mikaela？

We also had, in the world of Swift, a new testing work group. What do think that, Mikaela?

测试工作组刚刚成立，主要关注的是Swift测试，这是Swift包管理器的一个子命令。他们有一个Swift测试愿景文档，列出了他们想要实现的目标以及如何改进。众所周知，Swift测试是在上一届WWDC上发布的，并且它是开源的。目前最大的痛点之一就是Swift测试还没有UI测试功能。如果将来能加入这一功能，那会很好，我们之后也会看到一些相关的反馈。

So the testing work group has just been formed, and it's all about Swift testing, which is actually a subcommand of, like, the Swift package manager. So they have the swift testing vision document of everything that they're wanting to do and how they want to improve it. Because as we all know, swift testing was just released last dub dub and that is also open source. So one of the big pain points is like there is no UI testing yet with Swift testing. So like, if that's gonna be in there, and then also, we'll read some of the responses later on.

但我们也可以开始更多地影响测试方面的发展方向，以及我们希望Swift测试如何演进。

But we can then start to influence more of what do we want within testing and how do we want Swift testing to evolve.

是的。我希望不是因为XTest本身太慢。而是它根本没有真正地发展过。可以说，它在某个时间点就停滞不前了。因此对于Swift测试，我期待着有一股新动力、一些新的想法和可用API，让测试体验变得前所未有地好。

Yes. And I'm I'm hoping it's not that XTest was was slow. It just didn't evolve really ever. It was it it was kinda fixed in time as it were. And so Swift testing, I'm hoping for a sort of fresh impetus of ideas, of of APIs to work with, to make testing better than ever.

那将会是非常棒的。在我提到我们有多忙之后，我和Mikayla都会出席四月在东京举行的Tri Swift会议。你是今天飞过去吗，Miguel？

That'd be lovely to see. And off the back of me saying how busy we are, both Mikayla and I will be at Tri Swift Tokyo on April. Is that what you're flying today, Miguel?

是的。我会飞往东京，并且会一直待到会议结束。

Yes. I will fly to Tokyo, and I'm going to be there up until the conference.

我现在想起来了，你这次是要预订一个共享办公空间，然后全天候不停地开发Fruitful。

And I remember now, this is where you're gonna book a coking space and work twenty four seven on Fruitful the entire time.

没错。

Exactly.

没有滑雪板，没有滑雪，什么娱乐都没有。

No snowboarding, no skiing, nothing like that.

这要看你说的是哪个时间段。是的。

Depending on which date you're talking about. Yes.

哦，不，不。无论如何，到时候再见吧。

Oh, no. No. Anyway, I'll see you there again.

太好了。本期的主题是我们如何编写优秀的网络代码？每个iOS应用在某种程度上都需要某种形式的网络功能。（虽然不是每一个都一定需要，但很多都是如此。）而我的应用当然有大量网络相关代码。

Awesome. The theme of this episode is how are we writing great networking code? So every iOS app at some point has to have some kind of networking. Maybe not every, but many of them. And my app surely has a ton of networking.

那么让我们开始吧。我正在尝试编写可以进行单元测试的网络代码，因为我明白这是可能的，我知道你可以做到，我自己也曾经做过，但现在我正试图在我的应用程序中实际实现这一点，这有点困难，因为问题是：我真的想对所有这些代码做单元测试吗？但同时我又觉得我应该这么做，而且这也是件好事。所以我现在正尝试通过编写一个使用URL Session的协议来实现一切可测试的目标，这样你就可以对其进行模拟（mock），并返回你期望的数组结果，而不是真的去访问我的服务器，这是我目前的起点。

So let's kick it off with. I'm attempting to write networking code that I can also unit test because I know it's possible and I know you could do it and I have done it, but now I'm trying to actually do that in my own application, which is difficult because it's like, do I really want to unit test all of this? But then it's also like I should and it's a good thing. So I'm doing that so I can attempt to unit test everything by writing a protocol. That uses URL session and then you can mock it and then just like return an array that you expect as opposed to, like, actually hitting my server is sort of where I'm starting with everything.

你呢，保罗？

What about you, Paul?

是的。所以这里有一些前提条件，大家。米卡埃拉谈到的是一种非常精确的网络测试形式，因为你不想进行单元测试时测试普通的网络代码，因为那样会破坏你的单元测试时间。你的单元测试应该每秒运行一千次甚至更多，速度要非常快。如果你在其中实际进行网络请求，它立刻就会变慢，甚至像十分之一秒这样的延迟对单元测试来说都是灾难性的。

Yeah. So some provisos here, folks. Mikaela's talking about a very precise form of testing networking, because you you don't want to test unit test, sorry, regular networking code, because that destroys your unit test time. Your unit test should run a thousand or more per second, like extreme speed. If you do actual networking there, it'll slow down immediately to even like a a tenth of a second is horrific for a unit test.

米卡埃拉所说的是创建一个URL协议的子类来模拟数据，并说当我尝试获取这个特定URL时，直接立即返回这些数据。这非常好，因为现在你在做网络相关的事情，但能以单元测试预期的速度立即获得响应数据。因此这是一个非常好的做法。我也同意网络功能对于iOS应用来说是基础性的。对吧？

What Mikaela's talking about is making a subclass of URL protocol to mock data and say, when I try and fetch this URL here, just send back this data immediately. And that is great because now you're doing networking stuff, but getting back data instantly at the speed of a unit as expected. So that's a really good place to be. And I do agree that networking is is fundamental to iOS apps. Right?

我刚刚完成了我的新课程草稿，主题是如何通过带回家的测试任务。其关键在于大多数带回家的任务都会要求你：好，访问这个URL，获取数据，然后做一些处理。仅此而已。你要让它在屏幕上显示良好，或者实现搜索功能等等，这些都是我们代码中非常常见的部分。

And I've I've just finished the draft for my new course about take home tests, how to pass take home tests. And it comes down to the fact that most take home tests will say, okay, hit this URL, grab the data, do something with it. And that's it. You know, that make it look good in the screen, whatever, search it, whatever. It's so so common to our our our code.

你必须把它做好。而你可以用很多方式把它做得很好。你知道吗？这是需要了解你的工具。你知道吗？事实上这是我坚信结合式编程（Combine）优于常规代码的少数几个地方之一。

You've gotta get it right. And there are so many ways you can get it wrong brilliantly by getting it right. You know. It's it's knowing your tools, you know. It's actually it's one of the very few places where I believe combined code is better than regular code.

因为你可以这样说，当用户输入搜索词时，你可以半秒钟去抖动（debounce），然后尝试访问一个URL，如果需要的话再重试两次，接着从响应中解析数据，解码成类型，无论你想做什么，都只需要三行，也许四行代码就能完成。简直太神奇了。

Because you can say, as these are typed to search, you can debounce a half second, then try hitting a URL, then retry twice more if needed, then plot the data from the response, decode to a type, whatever you want to, in just like three, maybe four lines of code. And it's just magical.

没错。能够如此轻松地写出类似的东西真是太棒了，尤其是对于我们经常做的事情来说。Combine并不是我的最爱。我仍然在努力理解Combine以及那些你随意添加的方法，它们似乎以某种方式神奇地工作。但是能够如此轻松地做到这一点确实很棒。因为我在开发自己的API时，无论是来自服务器还是来自iOS应用，我都会使用像Postman或GetAPI这样的工具，这是一个非常轻量级的客户端，可以做同样的事情，让你实际测试你的网络请求并测试你设定的数据格式。

Yes. That is truly amazing to able to write something like that easily for something that we do all the time too. Combine is not my favorite. I still, like, struggle through understanding Combine and all the different methods you just like tack on and then they like somehow magically work. But it is nice being able to do that very easily because one thing like I do when I'm working on like my own API, either from the server or like from my iOS app, is really using something like Postman or GetAPI, which is, a very lightweight client, that does the same thing, where you can actually test your network request and test the format that you have them in.

因为这样你首先只是在测试：我知道如何正确地进行网络通信吗？一旦你知道了并且所有参数都正确了，你就可以将它放入你的iOS应用中，开始编写你的网络代码。因为如果你不这样做，在现实中，你实际上是在同时测试两件不同的事情。你在测试我的Swift代码是否正确，同时也在测试我是否输入了正确的网络请求参数。

Because then you're first just testing, Do I know how to properly do the networking? And then once you know and you have all the parameters right, you can then put it in your iOS app and be like, now I'm actually going to write my net networking code. Because if you don't do that stuff, in reality, you're actually testing two different things. You're testing is my swift code correct, but also in my entering all the correct parameters for that network request. But.

如果你没有做好这两者中的任何一个，那都不会起作用。所以使用像GetAPI或Postman这样的工具，你就隔离了其中的一部分。当你真正开始编写自己的代码时，你就能正确地实现了。

If you don't do either one of those, it's not going to work. So then using something like get API or Postman, you're isolating part of that. So then when you actually go to write your own code, you can do it correctly.

哦，是的。我见过太多次测试代码并没有真正测试真实的数据，它只测试了模拟数据。嗯，好吧。它通过了假数据测试，但它能处理真实数据吗？我完全不知道。

Oh, yeah. I the number of time I've seen testing code that doesn't actually test the real data, It's sort of testing only mock data. And like, well, okay. It passes the fake data, but does it work with the real data or not? You know, I've got no idea.

而且，它会把你带到一个奇怪的地方。你的测试实际上变得毫无用处。它们看起来很好，它们通过了某种外部的检查标记。是的。

And it it you can get to a strange place. Your tests become effectively useless. They they look good. They pass some sort of, like, external, like, check mark. Yes.

我们已经实现了很高的代码覆盖率数字。但实际上它们并没有测试太多有用的东西，这非常奇怪。我认为网络功能特别容易陷入这种状况。对我来说，我处于更简单的层面。比如，我会告诉别人尽量以尊重的方式使用网络。

We've done some high code coverage number. But they don't test very much actually useful, which is very strange. I think networking particularly falls into that hole very quickly. For me, I'm at a much more simple level. Like, for me, what I tell folks is try and use a network respectfully.

你知道什么时候该访问网络，也知道什么时候该退避。对于很多人来说，这意味着使用NWPathMonitor。我会说，是的，这条路现在可用。那它是否被视为受限或昂贵？例如，如果你要通过手机共享热点，那就是受限的。

You know, know when to hit the network and know when to back off. And for many folks, that means using NW path monitor. I'll say, yes, this route's available right now. Is it considered constrained or expensive? If you're gonna hotspot through a phone, for example, that's constrained.

或者你可以创建一个自定义的URL会话配置。这样你就可以直接说，是的，当网络受限时，根本不要允许网络数据传输。我不想知道它，因为它太昂贵了。如果你采用这种方法，那就更好了，因为你实际上可以将waitsForConnectivity布尔值设置为true。因此，iOS将会延迟你的请求，直到网络恢复，然后它会再次发起请求并正常返回结果。

Or you could make a custom URL session configuration. They'll you can just say, yes, don't even allow network data when it's constrained. I don't wanna know about it because it's too expensive. And if you do that approach, it's even better because you can actually set the waits for connectivity boolean to true. And so iOS will just delay your request until network comes back alive again, and it'll hit it then and return as normal.

这真的非常好。

It's really, really nice.

这样做之后，它就知道了你试图发出的是哪个网络请求，所以当网络恢复后，它就会执行你之前尝试的那个请求，对吗？

And with doing that, you it knows which network request you were trying to make, so then when it does come back, it will fire off that one that you were attempting to do?

是的。代码完全一样。如果你想的话，可以用async await，或者如果你想用旧的数据任务版本也没问题。它运行同样的完成闭包，也就是你之前的那段代码，只是时间晚了一些，这真的很棒。

Yeah. It's exactly the same code. Async await if you want to, or if you wanna use the old data task version, that's fine. It's this runs the same completion closure, the same code you had before, just later on, which is really, really nice.

哦，这真不错。我应该找个时间这么做一下。我只是说，嗯，我的应用完全是在线使用的，就这样。

Oh, that's nice. I should do that sometime. I just said Yeah. My app is a 100% online. That's it.

没错。你可以这么做。我想外面有一些缓存机制也挺好的，不是吗？某种形式的缓存？

Yes. You can do that. I think some caching's good out there, isn't it? Some sort of caching?

迟早的事。

Eventually.

哦，对了，版本二。公平地说，你确实可以控制缓存。你可以设置 URL 会话配置的请求缓存策略。你可以选择使用所有缓存、仅忽略本地缓存、忽略远程缓存，或者任何你想要的方式。

Oh, no. Version two. You do have control of caching, to be fair. You could set the request cache policy of your URL session configuration. And you could say, you know, use all the caches, ignore the local cache only, ignore the remote cache, whatever you want to.

仅仅一行代码就可以让一切变得更好很多。

And just one line of code can make everything a lot lot better.

我现在就要记下来，等我做所有事情的时候把它作为一个新的线性任务。听起来不错。因为我在我的应用中一直在做一件事，我觉得我花了很多时间去做这件事，仅仅是因为好玩。那就是这个项目实际上是创建了一个用于网络请求的枚举。我有一个网络控制器，可以发送某种符合类似网络请求协议的内容，然后这个网络请求就是好友端点，其中的一个 case 是用来获取好友信息的。

I'm gonna take a note of this right now to put this as, you know, a new linear task when I make everything. Sounds good. Because something I've been doing in my app, which I think I spend a lot of time kind of doing it just because for funsies. But that's like you know this whole project is making an actual enum that I use for the network request. I have like a network controller that can send off some kind of protocol that conforms like a network request and then the network request is like the friends endpoint and then a case is for getting friends.

在这种情况下，我会定义一些变量，它们都根据 self 的值进行切换。所以我可以这样写：这个 case 对应的端点是什么？是 /friends。HTTP 方法是什么？哦，是一个 GET 请求。

And then in that case I have variables that all just switch on self. So then I can be like, what's the endpoint? It's slash friends. What is the HTTP method? Oh, it's a get request.

然后我可以把这些内容都写在枚举里。这样一来，网络控制器就知道如何处理这些不同的请求类型。能够整合所有的信息，我觉得这非常有趣，因为你只需要定义一次，而不需要每次发起网络请求时都重复定义。

And then I can write all of this in the enum. So then the network controller would like know how to handle all these different kinds of requests. Be able to like put together all of the information, which I think is super fun because then you can define it once and you don't have to define it every single time you make that network request.

没错。对我来说，优秀的网络代码的主要标志就是在主应用程序逻辑中没有大段直接编写的网络代码。把请求类型、响应类型、方法等内容都集中在一个地方配置会让代码迅速变得非常混乱。只要调用 myManager.fetch 并传入 .users 就好了。

Yes. For sure. I think for me, the main hallmark of great networking code is is not having this big wadge of networking code direct in your main app logic. It gets very, very messy very quickly trying to configure request types and response types and methods and similar in one place. And just by to say my manager dot fetch and then pass in dot users.

就这样。.users 意味着去使用特定的请求方法访问该端点，这种方式要简洁得多，干净得多。说实话，它能避免出错。当然不是说你个人会犯错，而是总体上减少了犯错的可能性。没错。

And that's it. And not users means go ahead and hit this endpoint with this request method rather than the downline is so much nicer and so much cleaner. And it it honestly, it avoids you screwing up. Well, not, you know, you personally, but avoids one screwing up generally. Yeah.

因为这种错误太容易发生了。

Because it's so easy to do.

是的。一次性编写好，然后可以在任何地方复用，这是非常棒的。如果我们能在网络代码中做到这一点就更好了，毕竟作为 iOS 开发者，这是我们最常做的事情之一。我最初是从之前工作过的公司 Lookability 学到这种方法的。他们就是这样做的，并且他们在 GitHub 上有一个开源包，你可以找到它。

Yeah. Writing everything once and being able to use it everywhere is super nice. And if we can do that with our networking code because it's one the most common things we do as iOS developers, that's great. I had first originally, like, gotten this approach from, lookability, a company I previously worked for. They did this and they have an open source package, like, on GitHub, you can find it.

我基本上借鉴了其中的一些思路来构建我自己的实现。

And I basically used, like, pieces of that to make my own too.

如果我有一个吸引人的名字就好了，比如说，不要重复自己。

If only I had some sort of catchy name, like, I don't know, don't repeat yourself.

那很聪明。

That's smart.

在本期的公开投票中，我们问了你们一个问题，在距离Dub Dub DC '25还有好几个月的时候，你们希望在Xcode、SwiftUI、SwiftUI等方面看到哪些重大变化？我们收到了大量的回复，伙计们，太多了。我们不得不从中挑选了大约四分之一的内容。我认为这是第一次，大多数回复来自Mastodon。

For our open ballot this episode, we asked you, with several months still to go until dub dub d c '25, what are the major changes you're hoping to see in Xcode, SwiftUI, SwiftUI, more? We had a wall of responses, folks. So many responses. We've had to pick maybe a quarter of them here. I think for the first time, the majority came from Mastodon.

对吧？

Right?

是的。这很有趣，因为我们尝试将它们发布到所有的社交媒体上，包括Twitter、Mastodon和Blue Sky。我把它们发到了Threads上，所有这些平台都发了。所以在Mastodon上收到大部分回复是很有趣的。

Yeah. It's interesting because we try to post them all to all the socials, Twitter, Mastodon, Blue Sky. I post them on threads. All all of the all of the things. So getting a majority of their responses on Mastodon is very interesting to see.

没错。那么我们先来看看关于Swift的改进建议。就像Judas说的那样，作为一个新手开发者，我希望看到更直接的错误提示信息。一些能够真正帮助我解决问题的信息，而不是让我重新考虑我的人生选择。这是一个很有趣的问题，因为在SwiftUI的早期阶段，你经常会遇到相当糟糕的错误提示信息，比如编译器会告诉你无法进行类型检查。

Yeah. So let's go into the swift changes first. Hang in like Judas says, as a new developer, I would love to see more straightforward error messages. Something that can actually help me fix the issue, not make me rethink my life choices. So, yeah, this is an interesting one because in the very early days of SwiftUI, you'd regularly get fairly bad error messages that were, you know it would say, it can't type check this.

基本上就是祝你好运了。于是你就删除一半代码，问题还在。再删掉一半代码，问题仍然存在。

Good luck, basically. So you delete half the code. It's still there. Delete half the code. Still there.

继续删掉一半代码，哦，现在问题消失了。好吧。把刚才删的那一半加回去，然后去掉另一半试试看。

Delete half the code. Oh, it's gone away now. Okay. Put that half back. Take the other half out kind of thing.

你会用二分法来查找错误所在的位置。不过这个问题在Swift 5.2、5.3、5.4左右得到了很大改善，从那时起就变得非常好了。我不知道那里发生了什么。对于刚开始学习开发的人，他们可能只是拼错了一个枚举案例或者其他类似的小错误，但编译器却完全帮不上忙，这让我感到很难过。

And you do a binary chop to try and find where the error was. And then it got a lot better around sort of four 5.2, 5.3, 5.4 maybe, and then it's really created since then. I don't know what's happened there. I feel bad for developers who are just starting out and have mistyped an enum case or something, and it's giving them no help whatsoever.

能够读懂错误提示信息几乎就是作为开发者的必备技能。你能读懂编译器告诉你的那些晦涩难懂的东西吗？如果你能，很好，你就能正确地进行下去。

Being able to read error messages is literally like being a developer. Can you read the obscure thing the compiler is telling you? Okay. If you can, great. You're doing it right.

是的。Daniel Lyons曾说，我只是希望Swift能发布Swift语法的二进制文件，这样我就能在我有生之年完成编译了。我觉得这是个好主意。我无法形容Swift语法的重要性，朋友们，它就是Swift宏背后的技术。

Yeah. Yeah. We had Daniel Lyons saying, I just want Swift to ship this binaries of Swift syntax so I can compile before I die of old age. I I think it's a a good idea. I can't so Swift syntax, folks, is what is behind Swift macros.

所以你想创建一个Swift宏，任何一个Swift宏，你都必须引入Swift语法。而目前，这是一个非常重量级的依赖项，构建起来耗时很长。现在对于本地来说这是一次性的成本，但对于像CICD在线或云服务等场景，每次检出代码都需要重新构建，因此确实非常慢。

So you wanna make a Swift macro, any Swift macro, you've gotta bring in Swift syntax. And right now, it's a very heavyweight dependency. It takes a long time to build. Now it's a one time cost for local stuff, but for like CICD online, let's go cloud, whatever, that's a build every time you check the code out. So it's very, very slow indeed.

预先构建好的Swift语法的想法似乎很绝妙，但我确信一定有很多原因导致我无法这么做。如果真不行，我相信他们会告诉我。但我也很想了解其中的原因，因为我认为这确实是个好主意。

The idea of having a pre built Swift syntax seems brilliant, but I'm sure that every reason why I can't do it. If it if it is, I'm sure they'll let me know. But I'd love to know why folks, because I think it's a good idea indeed.

总是那一件小事让我们都在想，他们为什么不能就这么做了呢？

It's always that one little thing that we're all like, why can't they just do this?

我知道。然后我们才发现

I know. And then we figure

哦，原来如此。

out, oh, that's why.

哦，是啊。我知道。对吧？就在这里很明显。我们收到了很多关于并发的反馈。

Oh, yeah. I know. Right? It's obvious huge it's right here. We had a whole bunch of responses about concurrency.

我只挑出其中三条。Fred a nurse提到：别再每五分钟就推出一个改变世界的新功能了，让并发变得简单一些吧。现在只有《星际迷航》里那种超级大脑的人才能搞懂。Mike Sachs表示，在使用最新版Swift和框架特性时，请再次让常规路径变得特别容易。近年来，默认的Swift并发方式引入了大多数开发者本不需要面对的复杂性。

I'll pick out just three of them. We had Fred a nurse saying, stop introducing earth changing features every five seconds and make concurrency easy. Right now, only the giant brain people from Star Trek can figure it out. Mike Sachs said, making the happy path super easy again when using the latest and greatest Swift and framework features. The default Swift concurrency way in recent years has introduced complexity that most developers shouldn't have to deal with.

Matt Masacate则说，目前大量现有的SDK在Swift中根本运行错误。当你处于Swift 5模式下时更容易忽略这个问题，并且对象导入规则的变化也有所帮助。但目前的情况不容乐观。

And Matt Masacate said, right now, a huge portion of the existing SDK just plain works wrongly in Swift. It's easier to miss if you're in Swift five mode, and the change in the object of c import rules to help. But the situation right now is grim.

并发问题，我觉得我们几乎每一集都会谈到。它总是一个问题：我们到底要不要处理它？我们又该如何真正开始着手解决这个问题？我们之前已经有一期节目讨论过部分内容。

Concurrency, I feel like we almost talk about it every episode. It just keeps becoming that thing of do we do it? Do we not? How do we actually even get started with this? Which we've done an episode covering parts of it.

但正如大家所知，一旦你开启几个标志或者尝试启用某些功能，马上就会收到警告。这让人很害怕。最近我好像听说有一个新的提案，大概是说，是的，我们需要让这个变得更简单一些，因为现在每个人都在挣扎。

But then as everyone knows, once you turn on a few flags or you start and just try, you're just immediately hit with warnings. It's scary. And lately, there's a new proposal, I think it is, on this performs of them being like, oh, yeah, we do need to make this easier because everyone is struggling right now.

没错。我真为那些开发者感到难过。并发确实解决了一个实际问题。这些竞态条件确实存在，并且的确有问题。大多数我们中的人没有遇到它们，或者没有明显地遇到它们，并且以某种方式发布了优秀的软件，这其实挺烦人的，因为我们现在把很多初学者都吓退了，他们根本无法理解这些东西到底意味着什么。

Yeah. I feel really bad for folks. It concurrent is solving a real problem. These these race conditions definitely existed and were definitely problematic. The fact that most of us didn't hit them or didn't knowingly hit them and somehow shipped great software is annoying because it it it we're now putting off a lot of beginners who just don't understand, who don't understand what the hell this stuff means.

而且 Xcode 有时候会弹出最糟糕的自动修复建议。比如，哦，对了，只要将此类标记为 unchecked sendable，所有问题都会消失。别这么做。不要使用 unchecked sendable。

And Xcode throws up the most terrible fix it sometimes. Like, oh, yes. Just mark this class as unchecked sendable, and it'll all go away. Don't do that. Don't use unchecked sendable.

那是个非常糟糕的主意。别告诉我那样做。事实上，Matt Masacotti（可能是苹果之外最了解 Swift 并发的专家）表示，目前的情况真的很糟。这不是一个好兆头。我知道 Swift 团队正在努力改进这一切。

That's a really, really bad idea. Don't tell me that. And the fact that Matt Masacotti, who is probably the world expert on Swift concurrency outside of Apple, is saying, it's grim right now. That's that's a it's not a good sign. I know the Swift team are working so hard to make it better.

不仅是在优化代码路径和提升框架支持方面，还包括提供更好的错误信息，帮助开发者更清晰地诊断问题。情况会变好的，但现在嘛，确实不太理想。在 SwiftUI 方面，我们有 Pascal 提到，SwiftUI 的文本编辑器需要重大升级。他希望有更多的原生文本操作 API。

Not only in just smoothing out the code paths and improving the framework support, but also getting better error messages, you know, helping folks diagnose problems more clearly. It's gonna get better, but right now, yeah, it's it's it's not great. Over in SwiftUI, we have Pascal saying, SwiftUI's text editor needs a huge upgrade. I'm looking for more native text manipulating APIs.

没错。文本编辑器内的文本操作，我们完全没有这样的功能。当你想要做一些与默认提供的行为稍微不同的事情时，就开始变得棘手了。这适用于文本编辑器，也适用于像滚动视图或网页视图之类的东西。

Yes. Text manipulation within the text editor, Something we do not have at all. And it's something like when you want to do something slightly different than your leg prescribes with UI way, that's when it starts to get. Hairy for everything that you do. And then that applies like the text editor, but also like anything with like scroll views or web view or something.

就像你想做一些你觉得应该可以做到的事情，结果却发现完全不可能。所以如果我们能获得这些功能，那就太棒了。

It's like you want to do something that's what you I can't do. It's just completely impossible. So if we can get that, that'd be awesome.

我认为在这方面尤其如此，因为 Genmoji 需要更高级的文本支持。它需要能够直接在文本中插入这些高级图像的能力。这在 NS 文本视图和 UI 文本视图中都可以很好地实现，但在 SwiftUI 中没有支持，因为我们目前不支持富文本。我们只有纯文本。所以是的，你在那边提到的功能确实很重要。

I think particularly here because Genmoji requires more advanced tech support. It requires the ability to put these advanced images inside your text directly. And it's available in NS text view and UI text view just fine, but no SwiftUI support because we just don't do rich text right now. We have plain text only. So yes, something you have have there.

哪怕只是某种方法能做到这一点——我说“某种方法”其实只是随口一说。天哪，这简直难如登天。在 UI 文本领域，无论是 UI 文本委托还是类似机制，都非常复杂。

Even just some way of saying and I don't and I say just some way. Crikey. It's hard as hell. Hard as hell. In in UI text land, UI UI text will delegate and similar.

你可以做一些事情，例如检查刚刚更改的字符范围，比如从 a 到 b。然后你可以判断，哦，有没有改变这么多或者那么少之类的。但是在 SwiftUI 中我们没有这种控制能力。这很难，因为在 SwiftUI 中我们基本上没有委托机制，只有在桥接 UIKit 的时候才有。

You can do things for, like, check the range of characters that just changed, for example, between a and b. And you could say, oh, did it change this much or that much, whatever. And we haven't got that kind of control in SwiftUI. And it's hard because we haven't got delegates in SwiftUI really for the most part. We only have in UIKit bridging land.

因此，有很多类似的API，它们都需要相当复杂的拼写技巧才能正确地在SwiftUI中使用，才能让我们处理这个API的方式看起来合理。当然还有对富文本的支持，这也是一个完全不同的工作领域。我们会看到的。但请记住，朋友们，这是他们面临的诸多问题之一。

And so there's a whole bunch of APIs like that that require fairly sort of limbo dancing levels of spelling to get right into SwiftUI land to make it feel right into SwiftUI how we handle this API. And then, of course, you know, rich tech support as well. It's a whole other world of work. We're gonna see. But for for keep in mind, folks, the biggest problem one of the big problems one of the many problems they face.

是恐惧、惊讶以及对教皇的狂热忠诚。不，他们面临的众多问题之一就是，他们不能发布一个API然后说，好了，完成了，我们搞定了。

It's fear, surprise, and the fanatical devotion to the pope. No. One of many problems that they face is that they can't ship an API and say, okay. It's done. We're done with this.

他们会确保它在iOS、macOS、tvOS、watchOS和VisionOS上都能很好地运行，而要做到这一点非常困难。所以，是的，我们会看看情况如何，但我并不急于求成。我只想看到他们把它做好。接下来，Eric Barrios提到了SwiftUI在macOS下的稳定性与性能。哦。

They'll make sure it works great on iOS and macOS and tvOS and watchOS and VisionOS, and that's bloody hard to do. So, yeah, we'll we'll see how it goes, but I'm not in a rush in that one. I I wanna see him get it right. Next up, Eric Barrios said, SwiftUI stability and performance under macOS. Oh.

我刚刚发布了macOS应用，总体来说还不错。事实上，大多数情况下都非常棒。用SwiftUI快速搭建并运行一个原生的macOS应用简直太棒了。但只要我能重新进入App Store Connect，我会切换到Catalyst。我不喜欢Catalyst。

So I have just shipped the macOS app, and it has been mostly good. Mostly great, in fact. You know, fact that can go really great macOS app up and running very, very quickly, native macOS is incredible. But as soon as I can get back into App Store Connect, I'm gonna switch to Catalyst instead. And I don't like Catalyst.

我真的很不喜欢Catalyst。我想要一个原生的AppKit应用。但是AppKit中SwiftUI的那些小故障会让我收到用户的投诉，比如一星评价和大量愤怒的用户。而我无法修复这些问题，因为这跟我一点关系都没有。例如，SwiftUI中的标签视图。

I really don't like Catalyst. I want a native AppKit app. But the glitches in AppKit SwiftUI are just they are gonna get me complaints from users, like really one star rating reviews and angry users galore. And I can't fix them because they're nothing to do with me. Like, one of them is the tab view in SwiftUI.

你可以顺畅地在标签之间切换。但在macOS上，当你从标签A切换到标签B时，它会忘记标签A正在做什么，丢失标签A的所有状态。你可能在这里做着重要的事情，切换到标签B然后再切回来，哦，一切都消失了。

You can sculpt in tabs smooth smoothly. On macOS, when you go from tab a to tab b, it forgets what tab a was doing. It loses all the state from tab a. So you could be doing something important over here, switch tab b and then go back in. Oh, it's just gone.

这会让用户非常生气。所以我只能无奈地选择Catalyst。

And that's gonna really make users very, angry. And so I've gotta gotta go to Catalyst sadly.

哦，那真糟糕。我还没有用SwiftUI做过任何Mac OS项目，但我记得问过朋友，他们说，是的，效果不是很好。

Oh, that's rough. I have not done any Mac OS with SwiftUI, but I remember asking friends and they're like, yeah. It's not amazing.

去年这方面已经好很多了。他们在上面投入了很多努力，我想今年还会更好。我对此充满希望。我们拭目以待。Mark Powell表示他希望能看到SwiftUI的网页视图。

It got so much better last year. They put a lot of work into it and I think this year we'll see a lot more again. I'm very hopeful. So we'll see. Mark Powell says he wants to see SwiftUI web views.

当然。WKWebView可以完成许多任务，比如WebKit等，但我们却什么都做不了。我们甚至无法显示WebView，还必须回到UIKit去做这些。因此，在SwiftUI中能实现任何程度的WebView使用都将是一个巨大的改进。

Absolutely. WKWebView can do so much stuff like WebKit and everything, and we can't do any of that. We can't even display the WebView. We still have to go back to UIKit to do that. So getting just anything of using the web view in SwiftUI would be a great addition.

我觉得他们不会随便做点什么就算了。比如，记得地图应用刚推出SwiftUI的时候吗？那时候地图勉强能用。然后，哦，可能是两年前吧？现在针对SwiftUI有一个巨大的MapKit升级，感觉现在变得特别好了。

I'm thinking they won't just do anything. Like, remember when maps launched SwiftUI, and it was like, maps kinda work. And then, oh, two years ago maybe? Okay. There's a huge map kit upgrade now for SwiftUI and it's like, oh, this is this is hella good now.

你知道的，他们在SwiftUI的地图功能上投入了很多心血。我认为他们会努力做到这一点。到现在为止，SwiftUI已经五六年了。他们不能只是做一个基础版的WebView复制品。他们在做一些事情。

You know, they've done a lot of a lot of love here in this SwiftUI map stuff. I think they're gonna strive for that. At this point, we're five, six years in SwiftUI. They can't just do a bare bones duplicate WebView. They're doing something.

显然他们在做某些事情。你可以看到WebKit是一个开源项目。你可以看到有提交记录在发生。他们在这方面非常努力。但我希望今年能看到WebKit的重大更新，并且带来很多改进。

They're they're obviously doing something. You can see WebKit's an open source project. You can see commits happening. They're working very hard on this. But I I'm hoping for a really big drop of WebKit this year with a lot of love behind it.

我们走着瞧吧。我们的老朋友Stuart Lynch说：“我很想看到一个简单的SwiftUI相机组件。Foundation对我来说太重了，大部分情况下我都不需要，而我讨厌必须使用UIKit的实现。因此这正是UIKit有点迷失的一个领域。它曾经有UIImagePickerController，可以处理图片，但奇怪的是也能处理相机相关功能。

We'll see. Our good friend Stuart Lynch says, I would love to see a simple SwiftUI camera. A foundation is too much for most of my needs, and I hate having to use the UI kit implementation. So this is an area where UI kit kind of got a bit lost. It had like UI image pick controller, which handled images, but also camera stuff weirdly.

这让拍照和选择图片这种操作很容易融合在一起，得到统一的结果，这点挺酷的。但对于SwiftUI来说可能不太合适。所以我想他们正在重新思考这个问题。是的，我也很想看到一些SwiftUI的相机相关功能。

And it made it made that sort of jewel, is it a picture or a camera thing, very easy to blend together in one result, which is cool. But it it wouldn't be great for for SwiftUI. And so I guess they're rethinking that. Yeah. I'd love to see some sort of SwiftUI camera stuff.

拍一张照片，把它作为图片、数据或图像对象导入进来，然后直接渲染出来。那将是非常棒的体验。

Take a picture, bring it in as a picture, as a data or image object perhaps, and render it straight away. Be lovely.

我完全同意。我觉得这个想法非常有野心，可能不太现实，但如果当你调出相机时，在预览或者模拟器中，它可以直接使用你的Mac摄像头，这样你至少可以将其与某个东西关联起来，让系统自动识别：哦，我正在使用模拟器，那就用网络摄像头代替相机。而不是仅仅显示一个空白屏幕，告诉你“你在模拟器上看不到这个”。这是个很宏大的想法，但他们也许真的能做到。

A 100% agree. I think it's very ambitious and probably will not happen, but it would be cool if when you present the camera, could that also if you're in, like, previews or simulator, could it just, like, use your Mac camera so you could at least like have it tied to something and it just kind of figure out that like, oh, I'm using the simulator. Just use the webcam as the camera rather than just being like, you know, present an empty screen, be like you can't see this on the simulator. It's ambitious, but maybe they could do it.

我很喜欢你还相信模拟器还能得到任何实质性的改进。我认为这个应用已经死了。我觉得整个应用都没戏了。我的直觉告诉我，苹果可能曾试图用更好的东西来替代它，但失败了，或者放弃了，或者改变了主意，或者资源不足，又或者失去了动力。因为有了Xcode Cloud之后，他们本可以做出更出色的模拟器。

I love that you still think simulator gets any work done to it at all. I think it's dead. I think the whole app is dead. I think my my gut instinct is that Apple probably tried to replace it with something better and failed or or backed out or changed their mind or lost resources or lost willpower. Because with Xcode Cloud being there, they could do a much better simulator.

比如，去测试这个应用在50台设备上的运行情况。开始。砰。那将会太棒了。但是，是的，实际上，这些都没有发生，恐怕。

Like, go and test this thing across 50 devices now. Go. Boom. That'd be amazing. But, yeah, in in practice, none of those, I'm afraid, actually happens.

所以我们拭目以待吧，不过我不确定近期是否能看到这些变化的发生。

So we'll we'll see, but I'm not sure we see any of that kind of happening in the near future.

我感到充满希望，因为我知道他们修复了一个bug，这个bug导致你无法在模拟器中移动应用程序图标，现在又可以移动了。所以我想，有人确实进去改动了一些东西。

I'm hopeful because I know they fixed a bug where you couldn't move any of the app icons around in the simulator, and now you can again. So I'm like, someone someone was in there changing things.

几年前有一个bug，比如甚至无法打开设置。是不是iOS 17？那时候就是坏的。没错。而且还有大量其他问题都与Swift数据有关。

There was a a bug a few years ago of, like, even launching settings wouldn't work. Is it iOS 17 perhaps? It was just broken. Yeah. And one whole bunch of more stuff was on Swift data.

乔·鲍杜瓦希望看到Swift数据性能能够达到Core Data的水平。处理大型复杂数据集时，Swift数据变得难以使用。真的吗？这很有趣。我完全没有遇到这种情况。

Jo Baudois would like to see Swift data performance to match correlated performance. Large, complex datasets makes Swift data unusable. Really? That's very interesting. I haven't found that at all.

我自己还没碰到这个问题，我也没有太多使用SwiftData的经验。不过我也确实没有听说过这样的抱怨。

I haven't hit that, but I haven't done too much with SwiftData either. But I haven't I haven't heard that complaint though either as well.

乔，记住SwiftData是基于Core Data构建的，对吧？所以如果你启用了SQL调试功能，你可以看到幕后发出的SQL语句。如果协调器和Core Data使用的SQL相同，那它们的速度应该是一样的。如果SQL不同，那你可能需要考虑一下你的谓词，也许就是这样。

Joe, keep in mind that SwiftData backed onto CoreData. Right? So if you enable the SQL debugging stuff, you can see what SQL is being issued behind the scenes. And if it's the same SQL for coordinator and and sort data, which which it should be, then it'll be the same speed no matter what. If it's different SQL, you gotta try and think about your predicates perhaps, maybe.

我不太确定那里有什么变化。迈克尔·罗斯说，让多谓词查询和复杂连接更容易一些就好了。就这样，就这样。

I'm not sure what changed there. Michael Rose says, just make it easier to do multi predicate queries and complex joins. Just just just just just.

只需要一点小小的改进。我们只需要一点点就好。

Just a little improvement. That's all we need. Just a little bit.

由于多谓词查询在幕后构建的方式，实现起来会非常困难。整个哈希谓词宏机制会在幕后为你构建一大堆这种谓词类型，因此它们官方上是类型安全的。其实并不是，但官方说是。所以其中某些要实现的功能实际上可能会非常困难。我不确定。

Multi predicate queries will be very, very hard because of the way they're built behind the scenes. The whole hash predicate macro thing builds a whole bunch of these predicate types behind the scenes for you so they're officially type safe. They're not, but officially are type safe. So one of those just things to do could be actually very, very hard. I'm not sure.

但祝你好运。我自己也很想看到它能实现。毕竟NSCompoundPredicate不是我们想要的东西，对吧？

But good luck. You know, I'd love to see it too. It's it's not like NSCompound predicate is what we want. Right?

没错。只要能够查询你的数据就行。因为保存数据是一回事，但如何查询才是对我们所有人来说真正重要的事情。我们使用数据的方式其实就是如何读取所有内容。

Yes. Just being able to query your data. Because saving the data is one thing, but how you query it is actually really what matters to all of us. Like, that is how we use data is how do we actually read everything.

很多用户，比如Wilson Good、Alexandra Wavron，还有很多人说，希望在使用Swift Data时能够在用户之间实现CloudKit共享。我认为从一开始大家就在问这个问题了。我们早就有了针对Core Data的高级CloudKit共享功能，但已经两年没有任何更新了。我知道，我知道。

A whole bunch of folks, Wilson Good, Alexandra Wavron, and many more said, I would love to have CloudKit sharing between users when using Swift Data. I think this has been a question since day one. We had advanced CloudKit sharing for Core Data for quite a while now, and nothing has been updated now for two years. I know. I know.

我知道这阻碍了很多人。

I know it's holding a lot of folks back.

确实是这样。这是我决定不在我的另一个小项目中使用Swift Data的主要原因之一。我甚至已经新建了一个项目，但也就仅此而已了。Swift Data缺乏共享功能是主要原因之一。我想开发一个超级简单的列表，并且可以与两个人共享，但现在还无法做到。你只能使用Core Data。

Absolutely. This is one of the top reasons I decided not to use Swift Data for, you know, one of my other little side projects that like I've done file new project and that's the farthest I got. But Swift Data not having sharing is one of the top reasons because I wanna make something where it's a super simple list and it can just be shared between two people and that's not possible right now. You have to use Core Data.

各位，如果你是Swift Data团队的成员，请考虑一下，当这个功能最终发布的时候，是否能有一个兼容iOS 18的方案。因为协调器支持共享的不同环境已经存在了。但从iOS 19开始加入这些功能还需要很长时间才能被开发者广泛采用。所以如果能够提供某种向后兼容性，比如说现在可以在iOS 18甚至更早的iOS 17上运行，那将会太棒了。最后，以Frank Foster的一个建议结束：推出Swift Assist吧。

Folks, if you're listening from the Swift Data team, if there's any way when this finally ships, it can have some kind of back compat story to iOS 18 at the very least. Because it's you know, this the the coordinator support's already there for sharing the different environments similar. But adding that into the data as well from iOS 19 onwards will be great, but would take a long time to get up from developers. So if you could have some kind of back compatibility story there, say, yes, it'll now work in iOS 18 or even, gosh, 17, would be amazing. And finally, one to end on from Frank Foster, an actual release of Swift Assist.

通常情况下，我们会让这个话题自然结束，就这样完了。我们不会再去回应这个结尾的问题。但这次，我不太确定。

So normally, we'd let this one to end on just kinda end, and that would be it. We wouldn't, like, respond to the one to end on. That'd be it. But this one, I I I don't know. I I don't feel quite right about it.

看，我也想看到Swift Assist。当然，我当然想。但我们其实……我不知道。我们只是观众席上的普通观众而已。

Look, I want to see Swift Assist. Of course, I do. Of course, I do. But like, we are effectively I don't know. We're in we're in the peanut gallery, folks.

我们只是坐在最便宜的位置看着苹果试图完成一些惊人的事情。而像我这样的人一直在唠叨追问，‘到底在哪？到底在哪？’嗯。

We're the the cheapest seats of the of the audience watching Apple try and pull off something amazing. And people like me harping on about it, badgering away saying, you know, where is it? Where is it? Where is it? I yeah.

我很期待看到它，但这并没有帮助。没有帮助，对它本身也没有任何好处。所以我现在可能不会再提这件事了，因为没用。这既帮不了他们，也帮不了我们，对系统整体也没有好处。

I'm eager to see it, but it's not helping. It's not helping. It's not gonna make it any better by badgering them about it. And so I'm, at this point, probably not gonna mention it anymore because there's no point. It doesn't help them, doesn't help us, doesn't help sort of sys get any better.

所以让他们去做该做的工作，花该花的时间，我们拭目以待。最后，我想引用我最喜欢的任天堂游戏设计师宫本茂的一句话来结束今天的分享：‘延期的游戏最终会变好，但仓促推出的游戏将永远糟糕。’

And so let them do the work, take the thought it takes, and we'll see how it gets on. And I wanna leave you with the words of one of my favorite game designers ever, Shigeru Miyamoto from Nintendo. And he said, a delayed game is eventually good, but a rushed game is forever bad.

感谢大家收听。别忘了告诉你的朋友订阅我们的节目，当然也请留下您的评价。我们下一次开放投票的话题是：你在苹果平台之外如何使用Swift？你是在服务器端还是嵌入式设备上使用？告诉我们吧。

Thank you to everyone for listening. Be sure to tell your friends to subscribe and, of course, leave a review. Our next open ballot, how are you using Swift outside of Apple platforms? Are you using on the server, embedded? Let us know.

下次见。再见。

See you next time. Bye.

再见。

Bye.

我想我得走了，因为延迟退房现在就结束了。

I think I do have to go because the late checkout ends, like, now.