Skip to content

Rename CKRecord.setValue overload to setBytes to fix unexpected Xcode 26.4 overload resolution#425

Open
jsutula wants to merge 1 commit intopointfreeco:mainfrom
jsutula:xcode-26.4-test-failures
Open

Rename CKRecord.setValue overload to setBytes to fix unexpected Xcode 26.4 overload resolution#425
jsutula wants to merge 1 commit intopointfreeco:mainfrom
jsutula:xcode-26.4-test-failures

Conversation

@jsutula
Copy link

@jsutula jsutula commented Mar 20, 2026

Problem

Unit tests are failing with Xcode 26.4 (I'm on Xcode 26.4 RC 17E192).

When calling CKRecord.setValue(_ newValue:forKey:at) with a value of bytes ([UInt8]), building with Xcode 26.4 results in an unexpected setValue overload being invoked, causing test failures in SchemaChangeTests and AssetsTests.

With Xcode 26.3, the expected overload accepting [UInt8] is invoked. This overload saves the bytes in a CKAsset and then saves the asset as a regular field on the record.

package func setValue(
_ newValue: [UInt8],

With Xcode 26.4, the overload accepting some CKRecordValueProtocol & Equatable is invoked instead. This overload writes the value directly to encryptedValues, no CKAsset.

package func setValue(
_ newValue: some CKRecordValueProtocol & Equatable,

Solution

Rename the overload which accepts bytes to setBytes and update all callers. The new name sidesteps the compiler having to resolve the overload and better reflects there being a distinct behavioral difference compared to plain setValue.

Testing

With Xcode 26.4 selected, swift test. All tests pass including previously failing SchemaChangeTests and AssetsTests.

Comment on lines 254 to +255
case .blob(let value):
setValue(value, forKey: column.name, at: userModificationTime)
setBytes(value, forKey: column.name, at: userModificationTime)
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stephencelis I was hoping the impact of this bug would be in tests only, but I had to change this line here in CKRecord.update to fix things, and unfortunately it's called by SyncEngine. I believe this means that anyone who's already been building/running/deploying with Xcode 26.4 will have to contend with this behavioral change having impacted how data is stored (blobs directly in the record vs CKAsset), and address any side effects stemming from that. Can you confirm if this is something we need to be concerned about?

I also see that you made the change to support Xcode 26.4 last month with release 1.6.0. Were the tests passing with early Xcode 26.4 betas? I jumped straight from 26.3 to 26.4 RC, so it's possible the behavior change may have been introduced in a later beta build or RC.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant