Redundant conformance of 'Color'

[blackyhn]

Hello, I'm getting error when triyng to extend the SwiftUI.Color because of the Color struc extension.

"redundant conformance of 'Color'"

Thanks in advance!

Check these before submitting:

• [X] The issue doesn't involve an Unsupported Feature
• [X] This issue isn't related to another open issue

This issue is a:

• [X] Non-Crashing Bug (Visual or otherwise)
• [] Crashing Bug
• [X] Feature Request
• [] Regression (Something that once worked, but doesn't work anymore)

What Platform are you on?

• [] MacOS
• [X] iOS

What Language are you in?

• [X] Swift
• [] Objective-C

Expected Behavior

I expect to extend SfiwftUI.Color wihtout issues.

Actual Behavior

I'm getting the "redundant conformance of 'Color'" error because of the extension of the Color struct.

[erwinmaza]

It's not just Color that's an issue, there are several structs defined in lottie-ios that share a name with SwiftUI structs. This is a problem for any project using this library and extending SwiftUI primitives.

For now I've worked around this issue by adding this to my project:

extension View {
	// resolve naming conflicts with dependency libraries
	typealias Color = SwiftUI.Color
	typealias Group = SwiftUI.Group
	typealias Animation = SwiftUI.Animation
	typealias Rectangle = SwiftUI.Rectangle
}

and I keep having to add to this list as I build out my app's infrastructure.

Despite this, I've also had to explicitly use the SwiftUI namespace in some files, like so

extension SwiftUI.Color {
	static let myColor = SwiftUI.Color([my custom color])
}

But this should not be necessary. A longstanding best practice for libraries is to "namespace" their custom objects by prepending them with a custom identifier, usually the library or author's initials. So, for example, lottie-ios Color should be renamed LTColor or ABNBColor or similar.

As SwiftUI gains adoption in more complex production apps, these name conflicts will become more of a problem, and will increasingly be a barrier to adopting this library and Lottie in general. Please consider renaming all your public primitives.

[calda]

Renaming these public types would be a breaking API change, so we would need to do it in a Lottie 4.0.0 release. I started a discussion about this here: https://github.com/airbnb/lottie-ios/discussions/1713

[calda]

Do Lottie.Group and Lottie.Rectangle actually cause issues in SwiftUI projects? Those types are internal.

[liudhzhyym]

Any new progress on this issue? I have face same problem when I use lottie-ios in SwiftUI project

[calda]

@erwinmaza We're renaming Color and Animation, since those types are public. I see you mentioned Rectangle and Group as well, but those types are internal. Are you encountering conflicts from those types? If so, could you share a piece of sample code?

If this is causing a problem we'd like to also fix it in Lottie 4.0, which we are releasing in a few weeks.

[erwinmaza]

I'm incorporating the library as source code in my project (I prefer full source control and stability, plus I've customized it a bit), so internal is visible to the rest of my app.

As an aside, I moved from the typealias solution to renaming the types in the source files myself.

Great to hear that 4.0 is coming out soon. I've had "Update Lottie to 3.4.0" for the performance improvements in my backlog for awhile. Now I'll just wait for 4.0 so I don't have to rename things again.

Thanks for addressing this issue.

[calda]

I see, thanks for the info -- I think I'm going to leave them as-is for now. Since those types are internal we can rename them in the future without breaking source compatibility, we don't need to make that change specifically in Lottie 4.0.

[calda]

We made the first step towards resolving this issue in Lottie 3.5.0. We will fix the issue completely in Lottie 4.0.