As it turns out, the @ObservationTracked macro is automatically granted even if it is a private var. Therefore, I think it is not wrong to grant @ObservationIgnored. @ObservationTracked grants the following processing to isFetchingData. private var isFetchingData = false // Code given by ObservationTracked macro from here on { @storageRestrictions(initializes: _isFetchingData) init(initialValue) { _isFetchingData = initialValue } get { access(keyPath: \.isFetchingData) return _isFetchingData } set { withMutation(keyPath: \.isFetchingData) { _isFetchingData = newValue } } _modify { access(keyPath: \.isFetchingData) _$observationRegistrar.willSet(self, keyPath: \.isFetchingData) defer { _$observationRegistrar.didSet(self, keyPath: \.isFetchingData) } yield &_isFetchingData } } For the use you are describing, it is conceivable that the set and _modify would be called if the data is changed frequently, which would slow down the process. However, I'm sorry to say that I don't know if you can really feel it. Personally, I don't see the point of running this process with private, so I would add @ObservationIgnored to avoid wasting code. If you want to know more about this Observation macro, you may want to take a look at the following implementation in Swift. GitHub Swift Language Repository