haptics_kit

Haptic feedback for DartNative apps, with the haptic_feedback package's API, so code written for it ports by changing one import:

// import 'package:haptic_feedback/haptic_feedback.dart';
import 'package:haptics_kit/haptics_kit.dart';

Nine types — success, warning, error, light, medium, heavy, rigid, soft and selection — on iOS (UIKit feedback generators) and Android (Vibrator / VibrationEffect, optionally HapticFeedbackConstants). It is a pure-FFI plugin: no view, no method channel, no callbacks into Dart.

Why this package

DartNative's built-in HapticFeedback has only light/medium/heavy impacts, selection and vibrate, and it does nothing on Android. haptics_kit adds the notification types (success, warning, error), rigid and soft, canVibrate, and a real Android implementation that follows the iOS patterns.

iOS	Android

Install

dependencies:
  haptics_kit:
    hosted: https://dartpub.dev
    version: ^0.1.0

dn pub get

dn pub get adds the plugin to lib/dartnative_plugin_registrant.dart. main() needs only the usual first line:

void main() {
  DartNativePluginRegistrant.registerAll();
  runApp(const HomeScreen());
}

Platform setup

• iOS: nothing. No Info.plist key; the pod links UIKit and CoreHaptics. Minimum iOS 15.

• Android: nothing to add by hand. The plugin's manifest declares

  <uses-permission android:name="android.permission.VIBRATE" />
  

  and it is merged into your app. It is a normal install-time permission, with no runtime prompt. Minimum API 24.

Use

import 'package:haptics_kit/haptics_kit.dart';

final canVibrate = await Haptics.canVibrate();
if (canVibrate) {
  await Haptics.vibrate(HapticsType.success);
}

// Android only: route through VibrationAttributes (API 33+), or prefer the
// system's HapticFeedbackConstants where one fits.
await Haptics.vibrate(
  HapticsType.heavy,
  usage: HapticsUsage.media,
  useAndroidHapticConstants: true,
);

vibrate throws HapticsException (code is unavailable, unknownType or nativeError) when the native side is missing or fails. A helper that caches canVibrate() and catches everything is the usual app-side wrapper.

What happens where

With useAndroidHapticConstants, success/error map to CONFIRM/REJECT (API 30+), light to VIRTUAL_KEY, medium to KEYBOARD_PRESS, heavy to CONTEXT_CLICK and selection to CLOCK_TICK; warning, rigid and soft, or no resumed activity, fall through to the vibrator. Some OEM builds mute USAGE_UNKNOWN vibrations when touch haptics are off; pass usage: if that matters.

Example

example/lib/main.dart has one button per type, canVibrate, "Play all", and on Android the constants switch and a usage picker.

cd example && dn pub get && dn run

Differences from haptic_feedback

• HapticsException replaces PlatformException / MissingPluginException.
• No platform interface; tests set Haptics.debugBackendOverride to a HapticsBackend fake instead.
• iOS 15 minimum, so the pre-iOS-13 fallbacks and the private _feedbackSupportLevel lookup are gone.
• Android: soft falls back to TICK on API 30 (upstream's check made that fallback unreachable), and the on/off waveform uses VibrationEffect on API 26+.

Credits & license

• haptic_feedback 0.6.5 by Joachim Nohl, BSD-3-Clause. It is the source of the API and its docs, the iOS type-to-generator mapping, and the Android patterns (timings, amplitudes, primitives, HapticFeedbackConstants mapping) and fallback chain. They were reworked from method channels to FFI; those portions stay under BSD-3-Clause.
• This package's own code: MIT, see LICENSE.
• Full notices are in THIRD_PARTY_NOTICES, which ships with the package.