当年（ iOS 4 左右的时代）硬件所限，要在 iOS 上开发流畅应用的确需要极致的优化功夫。今天已经不需要了，你看 iOS 上的商业 App ，并不会觉得真的比安卓优化得好多少（后台、权限这些问题除外）。

要说苹果清醒，大概不把 macOS 放到 iPad 上算一件清醒的事吧。

@libook
忒修斯之船。其实这个现象可能已经发生在 Windows 和 macOS 了（相比七八十年代的旧代码库）

好像原生安卓的通话录音也取消了

Unix 哲学说，机制优于策略。到今天，传统意义的 Unix 已经死了，但继承 Unix 理念的系统被发扬光大。所以一百年后，今天的软件未必活着，但一定会有新作品继承它们的精神。

我每次在 App 里付款的时候，有 Apple Pay 我就优先用😂不知道服务端统计里能有几个人用 Apple Pay

1. 其实到处让人填个人资料这种事，除了说明大众没有尊重隐私的观念外，还意味着整个管控体系的信息化非常落后。即使没有 COVID ，咱从小学到大学想必也填过无数份个人资料、家庭信息吧，为什么要填这么多次呢？

身份证号这种迁户口都无法 revoke 的东西（人脸识别也是一样）到处飞本来就极不靠谱。理想的形态应该 GOV 给每个人签署一对密钥，存储在手机或者某个硬件密钥里，然后使用的时候要求认证才能签名。如果遇到泄露，可以去申请 revoke 并重新颁发密钥。

听起来太麻烦了，一点不现实？其实你仔细思考下，现行的健康码行程码核酸码医保码从使用者角度说只会比这个麻烦。参考今天 WWDC 讲身份证和 Passkey 的那部分吧。

2. 不用想，该联网的早就联网啦。个人信息泄露到这一步已经彻底没法挽回了。个人能做的只有尽量减少自己产生的其他信息同个人身份关联起来的机会。要知道数字人民币还没推开哦。

国内普通人对隐私泄露危害的认知，主要是「犯罪分子知道你个人信息后可以用来诈骗」，至于后来咱是怎么解决诈骗这个问题的嘛……

隐私保护这个问题跟控枪有些像。犯罪分子的技术力和资源永远比普通人强大：一开始实名验证用身份证+姓名就够了，后来要上传身份证照片，后来要手持，再后来又要人脸识别……这件事没有头

顺便问懂医学的朋友一句：核酸检测能采集到个人的 DNA 信息吗？就是像去专业机构做 DNA 检查一样？

应该有很多人是因为对这个作者印象不好所以才不推荐的吧，不过独立开发者里面这种人本来也不少..

1. iPhone X 一直到 12 的刘海比例是相对合适的，虽然不完美，但刘海在短边上，顶栏还变厚了，用手机的时候对视线没那么大影响。
2. iPhone 13 系列把刘海变窄了，虽然屏占比变高，但视觉上更像是顶部缺了一块而不是屏幕向两角各扩展了一块，其实是变难看了。此前某些安卓手机极端追求屏占比结果搞得不伦不类也是这个原因。
3. MacBook 的屏幕刘海在长边，这个缺了一块的感觉会更明显，而且很容易注意到这个刘海。我已经用 SwitchResX 强制把分辨率改回 16:10 ，回到和 Intel 16 寸一样的显示效果了。感谢 MiniLED ，刘海那一栏不显示内容的时候完全不发光。
4. 既然能在笔记本上加刘海，那平板也不是不可以加刘海。平板的刘海只会比电脑和手机的更恶心——电脑不会竖屏用，手机只有看视频玩游戏的时候会横屏，而 iPad 刘海无论加在哪一边，总会有一批人大部分使用时间会被恶心。

单说通勤的话，北京可能比较难受，但是上海广州深圳应该还是能找到离公司不远的房子的。

YouTube Music 没有桌面客户端其实挺恶心的

现代文也没必要分。小学学语文老师就说过一群人既有男的也有女的就用「他们」，「他」这个字本来也没有男字旁，就应该男女都可以表述，省得用「他」指代女性还有人出来打拳

每当我坚定地觉得还在用 8G 内存已经是对 Mac 这个品牌的不尊重的时候，点开本站二手交易区和微博关注的几个买全新 /二手的博主，M1 Mac 清一色的 8+256 或者 8+512 ，极少见到 16G 内存

大幅增强多任务、后台能力，完整支持外接显示器，部分开放侧载权限，提高稳定性。至于上 macOS 就别想了，苹果不会这么做，作为用户也不希望如此

苹果的所有在线服务，最稳定的只有一个：APNs ，就是手机上的消息推送。其余的，抽风都是日常

@vain
阿里的所有服务都集成了这个东西，包括优酷啥的，特别恶心

@agagega
复杂的情况下你可以自己定义 Binding ，@ Binding 和$只是语法糖，Binding 的本质就是一个封装了 getter 和 setter 的对象： https://developer.apple.com/documentation/swiftui/binding

@MakHoCheung
SwiftUI 有 @ Binding 这个东西，如果你的 User 是 struct 并且 user 是 @ State ，那可以直接$user 传给子组件，子组件 @ Binding user: User 。这种情况因为都是值语义所以不需要定义 ViewModel 了

我没能太理解你的问题。

@ ObservedObject 和 @ State 标记都是用来做数据绑定的，View 里如果引用到了这些标记的变量，当它们改变时，View 也会对应更新。

之所以要区分 ObservedObject 和 State ，是因为 Swift 不同于 JS ，是一个严格区分值语义和对象语义的语言。Swift 中，struct 和大部分没有 NS 前缀的内置类型都是值语义，即任何一部分被修改了都会视为整个对象被修改；而 class 和 Foundation 里 NS 开头的类型都是对象语义，对它们属性的修改并不会被视为对整个对象的修改。

因为 MVVM 的核心就是追踪绑定数据的改变，所以 SwiftUI 必须区别对待值语义变量和对象语义变量。对值语义用 @ State ，任何修改都会简单触发 View 重新渲染；对对象语义用 @ ObservedObject ，被它修饰的类型都要满足 ObservableObject 这个协议，这些类型中任何被 @ Published 修饰的成员发生修改，整个对象就会触发 objectWillChange 事件。

这和 ViewModel 本身没有关系，只是因为 ViewModel 本来就是我们自己定义出来封装事件逻辑的模块，所以通常会实现为 class ，然后加上 @ ObservedObject 做修饰。

SwiftUI 里还有个修饰符叫 @ StateObject ，也是修饰对象语义的，和 ObservedObject 的区别在于后者不会维护对象的生命周期，而 StateObject 在生命周期上和 State 类似，由当前组件来维护。