home_widget: a Flutter bridge to native home screen widgets

What the package deliberately does not do

The README is unusually direct about the boundary. HomeWidget does not allow writing widgets with Flutter itself, and it still requires writing the widgets with native code. What the package provides is a unified interface for sending data, retrieving data and updating the widgets. That is a smaller promise than the name suggests, and the difference decides whether this package helps you. If your plan was to build a home screen widget in Flutter and ship it to both platforms, this is not that package. If your plan was to write the widget once in the platform's own widget framework and then find yourself copying the same data plumbing into a second native implementation, the package removes exactly that copy. It helps on the native side as well, with setup guidance, and it is developed against both Android and iOS, with a single Dart API on top.

The data path is two calls: save, then update

Once the native widget exists, sending it data is short. The first call writes a value under an identifier:

HomeWidget.saveWidgetData<String>('id', data);

The second call asks the platform to reload the widget:

HomeWidget.updateWidget(
    name: 'HomeWidgetExampleProvider',
);

The order matters and the separation is the design. Writing data does not by itself refresh anything, and updating does not carry the payload, so a widget that shows a stale value is usually a missing update call rather than a failed save. The name in updateWidget is the identifier of the native widget provider, the piece of platform configuration that the native side registers, which is also why the example names a provider rather than a widget. The typed generic on saveWidgetData tells the plugin how to serialise the value, and the identifier is the key your native code reads back. For a developer coming from the platform SDKs, the shape is familiar; what changes is that the write now happens in Dart.

Rendering Flutter widgets, and widgets that call back into Dart

Two of the four headline features go beyond the data bridge. The package can render and display Flutter widgets on home screen widgets, which is a different mechanism from the save and update path and does not remove the need for native widget code. Interactive widgets that call Dart code are the other: a home screen element that responds to a tap by running your Dart logic, rather than merely showing a number. That closes the loop that static home screen widgets leave open, and it is the reason to look at this package rather than writing a shared preferences file by hand. The full list of features is short and worth reading in order, because they are not variations of one another: help setting up widgets on the native side, sending data from Flutter to the widget and updating them, rendering and displaying Flutter widgets on home screen widgets, and interactive widgets that call Dart code. Each answers a different gap, and you will probably use two of them.

Five example apps instead of one toy demo

The repository is a workspace rather than a single package, with a packages directory, a docs directory, an examples directory, a pubspec at the root, a docs.json for the documentation site and a CHANGELOG.md. The examples are the part that tells you what the package is good for. There are five of them, and the names are a list of use cases: configurable_widget, which is the closest to the common case of a widget whose content is set from app data; file_and_images, for widgets that show a file or an image; generator_basics, for the code generation path; lockscreen_widgets, for the lock screen rather than the home screen; and streak_widget, which is a habit tracker style widget with accumulated state. Each is a starting point you can run, and the fact that there is a dedicated example for lock screen widgets and for images tells you the package has been pushed past the single counter demo that most plugins settle for. A dedicated example for images also hints that the data path is not limited to small strings, which matters when you are deciding whether to pass a path or a payload.

Documentation, discussions and a show-and-tell category

The documentation lives on a hosted site, docs.page, with a guide for setting up home_widget and home screen widgets on your desired platforms, and that setup guide is the part you will need, because the package cannot write the native widget for you. The project keeps a normal set of community channels: GitHub Issues for bugs and feature requests, GitHub Discussions for questions and for helping other users, plus a show and tell category in Discussions where people are invited to share the widgets they have added to their app. The contributing notes also ask for documentation updates and for fixes to typos, which tells you the maintainer treats docs as part of the deliverable. The package is developed in the maintainer's free time and is offered through GitHub Sponsors, so if it earns a place in your app, that is the mechanism the author asks you to use.

Still on the 0.9 line, with no declared licence

Two practical cautions. The first is versioning. The published releases are home_widget-v0.9.0 on 2026-01-07, v0.9.1 and v0.9.2 both on 2026-05-25, so the package is still below 1.0 and the API is not claiming stability. Under semantic versioning, a 0.x package can change breaking behaviour in a minor release, and a plugin whose consumer is native code on two platforms is exactly the kind of package where a renamed method shows up as a silent no-op at runtime rather than a compile error. The last push was on 2026-10-13, so work continues between the tagged releases. The second caution is the licence. No licence file appears at the top level of the repository, and the package does not declare one, so while the code is readable, the terms for copying it into a commercial product are not stated. That is worth raising with the maintainer before the package goes into an app you ship.

Platform coverage in CI: GitHub Actions and Codemagic

A plugin like this is only as good as its testing on real platforms, and the repository shows the testing setup. The main GitHub Actions workflow is configured in the repository and referenced by the build badge, and there is a separate Codemagic configuration with a status badge for iOS integration tests, which is the piece that matters most here, since the interactive widget behaviour and the update callbacks differ between the two platforms. Coverage is tracked through codecov with a configuration file at the root. The consequence for you as a user is indirect but real. A package with device level integration tests in CI is likely to notice when an operating system update changes widget behaviour, whereas a package tested only on the Dart side can look healthy while breaking on a phone. The build badge in the README is therefore a better signal of the package's health than the version number alone.

Editorial conclusion

home_widget suits a Flutter team that wants one Dart side to feed a home screen widget on both Android and iOS and is prepared to write the widget view natively. It is the wrong tool if you expect to build the widget in Flutter, since the package does not allow that, and it is the wrong tool for a commercial product until the licence question is settled, because no licence is declared. Before adopting it, read the version history, since the package is still on the 0.9 line, and check the platform guide for your own app rather than copying the example widgets as they stand.

Frequently asked questions

Official sources

1. ABausG/home_widget on GitHub
2. Issues
3. README
4. Releases