Layers

The main component to create content in SwiftChart are layers. Layers conform to the protocol ChartLayer. It's probably helpful to think about layers like view controllers - they manage the model data and the presentation. The chart itself is only a lightweight container that iterates through the layers, calling methods like chartInitialized on them, when it's ready to display data, or broadcasting zooming and panning events, which each layer can decide to handle individually (more details about transform handling in View hierarchy and transforms).

Everything that is displayed in a chart is part of a layer. The axes as well as the different content types are implemented using layers. Here is a quick diagram of the layer hierarchy containing the main layers and some others, to give a rough idea:

Rendering, z-order

Layers have a lot of independence - they decide when and how to render their data. They can add subviews to the chart, or CALayers, or render with core graphics in the chart's view, or in their own added subviews... the possibilities are endless (not literally of course!). This flexibility of course enables a potential "mess" where it's difficult to predict the z-ordering of the views added by each individual layer, but it's a small price to pay and for the usual combinations of layers this doesn't cause problems (see outlook for more thoughts about this).

Just keep in mind that layers that work with subviews will always be displayed in front of layers that use core graphics on the chart view, independently of where they are in the chart layers array, and that similarly, views that are added after a delay to the chart will appear in front of views that were added previously, independently of which layers they belong to (unless the delayed views are added to a subview which was added at initialization by the layer they belong to, in which case the z order remains "correct").

In most cases you don't have to worry about this, though, if you just use the layers provided by SwiftCharts and standard layer combinations.

Custom layers

You of course can implement your own layers if you need a special kind of chart or high-level functionality not currently supported by SwiftCharts. An example of functionality where it would make sense to create a new layer would be a crosshair for the scatter chart. This requires special logic, and possibly state (e.g. a quadtree to optimize the search behaviour), which involves all the chart points. Things where you don't need a new layer, on the other side, is for example to customize the appearance or interactivity of individual chart points. In most of these cases you only have to use ChartPointsViewsLayer with a custom view generator or customize / extend one of the existing layers. The exact layer class you have to extend depends on your requirements. Looking at the existing layers is probably a good guide to figure this out.

Side note / outlook

It was mentioned before that allowing different types of rendering doesn't cause a lot of problems, but for diverse reasons a switch to a CALayer-only api seems still meaningful:

• It would facilitate making the library compatible with MacOS.
• If would make the library more consistent and simpler, by focusing only on one type of rendering.
• It would have better performance.
• There's really no reason to draw using core graphics directly on the chart's view, all this can be accomplished using CALayer, with better performance + animations.
• It would make the z-ordering more predictable.

The only contra of using CALayer is that there's no built in interaction support, so we wouldn't be anymore able to easily create interactive elements e.g. when using ChartPointsViewsLayer.

With all this in mind, an hybrid approach could make sense, where we start introducing CALayer based chart layers, which can be used in parallel to the rest (which is already the case), and focus on this. ChartPointsViewsLayer would be a handy iOS-specific "nice to have" chart layer that can be used for easy interaction or when people simply feel more comfortable working with UIView than CALayer (with the cost, of course, that custom charts created this way would not be portable to MacOS).

(Thoughts? Open an issue! There's also a task in the "improvements" project now for this).