Why is the SwiftUI re-render the UI event if the view does not use the counter like in the example bellow...shouldn't SwiftUI framework be smart enough to detect that??
import SwiftUI
class ViewModel: ObservableObject {
@Published var counter: Int = 0 // Not used in the view's body
@Published var displayText: String = "Hello" // Used in the view's body
}
struct ContentView: View {
@StateObject private var viewModel = ViewModel()
var body: some View {
VStack {
Text(viewModel.displayText) // Depends on displayText
}
.onChange(of: viewModel.counter) { newValue in
print("Counter changed to: \(newValue)")
}
}
}
Is there any solution more elegant without using Publishers??
How did we do? We’d love to know your thoughts on this year’s conference. Take the survey here
Combine
RSS for tagCustomize handling of asynchronous events by combining event-processing operators using Combine.
Posts under Combine tag
17 Posts
Sort by:
Post
Replies
Boosts
Views
Activity
When presenting a SwiftUI sheet containing ObservableObject's injected using environmentObject(_) modifier, the objects are unexpectedly retained after the sheet is dismissed if a TextField within the sheet gains focus or is edited.
This issue occurs on iOS and iPadOS (on macOS the objects are always released), observable both in the simulator and on physical devices, and happens even when the view does not explicitly reference these environment objects, and the TextField's content isn't bound to them.
Expected Results:
When the sheet is dismissed, all environment objects passed to the sheet’s content view should be released (deinitialized), regardless of whether the TextField was focused or edited.
Actual Results:
If the TextField was focused or edited, environment objects (ObservableA and ObservableB) are retained after the sheet is dismissed. They are not deinitialized as expected, leading to unintended retention.
Interestingly, previously retained copies of these environment objects, if any, are released precisely at the moment the TextField becomes focused on subsequent presentations, indicating an inconsistent lifecycle behavior.
I have filed an issue FB17226970
Sample Code
Below is a sample code that consistently shows the issue on iOS 18.3+.
Steps to Reproduce:
Run the attached SwiftUI sample.
Tap the button labeled “Show Sheet” to present a sheet.
Tap on the TextField to focus or begin editing.
Dismiss the sheet by dragging it down or by other dismissal methods (e.g., tapping outside on iPadOS).
import SwiftUI
struct ContentView: View {
@State private var showSheet: Bool = false
var body: some View {
VStack {
Button("Show Sheet") {
showSheet = true
}
}
.sheet(isPresented: $showSheet) {
SheetContentView()
.environmentObject(ObservableA())
.environmentObject(ObservableB())
}
}
}
struct SheetContentView: View {
@State private var text: String = ""
var body: some View {
TextField("Select to retain observable objects", text: $text)
.textFieldStyle(.roundedBorder)
}
}
final class ObservableA: ObservableObject {
init() {
print(type(of: self), #function)
}
deinit {
print(type(of: self), #function)
}
}
final class ObservableB: ObservableObject {
init() {
print(type(of: self), #function)
}
deinit {
print(type(of: self), #function)
}
}
#Preview {
ContentView()
}
I see SwiftUI body being repeatedly called in an infinite loop in the presence of Environment variables like horizontalSizeClass or verticalSizeClass. This happens after device is rotated from portrait to landscape and then back to portrait mode. The deinit method of TestPlayerVM is repeatedly called. Minimally reproducible sample code is pasted below.
The infinite loop is not seen if I remove size class environment references, OR, if I skip addPlayerObservers call in the TestPlayerVM initialiser.
import AVKit
import Combine
struct InfiniteLoopView: View {
@Environment(\.verticalSizeClass) var verticalSizeClass
@Environment(\.horizontalSizeClass) var horizontalSizeClass
@State private var openPlayer = false
@State var playerURL: URL = URL(fileURLWithPath: Bundle.main.path(forResource: "Test_Video", ofType: ".mov")!)
var body: some View {
PlayerView(playerURL: playerURL)
.ignoresSafeArea()
}
}
struct PlayerView: View {
@Environment(\.dismiss) var dismiss
var playerURL:URL
@State var playerVM = TestPlayerVM()
var body: some View {
VideoPlayer(player: playerVM.player)
.ignoresSafeArea()
.background {
Color.black
}
.task {
let playerItem = AVPlayerItem(url: playerURL)
playerVM.playerItem = playerItem
}
}
}
@Observable
class TestPlayerVM {
private(set) public var player: AVPlayer = AVPlayer()
var playerItem:AVPlayerItem? {
didSet {
player.replaceCurrentItem(with: playerItem)
}
}
private var cancellable = Set<AnyCancellable>()
init() {
addPlayerObservers()
}
deinit {
print("Deinit Video player manager")
removeAllObservers()
}
private func removeAllObservers() {
cancellable.removeAll()
}
private func addPlayerObservers() {
player.publisher(for: \.timeControlStatus, options: [.initial, .new])
.receive(on: DispatchQueue.main)
.sink { timeControlStatus in
print("Player time control status \(timeControlStatus)")
}
.store(in: &cancellable)
}
}
Hi, folks.
I know that in the new observation, class property changes can be automatically notified to SwiftUI, which is very convenient. But in the new observation framework, how to monitor the property changes of different model classes? For example, class1 has an instance of class2, and I need to notify class1 to perform some actions and make some changes when some properties of class2 are changed. How to do it in observation? In the past, I could use combined methods to write the second part of the code for monitoring. However, using the combined framework in observation is a bit confusing. I know this method can be withObservationTracking(_:onChange:) but it needs to be registered continuously.
If Observation is not possible, do I need to change my design structure?
Thanks.
// Observation
@Observable class Sample1 {
var count: Int = 0
var name = "Sample1"
}
@Observable class Sample2 {
var count: Int = 0
var name = "Sample2"
var sample1: Sample1?
init (sample1 : Sample1) {
self.sample1 = sample1
}
func render() {
withObservationTracking {
print("Accessing Sample1.count: \(sample1?.count ?? 0)")
} onChange: { [weak self] in
print("Sample1.count changed! Re-rendering Sample2.")
self?.handleSample1CountChange()
}
}
private func handleSample1CountChange() {
print("Handling count change in Sample2...")
self.count = sample1?.count ?? 0
}
}
// ObservableObject
class Sample1: ObservableObject {
@Published var count: Int = 0
var name = "Sample1"
}
class Sample2: ObservableObject {
@Published var count: Int = 0
var name = "Sample1"
var sample1: Sample1?
private var cancellables = Set<AnyCancellable>()
init (sample1 : Sample1) {
self.sample1 = sample1
setupSubscribers()
}
private func setupSubscribers() {
sample1?.$count
.receive(on: DispatchQueue.main)
.sink { [weak self] count in
guard let self = self else { return }
// Update key theory data
self.count = count
self.doSomeThing()
}
.store(in: &cancellables)
}
private func doSomeThing() {
print("Count changes, need do some thing")
}
}
After the app is put in background for sometime and brought in to foreground and the app crashes each time with a different thread stack entries but all of them states same exception reason.
Hello,
I recently implemented a conditional debounce publisher using Swift's Combine.
If a string with a length less than 2 is passed, the event is sent downstream immediately without delay. If a string with a length of 2 or more is passed, the event is emitted downstream with a 0.2-second delay.
While writing test logic related to this, I noticed a strange phenomenon: sometimes the publisher, which should emit events with a 0.2-second delay, does not emit an event.
The test code below should have all indices from 1 to 100 in the array, but sometimes some indices are missing, causing the assertion to fail. Even after observing completion, cancel, and output events through handleEvents, I couldn't find any cause. Am I using Combine incorrectly, or is there a bug in Combine?
I would appreciate it if you could let me know.
import Foundation
import Combine
var cancellables: Set<AnyCancellable> = []
@MainActor func text(index: Int, completion: @escaping () -> Void) {
let subject = PassthroughSubject<String, Never>()
let textToSent = "textToSent"
subject
.map { text in
if text.count >= 2 {
return Just<String>(text)
.delay(for: .seconds(0.2), scheduler: RunLoop.main)
.eraseToAnyPublisher()
} else {
return Just<String>(text)
.eraseToAnyPublisher()
}
}
.switchToLatest()
.sink {
if $0.count >= 2 {
completion()
}
}.store(in: &cancellables)
for i in 0..<textToSent.count {
let stringIndex = textToSent.index(textToSent.startIndex, offsetBy: i)
let stringToSent = String(textToSent[textToSent.startIndex...stringIndex])
subject.send(stringToSent)
}
}
var array = [Int]()
for i in 1...100 {
text(index: i) {
array.append(i)
}
}
DispatchQueue.main.asyncAfter(deadline: .now() + 5) {
for i in 1...100 {
assert(array.contains(i))
}
}
RunLoop.main.run(until: .now + 10)
.onReceive construction isn't working with button long press gesture but tap is working, it increases count by 1. Construction should increase count every 0.5 seconds if button pressed
struct Test: View {
@State private var count = 0
@State private var isLongPressed = false
var body: some View {
VStack {
Text("Count: \(count)")
Button("Increase") {
count += 1
print("Button tapped")
}
.onLongPressGesture {
isLongPressed = true
print("Long press started")
}
.onLongPressGesture(minimumDuration: 0) {
isLongPressed = false
print("Long press ended")
}
}
.onReceive(Timer.publish(every: 0.5, on: .main, in: .common).autoconnect()) { _ in
if isLongPressed {
count += 1
print("Count increased: \(count)")
}
}
}
}
We have product for network monitoring and we are't able to add support auto-instrumenting the networking requests for URLSession async/wait methods as these methods are't exposed to dynamic environment or not exposed to ObjC and we con't use any of the run-time functionality and we con't override these methods as these methods are't public.
looking for a way to add some kind of logic so that when customers use our product they don't have to add any code from there end to monitor this system.
Given the below code with Swift 6 language mode, Xcode 16.2
If running with iOS 18+: the app crashes due to _dispatch_assert_queue_fail
If running with iOS 17 and below: there is a warning: warning: data race detected: @MainActor function at Swift6Playground/PublishedValuesView.swift:12 was not called on the main thread
Could anyone please help explain what's wrong here?
import SwiftUI
import Combine
@MainActor
class PublishedValuesViewModel: ObservableObject {
@Published var count = 0
@Published var content: String = "NA"
private var cancellables: Set<AnyCancellable> = []
func start() async {
let publisher = $count
.map { String(describing: $0) }
.removeDuplicates()
for await value in publisher.values {
content = value
}
}
}
struct PublishedValuesView: View {
@ObservedObject var viewModel: PublishedValuesViewModel
var body: some View {
Text("Published Values: \(viewModel.content)")
.task {
await viewModel.start()
}
}
}
Hello,
I’ve encountered a warning while working with UITableViewDiffableDataSource. Here’s the exact message:
Warning: applying updates in a non-thread confined manner is dangerous and can lead to deadlocks. Please always submit updates either always on the main queue or always off the main queue - view=<UITableView: 0x7fd79192e200; frame = (0 0; 375 667); clipsToBounds = YES; autoresize = W+H; gestureRecognizers = <NSArray: 0x600003f3c9f0>; backgroundColor = <UIDynamicProviderColor: 0x60000319bf80; provider = <NSMallocBlock: 0x600003f0ce70>>; layer = <CALayer: 0x6000036e8fa0>; contentOffset: {0, -116}; contentSize: {375, 20}; adjustedContentInset: {116, 0, 49, 0}; dataSource: <TtGC5UIKit29UITableViewDiffableDataSourceOC17ArticleManagement21DiscardItemsViewModel17SectionIdentifierSS: 0x600003228270>>
OS: iOS Version: iOS 17+,
Xcode Version: 16.0,
Frameworks: UIKit, Diffable Data Source,
View: UITableView used with a UITableViewDiffableDataSource.
Steps to Reproduce:
Using a diffable data source with a table view.
Applying snapshot updates in the data source from a main thread.
Warning occurs intermittently during snapshot application.
Expected Behavior:
The snapshot should apply without warnings, provided the updates are on a main thread.
Actual Behavior:
The warning suggests thread safety issues when applying updates on non-thread-confined queues.
Questions:
Is there a recommended best practice to handle apply calls in diffable data sources with thread safety in mind?
Could this lead to potential deadlocks if not addressed?
Note :- I confirm I am always reloading / reconfiguring data source on main thread. Please find the attached screenshots for the reference.
Any guidance or clarification would be greatly appreciated!
Hello everyone,
I've built a @CurrentValue property wrapper that mimics the behavior of @Published, allowing a property to publish values on "did set". I've also created my own assign(to:) implementation that works with @CurrentValue properties, allowing values to be assigned from a publisher to a @CurrentValue property.
However, I'm running into an issue. When I use this property wrapper with two classes and the source class (providing the publisher) is not stored as a property, the subscription is deallocated, and values are no longer forwarded.
Here's the property wrapper code:
@propertyWrapper
public struct CurrentValue<Value> {
/// A publisher for properties marked with the `@CurrentValue` attribute.
public struct Publisher: Combine.Publisher {
public typealias Output = Value
public typealias Failure = Never
/// A subscription that forwards the values from the CurrentValueSubject to the downstream subscriber
private class CurrentValueSubscription<S>: Subscription where S: Subscriber, S.Input == Output, S.Failure == Failure {
private var subscriber: S?
private var currentValueSubject: CurrentValueSubject<S.Input, S.Failure>?
private var cancellable: AnyCancellable?
init(subscriber: S, publisher: CurrentValue<Value>.Publisher) {
self.subscriber = subscriber
self.currentValueSubject = publisher.subject
}
func request(_ demand: Subscribers.Demand) {
var demand = demand
cancellable = currentValueSubject?.sink { [weak self] value in
// We'll continue to emit new values as long as there's demand
if let subscriber = self?.subscriber, demand > 0 {
demand -= 1
demand += subscriber.receive(value)
} else {
// If we have no demand, we'll cancel our subscription:
self?.subscriber?.receive(completion: .finished)
self?.cancel()
}
}
}
func cancel() {
cancellable = nil
subscriber = nil
currentValueSubject = nil
}
}
/// A subscription store that holds a reference to all the assign subscribers so we can cancel them when self is deallocated
fileprivate final class AssignSubscriptionStore {
fileprivate var cancellables: Set<AnyCancellable> = []
}
fileprivate let subject: CurrentValueSubject<Value, Never>
fileprivate let assignSubscriptionStore: AssignSubscriptionStore = .init()
fileprivate var value: Value {
get {
subject.value
}
nonmutating set {
subject.value = newValue
}
}
init(_ initialValue: Output) {
self.subject = .init(initialValue)
}
public func receive<S>(subscriber: S) where S: Subscriber, Failure == S.Failure, Output == S.Input {
let subscription = CurrentValueSubscription(subscriber: subscriber, publisher: self)
subscriber.receive(subscription: subscription)
}
}
public var wrappedValue: Value {
get { publisher.value }
nonmutating set { publisher.value = newValue }
}
public var projectedValue: Publisher {
get {
publisher
}
mutating set {
publisher = newValue
}
}
private var publisher: Publisher
public init(wrappedValue: Value) {
publisher = .init(wrappedValue)
}
}
/// A subscriber that receives values from an upstream publisher and assigns them to a downstream CurrentValue property.
private final class AssignSubscriber<Input>: Subscriber, Cancellable {
typealias Failure = Never
private var receivingSubject: CurrentValueSubject<Input, Never>?
private weak var assignSubscriberStore: CurrentValue<Input>.Publisher.AssignSubscriptionStore?
init(currentValue: CurrentValue<Input>.Publisher) {
self.receivingSubject = currentValue.subject
self.assignSubscriberStore = currentValue.assignSubscriptionStore
}
func receive(subscription: Subscription) {
// Hold a reference to the subscription in the downstream publisher
// so when it deallocates, the susbcription is automatically cancelled
assignSubscriberStore?.cancellables.insert(AnyCancellable(subscription))
subscription.request(.unlimited)
}
func receive(_ input: Input) -> Subscribers.Demand {
receivingSubject?.value = input
return .none
}
func receive(completion: Subscribers.Completion<Never>) {
// Nothing to do here
}
public func cancel() {
receivingSubject = nil
assignSubscriberStore = nil
}
}
public extension Publisher where Self.Failure == Never {
/// Assigns the output of the upstream publisher to a downstream CurrentValue property
/// - Parameter currentValue: The CurrentValue property to assign the values to
func assign(to currentValue: inout CurrentValue<Self.Output>.Publisher) {
let subscriber = AssignSubscriber(currentValue: currentValue)
self.subscribe(subscriber)
}
}
Here’s an example demonstrating the issue, where two classes are used: Source, which owns the @CurrentValue property, and Forwarder1, which subscribes to updates from Source:
final class Source {
@CurrentValue public private(set) var value: Int = 1
func update(value: Int) {
self.value = value
}
}
final class Forwarder1 {
@CurrentValue public private(set) var value: Int
init(source: Source) {
self.value = source.value
source.$value.dropFirst().assign(to: &$value)
// The source is not stored as a property, so the subscription deallocates
}
func update(value: Int) {
self.value = value
}
}
With this setup, if source isn’t retained as a property in Forwarder1, the subscription is deallocated prematurely, and value in Forwarder1 stops receiving updates from Source.
However, this doesn’t happen with @Published properties in Combine. Even if source isn’t retained, @Published subscriptions seem to stay active, propagating values as expected.
My Questions:
What does Combine do internally with @Published properties that prevents the subscription from being deallocated prematurely, even if the publisher source isn’t retained as a property?
Is there a recommended approach to address this in my custom property wrapper to achieve similar behavior, ensuring the subscription isn’t lost?
Any insights into Combine’s internals or suggestions on how to resolve this would be greatly appreciated. Thank you!
When using conformance to ObservableObject and then doing async work in a Task, you will get a warning courtesy of Combine if you then update an @Published or @State var from anywhere but the main thread. However, if you are using @Observable there is no such warning.
Also, Thread.current is unavailable in asynchronous contexts, so says the warning. And I have read that in a sense you simply aren't concerned with what thread an async task is on.
So for me, that begs a question. Is the lack of a warning, which when using Combine is rather important as ignoring it could lead to crashes, a pretty major bug that Apple seemingly should have addressed long ago? Or is it just not an issue to update state from another thread, because Xcode is doing that work for us behind the scenes too, just as it manages what thread the async task is running on when we don't specify?
I see a lot of posts about this from around the initial release of Async/Await talking about using await MainActor.run {} at the point the state variable is updated, usually also complaining about the lack of a warning. But ow years later there is still no warning and I have to wonder if this is actually a non issue. On some ways similar to the fact that many of the early posts I have seen related to @Observable have examples of an @Observable ViewModel instantiated in the view as an @State variable, but in fact this is not needed as that is addressed behind the scenes for all properties of an @Observable type.
At least, that is my understanding now, but I am learning Swift coming from a PowerShell background so I question my understanding a lot.
Topic:
App & System Services
SubTopic:
Processes & Concurrency
Tags:
Concurrency
Swift
SwiftUI
Combine
Hey all,
I am facing a new issue on iOS 18 with ScenePhase and .onChange modifier.
Here's roughly the code:
.onChange(of: scenePhase, initial: true) { old, new in
if new == .active {
doStuff()
}
}
on iOS 17 this was working as expected and triggered when eg. ap was brough from background or user navigated back to view
on ios18 though this code gets triggered constatnly in my case when I eg. navigate to another screen on top of the one with that .onChange. after navigation happens, the onChange is being triggered continuosly and does not stop which causes doStuff() to be called multiple times
I'm experiencing an issue where my app freezes when built with Xcode 16 on iOS 18.
Additional Information:
The issue does not occur when building the app with Xcode 16 on iOS 17 or lower.
The issue does not occur when building the app with Xcode 15 on iOS 18.
The CPU usage spikes to 100% when the app freezes.
The app specifically freezes after the code runs into .sink(receiveValue:).
Here is the relevant code snippet:
@Published var selectedCardData: CardData?
@Published var selectedRootTab: RootViewTab = .statement
override func load() {
state = .loading
$selectedCardData.ignoreNil()
.removeDuplicates()
.map { [unowned self] cardData in
$selectedRootTab.filter { $0 == .statement }
.first()
.map { _ in cardData }
}
.switchToLatest()
.sink(receiveValue: { value in
print(value) // value not nil
print("Execution reaches this point and the app freezes (CPU 100%).")
})
.store(in: &cancellables)
}
Are there any known changes in iOS 18 or Xcode 16 that might affect this code?
Apple's documentation pretty much only says this about ObservableObject: "A type of object with a publisher that emits before the object has changed. By default an ObservableObject synthesizes an objectWillChange publisher that emits the changed value before any of its @Published properties changes.".
And this sample seems to behave the same way, with or without conformance to the protocol by Contact:
import UIKit
import Combine
class ViewController: UIViewController {
let john = Contact(name: "John Appleseed", age: 24)
private var cancellables: Set<AnyCancellable> = []
override func viewDidLoad() {
super.viewDidLoad()
// Do any additional setup after loading the view.
john.$age.sink { age in
print("View controller's john's age is now \(age)")
}
.store(in: &cancellables)
print(john.haveBirthday())
}
}
class Contact {
@Published var name: String
@Published var age: Int
init(name: String, age: Int) {
self.name = name
self.age = age
}
func haveBirthday() -> Int {
age += 1
return age
}
}
Can I therefore omit conformance to ObservableObject every time I don't need the objectWillChange publisher?
Given that SwiftUI and modern programming idioms promote asynchronous activity, and observing a data model and reacting to changes, I wonder why it's so cumbersome in Swift at this point.
Like many, I have run up against the problem where you perform an asynchronous task (like fetching data from the network) and store the result in a published variable in an observed object. This would appear to be an extremely common scenario at this point, and indeed it's exactly the one posed in question after question you find online about this resulting error:
Publishing changes from background threads is not allowed
Then why is it done? Why aren't the changes simply published on the main thread automatically?
Because it isn't, people suggest a bunch of workarounds, like making the enclosing object a MainActor. This just creates a cascade of errors in my application; but also (and I may not be interpreting the documentation correctly) I don't want the owning object to do everything on the main thread.
So the go-to workaround appears to be wrapping every potentially problematic setting of a variable in a call to DispatchQueue.main. Talk about tedious and error-prone. Not to mention unmaintainable, since I or some future maintainer may be calling a function a level or two or three above where a published variable is actually set. And what if you decide to publish a variable that wasn't before, and now you have to run around checking every potential change to it?
Is this not a mess?
Is it ok for an Actor type to have a Publisher as a property to let others observe changes over time? Or use the @Published property wrapper to achieve this?
actor MyActor {
var publisher = PassthroughSubject<Int, Never>()
var data: Int {
didSet {
publisher.send(data)
}
}
...
}
// Usage
var tasks = Set<AnyCancellable>()
let actor = MyActor()
Task {
let publisher = await actor.publisher
publisher.sink { print($0) }.store(in: &tasks)
}
This seems like this should be acceptable. I would expect a Publisher to be thread safe, and as long as the Output is a value type things should be fine.
I have been getting random EXC_BAD_ACCESS errors when using this approach. But turning on the address sanitizer causes these crashes to go away. I know that isn't very specific but I wanted to start by seeing if this type of pattern is ok to do.