TapticEngine - native extension for iOS Taptic Engine


Here is a tiny extension which provides API to call iOS native Taptic Engine feature: https://github.com/MaratGilyazov/def_taptic_engine

It provides “Haptic feedback”, kinda soft vibrations, works on devices starting from iPhone7.

if (taptic_engine and taptic_engine.isSupported()) then


Tested under Mac, Editor 1.2.158 on devices: iPhone XR, iPhone7 and iPhone5 (there is no Taptic engine here).

I’d appreciate any feedback regarding API, implementation code and usage.




Wow, fantastic! Had this on my personal list of exploration ideas, great submission to the community! :smiley:



This is great, thank you :space_invader:
You should definitely add this to asset



Done: https://www.defold.com/community/projects/149233 :wink:



Can anyone test it on iOS lower than 10.0 ?

1 Like


As I understand this is your first Native Extension for Defold?
What do you think about the process of NE creation? (It was hard? Did you have any difficulties?)



@marat.giliazov I added a very simple example GUI in the project, created a PR for it here: https://github.com/MaratGilyazov/def_taptic_engine/pull/1

Will try on a few devices with lower OS versions.

edit: Tried it on two devices now, taptic_engine.isSupported() reported false on both of these. Trying to call any other function that would cause a taptic response (impact, notification or selection) crashes the engine. Might be a good idea to check isSupported internally as well so that these functions would exit early if there isn’t any support instead of crashing. :+1: Tried it on these devices:

  • iPhone 5s (iOS 8.3)
  • iPhone 4s (iOS 9.3.5)


PR is approved and merged, thanks!

And thanks for testing on lower iOS devices - I’ve added internal checks for “isSupported” before calling actual taptic APIs. There are no warnings or returning error codes, but it is ok as is, I believe. At least it should not cause crashes now.

1 Like


Yes, it was my first extension for Defold, but I’ve had some little experience with writing such native plugins for Adobe AIR and Unity - in general the approach is pretty the same, you need to make a “bridge” between native code and engine code.

I’ve spent about 5 hours from googling “defold native extesion” to having first impact-vibrations on my device, using the first iteration of the extension, so the process was pretty smooth. I was expecting more issues and spending 2-3 days just to make it to work.

Good part - having lots of ready extensions with open sources, so I was looking and getting different parts from defreview, vibration, admob extentions and looked through few others. Plus for iOS part I’ve looked at pretty the same plugin made for Unity.

Bad part - I felt some lack of documentation. Looking at other solutions is ok, but in general I was not really understanding what am I actually doing.

For example - there is DM_DECLARE_EXTENSION(EXTENSION_NAME, LIB_NAME, AppInitializeTaptic, AppFinalizeTaptic, InitializeTaptic, 0, 0, FinalizeTaptic) line and I have no idea what it does and why in some extension there is “Update” function and in others there is “0” (I’ve tried both and nothing changed).

Or when I wanted to use constants like “taptic_engine.IMPACT_LIGHT” I just looked through different extension’s sources to find such thing and did not find such instructions in docs.

Or getting parameters via luaL_checkint(), luaL_checkstring() - it’s not obvius how this works, what is the “stack” in this circumstances etc.

Maybe I missed it in docs, maybe it’s obvious things for C++ developers, but anyway - if I was able to make it work just in 5 hours, then I believe everything is pretty enough to make your own extensions :slight_smile:

I think adding some additional paragraphs like “if you want to get parameter, use this API”, “if you want to declare constands, do this”, “if you need to return value - do this, and if your method is void - then do this” etc might be helpful.



This is a personal preference but I’m posting it here anyway: I really don’t like the mix of camelCase and snake_case. I would prefer one or the other. And when it comes to Lua and Defold I recommend sticking with existing naming convention as Lua and Defold uses, ie snake case.




Heh, in my game code in Defold I use uderscores, but I saw camelCase somewhere in other extensions and this shattered my principles :slight_smile:

Not sure if it’s good idea to change API now, but I’ll remember this for future

1 Like