onAppear 是 SwiftUI 中极其关键的生命周期方法，用于在视图呈现时注入关键逻辑。由于视图实例可能会频繁地被创建和重建，开发者通常会选择在这些方法中准备数据、执行初始化操作。理论上，这些生命周期方法的调用时机应当是可预测和一致的。然而，在某些特定场景下，onAppear 可能会出现非预期的、不必要的调用，这不仅可能导致性能开销，更可能引发应用状态的不可控变化。本文将揭示这一容易被忽视的 SwiftUI 行为陷阱，并提供临时的应对策略。
SwiftUI 提供的 onChange 修饰器，使开发者能够在视图中监听特定值的变化，并在值发生改变时执行相应的操作。直觉上，只要某个视图位于当前可见的视图树分支中（ 活动中 ），在观察的值发生变化时，对应的闭包就应该被触发。但在某些特定的导航场景下，onChange 修饰器似乎会“选择性失聪”，明明观察的值发生了变化，却诡异地保持沉默。这究竟是苹果精心设计的特性，还是一个隐藏已久的代码缺陷？本文将揭示这一现象并对开发者给予必要的提醒。
SwiftUI 中，视图的自动刷新机制让我们能够轻松构建响应式的用户界面。但有时，视图可能并不会按照我们的预期进行更新。本文将通过一个看似简单但颇具代表性的 TimelineView 刷新问题，探讨 SwiftUI 的视图刷新机制。
在 SwiftUI 中，苹果提供的 @AppStorage 属性包装器极大地简化了开发者在视图中响应和修改 UserDefaults 内容的过程。然而，随着 Observation 框架的引入，这一领域出现了新的挑战——苹果尚未为 Observation 提供相应的 UserDefaults 管理方案。本文将探讨如何在 Observation 框架下高效且便捷地管理 UserDefaults 中的数据，并提出一个完整而实用的解决方案。
历经六个版本的迭代，SwiftUI 已不再是一个新兴框架。然而，开发者在使用过程中仍然会不时遇到由框架代码 Bug 引发的各种奇怪问题。本文将通过剖析一个 Grid 布局异常的案例，探讨在日常 SwiftUI 开发中遇到问题时的分析思路和解决策略。
尽管图片平铺并非常用功能，但多数开发者仍能轻松掌握其实现方法。通过搜索引擎查询，几乎所有结果都指向同一解决方案 —— 使用 `resizable` 修饰符。然而，对于一个功能强大的 UI 框架而言，若某个需求仅有单一解决方案，显然是不够全面的。在本文中，我们将探讨两种不同的图片平铺实现方式，并由此引申出一种在 SwiftUI 中较少使用的 `Image` 构建方法。
本文旨在探讨几个关于 SwiftUI 的常见误解，以帮助开发者更好地理解和运用 SwiftUI。我们将剖析这些误区，包括对 SwiftUI 学习难度的认知、跨平台开发的期望、框架功能的范畴、以及代码量的误解等。通过澄清这些观念，我们希望能为 SwiftUI 开发者提供更清晰的学习方向和使用策略。
SwiftUI 的出现为苹果生态的开发带来了革命性的变化，但在面对某些复杂需求时，它仍然存在一些挑战。最近，我开发了一个名为 Infinite4Pager 的组件，它支持无限四向滚动分页功能。本文中我们将分析实现过程中的关键思路，讨论需要特别注意的事项，并坦诚地审视 SwiftUI 在应对这类场景时的不足之处。通过这个案例，我们不仅能学习到具体的技术实现，还能更好地理解如何在 SwiftUI 的框架下突破常规，创造性地解决问题。
在 SwiftUI 的世界里，List 和 LazyVStack 作为两大核心惰性容器，为开发者展示大量数据提供了强大的支持。然而，它们在某些场景下表现相似，常常让开发者在选择时感到困惑。本文旨在剖析这两个组件的特点、优势，以帮助你更好地作出选择。
在 WWDC 2024 中，苹果再次为 SwiftUI 的 ScrollView 组件带来了一系列令人瞩目的新 API。这些新功能不仅增强了开发者对滚动行为的控制能力，也反映了 SwiftUI 框架设计理念的持续演进。本文将探讨这些最新的滚动控制 API，并回顾从 SwiftUI 诞生至今与滚动控制相关的所有重要 API 的发展历程。通过这个微观视角，我们将揭示 SwiftUI 在过去几年中设计风格的变迁，以及背后蕴含的宏观设计趋势。
Text 组件在 SwiftUI 应用中极为常见。过去几年里，尽管苹果不断扩展其功能，开发者仍期待能更深层次地控制这一组件。在 WWDC 2024 上，SwiftUI 推出了 TextRenderer 协议，赋予开发者调整 Text 组件渲染表现的新能力，使得实现许多先前难以想象的效果成为可能。本文将深入探讨这一新增功能。
当人们久别重逢时，常会对朋友的变化感到惊讶；而那些日复一日陪伴在我们身边的人，他们的变化往往容易被我们忽视。在这篇文章中，我将梳理从首个版本起那些给我留下深刻印象的 SwiftUI 关键更新及其影响。这不仅是对 SwiftUI 从诞生到逐渐成熟过程的回顾，也是一次对它所蕴含活力的新的认识。
在 SwiftUI 中，许多布局容器的构造函数都包含一个默认值为 nil 的 spacing 参数，该参数负责控制临近视图之间的间隙。本文将从这一默认参数出发，深入探讨 SwiftUI 中的 Spacing 概念，并分享一些相关的技巧及注意事项。
在 WWDC 2023 上，苹果公司为 SwiftUI 引入了 containerRelativeFrame 视图修饰器。这个修饰器使得一些以往难以通过常规方法实现的布局操作变得十分简单。本文将深入探讨 containerRelativeFrame 修饰器，内容涵盖定义、布局规则、使用场景以及相关注意事项。在文章的最后，我们还将创建一个兼容旧版本 SwiftUI 的 containerRelativeFrame 复刻版，通过这一实践加深对其功能的理解。
在 SwiftUI 的工具箱中，overlay 和 background 是两个极其有用的视图修饰器，它们在多种开发场景中扮演着不可或缺的角色。本文将深入探索这两种修饰器的独特属性，并明确它们与 ZStack 的基本差异，以及适合它们的应用场景。
在本篇文章中，我们将探讨一个影响多窗口模式下 SwiftUI 应用的 Bug，并提出有效的临时解决策略。我们不仅会详细描述这一问题的表现，还将分享从发现到诊断，最终解决问题的全过程。通过这一探索，旨在为遇到类似挑战的开发者提供一个指引，以帮助他们更好应对其他的 SwiftUI 开发难题。
这是我在 Let's VisionOS 2024 上的演讲内容。为了便于阅读，我对原始内容进行了简化，并调整为更加书面化的表达。本次分享的核心是传达这样一个中心思想：尽管这些新框架是为了解决现有框架中的问题而设计的，但我们不应被过往的经验和惯例所限制。需要用开放的心态和全新的视角去学习和使用这些新工具。将采用新框架的过程视为将项目向更安全、更现代化方向重构的绝佳机会。
越来越多的开发者开始尝试开启并发严格检查选项，为 Swift 6 的到来做准备。在收到的警告和错误中，有一部分是与 SwiftUI 的视图有关，其中很多都是由于开发者没有正确的理解和使用 @MainActor 造成的。本文将聊聊 @MainActor 的含义，以及在 SwiftUI 的视图中应用 @MainActor 的技巧和注意事项。
在之前的文章 “SwiftData 中的并发编程” 中，我们深入探讨了 SwiftData 提出的创新并发编程模式，包括它的原理、核心操作及相关的注意事项。这种优雅的编程解决方案赢得了不少赞誉。然而，随着更多开发者在实际的 SwiftUI 应用中尝试使用 SwiftData，他们遇到了一些挑战：尤其在启用 Swift 的严格并发检查后，发现 SwiftData 基于 Actor 的并发模型与传统的应用构建方法很难融合。本文将采用类似教程的方式阐述如何将 SwiftData 与现代编程理念相结合，顺畅地融入 SwiftUI 应用之中，同时提供策略来应对目前开发者面临的挑战。
在 SwiftUI 的框架中，惰性布局容器，如 List 和 LazyVStack，提供了一种高效展示大型数据集的方法。这些容器的设计精妙，它们仅在必要时才动态地构建和加载视图，从而显著优化了应用的性能和内存使用效率。本文将探讨一些实用技巧和重要注意事项，旨在赋予开发者利用 SwiftUI 惰性容器时增强应用响应性和资源管理的能力。
在本文中，我们将对 @UIApplicationDelegateAdaptor、@AccessibilityFocusState、 @FocusedObject 、@FocusedValue 和 @FocusedBinding 等属性包装器进行探讨。这些属性包装器涵盖了不同框架声明周期的整合、辅助聚焦、焦点值观察管理等功能。
在本文中，我们将对 @FetchRequest、@SectionedFetchRequest、@Query、 @Namespace 和 @Bindable 等属性包装器进行探讨。这些属性包装器涵盖了在视图中对 Core Data 和 SwiftData 数据进行检索以及在视图中创建命名空间等功能。
在本文中，我们将继续了解 SwiftUI 中的属性包装器：@AppStorage、@SceneStorage、@FocusState、@GestureState 以及 @ScaledMetric。这些属性包装器涵盖了数据持久化、交互响应、辅助功能、多窗口支持等多个方面，为开发者提供了简洁实用的解决方案。
在这篇文章中，我们将探讨几个在 SwiftUI 开发中经常使用且至关重要的属性包装器。本文旨在提供对这些属性包装器的主要功能和使用注意事项的概述，而非详尽的使用指南。
在 WWDC 2023 中，苹果为 SwiftUI 添加了一个新的修饰器：geometryGroup()。它可以解决一些之前无法处理或处理起来比较困难的动画异常。本文将介绍 geometryGroup() 的概念、用法，以及在低版本 SwiftUI 中，在不使用 geometryGroup() 的情况下如何处理异常。
在 iOS 16 中，SwiftUI 增加了一个新的自适应布局容器 ViewThatFits。正如其名称所示，它的作用是在给定的多个视图中找出最合适的视图并使用。对于大多数人来说，这是一个简单易用的容器。不过，本文打算对其进行彻底的剖析，包括规则细节、理想尺寸的含义、使用示例等。最后，我们将创建一个复刻版本的 ViewThatFits，以加深对其的认识和理解。
GeometryReader 自 SwiftUI 诞生之初就存在，它在许多场景中扮演着重要的角色。然而，从一开始就有开发者对其持负面态度，认为应尽量避免使用。特别是在最近几次 SwiftUI 更新中新增了一些可以替代 GeometryReader 的 API 后，这种观点进一步加强。本文将对 GeometryReader 的“常见问题”进行剖析，看看它是否真的如此不堪，以及那些被批评为“不符预期”的表现，是否其实是因为开发者的“预期”本身存在问题。
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 年 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 ）功能后，应用对不同视觉大小模式的兼容能力就越发显得重要。本文将就如何创建可自适应不同尺寸模式的程序化导航方案这一内容进行探讨。
Ask Apple 为开发者与苹果工程师创造了在 WWDC 之外进行直接交流的机会。本文对本次活动中与 SwiftUI 有关的一些问答进行了整理，并添加了一点个人见解。本文为下篇。
Ask Apple 为开发者与苹果工程师创造了在 WWDC 之外进行直接交流的机会。本文对本次活动中与 SwiftUI 有关的一些问答进行了整理，并添加了一点个人见解。本文为上篇。
本文将聊聊一个与创建复杂的 SwiftUI 应用很契合的框架 —— The Composable Architecture（ 可组装框架，简称 TCA ）。包括它的特点和优势、最新的进展、使用中的注意事项以及学习路径等问题。
StateObject 是在 SwiftUI 2.0 中才添加的属性包装器，它的出现解决了在某些情况下使用 ObservedObject 视图会出现超预期的问题。本文将介绍两者间的异同，原理以及注意事项。
经常有朋友咨询，学习 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 提供的原生手段定制所需手势。
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 来创建样式化文本。本文将对其做全面的介绍并演示如何创建自定义属性。
当我们使用一个英文 app 时，很多人第一时间会去查看是否有对应的中文版本。可见，在 app 中显示让使用者最亲切的语言文本是何等的重要。对于相当数量的 app 来说，如果能够将 UI 中显示的文本进行了本地化转换，基本上就完成了 app 的本地化工作。本文中，我们将探讨 iOS 开发中，如何实现显示文本的本地化工作。
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 的教训、经验、心得。
本文介绍了其中几个在健康笔记开发过程中使用的第三方的开源库
在前面的两篇文章中，我们探讨了如何制作一个可以判断是否进行了修改的表单，以及如何统一管理 app 各个层级 View 的弹出 Sheet。今天我们将他们合并在一起，完成整个项目的最终目的——在 Sheet 中制作一个可以实时响应的表单，并且 sheet 会感觉表单的情况响应取消手势。
我的 app 健康笔记主要是对数据的收集、管理，所以对于表单的实时检查、响应的要求比较高。因此制作一个对用于输入响应及时、反馈准确的 Form 十分重要。本文尝试提出一个 SwiftUI 下的 Form 开发思路。
Sheet 是一个我比较喜欢的交互形式，它可以很好的控制用户的操作行为，让用户的交互逻辑单线条化。在 iOS14 上，SwiftUI 增加了 fullCover，支持了全屏的 Sheet 方式，让开发者又了更多的选择。
在 SwiftUI 中使用 List 可以非常方便快速的制作各种列表。List 其实就是对 UITableView 进行的封装。
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 中新增了 Label 控件，方便我们添加由图片和文字组成的标签。
SwiftUI2.0 提供了 LazyVStack 和 LazyHStack，其作用是只有当 View 在可见区域内才进行渲染，这样可以大大大提高 app 执行效率
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 中，采用单一数据源 (Single Source of Truth) 的开发模式，ObservableObject 是否为最佳选择。是否可以在几乎不改变现有设计思路下进行新的尝试，以提高响应效率。最后提供了一个仍采用单一数据源设计思路但完全弃用 ObservableObject 的方式。
本文试图探讨并分析 SwiftUI 中 @State 的实现方式和运行特征；最后提供了一个有关扩展@State 功能的思路及例程。读者需要对 SwiftUI 的响应式编程有基本概念。