Build failure after upgrading to Rive iOS 6.15.0 due to boolValue property name collision

[smilesiosteam]

After upgrading Rive iOS SDK to version 6.15.0, my project no longer builds.

It appears the SDK introduced a property named boolValue, which conflicts with an existing Foundation API (NSString.boolValue). This results in ambiguous or conflicting symbol usage during compilation.

Property introduced in Rive SDK:
/// The boolean value (valid when type is boolean). @property(nonatomic, readonly, nullable) NSNumber *boolValue;

Existing Apple Foundation API (already used in project):
@property (readonly) BOOL boolValue API_AVAILABLE(macos(10.5), ios(2.0), watchos(2.0), tvos(9.0));
Because both properties share the same selector (boolValue), the compiler fails when resolving references, causing the build to break after the upgrade.

Expected Behavior

Upgrading the Rive SDK should not break existing projects or introduce naming conflicts with long-standing Foundation APIs.

[dskuza]

Can you share a screenshot of the error you're seeing? That boolValue property exists on a subclass of NSObject; it shouldn't interfere with any other function definitions, especially Foundation types, depending on how it's being used / clalled. How are you using Foundation's boolValue? At first glance, I don't see why the compiler would suggest they're conflicting, unless used in such a way where boolValue is being called on the equivalent of id. I do want to acknowledge that, yes, Foundation does have a boolValue function.

It'd also be great to know what version of macOS you're running, and what version of Xcode you're using.

I have not yet encountered this issue, but this is definitely unintended behavior, and is something that could be addressed. I'm a little surprised to see this issue, given that it's an internal helper type, but I think I understand why. I'd like to see if this is something that can temporarily be (temporarily) mitigated on your end.

Additionally, is this happening in a minimal reproduction?

[dskuza]

Just following up. I refactored the code path that utilizes that internal helper and ended up removing it, so there should be no more collision in an upcoming release.