Brendan Kirchner

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.

> 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...

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 disagree. We have a...

> > 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? >...

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

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

* 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?

SPM support would be excellent, given the first class support for SPM in Xcode 11

@gonzalezreal with the change merged and released in 1.0.1, should this issue be closed?