Library name conflict with Apple Charts

[remlostime]

ℹ Please fill out this template when filing an issue. All lines beginning with an ℹ symbol instruct you with what info we expect. You can delete those lines once you've filled in the info.

Per our *CONTRIBUTING guidelines, we use GitHub for bugs and feature requests, not general support. Other issues should be opened on Stack Overflow with the tag ios-charts.

Please remove this line and everything above it before submitting.

• [x] I've read, understood, and done my best to follow the *CONTRIBUTING guidelines.

What did you do?

There's apple Charts now. If we import Charts , when does the Xcode know it's apple one or third party one?

What did you expect to happen?

ℹ Please replace this with what you expected to happen.

What happened instead?

ℹ Please replace this with of what happened instead.

Charts Environment

Charts version/Branch/Commit Number: Xcode version: Swift version: Platform(s) running Charts: macOS version running Xcode:

Demo Project

ℹ Please link to or upload a project we can download that reproduces the issue.

[waterskier2007]

Following for status updates. Personally what I did is fork the repo and then rename the library so that it didn't conflict with the native implementation.

[liuxuan30]

ok.. this sucks, @jjatie @danielgindi @pmairoldi thoughts? What would be the appropriate name now?

[danielgindi]

This is a major oversight on Apple's side. Some of their engineers are probably aware that this library exists.

Now we need some ideas regarding the naming.

Also one question- does this happen also when not adding the Swift Charts framework to the project?

[waterskier2007]

Also one question- does this happen also when not adding the Swift Charts framework to the project?

It does not occur if you do not use the Swift Charts framework

[waterskier2007]

Perhaps a name such as UIKitCharts (just off the top of my head) or something else to indicate that the implementation is in UIKit?

[pmairoldi]

I doubt someone would use both at the same time. This seems to be implemented in swift 5.7 so maybe this could work https://github.com/apple/swift-evolution/blob/main/proposals/0339-module-aliasing-for-disambiguation.md

[waterskier2007]

I doubt someone would use both at the same time. This seems to be implemented in swift 5.7 so maybe this could work https://github.com/apple/swift-evolution/blob/main/proposals/0339-module-aliasing-for-disambiguation.md

I disagree. We have a large app we support that has some "legacy" views using UIKit that have charts in them but we would also like to start adding Swift Charts to our SwiftUI views once iOS 16 rolls out. I imagine that use case could be common.

[pmairoldi]

Could wrapping these old views or new views in a framework and then importing that into your app solve this issue or would the libraires still clash?

[alanzeino]

Could wrapping these old views or new views in a framework and then importing that into your app solve this issue or would the libraires still clash?

they wouldn't clash, this is what @waterskier2007 should do in the short term; make a new framework and put your new SwiftUI views in that framework

[waterskier2007]

Could wrapping these old views or new views in a framework and then importing that into your app solve this issue or would the libraires still clash?

they wouldn't clash, this is what @waterskier2007 should do in the short term; make a new framework and put your new SwiftUI views in that framework

I've already solved the issue as mentioned above in one of my comments.

[liuxuan30]

I doubt someone would use both at the same time. This seems to be implemented in swift 5.7 so maybe this could work https://github.com/apple/swift-evolution/blob/main/proposals/0339-module-aliasing-for-disambiguation.md

I disagree. We have a large app we support that has some "legacy" views using UIKit that have charts in them but we would also like to start adding Swift Charts to our SwiftUI views once iOS 16 rolls out. I imagine that use case could be common.

moduleAliases is something we could look further, smell like a possible solution, why it doesn't work for your case? (Not yet looking deep into it)

UPDATE: oops, I take a quick look, it seems only applys for SPM, and has some pre conditions...

[liuxuan30]

This is a major oversight on Apple's side. Some of their engineers are probably aware that this library exists.

Now we need some ideas regarding the naming.

Also one question- does this happen also when not adding the Swift Charts framework to the project?

@danielgindi what odds you think if we send a request to apple to change name? I would say little

If we are the side to rename the library, a few options, ChartKit, swift ChartKit, iOS ChartKit, might a fit.. My current company named internal a lot of libraries following the UIKit AppKit fashion.

[waterskier2007]

This change could be an option. I just picked ChartKit since it seemed to make sense but it could be anything.

https://github.com/danielgindi/Charts/compare/master...waterskier2007:Charts:master

[danielgindi]

We just need a good suggestion that will be acceptable for everyone and easy enough to migrate :) We will need to rename though, no running away from it.

[waterskier2007]

My branch above has been working for for me in a project leveraging both this library and the new Swift Charts library

[liuxuan30]

then... a vote? Or you could make the call @danielgindi

[danielgindi]

then... a vote? Or you could make the call @danielgindi

I think we need some ideas before we vote :) ChartKit sounds more like an Apple kit (I would expect their library to be named ChartKit..., not ours!) Any good ideas here?

[waterskier2007]

• ChartsKit
• ChartsUI

Those seem like the two most viable options and since there was objection to ChartKit sounding too Apple-ish, why not just ChartsUI?

[liuxuan30]

then... a vote? Or you could make the call @danielgindi

I think we need some ideas before we vote :) ChartKit sounds more like an Apple kit (I would expect their library to be named ChartKit..., not ours!) Any good ideas here?

I have filed a radar to request a rename, but no update yet.. and likely will not have in the near future

[danielgindi]

I'm thinking UICharts

[PiotrSzmyt]

Do we know maybe when this rename can happen? (I am using lib via cocoapods)

[waterskier2007]

@danielgindi would you like me to update my PR to include the podspec change or are you wanting to rename directories and source files as well?

[danielgindi]

@danielgindi would you like me to update my PR to include the podspec change or are you wanting to rename directories and source files as well?

Every PR should contain a very specific change. Otherwise it's impossible to properly review.

I guess I'm waiting for a bit more participants here. If there are no other good ideas then we'll rename to UICharts very soon and bump a major version.

[waterskier2007]

Absolutely. What I meant to ask was if you wanted to perform any other changes such as source file names or directories that were specifically related to the name change.

[waterskier2007]

@danielgindi what are your thoughts now that Xcode 14 & the new SDKs are live?

[superz515]

Same problem here. Need to import both Charts modules for compatibility. Any updates? How soon should we expect the renaming?

[superz515]

How about "ICharts"? "I" stands for "iOS". Although it still sounds Apple-ish.. Or maybe "OpenCharts"?

[pmairoldi]

I get that it’s sucks that it doesn’t “just work” but can’t you just put this library in your own framework target and expose your own namespace. It seems like most people who have this problem are trying to migrate to swift ui charts in the future but don’t want to do it all at once.

[waterskier2007]

I get that it’s sucks that it doesn’t “just work” but can’t you just put this library in your own framework target and expose your own namespace. It seems like most people who have this problem are trying to migrate to swift ui charts in the future but don’t want to do it all at once.

That's completely doable but that seems like a pretty big backtrack from the prior conversation. There are certainly many apps that will utilize both UIKit and SwiftUI for the foreseeable future, especially given that Swift Charts can only be fully adopted if the minimum deployment is iOS 16.

[pmairoldi]

I am not saying we are not gonna rename. It’s just for now I don’t have the time to do it. Just proposing alternatives to people ending up on this thread.

[superz515]

I get that it’s sucks that it doesn’t “just work” but can’t you just put this library in your own framework target and expose your own namespace. It seems like most people who have this problem are trying to migrate to swift ui charts in the future but don’t want to do it all at once.

Oh I'm not pushing. I just saw @danielgindi said we are going to rename soon and asked for more proposals, so I'd like to offer my ideas and ask when it will happen.

[getmonyinfo]

please update the package name, it's 3 months after the discussion

[DevboiDesigns]

Any idea when this might be renamed?

It seems like iOSCharts is the most common search term. Might be a good name

[edbarbier]

any update on this? I'm also using both Charts & Swift Charts in a project and this is blocker at the moment.

[Daniel-Berezhnoy]

@danielgindi UICharts seems like a good name. Would also like to know when the renaming will happen!

[Daniel-Berezhnoy]

For anyone still struggling to find a solution, this StackOverflow answer worked for me!

That is if you're using Cocoapods. Haven't found a way to make this work with SPM. Couldn't figure out how to use Module Aliasing

[waterskier2007]

Any update here @danielgindi @pmairoldi

[Daniel-Berezhnoy]

Any update here @danielgindi @pmairoldi

Doesn't seem like it :(

[waterskier2007]

@danielgindi and @pmairoldi I am fine to PR the change, I just want to know what the scope should be. I can just make the change to the Package.Swift and the directories as well, but there was some objection to my prior PR that included such a scope.

[waterskier2007]

https://github.com/danielgindi/Charts/pull/5009

[zygoat]

This is a major oversight on Apple's side. Some of their engineers are probably aware that this library exists.

Seems like a bit of an ebullient and wishful statement. Are Apple expected to survey the entire third-party landscape and abstain from ever naming a framework similarly?

I'm thinking UICharts

In my opinion that is not a great name either. I use Charts on Mac (AppKit), for which it's also designed—it's a purposefully cross-platform framework. Besides that, “UI” is not particularly descriptive or unique. Better might be “GindiCharts”, or even “AndroidCharts” (in view of its lineage).

[xjki]

@danielgindi UICharts seems like a good name. Would also like to know when the renaming will happen!

Please don't use UI as prefix, as it is already default prefix for UIKit classes

[pmairoldi]

Closed by #5027