Native Touch has been discontinued

It's been a long ride. Native Touch has been around since April 2018, started at the same time as Native Audio for my own game. Many of Native Audio's research notes still link to this page, so I think it is a good idea to leave this behind what finally leads me to this decision.

But first, I sincerely thank you all for the bug reports and supports so far. There are so many bugs left over to production that I feel like there is no version without a hotfix 2 days after if not for you all that reminds me about it.

Sirawat Pitaksarit / 5argon, Exceed7 Experiments (26/11/2019)

Reasons for Native Touch

I made Native Touch personally in order to get back a real hardware touch timestamp because Input API removed them. The second reason is maybe, I will try leaving a callback function at native side that calls to C# for fun and see if I could combo with Native Audio. You can imagine a touch that immediately sounds, out of normal frame flow.

I go check the built project on iOS and Android to look, only to find the data from input originating function pouring straight to Unity's internal, closed codebase without any more explanation.

I was left with nothing but just pray that they came out the C# side's Input API, as fast as possible, as complete as possible, as correct as possible, etc. But I can never make sure as long as this black box is in the way.

I made an effort to lay down a sneaky portal at native side so that MotionEvent and UIEvent could surface at C# side to read back. This is by using UIGestureRecognizer on iOS and OnTouchListener added to the main view on Android.

I did, and I recovered the touch timestamp in order to faithfully judge my player's input!

I even found out according to this clip that became an extra selling point for Native Touch, that thanks to Android's off-main thread touch processing, the callback can even race and win before Unity's input appear at Input API, before the graphic submit of the previous frame. This make it even possible to make a difference visually.

Decision to put on the store

I was excited so I put Native Touch on sale as maybe someone want to go this far for micro-optimization as me.

Get back touch timestamp. (main point, personally)
Sometimes callback make a frame difference. (bonus)
Even if it didn't make a frame difference, the data is more complete. In Input API, the data clearly disappeared or summarized in an unknown way. You can get and process all the data manually. (bonus)
Have access back to OS specific quirks that Unity unified. For example, only in Android you can get the touch's "ellipse" area (not just circle) with getTouchMajor and getTouchMinor? On iOS no such thing exists, but you can get tapCount to detect double-tap, triple-tap natively which is not available on Android. (bonus)

I did all of it despite I only want the first one for myself, so it feels more like a complete package that benefits wider audience.

Android's move to 64-bit only

The first catalyst for this decision is that Android can no longer be submitted with Mono build from mid-2019. On IL2CPP, the frame advantage as shown in video is not possible anymore as the timing vs. render call is different at native side. (Sometimes the result is even different depending if you select GL2, GL3, or Vulcan.)

And also IL2CPP in Unity has problem about native-to-managed call that it is very slow. One of my user "schwarzer" dig in and found that in C++ IL2CPP code there is a costly thread switching code, an after product that Android input thread is not the same as the game thread.

Anyways for me personally Native Touch was all about getting back the timestamp, and that is still an advantage. So I still keep maintaining the plugin around at that point. Though it is getting difficult to instruct that Mono can do this, IL2CPP can't do that, etc. That I don't really care since I still get my timestamps.

Unity's New Input System

This package was under painfully slow development since around 2015? But at the previous Unite Copenhagen finally a preview of 1.0 release appeared. I was aware of this since long ago and evaluated it from time to time, but the Touchscreen module wasn't ready until now.

I evaluate it again and honestly it has everything I want, mainly, the touch timestamp. Not only that, it has the same write data read data approach as my hacks in Native Touch. You can even turn on manual consume mode, that if you do not consume event for a period of time then a buffer discards old one progressively. This is exactly like the "ring buffer iteration" implemented in Native Touch.

New Input System promises open code base and extensibility. I did look at it for real and it goes very deep to buffer level in namespace UnityEngine.InputSystem.LowLevel. The black box that was bothering me so much I made Native Touch is no longer there. Unity is changing, towards UPM-based design codes are more and more visible. Sometimes things like Scriptable Rendering Pipeline is even better than completely open engine source code, since you can safely edit within its reasonable limits.

The only thing missing is that it has a Preview badge, which is to be removed in 2020.1. But I am sure I don't want to maintain Native Touch when I can use the new Input System when it is out of preview.

But what about other remaining benefits? For instance, it is still a fact that Native Touch could return raw, original OS touch data, and Input System still has some more processing to them. This leads to my personal work ethic reasons.

I do not want to distribute what I don't personally use

My creations : Introloop, Native Audio, Notch Solution (open sourced), etc. are all active in my projects. I learned along the way that I was very motivated to fix every bit of bugs reported to me via e-mail or Discord, not because they made income, but because they would eventually affects my game.

When I know a much more successful game than mine was using Native Audio, I was genuinely very happy and confident at the same time. The reason because I dogfood it. My game code runs through it all day, if something breaks I would have known by now.

And I was even having fun because it didn't feel like a chore. Even the free Notch Solution which do not have monetary incentive to do so, the fact that it ties to my games make me motivated to keep improving it.

Native Touch is the first plugin to fall into this "out of personal use" state.

In fact I have been thinking since I saw the Copenhagen talk in October, but I was not sure how to feel or think because it hadn't happen before. Now I am quite sure of my feeling that I definitely do not want to maintain a product in this state, regardless of its remaining benefits.

Why now?

Technically I can keep quiet about this or wait until Input System came out in 2020 and discontinue there, so I get some more income from the person who didn't know what's coming. (That sentence already feels wrong, right?)

It just doesn't feel right to keep distributing bad product, even if it is not that bad right now.

Though I know some very popular products from the past that was superceded by various things at present day, but its popularity still attracts new purchases and they still have their non-overlapping use. It make sense to continue maintaining them. (Some has compatibility back to like Unity 5, it's crazy!)

I could use the same approach as them and try to shift the focus of Native Touch from touch timestamp & frame advantage, to be a plugin for accessing raw touch data (as you can see the motto on top of this page, I was in-progress of fighting with myself whether to keep or not to keep), but my inner says louder that I don't want to use Native Touch. Therefore I don't want to pretend to proudly distribute Native Touch.

It's better think of the user like yourself. I would like to tell my user to learn and try the Input System if you want the timestamp. If you were looking for other benefits of Native Touch that is not a timestamp, I am deeply sorry that I can't provide continued support for those.

What about my purchase?

According to section 8 "Asset Takedowns" of Asset Store Provider Agreement, you can keep using the final version (4.1.0) that you have as much as you like according to Unity's license agreement and you still have my full support of that version. Feel free to e-mail to 5argon@exceed7.com or come to Discord.

The future of the source code

It is very interesting to just release them as an open source via GitHub now that I decided to discontinue it from Asset Store. But the state of it is so bad, I don't have opportunity or motivation to polish them up to be open sourced right now either.

I know from Notch Solution that an open source project requires even more discipline, so I afraid this is not possible right now.

Legacy site

I have uploaded the previous website on a new URL root : https://exceed7.com/native-touch-archived

It still contains crazy research like in that "Callback Details" section, I am still proud of what I found that all leads to Native Touch's development.