Charts
Charts copied to clipboard
danielgindi
Library name conflict with Apple Charts
ℹ 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.
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.
ok.. this sucks, @jjatie @danielgindi @pmairoldi thoughts? What would be the appropriate name now?
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?
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
Perhaps a name such as UIKitCharts (just off the top of my head) or something else to indicate that the implementation is in UIKit?
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 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.
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?
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
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.
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...
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.
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
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.
My branch above has been working for for me in a project leveraging both this library and the new Swift Charts library
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?
- 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?
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
Do we know maybe when this rename can happen? (I am using lib via cocoapods)
@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 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.
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.
@danielgindi what are your thoughts now that Xcode 14 & the new SDKs are live?
Same problem here. Need to import both Charts modules for compatibility. Any updates? How soon should we expect the renaming?
How about "ICharts"? "I" stands for "iOS". Although it still sounds Apple-ish.. Or maybe "OpenCharts"?
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.
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.
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.