通常在一个循环中创建多个SwiftUI视图。例如，我们可能想要遍历一系列名称，并让每个名称成为文本视图，或者遍历一系列菜单项，并将每个名称显示为图像。
为可滚动容器的内容或滚动指示器（Scroll Indicator）添加外边距（Margin）。
本文将通过一段可复现的“灵异代码”，对 State 注入优化机制、模态视图（ Sheet、FullScreenCover ）内容的生成时机以及不同上下文（ 相互独立的视图树 ）之间的数据协调等问题进行探讨。
最近时常有朋友反映，尽管 SwiftUI 的布局系统学习门槛很低，但当真正面对要求较高的设计需求时，好像又无从下手。SwiftUI 真的具备创建复杂用户界面的能力吗？本文将通过用多种手段完成同一需求的方式，展示 SwiftUI 布局系统的强大与灵活，并通过这些示例让开发者对 SwiftUI 的布局逻辑有更多的认识和理解。
我接触电脑的时间比较早（ 第一台电脑型号是 CP-80，CPU 是 MC6800 ），开始学习编程也比较早（ 从中华学习机开始，Apple II 的国内兼容机 ）。对于电脑和编程也都一直很有兴趣，不过从来也没有真正的把写代码当做过职业。虽然也使用过几种编程语言在不同的平台上写过些代码，但都不能算作完整的产品。习惯性地对信息行业的前沿动态以及一些新的技术方向保持着关注，但由于生意及其它方面的原因，从 10 几年前便完全没有再接触过编程了。
从 iOS 14 开始，SwiftUI 为视图提供了 onChange 修饰器，通过使用 onChange，我们可以在视图中对特定的值进行观察，并在其更改时触发操作。本文将对 onChange 的特点、用法、注意事项以及替代方案做以介绍。
在 SwiftUI 中，尺寸这一布局中极为重要的概念，似乎变得有些神秘。无论是设置尺寸还是获取尺寸都不是那么地符合直觉。本文将从布局的角度入手，为你揭开盖在 SwiftUI 尺寸概念上面纱，了解并掌握 SwiftUI 中众多尺寸的含义与用法；并通过创建符合 Layout 协议的 frame 和 fixedSize 视图修饰器的复制品，让你对 SwiftUI 的布局机制有更加深入地理解。
在 UIKit（AppKit）的世界中，通过框架提供的大量钩子（例如 viewDidLoad、viewWillLayoutSubviews 等），开发者可以将自己的意志注入视图控制器生命周期的各个节点之中，宛如神明。在 SwiftUI 中，系统收回了上述的权利，开发者基本丧失了对视图生命周期的掌控。不少 SwiftUI 开发者都碰到过视图生命周期的行为超出预期的状况（例如视图多次构造、onAppear 无从控制等）。
本文是笔者参加 2023 年 4 月 20 日 “SwiftUI 技术沙龙（ 北京站 ）” 活动的分享内容。基于记忆整理而成。有关本次活动的情况，可以参阅 我在北京参加 SwiftUI 技术沙龙[1] 一文。
本文是笔者参加 2023 年 4 月 20 日 “SwiftUI 技术沙龙（ 北京站 ）” 活动的分享内容。基于记忆整理而成。有关本次活动的情况，可以参阅 我在北京参加 SwiftUI 技术沙龙 一文。
已迈入第三个年头的SwiftUI相较诞生初始已经提供了更多的原生功能，但仍有大量的事情是无法直接通过原生SwiftUI代码来完成的。在相当长的时间中开发者仍需在SwiftUI中依赖UIKit（AppKit）代码。好在，SwiftUI为开发者提供了便捷的方式将UIKit（AppKit）视图（或控制器）包装成SwiftUI视图。
SwiftUI 引入了一组视图修饰符，使我们能够有效地管理视图中的安全区域。在许多情况下，安全区域是你希望放置内容的地方。今天，我们将了解 SwiftUI 引入的新内容边距概念以及它与安全区域的区别。
大多初学者都会在第一时间惊叹于 SwiftUI 轻松实现各种动画效果的能力，但经过一段时间的使用后，他们会发现 SwiftUI 的动画并非像表面上看起来那样容易驾驭。开发者经常需要面对：如何动、怎么动、什么能动、为什么不动、为什么这么动、如何不让它动等等困扰。对 SwiftUI 的动画处理逻辑了解的不够深入是造成上述困扰的主要原因。本文将尝试对 SwiftUI 的动画机制做以介绍，以帮助大家更好地学习、掌握 SwiftUI 的动画，制作出满意的交互效果。
在上篇[2]中，我们对 result builders 做了较详细的介绍。本篇我们将通过对 ViewBuilder 的仿制，探索更多有关 SwiftUI 视图背后的秘密。
在 Part 1 我们探索了布局协议的基础知识，为理解布局是如何工作的打下了坚实的基础。现在，是时候深入研究那些更少提及的功能了，以及如何使用它们来为我们带来便利。
Ask Apple 为开发者与苹果工程师创造了在 WWDC 之外进行直接交流的机会。本文对本次活动中与 SwiftUI 有关的一些问答进行了整理，并添加了一点个人见解。本文为上篇。
我在去年底使用了SwiftUI写了第一个 iOS app 健康笔记，这是我第一次接触响应式编程概念。在有了些基本的认识和尝试后，深深的被这种编程的思路所打动。不过，我在使用中也发现了一些奇怪的问题。我发现在视图（View）数量达到一定程度，随着数据量的增加，整个app的响应有些开始迟钝，变得有粘滞感、不跟手。app响应出现了问题一方面肯定和我的代码效率、数据结构设计欠佳有关；不过随着继续分析，发现其中也有很大部分原因来自于SwiftUI中所使用的响应式的实现方式。不恰当的使用，可能导致响应速度会随着数据量及View量的增加而大幅下降。通过一段时间的研究和分析，我打算用两篇文章来阐述这方面的问题，并尝试提供一个现阶段的使用思路。
StateObject 是在 SwiftUI 2.0 中才添加的属性包装器，它的出现解决了在某些情况下使用 ObservedObject 视图会出现超预期的问题。本文将介绍两者间的异同，原理以及注意事项。
SwiftUI的环境使我们可以使用来自外部的值，这对于读取Core Data上下文或视图的展示模式等很有用。但是我们也可以将自定义对象发送到环境中，并在以后将它们读出来，这使我们可以在复杂的应用程序中更轻松地共享数据。
编译 | 核子可乐、Tina SwiftUI 很好，但是苹果对它投资不足。 在 2019 年的 WWDC 大会上，苹果推出了一个全新的 SwiftUI 框架，这是一个现代化的 UI 界面编码结构，它是基于 Swift从头开始构建的。新框架使用声明性范例，让开发者用更少的代码编写相同的 UI。 SwiftUI 的愿景是降低开发 iOS 门槛，吸引更多开发者、丰富 iOS 的业态。并且 SwiftUI 可以“实现一次编码，可适应五端 Apple 产品平台”， 包括watchOS、tvOS、macOS 等，
最近，在我正在开发一个在 Dribbble 上找到的设计的 SwiftUI 实现时，我想到了一个点子，可以通过一些酷炫的筛选器扩展该项目以缩小结果列表。
SwiftUI有两种创建警报和表单的方式，到目前为止，我们仅使用一种方法：绑定到布尔值，该布尔值在变为 true 时显示 Alert 或 Sheet。
SwiftUI Overlay Container[1] 是一个用于 SwiftUI 的视图容器组件。一个可定制、高效、便捷的视图管理器。
SwiftUI 和 Core Data 之间相差将近十年 —— SwiftUI 随着 iOS 13 面世而 Core Data 则是 iPhoneOS 3 的产物；很久以前，它还没有被称为 iOS，因为 iPad 尚未发布。尽管时间相距遥远，Apple 还是投入了大量工作以确保这两种强大的技术能够完美地相互配合使用，这意味着 Core Data 就像始终以这种方式设计一样，已集成到 SwiftUI 中。
本文中我们将探讨在 SwiftUI 视图中批量获取 Core Data 数据的方式，并尝试创建一个可以使用 mock 数据的 FetchRequest。由于本文会涉及大量 前文[1] 中介绍的技巧和方法，因此最好一并阅读。
“对齐”是 SwiftUI 中极为重要的概念，然而相当多的开发者并不能很好地驾驭这个布局利器。在 WWDC 2022 中，苹果为 SwiftUI 增添了 Layout 协议，让我们有了更多的机会了解和验证 SwiftUI 的布局原理。本文将结合 Layout 协议的内容对 SwiftUI 的 “对齐” 进行梳理，希望能让读者对“对齐”有更加清晰地认识和掌握。
onAppear（ task ）是 SwiftUI 开发者经常使用的一个修饰符，但一直没有权威的文档明确它的闭包被调用的时机。本文将通过 SwiftUI 4 提供的新 API ，证明 onAppear 的调用时机是在布局之后、渲染之前。
List 可能是 SwiftUI 附带的内置视图中最常用的一种，它使我们能够在任何 Apple 平台上呈现“类似于表格视图”的用户界面。今年，List 获得了许多非常重要的升级，使其更加灵活和易于定制。让我们看看都有哪些新功能。
GeometryReader 自 SwiftUI 诞生之初就存在，它在许多场景中扮演着重要的角色。然而，从一开始就有开发者对其持负面态度，认为应尽量避免使用。特别是在最近几次 SwiftUI 更新中新增了一些可以替代 GeometryReader 的 API 后，这种观点进一步加强。本文将对 GeometryReader 的“常见问题”进行剖析，看看它是否真的如此不堪，以及那些被批评为“不符预期”的表现，是否其实是因为开发者的“预期”本身存在问题。
Ask Apple 为开发者与苹果工程师创造了在 WWDC 之外进行直接交流的机会。本文对本次活动中与 SwiftUI 有关的一些问答进行了整理，并添加了一点个人见解。本文为下篇。
拥有优秀的交互效果和手感，是很多 iOS 开发者长久以来坚守的原则。同样一段代码，在不同数据量级下的响应表现可能会有云泥之别。本文将通过一个优化列表视图的案例，展现在 SwiftUI 中查找问题、解决问题的思路，其中也会对 SwiftUI 视图的显式标识、@FetchRequest 的动态设置、List 的运作机制等内容有所涉及。本文的范例需运行在 iOS 15 及以上系统，技术特性也以 SwiftUI 3.0 为基础。
在 WWDC 2023 中，苹果介绍了 Swift 标准库中的新成员：Observation 框架。它的出现有望缓解开发者长期面临的 SwiftUI 视图无效更新问题。本文将采取问答的方式，全面而详尽地探讨 Observation 框架，内容涉及其产生原因、使用方法、工作原理以及注意事项等。
长久以来，开发者对 SwiftUI 的导航系统颇有微词。受 NavigationView 的能力限制，开发者需要动用各种技巧乃至黑科技才能实现一些本应具备基本功能（例如：返回根视图、向堆栈添加任意视图、返回任意层级视图 、Deep Link 跳转等 ）。SwiftUI 4.0（ iOS 16+ 、macOS 13+ ）对导航系统作出了重大改变，提供了以视图堆栈为管理对象的新 API ，让开发者可以轻松实现编程式导航。本文将对新的导航系统作以介绍。
在苹果生态的应用中，开发者或多或少都会使用到UserDefaults。我个人习惯将可被用户自定义的配置信息（精度、单位、色彩等）保存在UserDefaults中。随着配置信息的增加，在SwiftUI视图中使用的@AppStorage越来越多。
今年 SwiftUI 新增最好的功能之一必须是布局协议。它不但让我们参与到布局过程中，而且也给了我们一个很好的机会去更好的理解布局在 SwiftUI 中的作用。
随着近年来有关 SwiftUI 的文章与书籍越来越多，开发者应该都已经清楚地掌握了 —— “视图是状态的函数” 这一 SwiftUI 的基本概念。每个视图都有与其对应的状态，当状态变化时，SwiftUI 都将重新计算与其对应视图的 body 值。
从 2022 年开始，Airbnb 的 iOS 团队就认为 SwiftUI 已经足够成熟，可以在他们的官方应用中使用它。但 Airbnb 的工程师 Bryn Bodayle 表示，这需要一个谨慎的转换过程。
Picker(selection: $selection, label: Text("Picker")) {
在本文中，我们将深入探讨一些创建 SwiftUI 动画的高级技术。我将广泛讨论 Animatable[1] 协议，它可靠的伙伴 animatableData[2]，强大但经常被忽略的 GeometryEffect[3] 以及完全被忽视但全能的 AnimatableModifier[4] 协议。
尽管 SwiftUI 的惰性容器以及 Core Data 都有各自的内存占用优化机制，但随着应用视图内容的复杂（ 图文混排 ），越来越多的开发者遇到了内存占用巨大甚至由此导致 App 崩溃的情况。本文将通过对一个演示 App 进行逐步内存优化的方式（ 由原先显示 100 条数据要占用 1.6 GB 内存，优化至显示数百条数据仅需 200 多 MB 内存 ），让读者对 SwiftUI 视图的存续期、惰性视图中子视图的生命周期、托管对象的惰值特性以及持久化存储协调器的行缓存等内容有更多的了解。
在这个技术项目中，我们将探讨 SwiftUI 如何处理布局。有些事情已经解释过了，有些可能是你自己弄明白的，但更多的是你在这一点上想当然的事情，所以我希望一个详细的探索能真正为 SwiftUI 的工作方式提供一些启示。
前些日子，一位网友在聊天室中就如下的 问题[3] 与大家进行了交流与探讨 —— 如何通过 Text + AttributedString 实现类似文章关键字检索的功能，并可通过按钮在搜索结果中进行滚动切换？
SwiftUI与苹果之前的UI框架的区别不仅仅在于如何定义视图和其他UI组件，还在于如何在整个使用它的应用程序中管理视图层级的状态。
SwiftUI使我们能够出色地控制视图的呈现方式，包括应用实时模糊，混合模式，饱和度调整等功能。
如果您曾经为UIKit或AppKit（Apple的iOS和macOS原始用户界面框架）编程，您会知道它们使用类而非结构体来构造视图。SwiftUI并非如此：我们更喜欢将结构体用于整体视图，这有两个原因。
@State是一个属性包装器（property wrapper），被设计用来针对值类型进行状态管理；用于在Struct中mutable值类型
SwiftUI 因其简便的动画 API 与极低的动画设计门槛而广受欢迎。但是，随着应用程序复杂性的增加，开发者逐渐发现，尽管动画设计十分简单，但要实现精确细致的动画控制并非易事。同时，在 SwiftUI 的动画系统中，有关 Transaction 的解释很少，无论是官方资料还是第三方文章，都没有对其运作机制进行系统的阐述。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
