SwiftUI geometryGroup() 指南：从原理到实践
在 WWDC 2023 中，苹果为 SwiftUI 添加了一个新的修饰器：geometryGroup()。它可以解决一些之前无法处理或处理起来比较困难的动画异常。本文将介绍 geometryGroup() 的概念、用法，以及在低版本 SwiftUI 中，在不使用 geometryGroup() 的情况下如何处理异常。
在 WWDC 2023 中，苹果为 SwiftUI 添加了一个新的修饰器：geometryGroup()。它可以解决一些之前无法处理或处理起来比较困难的动画异常。本文将介绍 geometryGroup() 的概念、用法，以及在低版本 SwiftUI 中，在不使用 geometryGroup() 的情况下如何处理异常。
在 iOS 16 中，SwiftUI 增加了一个新的自适应布局容器 ViewThatFits。正如其名称所示，它的作用是在给定的多个视图中找出最合适的视图并使用。对于大多数人来说，这是一个简单易用的容器。不过，本文打算对其进行彻底的剖析，包括规则细节、理想尺寸的含义、使用示例等。最后，我们将创建一个复刻版本的 ViewThatFits，以加深对其的认识和理解。
GeometryReader 自 SwiftUI 诞生之初就存在，它在许多场景中扮演着重要的角色。然而，从一开始就有开发者对其持负面态度，认为应尽量避免使用。特别是在最近几次 SwiftUI 更新中新增了一些可以替代 GeometryReader 的 API 后，这种观点进一步加强。本文将对 GeometryReader 的“常见问题”进行剖析，看看它是否真的如此不堪，以及那些被批评为“不符预期”的表现，是否其实是因为开发者的“预期”本身存在问题。
在上文中，我们介绍了 TipKit 的基础用法。在本文中，我们将讨论一些与 TipKit 相关的进阶问题，例如如何完全自定义 Tip 视图（不使用 TipView 和 popoverTip）、如何在 UIKit 中使用 TipKit，以及 TipKit 如何在不同的应用程序之间共享数据。最后，我们将尝试解答一些与 TipKit 相关的疑惑。
TipKit 是苹果在 WWDC 2023 上新推出的一个框架，可轻松在你的应用程序中显示提示。它可用于向用户介绍新功能，帮助他们发现隐藏的选项或展示完成任务更快的途径等场景。TipKit 可以运行在苹果生态系统的不同硬件环境和操作系统上，包括 iPhone、iPad、Mac、Apple Watch 和 Apple TV。我将用两篇文章探讨 TipKit 框架。在本文中，我们首先学习 TipKit 的用法；在下篇中，我们将讨论更多使用技巧、注意事项、实现原理，以及在其他场景中使用 TipKit 等扩展话题。
本文将解析 SwiftUI 中两个由于未能贯彻响应式编程原则而导致的严重错误，并提供相应的解决方案。这两个错误包括：通过手势取消 Sheet 后，快速右滑导航容器导致应用锁死；以及在滚动中返回上层视图时导致应用崩溃。
SwiftUI 因其简便的动画 API 与极低的动画设计门槛而广受欢迎。但是，随着应用程序的复杂性增加，开发者会逐渐发现，尽管动画设计变得前所未有的简单，但要实现精确细致的动画控制并非易事。同时，在 SwiftUI 的动画系统中，Transaction 始终有点像谜一样的存在。无论是官方资料还是第三方文章，都很少对其运作机制进行系统的阐述。本文将通过探讨 Transaction 的原理、作用、创建和分发逻辑等内容，告诉读者如何在 SwiftUI 中实现更加精确的动画控制，以及需要注意的其他问题。
在 WWDC 2023 中，苹果介绍了 Swift 标准库中的新成员：Observation 框架。它的出现有望缓解开发者长期面临的 SwiftUI 视图无效更新问题。本文将采取问答的方式，全面而详尽地探讨 Observation 框架，内容涉及其产生原因、使用方法、工作原理以及注意事项等。
在 SwiftUI 5.0 中，苹果大幅强化了 ScrollView 功能。新增了大量新颖、完善的 API。本文将对这些新功能进行介绍，希望能够让它们更多、更早的帮助到有需要的开发者。
WWDC 2023 正在如火如荼地进行。苹果不仅带来了全新形态的硬件产品，还推出了几个相当震撼的新框架。本文将聊聊我对本届 WWDC 中 SwiftUI 和 SwiftData 的初步印象。
作为 SwiftUI 最引人注目的功能之一，预览功能吸引了不少开发者初次接触 SwiftUI。然而，随着项目规模的增长，越来越多的开发者发现预览功能并不如最初想象的那么易用。由于预览崩溃的次数和场景的增加，一些开发者已经视预览为 SwiftUI 的缺点之一，并对其产生了排斥感。预览功能真的如此不堪吗？我们当前使用预览的方式真的妥当吗？我将通过两篇文章来分享我对预览功能的认知和理解，并探讨如何构建稳定的预览。本文将首先剖析预览功能的实现机制，让开发者了解哪些情况是预览必然无法处理的。
距离 2023 年的 WWDC 还有约 20 天，每个苹果生态的开发者都在期待苹果会在当天带来哪些新东西。在本文中，我将列出个人对于 SwiftUI 的愿望单，期待着看到哪些愿望能够实现。
4 月 18 日和 20 日，苹果分别在上海和北京举办了两场“SwiftUI 技术沙龙”活动。由于近几年类似的线下活动举办得极少（疫情原因），因此报名的开发者众多，早早地将参会名额预定一空。我很荣幸能够作为分享嘉宾参加了北京的活动。在这次交流中，我学习了不少新知识，与很多之前只在网上沟通的朋友见了面，并结交了不少新朋友。
本文是笔者参加 2023 年 4 月 20 日 “SwiftUI 技术沙龙（ 北京站 ）” 活动的分享内容。基于记忆整理而成。本次活动采用的是线下交流并辅以 live coding 的形式，因此内容的侧重点以及组织形式与以往的博客文章会有明显的不同。
onAppear（ task ）是 SwiftUI 开发者经常使用的一个修饰符，但一直没有权威的文档明确它的闭包被调用的时机。本文将通过 SwiftUI 4 提供的新 API ，证明 onAppear 的调用时机是在布局之后、渲染之前。
尽管 SwiftUI 的惰性容器以及 Core Data 都有各自的内存占用优化机制，但随着应用视图内容的复杂（ 图文混排 ），越来越多的开发者遇到了内存占用巨大甚至由此导致 App 崩溃的情况。本文将通过对一个演示 App 进行逐步内存优化的方式（ 由原先显示 100 条数据要占用 1.6 GB 内存，优化至显示数百条数据仅需 200 多 MB 内存 ），让读者对 SwiftUI 视图的存续期、惰性视图中子视图的生命周期、托管对象的惰值特性以及持久化存储协调器的行缓存等内容有更多的了解。
最近时常有朋友反映，尽管 SwiftUI 的布局系统学习门槛很低，但当真正面对要求较高的设计需求时，好像又无从下手。SwiftUI 真的具备创建复杂用户界面的能力吗？本文将通过用多种手段完成同一需求的方式，展示 SwiftUI 布局系统的强大与灵活，并通过这些示例让开发者对 SwiftUI 的布局逻辑有更多的认识和理解。
本文将通过一段可复现的“灵异代码”，对 State 注入优化机制、模态视图（ Sheet、FullScreenCover ）内容的生成时机以及不同上下文（ 相互独立的视图树 ）之间的数据协调等问题进行探讨。
通过 Style 改变组件的外观或行为是 SwiftUI 提供的一项非常强大的功能。本文将介绍如何通过创建符合 ButtonStyle 或 PrimitiveButtonStyle 协议的实现，自定义 Button 的外观以及交互行为。
保证应用不因 Core Data 的原因导致意外崩溃是对开发者的起码要求。本文将介绍可能在视图中产生严重错误的原因，如何避免，以及在保证视图对数据变化实时响应的前提下如何为使用者提供更好、更准确的信息。由于本文会涉及大量前文中介绍的技巧和方法，因此最好一并阅读。
本文中我们将探讨在 SwiftUI 视图中批量获取 Core Data 数据的方式，并尝试创建一个可以使用 mock 数据的 FetchRequest。由于本文会涉及大量前文中介绍的技巧和方法，因此最好一并阅读。
在上文中，我列举了一些在 SwiftUI 中使用 Core Data 所遇到的困惑及期许。在今后的文章中我们将尝试用新的思路来创建一个 SwiftUI + Core Data 的 app，看看能否避免并改善之前的一些问题。本文将首先探讨如何定义数据。
我使用 Core Data 已经有三年的时间了，虽然至今也不能算是完全掌握，但基本上可以做到熟练使用，很少会犯原则性的错误了。当前，如何让 Core Data 融入流行的应用架构体系，在 SwiftUI、TCA、Unit Tests、Preview 等环境下更加顺畅地工作已成为我的主要困扰和研究方向。我将通过几篇文章来介绍近半年来在这方面的一些想法、收获、体会及实践，也希望能够与有类似困惑的朋友进行更多的探讨。
随着苹果对 iPadOS 的不断投入，越来越多的开发者都希望自己的应用能够在 iPad 中有更好的表现。尤其当用户开启了台前调度（ Stage Manager ）功能后，应用对不同视觉大小模式的兼容能力就越发显得重要。本文将就如何创建可自适应不同尺寸模式的程序化导航方案这一内容进行探讨。
随着 SPM（ Swift Package Manager ） 功能的不断完善，越来越多的开发者开始在他的项目中通过创建多个 Package 的方式来分离功能、管理代码。SPM 本身提供了对包中各类资源（ 包括本地化资源 ）的管理能力，但主要局限于在本包中使用这些资源，难以将资源进行共享。在有多个 Target 均需调用同一资源的情况下，原有的方式很难应对。本文将介绍一种在拥有多个 SPM 包的项目中，对资源进行统一管理的方法。
Ask Apple 为开发者与苹果工程师创造了在 WWDC 之外进行直接交流的机会。本文对本次活动中与 SwiftUI 有关的一些问答进行了整理，并添加了一点个人见解。本文为下篇。
Ask Apple 为开发者与苹果工程师创造了在 WWDC 之外进行直接交流的机会。本文对本次活动中与 SwiftUI 有关的一些问答进行了整理，并添加了一点个人见解。本文为上篇。
本文将聊聊一个与创建复杂的 SwiftUI 应用很契合的框架 —— The Composable Architecture（ 可组装框架，简称 TCA ）。包括它的特点和优势、最新的进展、使用中的注意事项以及学习路径等问题。
StateObject 是在 SwiftUI 2.0 中才添加的属性包装器，它的出现解决了在某些情况下使用 ObservedObject 视图会出现超预期的问题。本文将介绍两者间的异同，原理以及注意事项。
到 2022 年，SwiftUI 已经迈入了第四个年头。尽管在之前的版本更新过程中，SwiftUI 也出现了或多或少的问题，但从来也没有像 SwiftUI 4 这么严重。Bug 众多的现象不仅仅表现在 SwiftUI 上，在 iOS、macOS 以及苹果很多其他的产品上都有所体现。
经常有朋友咨询，学习 SwiftUI 的最佳路径是什么？考虑到每个人的技术背景、学习能力、工作经验均不一样，因此很难说哪种学习方式或哪些资料是适合他本人的。不过随着这个问题被反复提起，最终还是想尝试整理一些资料给对 SwiftUI 感兴趣的朋友。本文将介绍一些对学习者技术基础要求较低（ 甚至可以零基础 ）的教程。
判断一个可滚动控件（ ScrollView、List ）是否处于滚动状态在某些场景下具有重要的作用。比如在 SwipeCell 中，需要在可滚动组件开始滚动时，自动关闭已经打开的侧滑菜单。遗憾的是，SwiftUI 并没有提供这方面的 API 。本文将介绍几种在 SwiftUI 中获取当前滚动状态的方法，每种方法都有各自的优势和局限性。
将某个视图在父视图中居中显示是一个常见的需求，即使对于 SwiftUI 的初学者来说这也并非难事。在 SwiftUI 中，有很多手段可以达成此目的。本文将介绍其中的一些方法，并对每种方法背后的实现原理、适用场景以及注意事项做以说明。
前些日子，一位网友在聊天室中就如何通过 Text + AttributedString 实现类似文章关键字检索的功能，并可通过按钮在搜索结果中进行滚动切换的问题与大家进行了交流与探讨。考虑到这个问题对于 SwiftUI 的应用来说比较新颖，且涉及不少博客中介绍过的知识，因此我对聊天室原本给出的解决方案进行了重新整理，并通过本文对解决思路、方法手段以及注意事项等内容与大家进行探讨。
SwiftUI 提供了强大的布局能力，不过这些布局操作都是在视图之间进行的。当我们想在 Text 中进行图文混排时，需要采用与视图布局不同的思路与操作方式。本文将首先介绍一些与 Text 有关的知识，并通过一个实际案例，为大家梳理出在 SwiftUI 中用 Text 实现图文混排的思路。
随着 Swift 5.5 引入了 async/await 特性，苹果也为 SwiftUI 添加了 task 视图修饰器，以方便开发者在视图中使用基于 async/await 的异步代码。本文将对 task 视图修饰器的特点、用法、注意事项等内容做以介绍，并提供了将其移植到老版本 SwiftUI 的方法。
随着近年来有关 SwiftUI 的文章与书籍越来越多，开发者应该都已经清楚地掌握了 —— “视图是状态的函数” 这一 SwiftUI 的基本概念。每个视图都有与其对应的状态，当状态变化时，SwiftUI 都将重新计算与其对应视图的 body 值。如果视图响应了不该响应的状态，或者视图的状态中包含了不该包含的成员，都可能造成 SwiftUI 对该视图进行不必要的更新（ 重复计算 ），当类似情况集中出现，将直接影响应用的交互响应，并产生卡顿的状况。通常我们会将这种多余的计算行为称之为过度计算或重复计算。本文将介绍如何减少（ 甚至避免 ）类似的情况发生，从而改善 SwiftUI 应用的整体表现。
在上篇中，我们对 SwiftUI 布局过程中涉及的众多尺寸概念进行了说明。本篇中，我们将通过对视图修饰器 frame 和 offset 的仿制进一步加深对 SwiftUI 布局机制的理解，并通过一些示例展示在布局时需要注意的问题。
在 SwiftUI 中，尺寸这一布局中极为重要的概念，似乎变得有些神秘。无论是设置尺寸还是获取尺寸都不是那么地符合直觉。本文将从布局的角度入手，为你揭开盖在 SwiftUI 尺寸概念上面纱，了解并掌握 SwiftUI 中众多尺寸的含义与用法；并通过创建符合 Layout 协议的 frame 和 fixedSize 视图修饰器的复制品，让你对 SwiftUI 的布局机制有更加深入地理解。
“对齐”是 SwiftUI 中极为重要的概念，然而相当多的开发者并不能很好地驾驭这个布局利器。在 WWDC 2022 中，苹果为 SwiftUI 增添了 Layout 协议，让我们有了更多的机会了解和验证 SwiftUI 的布局原理。本文将结合 Layout 协议的内容对 SwiftUI 的 “对齐” 进行梳理，希望能让读者对“对齐”有更加清晰地认识和掌握。
Table 是 SwiftUI 3.0 中为 macOS 平台提供的表格控件，开发者通过它可以快捷地创建可交互的多列表格。在 WWDC 2022 中，Table 被拓展到 iPadOS 平台，让其拥有了更大的施展空间。本文将介绍 Table 的用法、分析 Table 的特点以及如何在其他的平台上实现类似的功能。
长久以来，开发者对 SwiftUI 的导航系统颇有微词。受 NavigationView 的能力限制，开发者需要动用各种技巧乃至黑科技才能实现一些本应具备基本功能（例如：返回根视图、向堆栈添加任意视图、返回任意层级视图 、Deep Link 跳转等 ）。SwiftUI 4.0（ iOS 16+ 、macOS 13+ ）对导航系统作出了重大改变，提供了以视图堆栈为管理对象的新 API ，让开发者可以轻松实现编程式导航。本文将对新的导航系统作以介绍。
本文将介绍在 SwiftUI 视图中打开 URL 的若干种方式，其他的内容还包括如何自动识别文本中的内容并为其转换为可点击链接，以及如何自定义打开 URL 前后的行为等。
本文将对 @Published 与符合 ObservableObject 协议的类实例之间的沟通机制做以介绍，并通过三个示例：@MyPublished（ @Published 的仿制版本 ）、@PublishedObject（包装值为引用类型的 @Published 版本）、@CloudStorage（类似 @AppStorage ，但适用于 NSUbiquitousKeyValueStore ），来展示如何为其他的自定义属性包装类型添加可访问包裹其的类实例的属性或方法的能力。
大多初学者都会在第一时间惊叹于 SwiftUI 轻松实现各种动画效果的能力，但经过一段时间的使用后，他们会发现 SwiftUI 的动画并非像表面上看起来那样容易驾驭。开发者经常需要面对：如何动、怎么动、什么能动、为什么不动、为什么这么动、如何不让它动等等困扰。对 SwiftUI 的动画处理逻辑了解的不够深入是造成上述困扰的主要原因。本文将尝试对 SwiftUI 的动画机制做以介绍，以帮助大家更好地学习、掌握 SwiftUI 的动画，制作出满意的交互效果。
拥有优秀的交互效果和手感，是很多 iOS 开发者长久以来坚守的原则。同样一段代码，在不同数据量级下的响应表现可能会有云泥之别。本文将通过一个优化列表视图的案例，展现在 SwiftUI 中查找问题、解决问题的思路，其中也会对 SwiftUI 视图的显式标识、@FetchRequest 的动态设置、List 的运作机制等内容有所涉及。本文的范例需运行在 iOS 15 及以上系统，技术特性也以 SwiftUI 3.0 为基础。
本文将对 SwiftUI 的 zIndex 修饰符做以介绍，包括：使用方法、zIndex 的作用域、通过 zIndex 避免动画异常、为什么 zIndex 需要设置稳定的值以及在多种布局容器内使用 zIndex 等内容。
在【ViewBuilder 研究（上）—— 掌握 Result builders】中，我们对 result builders 做了较详细的介绍。本篇我们将通过对 ViewBuilder 的仿制，探索更多有关 SwiftUI 视图背后的秘密。
作为一个严重依赖 SwiftUI 的开发者，同视图打交道是最平常不过的事情了。从第一次接触 SwiftUI 的声明式编程方式开始，我便喜欢上了这种写代码的感觉。但接触地越多，碰到的问题也越多。起初，我单纯地将很多问题称之为灵异现象，认为大概率是由于 SwiftUI 的不成熟导致的。随着不断地学习和探索，发现其中有相当部分的问题还是因为自己的认知不够所导致的，完全可以改善或避免。我将通过上下两篇博文，对构建 SwiftUI 视图的 ViewBuilder 进行探讨。本篇将首先介绍 ViewBuilder 背后的实现者 —— result builders 。
SwiftUI Overlay Container 是一个用于 SwiftUI 的视图容器组件。一个可定制、高效、便捷的视图管理器。仅需简单配置，SwiftUI Overlay Container 即可帮你完成从视图组织、队列处理、转场、动画、交互到显示样式配置等基础工作，让开发者可以将精力更多地投入到应用程序视图的实现本身。
不同于众多的内置控件，SwiftUI 没有采用对 UIGestureRecognizer（或 NSGestureRecognizer）进行包装的形式，而是重构了自己的手势体系。SwiftUI 手势在某种程度上降低了使用门槛，但由于缺乏提供底层数据的 API，严重制约了开发者的深度定制能力。在 SwiftUI 下，我们无法拥有类似构建全新 UIGestureRecongnizer 的能力。所谓的自定义手势，其实只是对系统预置手势的重构而已。本文将通过几个示例，演示如何使用 SwiftUI 提供的原生手段定制所需手势。
赶在 2021 年底，苹果终于发布了 Swift Playgrounds 4，作为近年来最具革命性意义的版本，Swift Playgrounds 4 提供了在 iPad 上开发可发行 app 的能力。本文将对 Swift Playground 4 的新功能做以介绍，并探讨将其作为开发工具的可行性。
NSUbiquitousKeyValueStore 是苹果官方提供的用于在设备间共享键值数据的解决方案。本文将对其用法做以简单介绍，着重探讨如何便捷地在 SwiftUI 中使用 NSUbiquitousKeyValueStore。
本文将作者对 SwiftUI 视图、SwiftUI 视图生命周期的理解和研究做以介绍，供大家一起探讨。在 UIKit（AppKit）的世界中，通过框架提供的大量钩子（例如 viewDidLoad、viewWillLayoutSubviews 等），开发者可以将自己的意志注入视图控制器生命周期的各个节点之中，宛如神明。在 SwiftUI 中，系统收回了上述的权利，开发者基本丧失了对视图生命周期的掌控。不少 SwiftUI 开发者都碰到过视图生命周期的行为超出预期的状况（例如视图多次构造、onAppear 无从控制等）。
Safe Area（安全区域）是指不与导航栏、标签栏、工具栏或其他视图控制器提供的视图重叠的内容空间。本文将探讨如何在 SwiftUI 中获取 SafeAreaInsets、将视图绘制到安全区域之外、修改视图的安全区域等内容。
从 iOS 14 开始，SwiftUI 为视图提供了 onChange 修饰器，通过使用 onChange，我们可以在视图中对特定的值进行观察，并在其更改时触发操作。本文将对 onChange 的特点、用法、注意事项以及替代方案做以介绍。
本文将探讨涉及 SwiftUI TextField 的事件、焦点切换、键盘设置等相关的经验、技巧和注意事项。
SwiftUI 的 TextField 可能是开发者在应用程序中最常使用的文本录入组件了。作为 UITextField（NSTextField）的 SwiftUI 封装，苹果为开发者提供了众多的构造方法和修饰符以提高其使用的便利性、定制性。但 SwiftUI 在封装中也屏蔽了不少的高级接口和功能，增加了开发者实现某些特定需要的复杂性。本文为【SwiftUI 进阶】系列文章中的一篇，在本文中，我将介绍如何在 TextField 中实现如下功能：屏蔽无效字符、判断录入的内容是否满足特定条件、对录入的文本实时格式化显示。
在 WWDC 2021 上，苹果为开发者带来了有一个期待已久的功能——AttributedString，这意味着 Swift 开发人员不再需要使用基于 Objective-C 的 NSAttributedString 来创建样式化文本。本文将对其做全面的介绍并演示如何创建自定义属性。
本文将讲解如何通过 NSCoreDataSpotlightDelegate（WWDC 2021 版本）实现将应用程序中的 Core Data 数据添加到 Spotlight 索引，方便用户查找并提高 App 的曝光率。
SheetKit 是一个 SwiftUI 模态视图的扩展库。提供了数个用于模态视图的便捷展示、取消方法，以及几个用于模态视图的 View Extension
本文中我们将探讨如何实现一个 SwiftUI 3.0 中新增功能——interactiveDismissDisabled 的增强版；如何创建更 SwiftUI 化的功能扩展。
本文介绍了如何使用 Swift 5.5 版本的 Async/Await 功能重构 SwiftUI 的状态容器代码。
由于 SwiftUI 原生提供的导航手段能力有限，因此在之前的版本中，NavigationView 总是使用的不是那么的顺手。本文介绍一个我写的针对 NavigationView 的扩展库——NavigationViewKit。为原生 NavigationView 解决几个当前的痛点问题。
本文将探讨导致 SwiftUI 预览崩溃的部分原因，如何在之后的开发中避免类似的崩溃出现以及如何在 Xcode 中安全可靠地预览含有 Core Data 元素的 SwiftUI 视图
本文将通过对 UITextField 的包装来讲解如何在 SwiftUI 中使用 UIKit 视图、如何让你的 UIKit 包装视图具有 SwiftUI 风格、在 SwiftUI 使用 UIKit 视图需要注意的地方
本文探讨的是如何优雅、高效、安全地在 SwiftUI 中使用@AppStorage，在不借助第三方库的情况下，解决当前@AppStorage 使用中出现的痛点
SwiftUI 创建初衷之一便是可以高效、可靠的适配多个苹果的硬件平台。在健康笔记 2.0 开发初始，适配 iPad 便是我本次的设计目标之一。本文并非教程，只是我在进行本次开发中，对于适配 iPad 的一些教训和心得。
本文并非一个教你如何在 SwiftUI 下使用 CoreData 的教程。主要探讨的是在我近一年的 SwiftUI 开发中使用 CoreData 的教训、经验、心得。
本文介绍了其中几个在健康笔记开发过程中使用的第三方的开源库
一晃国庆中秋长假即将结束，距离上次的随笔也有了一段时间。在最近的日子里，我一方面继续着开发的进程，同时还要付出相当的精力同 iOS14 中的各种 Bug 和异常斗智斗勇。本篇随笔主要记录了这段时间碰到的一些问题，以及聊聊 iOS14、Xcode12 以及 SwiftUI2.0 的一些优缺点。想到哪、写到哪，可能逻辑会比较混乱。
一晃国庆中秋长假即将结束，距离上次的随笔也有了一段时间。在最近的日子里，我一方面继续着开发的进程，同时还要付出相当的精力同 iOS14 中的各种 Bug 和异常斗智斗勇。本篇随笔主要记录了这段时间碰到的一些问题，以及聊聊 iOS14、Xcode12 以及 SwiftUI2.0 的一些优缺点。想到哪、写到哪，可能逻辑会比较混乱。
本周没有太多的精力和情绪用来写代码。这两天在原来统一 sheet 管理和实时 Form 的基础上，完成了可以控制取消手势的 Sheet。这个是 SwiftUI 中一直以来的一个重要的缺失功能。 在 SwiftUI 中制作可以控制取消手势的 Sheet
在前面的两篇文章中，我们探讨了如何制作一个可以判断是否进行了修改的表单，以及如何统一管理 app 各个层级 View 的弹出 Sheet。今天我们将他们合并在一起，完成整个项目的最终目的——在 Sheet 中制作一个可以实时响应的表单，并且 sheet 会感觉表单的情况响应取消手势。
本周的由于其他琐事的原因，每天能够用于开发的时间基本上只能保证 2-3 个小时，所以进展不大。不过好在我也没有明确的进度指标。
Sheet 是一个我比较喜欢的交互形式，它可以很好的控制用户的操作行为，让用户的交互逻辑单线条化。在 iOS14 上，SwiftUI 增加了 fullCover，支持了全屏的 Sheet 方式，让开发者又了更多的选择。
我的 app 健康笔记主要是对数据的收集、管理，所以对于表单的实时检查、响应的要求比较高。因此制作一个对用于输入响应及时、反馈准确的 Form 十分重要。本文尝试提出一个 SwiftUI 下的 Form 开发思路。
本周的由于其他琐事的原因，每天能够用于开发的时间基本上只能保证 2-3 个小时，所以进展不大。不过好在我也没有明确的进度指标。
在 SwiftUI 中使用 List 可以非常方便快速的制作各种列表。List 其实就是对 UITableView 进行的封装。
健康笔记从 2020 年 1 月上线以来，至今已经过了大半年的时间（可以从 [老人新兵 —— 一款 iOS app 的开发手记](https://zhuanlan.zhihu.com/p/103822455) 了解健康笔记 app 的由来）。在这段时间里，我对于 Swift、SwiftUI、CoreData 等都有了进一步的了解和认识。在开发 1.0 版本时所面对的问题和疑惑多数都得到了解决。
SwiftUI 目前可以提供 sheet,fullScreenCover,alert,actionsheet 等弹出视图用于丰富 UI 交互。不过种类还是有些单调。为了能够更方便的编写各种弹出式窗口的代码，我写了一个简单的 SwiftUI 库 —— SwiftUIOverlayContainer。
随着 SwiftUI2.0 的不断完善，我觉得是时候将我的 app 做一个较大的升级了。之前一直想在 app 中实现类似 iOS 邮件程序那样优雅的侧滑菜单效果，在网上也找了一下，实现的较好的是适用于 UIKit 的，基本上没有能够很好的适配 SwiftUI 的项目库。最终自己在 Xcode12 实现了一个。
SwiftUI2.0 中新增了原生的文件导入导出功能。需注意的是对于不同目录下文件的导出行为会有不同，不同平台下对于权限的处理也不同。
SwiftUI2.0 增加了滚动定位功能，已经可以较轻松的适应大多数场景的应用。实现手段完全不同于之前民间的各种解决方案，并不是通过设置具体的 offset 来进行定位，而是使用 id 来进行位置标记。
SwiftUI2.0 新增了一些便捷的内置控件，比如说 Label、ProgressView 等。其基本形态都很普通，不过都支持自定义 style。官方的意图也比较明显，通过内置控件，规范代码、提高原型编写速度，如需要更精细控制可通过扩展 style 来完成。
SwiftUI2.0 由于可以采用新的代码架构（Life Cycle SwiftUI App）来组织 app, 因此提供了 onOpenURL 来处理 Univeresal Links。不同于在 AppDelegate 或 SceneDelegate 中的解决方案，onOpenURL 作为一个 view modifier，你可以在任意 View 上注册你的 app 的 URL 处理机制。
SwiftUI2.0 为了实现更好的多平台支持同时需要兼顾 1.0 版本代码兼容性，提供了一些与已有控件功能上类似但名称和用法全新的控件。比如 ToolBar, navigationTitle 等。Toolbar 可以实现 navigationbarItems 的全部功能，并新增了在多平台下的适配。采用了全新的语法，代码更易阅读。
SwiftUI2.0 提供了原生的打开 URL scheme 的功能，我们可以十分方便的在代码中调用其他的 app。
SwiftUI 的第一版中，官方并没有提供 UICollectionView 的对应功能。开发者需要自行包装或者依赖很多第三方库。SwiftUI2.0 中，苹果通过 LazyVGrid、LazyHGrid 提供了 Grid 控件。该控件的实现很有 SwiftUI 的风格，和众多的第三方库有显著的区别。
SwiftUI2.0 提供了 LazyVStack 和 LazyHStack，其作用是只有当 View 在可见区域内才进行渲染，这样可以大大大提高 app 执行效率
SwiftUI2.0 中新增了 Label 控件，方便我们添加由图片和文字组成的标签。
Swift2.0 中，苹果添加了 Map，让开发者可以非常容易的在 View 中添加需要的地图元素。本文简单介绍了其用法
在上篇文章中我们简单了解了 App、Scene，以及几个内置 Scene 的应用。在本文中，我们着重探讨在 SwiftUI2.0 新的代码结构下如果更高效的组织 Data Flow。
本文简单介绍了 SwiftUI2.0 中全新提供的 App 协议、Scene 协议，浅谈了在全新的代码结构下如何组织 Data Flow，并提供了 SwiftUI2.0 中预置的 Scene 的一些使用示例。当前运行环境为 Xcode Version 12.0 beta (12A6159), macOS Big Sur 11.0 Beta 版 (20A4299v)。
在苹果 WWDC20 中视频中出现了下面的代码，介绍了一个新的属性包装器@FocusedBinding。由于仍处于测试阶段，当前的代码并不能被正确的执行。@FocusedBinding 的资料苹果披露的也很少，网上也没有相关的信息。出于个人兴趣，我对它进行了简单的研究。尽管@FocusedBinding 在目前 Xcode Version 12.0 beta 2 (12A6163b) 的版本上运行还有很多问题，但我基本上对其有了一定的了解。
本文介绍了 SwiftUI 2.0 中，如何为 macOS 平台添加菜单。苹果在 SwiftUI2.0 中增加了 Multiplatform 项目模板，使得同一套代码，仅需少量的适配便可以同时满足 iOS 以及 macOS 的需要。对于 macOS 上运行的 app, 拥有自定义的菜单是一个十分重要的平台特征。对于没有 macOS 开发经验的我来说，学习如何设计开发菜单变得十分有趣且必要。
WWDC20 刚刚结束，在过去的一周，苹果为开发者带来了巨大的惊喜。由于新特性实在太多，需要不少时间来消化，我首先选择自己最感兴趣的内容进行一些简单的研究和探讨。本文首先浅谈一下 SwiftUI 新提供的属性包装器@StateObject。
本文试图探讨并分析 SwiftUI 中 @State 的实现方式和运行特征；最后提供了一个有关扩展@State 功能的思路及例程。读者需要对 SwiftUI 的响应式编程有基本概念。
本文主要研究在 SwiftUI 中，采用单一数据源 (Single Source of Truth) 的开发模式，ObservableObject 是否为最佳选择。是否可以在几乎不改变现有设计思路下进行新的尝试，以提高响应效率。最后提供了一个仍采用单一数据源设计思路但完全弃用 ObservableObject 的方式。