dartnative

Dependencies

Dependencies come from dartpub.dev, the developer hub. It carries your account and subscription, the first-party plugins, and everything the community publishes — and every published version stays archived, so a dependency can never disappear from under a shipped app.

dependencies:
  dartnative_supabase: ^0.1.0
  dartnative_revenuecat: ^0.1.0
  dartnative_notifications: ^0.1.0

Fetch them with dn pub get.

What’s on the hub

  • First-party plugins — the native surface, maintained like a product: camera, video, audio, webview, maps, notifications, purchases, storage, on-device AI. Browse them on dartpub.dev.
  • Community plugins — published with one command, discoverable in the same registry, versioned and archived on the same terms.
  • Pure-Dart packages — no native code required. They ship as a Dart-only tarball: no xcodebuild, no macOS, nothing to compile.

That last point is worth knowing if you maintain a package: a pure-Dart package is as welcome on the hub as a native plugin, and publishing one puts it in front of every DartNative developer, with versions archived permanently.

Publishing your own

Once a plugin is registered, publishing is one command:

dn plugin publish

Two things come back to you for it:

  • Production adoption discounts your framework subscription the more it’s used, scaled by how widely the package is actually used in shipped apps.
  • The Contributor badge, the same title the core team carries.

See the publisher guide for registration and the full flow, or the licence page for how adoption is counted.

Also supported: pure-Dart packages from pub.dev

Pure-Dart packages from pub.dev are supported as well, and work unchanged — no fork, no patch, no wrapper, same version constraints:

dependencies:
  # from dartpub.dev
  dartnative_supabase: ^0.1.0

  # from pub.dev — pure Dart, unchanged
  dio: ^5.7.0
  uuid: ^4.5.1

The rule is simple: if a package doesn’t import package:flutter, it just works. In practice that’s most of what an app depends on — http, dio, mqtt_client, uuid, crypto, intl, collection, equatable, get_it, bloc (the core package — flutter_bloc is the Flutter-bound one), solidart, logger and path all work as they are, along with the long tail of parsers, formatters and utilities.

When a package doesn’t work

The boundary is Flutter’s plugin mechanism. Flutter plugins reach native code through platform channels, which the DartNative Zero engine doesn’t support — it calls native code directly over FFI instead. A package built on MethodChannel won’t compile, and neither will one that imports package:flutter.

Two ways forward:

  1. Use the hub equivalent. Most Flutter packages you’d reach for already have one: path_provider, shared_preferences, permission_handler, share_plus, connectivity_plus and webview_flutter all have dartnative_ counterparts with the same API surface, so the change is usually the import line.
  2. Port it and publish it. The plugin API is FFI rather than platform channels — the build a plugin tutorial walks through it end to end.