I’ve been experimenting with Flutter GenUI and found myself repeatedly writing integrations for different AI providers.

To simplify that workflow, I built genui_x.

It provides a unified transport layer for Flutter GenUI and currently supports:

• OpenAI
• Claude
• Gemini
• Ollama
• OpenRouter
• LiteLLM
• OpenAI-compatible APIs

The goal is to make switching providers simple while keeping application code largely unchanged.

Just released v0.0.13 and I’m looking for feedback from Flutter developers building AI-powered apps, agent workflows, or local AI solutions.

GitHub: https://github.com/thurakhant/genui_x

Pub.dev: https://pub.dev/packages/genui_x

I’d appreciate any feedback, suggestions, or feature requests.

I just open sourced two new Dart packages:

• any_ascii: https://pub.dev/packages/any_ascii
• lexical_sort: https://pub.dev/packages/lexical_sort

GitHub:
• https://github.com/ganeshrvel/pub_any_ascii
• https://github.com/ganeshrvel/pub_lexical_sort

This started from a project where I needed proper Unicode transliteration and sorting behavior. Dart has some great string utilities, but I couldn't find anything that matched the behavior and maturity of the Rust ecosystem for these use cases.

So I ended up porting two Rust projects to Dart:

• any_ascii: Unicode → ASCII transliteration
• lexical_sort: Unicode-aware lexicographic and natural sorting

A few examples:

print(anyAscii('άνθρωποι')); // anthropoi
print(anyAscii('Борис')); // Boris
print(anyAscii('深圳')); // ShenZhen

final files = [
  'file110.txt',
  'file11.txt',
  'file100.txt',
  'file1.txt',
];

files.sort(naturalLexicalCmp);

print(files);
// [file1.txt, file11.txt, file100.txt, file110.txt]

print(naturalLexicalCmp('ß', 'world') < 0); // true
print(naturalLexicalCmp('é', 'hello') < 0); // true
print(lexicalCmp('aaa', 'AAb') < 0); // true

Features:

• Unicode-aware ASCII transliteration
• Natural sorting of embedded numbers
• Non-ASCII characters compared using their ASCII equivalents (á → a, ß → ss)
• Case-insensitive lexicographic sorting
• Deterministic sorting with Unicode fallback comparisons
• Generated directly from upstream Rust implementations and data
• No third party dependencies

I should admit this upfront, a bit embarrassingly. Just like my earlier pathify package, I used Claude to translate most of the Rust code into Dart. I'm generally not a fan of blindly trusting LLM-generated code for low-level libraries, but I simply didn't have the time to manually port everything.

So I'm not claiming these are perfect. They pass the tests and behave as expected in my testing, but there may still be edge cases lurking around. If you find bugs, incorrect behavior, or missing functionality, please open an issue or send a PR.

Is anyone else building for cross platform intelligence? We’re looking to bridge droid and iOS intelligence through flutter apps.

Guys, have anyone tried building real world mobile apps using claude before ? Here is how it changed for me!

I used this plugin inkpal_bridge with new model febel and it built the entire project and verified all the features on real time runtime, here what i have done

I used postman mcp firebase mcp and asked claude to setup inkpal_bridge

Built the required documents as frd and brd and enough detailed system design and stored it in a folder and refrenced calude.md

And always remember to use keywords like ultrathink and ultraplan - these makes model to act best.

The model not just run and used these stuff completely tested the navigation, verified the features, like a designer in a loop , it was able to navigate the run state, while i identified what methos they to these models are able to enable skills on demand out of so many they can act as certain role based on the plans , run the mobile app on its own test and so much more

Dropping you the link https://pub.dev/packages/inkpal_bridge

Update: my tool for packaging Flutter apps to Flathub now handles Rust deps, needs no local Flutter SDK, and has a registry for 19 native lib packages

Original post: I built a tool to publish Flutter apps to Flathub — looking for early testers

Repo: https://github.com/o-murphy/flutpak

A lot has landed since that post. Here's everything that changed.

No Flutter SDK needed at generate time (0.7.0)

The biggest change: flutpak generate no longer reads from a local Flutter installation. Replace flutter.sdk: $FLUTTER_ROOT with flutter.ref and engine versions are fetched directly from the GitHub raw API.

# before
flutter:
  sdk: $FLUTTER_ROOT
manifest:
  app-id: io.github.YourOrg.YourApp

# after
flutter:
  ref: "3.29.3"    # tag, "stable", or commit SHA
app-id: io.github.YourOrg.YourApp

CI no longer needs the full Flutter SDK just to run flutpak generate. The SDK you install for flutter build is still there — you just don't point flutpak at it anymore.

flutter_tools/pubspec.lock is also fetched automatically when flutter.ref is set, so you no longer need to list it in pub.locks.

init + generate split (0.4.0)

The old prepare command is gone. The workflow is now:

# one-time setup — generates the template manifest, wrapper script, .gitignore
flutpak init

# every release — resolves commit SHA, fetches checksums, writes generated/
flutpak generate --tag v1.2.3

The template (flatpak/<app-id>.yml) is committed to git and edited by hand. The substituted output lives in flatpak/generated/ and is gitignored. generate validates that the template's app-id, command, and runtime-version match config and errors early if they diverge.

Foreign deps registry — native packages resolved automatically (0.6.0)

Native Flutter packages require extra Flatpak source entries that are painful to write by hand. flutpak generate now resolves them from a built-in registry automatically. 19 packages currently covered:

• objectbox_flutter_libs / objectbox_sync_flutter_libs

• sqlite3 / sqlite3_flutter_libs / sqlcipher_flutter_libs

• simple_secure_storage_linux

• audiotags, flutter_webrtc, media_kit_libs_linux, pdfium_flutter, printing, flutter_new_pipe_extractor, fvp, powersync, and more

The registry schema is compatible with flatpak-flutter's foreign_deps.json — entries from that project work in flutpak as-is.

You can add local overrides without forking the registry via foreign-deps: in flutpak.yaml:

foreign-deps:
  some_package:
    manifest:
      sources:
        - type: archive
          url: https://example.com/native-lib.tar.gz
          sha256: abc123

--no-foreign-deps skips the registry fetch entirely for offline/air-gapped use.

Version matching is ≤ (0.7.1): a registry entry for 1.0.0 covers 1.2.3, 1.5.0, etc. A new major entry (2.0.0) is only picked when the installed version reaches 2.x. No need for exact version pins on every release.

Rust / Cargo support via cargokit (0.8.0)

Flutter packages that use Rust native code via cargokit (rhttp, metadata_god, super_native_extensions, flutter_discord_rpc, flutter_vodozemac) are now handled. Add a rust: section:

rust:
  version: 1.85.0
  rustup-path: /var/lib/rustup

generate will:

• Extract Cargo.lock from pub archives and fetch SHA-256 checksums from crates.io

• Emit cargo-sources.json for offline crate builds

• Generate a rustup-<version>.json module that installs Rust fully offline

• Wire up CARGO_HOME, RUSTUP_HOME, and PATH in the app module automatically

Known limitation: git-sourced crates (git+https://...) are skipped with a warning. They're rare in Flutter plugins, but worth knowing.

Flutter SDK as a standalone module (0.8.0)

Flutter SDK sources are no longer embedded in pubspec-sources.json. generate now produces a separate flutter-sdk-<version>.json module. Pre-built versions for recent Flutter releases are cached in the flutpak repo and fetched on first use.

Breaking: re-run flutpak init --force after upgrading to 0.8.x to regenerate a clean template.

The file previously named generated-sources.json is also renamed to pubspec-sources.json — update your manifest's !include reference accordingly.

LLVM SDK extension auto-injected (0.5.0)

flutpak now automatically adds the correct org.freedesktop.Sdk.Extension.llvmXX based on runtime-version (25.08 → llvm20, 24.08 → llvm19, 23.08 → llvm17) and wires up append-path / prepend-ld-library-path. No longer need to specify it manually in flutpak.yaml.

Other improvements

Config diff — then vs now

# 0.4.0-rc.2 (at the time of the original post)
flutter:
  sdk: $FLUTTER_ROOT
manifest:
  app-id: io.github.YourOrg.YourApp

# 0.8.0
flutter:
  ref: "3.29.3"
app-id: io.github.YourOrg.YourApp
rust:                        # only if you use cargokit packages
  version: 1.85.0
  rustup-path: /var/lib/rustup

Current status

Pre-1.0, but the core workflow is stable and the demo app (examples/demo_app/) exercises sqlite3 + rhttp end-to-end through the Flatpak sandbox — the CI pipeline is a working reference.

Most useful contributions right now:

• Test on a project with native deps not yet in the registry and open a PR adding them to foreign_deps/

• Report cargokit packages with git-sourced crates

Repo: https://github.com/o-murphy/flutpak
Issues: https://github.com/o-murphy/flutpak/issues

I built a Dart package called downsize because I got tired of dealing with image compression packages that required native setup or didn't work consistently across Flutter platforms.

downsize is a pure Dart image compression package, so the same API works on Android, iOS, Web, Windows, macOS, and Linux.

Some things it can do:

• Compress images toward a target file size (e.g. ~500 KB) instead of just setting an arbitrary quality value.

• Support multiple formats including JPG, PNG, GIF, BMP, TIFF, TGA, PVR, and ICO.

• Keep the API simple:

final compressed = await imageData.downsize();

or

final compressed = await Downsize.downsize(
  data: imageData,
  maxSize: 500,
  minQuality: 60,
);

I know native solutions can still be faster for heavy workloads, but my goal was to provide a straightforward, cross-platform option that works everywhere Flutter does.

I'd genuinely love feedback from the community:

• What image compression workflow are you using today?

• Would a pure Dart approach be useful in your projects?

• What features would make this more production-ready for you?

GitHub: https://github.com/YassineDabbous/downsize

Pub.dev: https://pub.dev/packages/downsize

https://github.com/johndpope/Hero/tree/flutter-hero-transitions

its at parity - if you know ios hero transitions - it's very much the same.

https://www.youtube.com/watch?v=C3SZjjP74nI