Source code for this contest can be found at https://github.com/alexvasilkov/TelegramChart

Indeed, thanks for reporting.
The values themselves have uniform distribution, it is a rounding issue introduced by labels formatter. This is how it looks without formatter:

Indeed, missed this part, thanks for reporting

Agree, should be hidden in this case

Thanks for reporting! This is what we actually have in provided data, I didn't apply any data fixes in the chart widget.

Same as above, this is what we actually have in provided data and the chart is showing it as is.

Thanks for noting, indeed, there is no state restoration. But most of other contestants don't have landscape orientation at all, so I could just lock the app into portrait.

Hm, that's unfortunate, works fine on all my test devices, strange to see such issues on a modern device. There is definitely a room for optimizations here.

I want to note, that the charts themselves should work smoothly on this device as well (I would expect you to create a dedicated issue if it wasn't a case), so only the transition for bonus part may lag on some devices.

Thanks! I was considering adding this "point run" animation, but it also requires a proper snapping animation which would take much more time, so it was in my low pri features list. Otherwise showing intermediate points leads to invalid data presentation as can be seen in other apps.

* Last line disabling: This is intentional, imo it isn't nice to disallow users doing something.

* Labels animation: I was considering adding it, but didn't find a good way to animate only some of date parts as in mocks, since their sizes are constantly changing and adding static gaps looks bad, e.g. check app #128 ;). Also too much animations does not make the app look "slick", imo.

* Sliding points: That's true, it was in my list but with low pri, and I didn't have enough time for it after all.

* Separate line: In chart #2 I applied a static multiplier to scale both charts in the same way. Otherwise they should better be shown using separate chart views.

* Last chart performance: As of my testing (checked about 25% of the apps on Nexus 5 now) it has one of the best performance out there.

* 101% in label: There is no good way to round percents but keep 100%. E.g. [49.(6)%, 49.(6)%, 0.(6)%]. It is better to show individual values correctly than struggling to have 100% in total.

Indeed, thanks for reporting. I'm testing on Nexus 5 as well and somehow I don't see such a problem. But it is definitely a bug.

You are right, but when showing full months names they are getting truncated when shown in ranges, so this was a consiuos decision.

Thanks for reporting, but it seems to be a duplicate of issue reported by Kingly Boar above.
The problem here is that some of the provided data (e.g. for Apr 16 and App 18) is incomplete and can start e.g. with 4:00 instead of 0:00, it makes x labels distribution looks quite random for such dates.
Note though, that there are only a few such broken dates, other dates should look fine, see attached screenshot.

Confirm, seems to be an issue when right range selector is in the right most position under pie chart, in other cases it should work fine.

Yes, but it was not a strong requirement from Telegram:
"Note that you are not expected to implement the zooming transitions exactly as shown in the video demonstrations. They may be replaced with any slick and fast transition of your choice."

I'm using a system date formatter which respects month position for your locale (US I suppose?). So "Dec 7" is a correct format for your locale but "7 Dec" is not. You can check how it will look with e.g. Russian locale.

Hm, I'm using a system time formatter which respects your 12h / 24h setting, and it seems like you have 12h format enabled. Though status bar shows time in 24h format and it is strange indeed.

Thanks. This is a labels rounding issue (similar issue is already reported), looks like the actual value for Y grid is around 1470, so 1490 point is shown above, but then the label is rounded to 1500.
I agree that it should not work like this, labels rounding should be synchronized with grid step rounding logic.

Hm, your screenshot shows that performance is not an issue actually, I don't see high GPU bars there.

Last chart performance is tricky (as you can see in other apps) and you actually found one of my secret optimizations here: I'm reducing drawing qaulity during animations. Good thing is that you won't notice it without magnifier, and once all the interactions are finished the chart is cristal clear again. So it is more like an advantage than an issue in my opinion :)