Make AnyType Sendable with Reflection support #782

JJ-Intuit · 2026-01-16T02:07:33Z

Make AnyType Sendable with Reflection Support

Overview

This PR makes the AnyType enum conform to the Sendable protocol, enabling safe usage across Swift concurrency boundaries (async/await, actors, etc.). Additionally, it adds reflection support for more ergonomic value access and type casting.

Motivation

With Swift 6's strict concurrency checking, AnyType needed to be Sendable to be used safely in concurrent contexts. The previous implementation used [String: Any] and [Any] in the anyDictionary and anyArray cases, which are not Sendable because Any cannot guarantee thread-safety.

Changes

1. Sendable Conformance via Recursive Types

Changed:

// Before
case anyDictionary(data: [String: Any])
case anyArray(data: [Any])

// After
case anyDictionary(data: [String: AnyType])
case anyArray(data: [AnyType])

This recursive approach eliminates Any types while maintaining the same functionality, making AnyType fully Sendable.

2. Backward Compatibility API

Added comprehensive helpers to maintain compatibility with existing code:

New Initializers

init(anyDictionary: [String: Any]) - Convert [String: Any] to AnyType
init(anyArray: [Any]) - Convert [Any] to AnyType
init(from: Any) - Recursively convert any Any value to AnyType

Conversion Properties

asAnyDictionary: [String: Any]? - Access as legacy dictionary format
asAnyArray: [Any]? - Access as legacy array format
asAny: Any - Convert back to Any for interop

Pattern Matching Helpers

matchAnyDictionary(_:) - Pattern match with [String: Any] handler
matchAnyArray(_:) - Pattern match with [Any] handler

3. Reflection Support (New Feature)

Added reflection capabilities for more ergonomic value access:

Dynamic Value Access

public var dynamicValue: Any { get }

Provides direct access to underlying values without pattern matching.

Type Casting Helper

public func `as`<T>(_ type: T.Type) -> T?

Enables clean type casting:

let title: String? = envelope["title"]?.as(String.self)

Subscript Access

public subscript(key: String) -> AnyType? { get }

Provides convenient dictionary-like access for all dictionary cases:

let name = payload["user"]?["name"]?.as(String.self)

4. Enhanced Type Handling

NSNumber Support: Proper handling of NSNumber from JSON deserialization
Type Specificity: init(from:) automatically chooses the most specific type (e.g., [String: String] becomes .dictionary not .anyDictionary)
Equatable/Hashable: Updated to work with recursive structures

Test Coverage

Added 23 new tests bringing the total to 44 tests (all passing):

Performance Considerations

No performance impact: The recursive structure has the same memory layout
Lazy conversion: asAnyDictionary and asAnyArray only convert when needed
Type-safe: Compile-time safety with no runtime overhead

Breaking Changes

None. All existing APIs remain functional and unchanged.

Files Changed

ios/core/Sources/Types/Generic/AnyType.swift - Core implementation
ios/core/Tests/Types/Generic/AnyTypeTests.swift - Test coverage

Benefits

Swift 6 Ready - Full Sendable conformance for strict concurrency
Backward Compatible - Existing code works without changes
Type Safe - No Any types in the core enum
Better Ergonomics - Reflection support for cleaner code
Fully Tested - 44 comprehensive tests
No Performance Cost - Same memory layout and efficiency

Examples

Sendable Usage

actor DataManager {
    var state: AnyType = .unknownData
    
    func updateState(_ newState: AnyType) async {
        self.state = newState // Now safe!
    }
}

Reflection Usage

// Clean, functional style
func extractUserInfo(from payload: AnyType) -> (String?, Int?) {
    let name: String? = payload["user"]?["name"]?.as(String.self)
    let age: Int? = payload["user"]?["age"]?.as(Int.self)
    return (name, age)
}

Nested Structure Access

let response = AnyType(anyDictionary: jsonResponse)
let title: String? = response["data"]?["article"]?["title"]?.as(String.self)

Checklist

Code compiles without errors
All existing tests pass (21/21)
New tests added and passing (23/23)
No breaking changes
Backward compatibility maintained
Documentation updated with examples
Sendable conformance verified
Performance characteristics unchanged

Related Issues

This change enables safe usage of AnyType in Swift 6 strict concurrency mode and modern async/await codebases.

Change Type (required)

Indicate the type of change your pull request is:

patch
minor
major
N/A

Release Notes

The AnyType enum conform to the Sendable protocol, enabling safe usage across Swift concurrency boundaries (async/await, actors, etc.). Existing code continues to work without modification.

For new code, consider using the more ergonomic APIs:

Old Pattern (still supported)

switch anyType {
case .anyDictionary(let data):
    // Manual conversion to [String: Any]
    let dict = data.mapValues { $0.asAny }
    let title = dict["title"] as? String
default:
    break
}

New Pattern (recommended)

// Clean and concise
let title: String? = anyType["title"]?.as(String.self)

Creating AnyType from Any

// New convenience initializers
let dict: [String: Any] = ["key": "value"]
let anyType = AnyType(anyDictionary: dict)

// Or use the universal converter
let anyValue: Any = // ... some value
let anyType = AnyType(from: anyValue)

Accessing Values

// Using backward compatibility helpers
if let dict = anyType.asAnyDictionary {
    // Work with [String: Any]
}

// Using reflection (new)
let value = anyType.dynamicValue
let typed: String? = anyType.as(String.self)

nancywu1 · 2026-01-20T20:50:01Z

pipeline is failing because some tests needs updating for usage of anyDictionary PubSubPluginTests and BaseBeaconPluginTests

KVSRoyal · 2026-01-21T06:04:09Z

ios/core/Sources/Types/Generic/AnyType.swift

 //

 import Foundation



Unrelated to this line, can you move the stuff that would be helpful for release notes (like the migration guide) to a "# Release Notes" section at the end of the PR notes? Anything under a "# Release Notes" section will be automatically added to the actual release notes. Example here with PR #749 in the latest release.

Updated. Too verbose?

No, that's perfect. Thanks!

KVSRoyal · 2026-01-21T06:08:27Z

ios/core/Sources/Types/Generic/AnyType.swift

+     Use the `asAnyDictionary` property for backward compatibility with `[String: Any]`.
     */
-    case anyDictionary(data: [String: Any])
+    case anyDictionary(data: [String: AnyType])


Is this a breaking change? I'm thinking code like this would break with this change:

let myDict: [String: Any] = ["a": 1] let example: AnyType = .anyDictionary(data: myDict)

Is that accurate?

If this is breaking, there might not be a need for backwards compat stuff 🤔 .

Yes - the example you shared is a breaking change. But, the backward compatibility helpers mitigate the issue.

The convenience initializer (110-115) could be used:

let myDict: [String: Any] = ["a": 1] let example: AnyType = AnyType(anyDictionary: myDict)

Or, the generic init(from:) (136-175)

let example: AnyType = AnyType(from: myDict)

For new code, wrapped values would also work:

let example: AnyType = .anyDictionary(data: ["a": .number(data: 1)])

How would you like to categorize the PR? If it's "breaking", all the helpers can be removed as you note.

Okay, I talked about it with @nancywu1 @KetanReddy @cehan-Chloe and our preference now is to introduce a second type, SendableAnyType, with all the new stuff and mark AnyType as deprecated, to be dropped in 1.0. This will avoid breaking changes and we won't really need any backwards compatibility code.

What are your thoughts?

If PlayerUI introduces both AnyType and SendableAnyType, it introduces a dual-type problem.

// PlayerUI would have: enum AnyType { case anyDictionary([String: Any]) // ... } enum SendableAnyType: Codable, Sendable { case dictionary([String: SendableAnyType]) // ... }

A few considerations:

At the conversion boundary between the PubSubPlugin, we'd need to transform AnyType to SendableAnyType creating client overhead.

Eventually, this would cause a breaking change (as intended) where this PR simply extends the type.

It would be easier to introduce and maintain this new type outside PlayerUI (at least for my use-case) and potentially more useful to place in a lower shared dependency since Player is one rendering mode.

KVSRoyal · 2026-01-21T06:14:40Z

ios/core/Sources/Types/Generic/AnyType.swift

+// MARK: - Backward Compatibility & Conversion Helpers
+
+extension AnyType {


What do you think about marking these as @deprecated, to be removed in Player 2.0? We're just working on player 1.0 now, so I think that would give people time to migrate.

I'm happy to do whatever makes sense. Yes, these convenience helpers could be removed and the API simplified for Player 2.0. What would you prefer?

KVSRoyal · 2026-01-21T06:20:49Z

ios/core/Sources/Types/Generic/AnyType.swift

+    /**
+     Pattern match on anyDictionary with a legacy `[String: Any]` handler.
+
+     - Parameter handler: Closure to execute if this is an anyDictionary case
+     */
+    public func matchAnyDictionary(_ handler: ([String: Any]) -> Void) {
+        if let dict = asAnyDictionary {
+            handler(dict)
+        }
+    }
+
+    /**
+     Pattern match on anyArray with a legacy `[Any]` handler.
+
+     - Parameter handler: Closure to execute if this is an anyArray case
+     */
+    public func matchAnyArray(_ handler: ([Any]) -> Void) {
+        if let arr = asAnyArray {
+            handler(arr)
+        }
+    }


What are your thoughts on removing matchAnyDictionary and matchAnyArray necessary? They seem to really just remove an if statement for the user and since they're backwards compat things, I'm worried about introducing more things that users will have to migrate away from (assuming the backwards compat is temporary until users migrate to the new pattern).

If you do want to keep them, what are your thoughts on renaming? I think the name is as a bit confusing, since match is typically used (in my experience, admittedly somewhat limited) for finding and returning something. Like a regex match.

Agreed - the convenience helpers can bridge the gap and they essentially remove an extra if. Will remove.

KVSRoyal · 2026-01-21T06:22:36Z

ios/core/Sources/Types/Generic/AnyType.swift

+    public var dynamicValue: Any {
+        return asAny
+    }


Is this necessary? It seems like a dupe of asAny, which is also public?

You're correct - let me remove this to simplify the interface.

KVSRoyal · 2026-01-21T06:23:16Z

ios/core/Sources/Types/Generic/AnyType.swift

+     let title: String? = dict["title"]?.as(String.self)
+     ```
+     */
+    public subscript(key: String) -> AnyType? {


This is nice!

KVSRoyal · 2026-01-21T06:24:29Z

ios/test-utils-core/Sources/ui-test/AssetCollection.swift

                            AssetFlowView(flow: flow.flow, plugins: plugins, result: result)
                                .padding(padding)
-                                .navigationBarTitle(Text(flow.name))
+                                .navigationTitle(Text(flow.name))


Are the changes in this file intended?

I was trying to debug why the build pipeline was failing remotely - and navigationBarTitle has been deprecated (and is unavailable on MacOS) and replaced with navigationTitle.

Let me revert it to keep this PR clean.

Locally, I can't get the project to build without the change:

bazel build //ios/core:PlayerUI //ios/test-utils-core:PlayerUITestUtilitiesCore //plugins/pubsub/ios:PlayerUIPubSubPlugin ... ERROR: /Users/jjessup/Documents/Code/Experiments/public/player/ios/test-utils-core/BUILD.bazel:3:13: Compiling Swift module //ios/test-utils-core:PlayerUITestUtilitiesCore failed: (Exit 1): worker failed: error executing SwiftCompile command (from target //ios/test-utils-core:PlayerUITestUtilitiesCore) bazel-out/darwin_arm64-opt-exec-ST-d57f47055a04/bin/external/rules_swift+/tools/worker/worker swiftc ... (remaining 1 argument skipped) ios/test-utils-core/Sources/ui-test/AssetCollection.swift:53:34: error: 'navigationBarTitle' is unavailable in macOS 51 | AssetFlowView(flow: flow.flow, plugins: plugins, result: result) 52 | .padding(padding) 53 | .navigationBarTitle(Text(flow.name)) | `- error: 'navigationBarTitle' is unavailable in macOS 54 | } 55 | .accessibility(identifier: "\(section.title) \(flow.name)") SwiftUI.View.navigationBarTitle:7:27: note: 'navigationBarTitle' has been explicitly marked unavailable here 5 | @available(watchOS, introduced: 6.0, deprecated: 100000.0, renamed: "navigationTitle(_:)") 6 | @available(visionOS, introduced: 1.0, deprecated: 100000.0, renamed: "navigationTitle(_:)") 7 | nonisolated public func navigationBarTitle(_ title: Text) -> some View | `- note: 'navigationBarTitle' has been explicitly marked unavailable here 8 | } 9 |

Ah, ios is not meant to be built directly like this---it will try to build for MacOS instead of iOS.

The intended ios dev process is one of these, also documented here.

// Build everything and open in Xcode (shorthand for my preferred) just dev-ios // Run the demo app from the cli with Bazel (which I basically never use except to confirm it continues to work) bazel run ios/demo:PlayerUIDemo

Make AnyType Sendable with Reflection support

598568f

JJ-Intuit requested a review from a team as a code owner January 16, 2026 02:07

JJ-Intuit and others added 2 commits January 20, 2026 13:07

Merge branch 'player-ui:main' into main

df27fad

AnyType: unit test fixes

5217754

KVSRoyal added the major Increment the major version when merged label Jan 21, 2026

KVSRoyal reviewed Jan 21, 2026

View reviewed changes

JJ-Intuit and others added 2 commits January 22, 2026 09:54

AnyType: PR review changes

f03916e

Merge branch 'player-ui:main' into main

8ef796f

		// MARK: - Backward Compatibility & Conversion Helpers

		extension AnyType {

Make AnyType Sendable with Reflection support #782

Are you sure you want to change the base?

Make AnyType Sendable with Reflection support #782

Uh oh!

Conversation

JJ-Intuit commented Jan 16, 2026 • edited by KVSRoyal Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Make AnyType Sendable with Reflection Support

Overview

Motivation

Changes

1. Sendable Conformance via Recursive Types

2. Backward Compatibility API

New Initializers

Conversion Properties

Pattern Matching Helpers

3. Reflection Support (New Feature)

Dynamic Value Access

Type Casting Helper

Subscript Access

4. Enhanced Type Handling

Test Coverage

Performance Considerations

Breaking Changes

Files Changed

Benefits

Examples

Sendable Usage

Reflection Usage

Nested Structure Access

Checklist

Related Issues

Change Type (required)

Release Notes

Old Pattern (still supported)

New Pattern (recommended)

Creating AnyType from Any

Accessing Values

Uh oh!

nancywu1 commented Jan 20, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JJ-Intuit Jan 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

JJ-Intuit commented Jan 16, 2026 •

edited by KVSRoyal

Loading

JJ-Intuit Jan 23, 2026 •

edited

Loading