The Wiredash Flutter SDK adds in-app feedback and NPS surveys to an app in three minutes

The integration model is one wrapper widget

Wiredash is an interactive user feedback tool for Flutter, and the entire integration model is that your root widget becomes a child of a Wiredash widget.

The README's pitch is that it takes less than 180 seconds to integrate, and the mechanism it uses is the simplest possible one. You import the package and wrap the root of your app:

import 'package:flutter/material.dart';
import 'package:wiredash/wiredash.dart';

class MyApp extends StatelessWidget {

  @override
  Widget build(BuildContext context) {
    return Wiredash(
      projectId: 'YOUR-PROJECT-ID',
      secret: 'YOUR-SECRET',
      child: MaterialApp(
        // Your Flutter app is basically Wiredash's direct child.
        // This can be a MaterialApp, WidgetsApp or whatever widget you like.
      ),
    );

  }
}

Two fields are required, the projectId and the secret, and both come from the Wiredash console under your project settings. The comment in the example is worth noting because it tells you how flexible the wrapper is: your app is Wiredash's direct child, and that can be a MaterialApp, a WidgetsApp or whatever widget you like.

That is the whole design decision. Rather than a service locator, a plugin registration, a custom navigator or an overlay you have to insert into your tree, the SDK inserts itself above your application and does its work from there. Anything inside your app can then reach it through the widget tree.

The features the SDK provides are three, and the README lists them in order. Real-time analytics, described as GDPR-compliant and hosted in the EU. Capture of in-app user feedback, with screenshots and tags. And scheduled promoter score surveys, which can be scheduled and automated.

Behind those sits the console, a dashboard for accessing your feedback and analytics.

Because it is written in Dart and is a Flutter package rather than a platform plugin with native code, the compatibility claim is broad: Android, iOS, Web, macOS, Windows, Linux, and IoT.

Setting it up: a dependency, a console project, two identifiers

The setup has three parts and the first one is an account.

You start at the Wiredash console and create your free account using Google or GitHub, or you request an email sign-in link. Then you create a project with a descriptive name, and that project is what the SDK identifiers belong to.

The dependency is added the standard way, and the README gives both forms. The command:

flutter pub add wiredash:^2.7.0

And the equivalent pubspec entry:

dependencies:
  flutter:
    sdk: flutter
  ...
  wiredash: ^2.7.0

Note that the version the README instructs you to install is 2.7.0, while the release history in the repository listing ends at v2.6.0 from October 2025. So the documentation is written against a newer version than the latest tag the listing shows, which is worth knowing if you pin strictly to what you can see.

The two identifiers, the projectId and the secret, come from the console path Your project then Settings then General Settings. The secret is a shared secret embedded in your app binary, which is the standard shape for a mobile SDK that identifies your project, and it is also the thing to think about when you review what the package does with it.

The package itself lives on pub.dev as wiredash, with the homepage at wiredash.com and the documentation at docs.wiredash.com. The repository's default branch is stable, which is the convention for a published Flutter package that keeps its release line separate from development, and the repository carries a CHANGELOG.md, a RELEASE.md, a CONTRIBUTION.md, an analysis_options.yaml and both an example/ and an examples/ directory.

Two calls reach the whole feature set

Once the widget is in place, everything is reached through Wiredash.of(context), and there are two entry points documented in the README.

The feedback flow:

FloatingActionButton(
  onPressed: () {
    Wiredash.of(context).show(inheritMaterialTheme: true);
  },
  child: Icon(Icons.feedback_outlined),
),

And the promoter score survey:

FloatingActionButton(
  onPressed: () {
  Wiredash.of(context).showPromoterSurvey(force: true);
  },
  child: Icon(Icons.feedback_outlined),
),

Both are shown as a floating action button, which is the point. The feedback flow is something the user triggers, and the widget sits inside your own app so the flow appears over your own UI.

Two parameters deserve a note. The show call takes inheritMaterialTheme, which makes the feedback UI adopt your app's theme rather than the SDK's, which is what stops a feedback overlay looking like a different application. The showPromoterSurvey call takes force, which bypasses whatever targeting or scheduling logic decides whether to show a survey to this user at this moment. That force flag is the one to be careful with: it is the difference between a survey that respects your targeting rules and one that appears on demand.

For the promoter score specifically, the README's feature list says surveys can be scheduled and automated, which means the SDK can decide when to ask rather than only asking when you call it. So the force parameter is for testing and for manual invocation, and the scheduled path is the one a product would normally use.

The README points at two example directories for the fuller picture, examples/theming for the feedback flow and examples/promoter_score for the survey, plus the documentation pages at docs.wiredash.com for the feedback and promoter score references.

The hosted console is the product, and the free tier is the boundary

What Wiredash provides is not just the in-app widget but a hosted service around it, and that is where the trade-offs live.

The analytics are described as real-time and GDPR-compliant, hosted in the EU, and the console at wiredash.com/console is the dashboard for both the feedback and the analytics. So the model is a software as a service product with an open source client SDK, and the open source part is the part that talks to your app.

The pricing boundary is explicit in the README's feature list: free for up to 100,000 monthly active devices. That is a device count rather than a user count, which is a slightly different unit, and it is the number to watch if your app is distributed widely to a mostly inactive audience.

The hosted nature also means the data path is not yours. Feedback items, screenshots and analytics go to Wiredash's infrastructure, and the EU hosting claim is a specific answer to data residency questions, but it does not make the service self-hostable. There is no local database in the package and no offline mode described.

The repository layout hints at how the implementation is split. Alongside the lib/ directory that a normal Flutter package would have, there are two unusual directories: wiresdk/ and wiresdk_sidekick/. That naming pattern, a wire protocol layer and a sidecar for it, suggests the SDK talks to a native or platform-specific helper rather than doing everything in Dart. The README does not describe what those directories contain, so the exact mechanism is not documented here.

The example/ and examples/ directories both exist, with a README in the singular one, which is typical of a package where one holds the standard pub example and the other holds feature-specific samples.

Where the Wiredash SDK is the wrong choice

The first limit is the licensing, and it is the one to check first because it is not a licence most Flutter developers have seen before. The Wiredash SDK is released under the Attribution Assurance License, which the README describes as redundant with BSD, with the LICENSE file linked for details.

Redundant with BSD sounds permissive, and the repository listing independently classifies the licence as a custom one that GitHub cannot classify. Both statements can be true while still leaving room for conditions you should read. The Attribution Assurance License is a relatively recent licence with its own attribution terms, and the fact that a licence is described as redundant with another is a claim by the project rather than a legal conclusion. If you ship a commercial Flutter app, read the LICENSE file yourself. That is a licensing note rather than legal advice, and it is the single fastest way to rule this package in or out.

The second limit is that the analytics and the feedback console are not yours to operate. If you need your feedback data in a system you control, or you need the surveys to fire without a third party deciding when, you are accepting a dependency on a hosted service whose availability, pricing and data handling are outside your control.

The third limit is the widget wrapping approach, which is elegant and has a cost. Because Wiredash has to sit above your MaterialApp, the feedback UI is a separate widget tree above your application rather than something that lives inside your navigation. That means it is not naturally integrated with your app's own theming beyond what inheritMaterialTheme provides, it does not participate in your app's transitions, and any overlay or full-screen route your app uses will sit underneath it. For an app with a strong design language, that is a visible compromise.

The alternative to weigh is building the survey and feedback flow yourself. The promoter score survey is a single question with a scale, and the feedback form is a screenshot plus a form; both are a weekend of work, and doing it that way gives you full control over when it appears, what it captures and where the data goes. The difference in approach is that Wiredash gives you the flow, the widget, the screenshot mechanism, the scheduling and the console immediately, and asks for a hosted dependency and a device-count limit in return.

There is also the middle option of an analytics and survey platform that is not app-feedback specific, such as a general product analytics SDK with an NPS survey feature. Those tend to have larger ecosystems and less opinionated UI, at the cost of not shipping an in-app screenshot feedback flow out of the box.

Maintenance, packaging and the shape of the project

The maintenance record is current. The last push was on 2026-10-06 and the repository is not archived, so the code is being worked on. The release history shows v2.6.0 on 2025-10-22, v2.5.0 on 2025-06-04 and v2.4.0 on 2025-02-13, which is a minor release roughly every four months, a normal cadence for a package with an active user base.

The README asks you to install 2.7.0, which suggests development is ahead of the tags the listing exposes. For a package whose main version is 2.x, the upgrade cost is low, since the integration surface is a widget wrapper and two method calls, and a minor bump is unlikely to break either.

The package is published on pub.dev as wiredash with the pub points, popularity and likes badges in the README header, which are the metrics pub.dev itself computes. The repository also carries a nightly workflow badge for the stable branch, and the badge points at a workflow file named nightly.yaml, which is a slightly odd pairing for a package that advertises stable as its default branch. It suggests that a nightly build runs against the stable branch for release checks.

The repository structure is standard for a Flutter package with two additions. There is lib/, test/, example/ and examples/, a pubspec.yaml, an analysis_options.yaml which is the linter configuration, a .metadata file, and a CHANGELOG.md. The unusual entries are RELEASE.md, which is the release process documentation, and the two directories wiresdk/ and wiresdk_sidekick/ described above.

The primary language is Dart, the default branch is stable, and the homepage is the pub.dev package page rather than a dedicated site, with wiredash.com and docs.wiredash.com linked from the README instead.

Editorial conclusion

Adopt the Wiredash SDK if you run a Flutter app and want in-app feedback capture and NPS surveys without building the widget, the screenshot flow and the survey scheduler yourself, and if your user base is inside the free tier of 100,000 monthly active devices. Do not adopt it if you need self-hosted analytics, since the console and the data are vendor-hosted, or if a copyleft-style obligation is a problem, since the Attribution Assurance License is not a standard permissive licence. Verify first where your users are located relative to the EU hosting, and that the widget wrapping does not conflict with the root widget structure your app already uses.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. wiredashio/wiredash-sdk on GitHub