为了方便使用，Foundation 为 iOS 开发中的几个常见操作提供了直接获取 Publisher 的方式。
本文将对 @Published 与符合 ObservableObject 协议的类实例之间的沟通机制做以介绍，并通过三个示例：@MyPublished（ @Published 的仿制版本 ）、@PublishedObject（包装值为引用类型的 @Published 版本）、@CloudStorage（类似 @AppStorage ，但适用于 NSUbiquitousKeyValueStore ），来展示如何为其他的自定义属性包装类型添加可访问包裹其的类实例的属性或方法的能力。
我是在去年阅读王巍写的《SwiftUI 与 Combine 编程》才第一次接触到单一数据源这一概念的。
Combine 既可以在 SwiftUI 中使用，也可以在 UIKit 中使用。下面分别实践一下。
判断一个可滚动控件（ ScrollView、List ）是否处于滚动状态在某些场景下具有重要的作用。比如在 SwipeCell[3] 中，需要在可滚动组件开始滚动时，自动关闭已经打开的侧滑菜单。遗憾的是，SwiftUI 并没有提供这方面的 API 。本文将介绍几种在 SwiftUI 中获取当前滚动状态的方法，每种方法都有各自的优势和局限性。
VIPER架构模式是MVC或MVVM的另一种选择。虽然SwiftUI和Combine框架创建了一个强大的组合，可以快速构建复杂的ui和在应用程序中移动数据，但它们也面临着各自的挑战和对架构的看法。
前些日子，一位网友在聊天室中就如下的 问题[3] 与大家进行了交流与探讨 —— 如何通过 Text + AttributedString 实现类似文章关键字检索的功能，并可通过按钮在搜索结果中进行滚动切换？
经过两年多的时间，SwiftUI发展到当前的3.0版本，无论SwiftUI的功能还是Swift语言本身在这段时间里都有了巨大的提升。是时候使用Async/Await来重构我的的状态容器代码了。
StateObject 是在 SwiftUI 2.0 中才添加的属性包装器，它的出现解决了在某些情况下使用 ObservedObject 视图会出现超预期的问题。本文将介绍两者间的异同，原理以及注意事项。
概念 Combine 中包括Publisher在内的一系列角色都使用协议来进行定义，这是 Swift 面向协议编程思想的具体体现。 Publisher 随着时间推移向一个或多个Subscriber发布数据。 Publisher 最主要的工作其实有两个 被 Subscriber 订阅 发布数据和数据 Publisher定义 public protocol Publisher { /// 发送的数据的类型 associatedtype Output /// Publisher可能产生
SwiftUI中的界面是严格数据驱动的：运行时界面的修改，只能通过修改数据来间接完成，而不是直接对界面进行修改操作。
越来越多同学打算开始用 Swift 来开发了，可很多人以前都没接触过 Swift。这篇和我以前文章不同的是，本篇只是面向 Swift 零基础的同学，内容主要是一些直接可用的小例子，例子可以直接在工程中用或自己调试着看。
因为SwiftUI View 采用的是结构体，当创建想要更改属性的结构体方法时，我们需要添加mutating关键字,例如：
随着近年来有关 SwiftUI 的文章与书籍越来越多，开发者应该都已经清楚地掌握了 —— “视图是状态的函数” 这一 SwiftUI 的基本概念。每个视图都有与其对应的状态，当状态变化时，SwiftUI 都将重新计算与其对应视图的 body 值。
在 WWDC 2023 中，苹果介绍了 Swift 标准库中的新成员：Observation 框架。它的出现有望缓解开发者长期面临的 SwiftUI 视图无效更新问题。本文将采取问答的方式，全面而详尽地探讨 Observation 框架，内容涉及其产生原因、使用方法、工作原理以及注意事项等。
Combine.framework 是Apple在2019 WWDC 上基于Swift推出的函数响应框架（Functional Reactive Programming）,支持Apple全平台的操作系统（iOS13+，macOS 10.15+等）。函数式响应框架无论在哪个平台早已流行泛滥，开源的Rx更是实现了各种语言的响应式编程框架。Apple在这个时候推出响应式框架，无疑是对自己护城河的进一步巩固。事实上SwiftUI的数据驱动就是依赖Combine。
源码 1. Swift 首先看下工程组织结构 下面就是源码了 1. SceneDelegate.swift import SwiftUI class SceneDelegate: UIRespond
设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。项目中合理的运用设计模式可以完美的解决很多问题，每种模式在现在中都有相应的原理来与之对应，每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是它能被广泛应用的原因。
SwiftUI的环境使我们可以使用来自外部的值，这对于读取Core Data上下文或视图的展示模式等很有用。但是我们也可以将自定义对象发送到环境中，并在以后将它们读出来，这使我们可以在复杂的应用程序中更轻松地共享数据。
NSUbiquitousKeyValueStore 是苹果官方提供的用于在设备间共享键值数据的解决方案。本文将对其用法做以简单介绍，着重探讨如何便捷地在 SwiftUI 中使用 NSUbiquitousKeyValueStore。
最近看了斯坦福大学 2020 春季的 SwiftUI 课程，总结一下 SwiftUI 是如何支持 MVVM 设计模式的。
Safe Area（安全区域）是指不与导航栏、标签栏、工具栏或其他视图控制器提供的视图重叠的内容空间。
本文中我们将探讨在 SwiftUI 视图中批量获取 Core Data 数据的方式，并尝试创建一个可以使用 mock 数据的 FetchRequest。由于本文会涉及大量 前文[1] 中介绍的技巧和方法，因此最好一并阅读。
长久以来，开发者对 SwiftUI 的导航系统颇有微词。受 NavigationView 的能力限制，开发者需要动用各种技巧乃至黑科技才能实现一些本应具备基本功能（例如：返回根视图、向堆栈添加任意视图、返回任意层级视图 、Deep Link 跳转等 ）。SwiftUI 4.0（ iOS 16+ 、macOS 13+ ）对导航系统作出了重大改变，提供了以视图堆栈为管理对象的新 API ，让开发者可以轻松实现编程式导航。本文将对新的导航系统作以介绍。
在这篇文章中，我们将探讨几个在 SwiftUI 开发中经常使用且至关重要的属性包装器。本文旨在提供对这些属性包装器的主要功能和使用注意事项的概述，而非详尽的使用指南。
前面的几篇文章总结了怎样用 SwiftUI 搭建基本框架时候的一些注意点（和这篇文章在相同的分类里面，有需要了可以点进去看看），这篇文章要总结的东西是用地图数据处理结合来说的，通过这篇文章我们能总结到的点有下面几点：
如果想获得更好的阅读体验，可以访问我的博客 www.fatbobman.com。[1]
去年 12 月 25 日，我的博客经过重新设计后正式上线。这次改版的一个重要变化是提供了文章的中英文两个版本，并且我也停止了在中国其他技术平台上更新文章。一个月后，即从 12 月 25 日至 1 月 23 日，博客的访问数据呈现出显著的变化：
苹果于 WWDC 2023 上推出新框架 SwiftData，提供声明性的、以 Swift 为先的 API，可在 iOS 应用中进行数据持久化工作。SwiftData 可轻松将一个 Swift 类转换为一个持久化模型，非常适合同 SwiftUI 一并使用。
我对 iOS 开发、手机开发、SwiftUI 开发经验有限，若有理解错误的部分欢迎指正。
我们常常会遇到这样的情况：方法、变量、类名等会被保存在某个变量里，例如下面这个例子。
Ask Apple 为开发者与苹果工程师创造了在 WWDC 之外进行直接交流的机会。本文对本次活动中与 SwiftUI 有关的一些问答进行了整理，并添加了一点个人见解。本文为上篇。
本篇文章引导你通过Spring Boot，Spring Data JPA和MySQL实现many-to-many关联表存在额外字段下关系映射。
随着苹果对 iPadOS 的不断投入，越来越多的开发者都希望自己的应用能够在 iPad 中有更好的表现。尤其当用户开启了台前调度（ Stage Manager ）功能后，应用对不同视觉大小模式的兼容能力就越发显得重要。本文将就如何创建可自适应不同尺寸模式的程序化导航方案这一内容进行探讨。
观察者模式是一种行为设计模式，它建立了一种对象之间的一对多依赖关系。在这种模式中，一个对象（称为主题）维护了一个观察者列表，并在状态变化时通知所有的观察者。这使得观察者能够及时响应主题的变化，并执行相应的操作。
随着 Swift 5.5 引入了 async/await 特性，苹果也为 SwiftUI 添加了 task 视图修饰器，以方便开发者在视图中使用基于 async/await 的异步代码。本文将对 task 视图修饰器的特点、用法、注意事项等内容做以介绍，并提供了将其移植到老版本 SwiftUI 的方法。
设计模式（Design Pattern）是软件开发领域的宝贵经验，是多人反复借鉴和广泛应用的代码设计指导。它们是一系列经过分类和归纳的代码组织方法，旨在实现可重用性、可维护性和可理解性。使用设计模式，我们能够编写高质量的代码，使其更易于他人理解，并提供了代码可靠性的保证。
SwiftUI与苹果之前的UI框架的区别不仅仅在于如何定义视图和其他UI组件，还在于如何在整个使用它的应用程序中管理视图层级的状态。
设计模式其实最常用在面向对象编程中，如果通俗的说，他是软件开发中的一种思想，根据这种思想我们可以设计出来的软件更加优秀，同时软件之间更容易进行扩展。
https://github.com/shoufei403/ros2_galactic_tutorials
在我之前的文章@State研究中我们探讨过@State，通过它，我们可以方便的将值类型数据作为View的Source of truth。在SwiftUI 1.0时代，如果想将引用类型作为source of truth,通常的方法是使用@EnvironmentObject或者 @ObservedObject。
我在去年底使用了SwiftUI写了第一个 iOS app 健康笔记，这是我第一次接触响应式编程概念。在有了些基本的认识和尝试后，深深的被这种编程的思路所打动。不过，我在使用中也发现了一些奇怪的问题。我发现在视图（View）数量达到一定程度，随着数据量的增加，整个app的响应有些开始迟钝，变得有粘滞感、不跟手。app响应出现了问题一方面肯定和我的代码效率、数据结构设计欠佳有关；不过随着继续分析，发现其中也有很大部分原因来自于SwiftUI中所使用的响应式的实现方式。不恰当的使用，可能导致响应速度会随着数据量及View量的增加而大幅下降。通过一段时间的研究和分析，我打算用两篇文章来阐述这方面的问题，并尝试提供一个现阶段的使用思路。
SwiftUI的TextField可能是开发者在应用程序中最常使用的文本录入组件了。作为UITextField（NSTextField）的SwiftUI封装，苹果为开发者提供了众多的构造方法和修饰符以提高其使用的便利性、定制性。但SwiftUI在封装中也屏蔽了不少的高级接口和功能，增加了开发者实现某些特定需要的复杂性。本文为【SwiftUI 进阶】系列文章中的一篇，在本文中，我将介绍如何在TextField中实现如下功能：
要编写出色的应用程序，您不仅需要提出一个好主意，还需要考虑未来。快速有效地适应、改进和扩展应用程序功能的灵活性至关重要。无论您是在团队中工作还是独自工作，从长远来看，您编写和组织代码的方式将对维护您的代码产生巨大影响。这就是 SOLID 原则的用武之地。
Ask Apple 为开发者与苹果工程师创造了在 WWDC 之外进行直接交流的机会。本文对本次活动中与 SwiftUI 有关的一些问答进行了整理，并添加了一点个人见解。本文为下篇。
众所周知，SwiftUI 是一个响应式框架，这意味着，当数据源发生变化时，框架会自动更新视图。同样，当我们想调整视图显示时，应直接对状态进行修改。但是，SwiftUI 中的一些系统控件并没有完全遵循响应式的设计原则，由此在某些情况下会出现严重的错误，影响用户体验，并使开发者无所适从。
*此处重点，ROS1成熟，而ROS2还是深度开发中的实验版，LTS长期支持版目前也没有5年，而是3年，此版本不适合初学者学习！
作为 SwiftUI 最引人注目的功能之一，预览功能吸引了不少开发者初次接触 SwiftUI。然而，随着项目规模的增长，越来越多的开发者发现预览功能并不如最初想象的那么易用。由于预览崩溃的次数和场景的增加，一些开发者已经视预览为 SwiftUI 的缺点之一，并对其产生了排斥感。
iOS开发中UIKit中控件的交互方式默认是Target-Action，这种方式简单且直观。不过，一个问题在于编码方式太过于繁琐，需要定义一个方法，然后调用addTartget方式进行绑定；在复杂页面交互，需要跨多级数据传递的时候，就变得异常繁琐。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
