List 可能是 SwiftUI 附带的内置视图中最常用的一种，它使我们能够在任何 Apple 平台上呈现“类似于表格视图”的用户界面。今年，List 获得了许多非常重要的升级，使其更加灵活和易于定制。让我们看看都有哪些新功能。
SwiftUI与苹果之前的UI框架的区别不仅仅在于如何定义视图和其他UI组件，还在于如何在整个使用它的应用程序中管理视图层级的状态。
众所周知，SwiftUI 是一个响应式框架，这意味着，当数据源发生变化时，框架会自动更新视图。同样，当我们想调整视图显示时，应直接对状态进行修改。但是，SwiftUI 中的一些系统控件并没有完全遵循响应式的设计原则，由此在某些情况下会出现严重的错误，影响用户体验，并使开发者无所适从。
VIPER架构模式是MVC或MVVM的另一种选择。虽然SwiftUI和Combine框架创建了一个强大的组合，可以快速构建复杂的ui和在应用程序中移动数据，但它们也面临着各自的挑战和对架构的看法。
Ask Apple 为开发者与苹果工程师创造了在 WWDC 之外进行直接交流的机会。本文对本次活动中与 SwiftUI 有关的一些问答进行了整理，并添加了一点个人见解。本文为上篇。
visionOS是苹果Vision Pro的操作系统。将visionOS与熟悉的工具和技术一起使用，为空间计算构建沉浸式应用程序和游戏。
因为SwiftUI View 采用的是结构体，当创建想要更改属性的结构体方法时，我们需要添加mutating关键字,例如：
长久以来，开发者对 SwiftUI 的导航系统颇有微词。受 NavigationView 的能力限制，开发者需要动用各种技巧乃至黑科技才能实现一些本应具备基本功能（例如：返回根视图、向堆栈添加任意视图、返回任意层级视图 、Deep Link 跳转等 ）。SwiftUI 4.0（ iOS 16+ 、macOS 13+ ）对导航系统作出了重大改变，提供了以视图堆栈为管理对象的新 API ，让开发者可以轻松实现编程式导航。本文将对新的导航系统作以介绍。
已迈入第三个年头的SwiftUI相较诞生初始已经提供了更多的原生功能，但仍有大量的事情是无法直接通过原生SwiftUI代码来完成的。在相当长的时间中开发者仍需在SwiftUI中依赖UIKit（AppKit）代码。好在，SwiftUI为开发者提供了便捷的方式将UIKit（AppKit）视图（或控制器）包装成SwiftUI视图。
保证应用不因 Core Data 的原因导致意外崩溃是对开发者的起码要求。本文将介绍可能在视图中产生严重错误的原因，如何避免，以及在保证视图对数据变化实时响应的前提下如何为使用者提供更好、更准确的信息。由于本文会涉及大量前文中介绍的技巧和方法，因此最好一并阅读。
在这篇文章中，我们将探讨几个在 SwiftUI 开发中经常使用且至关重要的属性包装器。本文旨在提供对这些属性包装器的主要功能和使用注意事项的概述，而非详尽的使用指南。
已经了解了 SwiftUI 如何通过使用 @State 属性包装器将变化的数据存储在结构体中，如何使用 $ 将状态绑定到UI控件的值，以及更改 @state 包装的属性时是如何自动让 SwiftUI 重新调用我们的结构体的 body属性的。
梁启健，携程金融支付中心开发工程师，主要负责支付iOS端的开发与优化工作，喜欢研究大前端和跨平台技术。
如果发生重要事件，通知用户的一种常见方法是使用警报Alert弹窗-根据您的需要，该弹出窗口包含标题，消息和一个或两个按钮。
随着 Swift 5.5 引入了 async/await 特性，苹果也为 SwiftUI 添加了 task 视图修饰器，以方便开发者在视图中使用基于 async/await 的异步代码。本文将对 task 视图修饰器的特点、用法、注意事项等内容做以介绍，并提供了将其移植到老版本 SwiftUI 的方法。
你已经在 iOS 应用程序上工作了一段时间，你认为你很聪明。 你以为你已经做到了，嗯？
最近，我一直在为我的应用开发一个全新的界面，它可以让你查看 TestFlight 上所有可用的构建，并允许你将它们添加到测试群组中。
悬浮操作按钮（Floating Action Button, FAB）是一种在 Android 和 Material Design 中使用的 UI 元素。它用于触发特定屏幕的主要操作。
随着近年来有关 SwiftUI 的文章与书籍越来越多，开发者应该都已经清楚地掌握了 —— “视图是状态的函数” 这一 SwiftUI 的基本概念。每个视图都有与其对应的状态，当状态变化时，SwiftUI 都将重新计算与其对应视图的 body 值。
@State是一个属性包装器（property wrapper），被设计用来针对值类型进行状态管理；用于在Struct中mutable值类型
通过 Style 改变组件的外观或行为是 SwiftUI 提供的一项非常强大的功能。本文将介绍如何通过创建符合 ButtonStyle 或 PrimitiveButtonStyle 协议的实现，自定义 Button 的外观以及交互行为。
在我之前的文章@State研究中我们探讨过@State，通过它，我们可以方便的将值类型数据作为View的Source of truth。在SwiftUI 1.0时代，如果想将引用类型作为source of truth,通常的方法是使用@EnvironmentObject或者 @ObservedObject。
StateObject 是在 SwiftUI 2.0 中才添加的属性包装器，它的出现解决了在某些情况下使用 ObservedObject 视图会出现超预期的问题。本文将介绍两者间的异同，原理以及注意事项。
在 WWDC 2023 中，苹果介绍了 Swift 标准库中的新成员：Observation 框架。它的出现有望缓解开发者长期面临的 SwiftUI 视图无效更新问题。本文将采取问答的方式，全面而详尽地探讨 Observation 框架，内容涉及其产生原因、使用方法、工作原理以及注意事项等。
SwiftUI 的各种堆栈是许多框架中最基本的布局工具，能够让我们定义组视图，这些组视图可以按照水平、垂直或覆盖视图对齐。
近日，在一场关于JSX的讨论中，React核心成员「Sebastian Markbåge」（Hooks作者）表示：
编译 | 核子可乐、Tina SwiftUI 很好，但是苹果对它投资不足。 在 2019 年的 WWDC 大会上，苹果推出了一个全新的 SwiftUI 框架，这是一个现代化的 UI 界面编码结构，它是基于 Swift从头开始构建的。新框架使用声明性范例，让开发者用更少的代码编写相同的 UI。 SwiftUI 的愿景是降低开发 iOS 门槛，吸引更多开发者、丰富 iOS 的业态。并且 SwiftUI 可以“实现一次编码，可适应五端 Apple 产品平台”， 包括watchOS、tvOS、macOS 等，
每当我们将修饰符应用于 SwiftUI 视图时，我们实际上都会创建一个，应用了更改的新视图 —— 我们不仅仅是修改现有的视图。 如果你仔细想想，这种行为是有道理的 —— 我们的视图仅保留我们赋予它们的确切属性，因此，如果我们设置背景颜色或字体大小，则无处存储该数据。
本期是 Swift 编辑组整理周报的第四十二期，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。
Ask Apple 为开发者与苹果工程师创造了在 WWDC 之外进行直接交流的机会。本文对本次活动中与 SwiftUI 有关的一些问答进行了整理，并添加了一点个人见解。本文为下篇。
SwiftUI 和 Core Data 之间相差将近十年 —— SwiftUI 随着 iOS 13 面世而 Core Data 则是 iPhoneOS 3 的产物；很久以前，它还没有被称为 iOS，因为 iPad 尚未发布。尽管时间相距遥远，Apple 还是投入了大量工作以确保这两种强大的技术能够完美地相互配合使用，这意味着 Core Data 就像始终以这种方式设计一样，已集成到 SwiftUI 中。
本文中我们将探讨在 SwiftUI 视图中批量获取 Core Data 数据的方式，并尝试创建一个可以使用 mock 数据的 FetchRequest。由于本文会涉及大量 前文[1] 中介绍的技巧和方法，因此最好一并阅读。
上一篇我们总结的主要是VStack里面的东西，由他延伸到 @ViewBuilder, 接着我们上一篇总结的我们这篇内容主要说的是下面的几点，在这些东西说完后我准备解析一下苹果在SiwftUI文档中说道的比较好玩的一个东西，具体的我们后面在看。这篇我们还是说我们关于SwiftUI的东西，再提一下Demo代码我已经提交上Git了，目前Demo进度为一级页面基本上结束，地图点击大头针的添加也刚处理完，代码有需要的小伙伴可以去Git看看，项目地址
每当我们将修饰符应用于SwiftUI视图时，我们实际上都会创建一个应用了更改的新视图——我们不仅会修改现有的视图。如果您考虑一下，这种行为是有道理的——我们的视图仅保留我们赋予它们的确切属性，因此，如果我们设置背景颜色或字体大小，则无处存储该数据。
Apple 推出了由 Swift 语言的宏功能支持的新观察框架。新的观察框架与 Swift 并发功能结合使用，允许我们替代 Apple 公司看起来已经过时的 Combine 框架。下面将介绍如何使用观察框架来处理应用程序中的数据流。
本文将探讨涉及 SwiftUI TextField 的事件、焦点切换、键盘设置等相关的经验、技巧和注意事项。
SwiftUI最强大的功能之一是能够自定义视图的显示和隐藏方式。以前，您已经了解了如何使用常规if条件有条件地包含视图，这意味着当条件更改时，我们可以从视图层次结构中插入或移除视图。
前些日子，一位网友在聊天室中就如下的 问题[3] 与大家进行了交流与探讨 —— 如何通过 Text + AttributedString 实现类似文章关键字检索的功能，并可通过按钮在搜索结果中进行滚动切换？
1976 年 4 月 11 日，苹果公司迈出了重要一步，Steve Wozniak 设计的 Apple I 型电脑问世。尽管仅是一块需要用户自行添加键盘和显示器的电路板，但历史意义却极为重大，这款产品奠定了苹果公司的市场地位。
在 iOS 14 正式版发布之前我写了一篇博文《iOS开发之WidgetKit》，iOS 14 正式版发布以后，经测试，Apple 改变了 Widget 的 API，所以本文进行一个补充说明（在前文的基础上做了修改，尤其是代码部分）。
苹果于 WWDC 2023 上推出新框架 SwiftData，提供声明性的、以 Swift 为先的 API，可在 iOS 应用中进行数据持久化工作。SwiftData 可轻松将一个 Swift 类转换为一个持久化模型，非常适合同 SwiftUI 一并使用。
SwiftUI的TextField可能是开发者在应用程序中最常使用的文本录入组件了。作为UITextField（NSTextField）的SwiftUI封装，苹果为开发者提供了众多的构造方法和修饰符以提高其使用的便利性、定制性。但SwiftUI在封装中也屏蔽了不少的高级接口和功能，增加了开发者实现某些特定需要的复杂性。本文为【SwiftUI 进阶】系列文章中的一篇，在本文中，我将介绍如何在TextField中实现如下功能：
了解 iOS 17 中的 MapKit 后，我们会发现 Apple 引入了更适合 SwiftUI 的 API。
SwiftUI中的界面是严格数据驱动的：运行时界面的修改，只能通过修改数据来间接完成，而不是直接对界面进行修改操作。
使用 Python 写完爬虫后，有时候我们需要在手机上实时对爬虫进行调度，或实时展示爬虫的结果
我在去年底使用了SwiftUI写了第一个 iOS app 健康笔记，这是我第一次接触响应式编程概念。在有了些基本的认识和尝试后，深深的被这种编程的思路所打动。不过，我在使用中也发现了一些奇怪的问题。我发现在视图（View）数量达到一定程度，随着数据量的增加，整个app的响应有些开始迟钝，变得有粘滞感、不跟手。app响应出现了问题一方面肯定和我的代码效率、数据结构设计欠佳有关；不过随着继续分析，发现其中也有很大部分原因来自于SwiftUI中所使用的响应式的实现方式。不恰当的使用，可能导致响应速度会随着数据量及View量的增加而大幅下降。通过一段时间的研究和分析，我打算用两篇文章来阐述这方面的问题，并尝试提供一个现阶段的使用思路。
本文将通过一段可复现的“灵异代码”，对 State 注入优化机制、模态视图（ Sheet、FullScreenCover ）内容的生成时机以及不同上下文（ 相互独立的视图树 ）之间的数据协调等问题进行探讨。
SwiftUI是一个非常方便快速的构建UI的框架，与最新Xcode设计工具无缝协作，可为所有苹果设备构建UI。开发者通过SwiftUI，利用Swift语法就能够完成代码和设计的同步。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
