> - Small number of y lines, only 3 that have values, by design you should always have 6 (1.jpeg).
This depends on the y-label displaying logic. I described mine above and also why I thought this one is the best one. When there's enough scale to display more labels between current ones they will be displayed. The only config I have is max number of labels displayed – 6.
As for the design requirements, I don't agree you can infer any logic just from it – there are just some static shots or simple transitions and they don't say much about the exact y-labelling scheme. What I actually inferred from the designs is that it's preferable to use algorithm always producing 'nice looking' numbers for the y-labels. The logic I use does exactly that and I haven't seen yet another app achieving the same (though I checked just a few other apps)

> - Charts do not always start at min value line they are supposed to, which leads to a lot of unused screen real estate (2.jpeg)
Contrary to most (all?) other apps I chose to use 'synchronous' y-scaling depending on the visible x-range.  To me this provides a lot of benefits and feels a lot smoother/slick. But you have to apply some additional logic to make this synchronous scaling work smooth when there're are significant 'jumps' in y data points. So when the visible range is close to these 'jumps' the chart won't fill the whole viewport to make the transition smoother. Kinda hard to explain but easy to understand when you scroll left-right from this position :)

> - When graphs are right under y values, it makes reading those values pretty hard at times. (3.jpeg)
Valid concern in general but it feels like more of a design problem to resolve. I didn't have great ideas how to fix it easily and on the other hand wanted to stay as close to the provided design as possible.

> - The value 750 200 should be directly on or slighlty above the 750k line, on the screenshot it is slighly below (4.PNG)
Lines are always 1px (not points) to match designs as close as possible. They are rendered at exact pixel boundaries to avoid antialiasing issues. The bottom edge of the line is the actual value it represents (750k in that case). With all these limitations I think it's impossible to render this case better. I mean this case would look better if I chose to have top edge to match the exact value instead of the bottom one, but that would have same problem for the 749 800 value.