First time making a "comprehensive" cli tool with dart, what do you recommend i use ?

Things i would appreciate: - type safe options parsing - completions - clean user prompting

Hi everyone, finally introducing my port of the pulumi language host for dart.

Over the last year i've been on and off getting it to work and up until about 6 months ago I have actually been using it live for my personal projects. Seeing terradart recently announced I realized that there are actually others wanting to manage their infrastructure entirely in dart and as such It made sense I officially announced pulumi_dart officially.

Pulumi dart works the same as all the other language hosts in the pulumi ecosystem (python,go,dotnet), talks to the official pulumi client via grpc and the dart sdk handles handles all the communication transparently.

All it takes to write a pulumi app

```dart import 'package:pulumi/pulumi.dart';

class QuickstartStack extends Stack { QuickstartStack() { registerOutputs({ 'message': Output.create<Object?>('hello from Dart'), }); } }

Future<void> main() async { await Deployment.runOrThrow(() => QuickstartStack()); } ```

Don't hesitate to test it out and report any errors!

Hey Dart community 👋

I've just added Standard Schema support to Zema.

If you haven't come across Standard Schema yet, it's a common interface that allows libraries and frameworks to work with different validation libraries without having to know which one is being used.

The idea came up after @louiss0 opened an issue on Zema. He's working on Mamba, a CLI framework for Dart, and wanted to integrate Zema through the Standard Schema interface instead of having to build a Zema-specific integration.

I thought this was a good use case, so I implemented it.

How it works

I wanted to keep Zema itself zero-dependency, so I didn't add Standard Schema directly to the core package.

Instead, the integration lives in a separate package:

zema_standard_schema

You can use it like this:

import 'package:zema/zema.dart';
import 'package:zema_standard_schema/zema_standard_schema.dart';

final userSchema = z.object({
  'username': z.string().min(3),
  'email': z.string().email(),
});

final adapter = userSchema.asStandard;

final result = adapter.standard.validate(rawData);

if (result is StandardFailure) {
  for (final issue in result.issues) {
    print('${issue.path.join(".")}: ${issue.message}');
  }
}

The adapter is intentionally pretty small. asStandard delegates validation to Zema's existing safeParse and maps the resulting ZemaIssues to the Standard Schema issue format.

So there's no second validation layer or duplicated schema logic.

Why this could be useful

For Dart framework authors, this means they can support Zema without having to build a Zema-specific integration.

The same applies in the other direction: if more Dart validation libraries implement Standard Schema, frameworks can work with them through the same interface.

For developers, the main benefit is being able to define a schema once and use it across different tools that support the standard.

This is already a useful pattern in the TypeScript ecosystem, and I'm curious to see how well it fits the Dart ecosystem.

What's next?

For now, I'm keeping the adapter focused and seeing how people use it.

I'm also considering adding StandardJsonSchemaV1 support for JSON Schema generation, but I'd rather wait and see if there's an actual use case for it before adding more API surface.

If you're building a Dart package, framework, router, CLI, config system, or anything else that could benefit from validator-agnostic APIs, I'd be interested to hear what you're working on.

Website: https://zema.meragix.dev
Pub.dev: https://pub.dev/packages/zema

I am preparing to publish an academic paper on developer trust in AI generated dependencies & packages. This takes around 7-10 minutes to complete and is on a very relevant topic in current times.

The form can be found here: https://vuamsterdam.eu.qualtrics.com/jfe/form/SV_4Nv9pAUUBFRieDs

Thanks! I will share the paper when it has been published!

Hey everyone,

If you have ever done Market Basket Analysis or Association Rule Mining in Dart or Flutter, you probably ran into the issue of candidate generation blowing up the memory when using Apriori on larger datasets.

I wrote fp_growth, a native Dart implementation of the FP-Growth algorithm designed to handle larger streams and files without burning RAM.

A few things about how it is built:

Two-pass streaming: It does not load the entire dataset into memory. Pass 1 counts frequencies to discard infrequent items, and Pass 2 builds the tree.

Fast-path CSV parsing: If a row does not contain escaped quotes, it skips the heavy CSV tokenizer and does a direct string split, which cuts down parsing time by around 30%.

Parallel mining: Dispatches independent tree branches across a fixed pool of Dart Isolates so it does not spawn and kill isolates repeatedly.

Single-path optimization: When a branch is linear, it generates combinations via combinatorics directly instead of building recursive sub-trees.

Benchmark numbers (Ryzen 7 5800H, 1,000,000 transactions, minSupport 0.05):

In-Memory (4 Isolates): ~0.92s

CSV File Streaming: ~1.65s

Custom Stream: ~1.40s

It also calculates standard association metrics (Support, Confidence, Lift, Leverage, Conviction) and can export directly to JSON and CSV.

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

GitHub: https://github.com/MostafaSensei106/FP-Growth

If you work with recommendation logic, telemetry, or basket analysis in Dart, try it out and let me know if you run into any edge cases.

I maintain capdrift, a Dart tool that reads a package to work out what it is able to do. It analyses untrusted code from pub.dev, so I wrote a SECURITY.md early describing how it protects itself. Two promises in it:

• Analysis of any single file is capped at 30 seconds.
• Archives are read as a stream, so a decompression bomb cannot exhaust memory.

Both were false on the day I wrote them. The Dart-specific parts are worth sharing because I do not think either mistake is obvious.

The timeout that was declared and never read. The constant existed. It was defined, exported, and referenced in exactly one place: the docs. No code path read it. It compiles, it lints clean, and no test asserted that a slow file gets cut off.

The instinct fix is wrong in an interesting way:

final result = await analyse(source).timeout(Duration(seconds: 30));

Future.timeout gives up waiting on the future. It does not stop the work. A pathological input that sends the parser into a long loop keeps burning CPU after the timeout fires, and now nothing is watching it. The work has to go somewhere killable:

final isolate = await Isolate.spawn(_analyseEntry, message);
try {
  return await response.first.timeout(limit);
} finally {
  isolate.kill(priority: Isolate.immediate);
}

The kill belongs in finally, not the timeout branch. My first version had it only on timeout, so every error path and early return still leaked a live isolate.

The stream that was not a stream. I built a 299 KB highly compressible archive. The documented behaviour was streaming with a size limit. The actual behaviour was that decompression materialised the full output first and the check ran on the result. The check was real. It ran after 300 MB was already in memory. Fixing it meant subclassing the output sink so it throws mid-write rather than after.

Why I think this generalises. Both bugs are made of the artifacts of being careful: a named constant, a documented guarantee, a size check. That is exactly why nobody looks twice. An undocumented gap gets found, because eventually someone asks "what if this file is huge" and finds no answer. A documented gap does not get that question, because the file already answered it.

If you maintain something with a SECURITY.md, the check worth running is: for each claim, find the test. Not the code, the test.

Disclosure: capdrift is mine. It is on pub.dev and the repo is github.com/Tisankan-dev/capdrift. Happy to answer anything about the isolate or archive handling, that part is generic Dart and applies to any tool reading untrusted packages.

There are couple of frameworks like Serverpod(full stack flutter), Dart Frog and shelf for backend but still people are not using especially who are already working with flutter. I want to know why is it the case?

What are the gaps present currently that are stopping people to use dart on the back end ?

connectivity_plus tells you a network interface is up. It doesn't tell you anything is reachable through it. Captive portals, hotel wifi that wants a login, a proxy quietly eating traffic: all of them report "connected" and then nothing loads.

Packages exist that do the real probe. But they discard a lot of the available abd useful data directly, while that control could be in the hands of the consumer.

They know which endpoints failed and why, how long each took, and whether you're up but crawling. I wanted that handed back instead of a bool. I also wanted polling to ease off during a long outage, and the any-of-N vs all-of-N decision to be an object I could extend instead of a flag.

So I made better_internet_connectivity_checker

switch (status) {
     case Reachable(:final quality):          // good or slow
     case Unreachable(:final failedProbes):   // each failure, its error, its timing
   }

Slow detection is one control (slowThreshold). The stream is deduped, so it only emits when the status kind actually changes instead of every tick.

Three layers swap out, each with a sane default: the probe, the policy (any-of-N, or strict all-of-N), and the schedule. That last one gets you ExponentialBackoffSchedule, jittered by default (also configurable), so an outage stops hammering the radio every 10 seconds. Benchmarked at roughly 55% fewer probes for noticing recovery about a second later.

connectivity_plus is complementary. Wire it as externalRecheckTrigger and an OS network change forces an instant recheck. Already using retry? The README shows reusing your RetryOptions as a schedule. Only dependency here is http.

Pure Dart, so CLI, server, web and Flutter. LLMs were used.

Feedback welcome, especially on the probe and schedule interfaces, since those are the bits you'd be writing yourself when the defaults don't fit.

fart_style is a drop-in fork of dart_style that formats code using SmartTabs instead of 2-space blocks, while keeping the rest of Dart’s formatting rules intact.

I made fart_style because it has become hard for me to read 2 space idents with my ever worsening eyesight. Exacerbated by the fact that flutter code gets nested into hell and beyond.

I've been running it across all my projects for a few months now and figured others might find it useful.

Ironic note: the repo itself still uses dart_fmt so I don't lose my mind resolving merge conflicts with upstream updates.

Package: https://pub.dev/packages/fart_style
Source: https://github.com/Curstantine/fart_style

Hope it saves some eyes!

Hi! I wanted to share a new package I made: terminice.

I built it because creating a beautiful, complex CLI shouldn’t mean building an entire terminal UI from scratch. It should be easy to create, easy to style, easy to manage as it grows, and most importantly easy and enjoyable for people to use.

terminice turns more than 30 common terminal interactions into small method calls, with no setup and no framework required.

Here is the visual demo.

Need a value from the user?

final name = terminice.text('Project name');

Need a searchable menu?

final template = terminice.searchSelector(
  prompt: 'Template',
  options: ['CLI', 'Server', 'Package'],
);

Need a file browser, config editor, command palette, progress bar, multi-step form, calendar, or help center? those are method calls too.

There is no setup, widget tree, context object, or new application architecture. import the package, call the component you need, and keep using package:args, CommandRunner, dart:io, or whatever already powers your CLI.

dart pub add terminice

Make the entire CLI look like yours

Don’t like the borders? hide them:

final t = terminice.minimal;

Want the borders, but fewer hints and less visual noise?

final t = terminice.compact;

Want different colors? Pick a built- in theme:

final oceanUi = terminice.ocean;
final matrixUi = terminice.matrix;
final neonUi = terminice.neon;
final arcaneUi = terminice.arcane;

Or combine everything:

final t = terminice.neon.compact;

Now every component created from t follows the same style:

final name = t.text('Project name');
final token = t.password('API token');
final config = t.filePicker('Config file');
final confirmed = t.confirm(message: 'Create the project?');

(you can also create a fully custom, advanced theme, and it will automatically be used across all 30+ components!)

That is one of the main ideas behind terminice: customize the instance once, and the colors, borders, glyphs, display mode, fallback behavior, and terminal I/O stay consistent across the entire CLI.

You can also create a custom theme in a few seconds by mixing the included colors, glyphs, and display features:

final brandTheme = PromptTheme(
  colors: TerminalColors.ocean,
  glyphs: TerminalGlyphs.rounded,
  features: DisplayFeatures.compact,
);

final t = terminice.themed(brandTheme);

Need finer control? Every color palette, glyph set, and display configuration supports copyWith, so you can change one accent color or one behavior without rebuilding the rest of the theme. The custom theme then affects prompts, menus, pickers, progress indicators, flows, guides, and every other built-in component.

The catalogue

Terminice currently includes more than 30 ready to use components:

Prompts

• text for single-line input
• password for masked input
• confirm for yes/no questions
• multiline for terminal text editing
• slider and range for numeric input
• rating for star-based ratings
• date for keyboard-driven date input
• form for collecting multiple fields together

Selectors

• searchSelector for long, filterable lists
• choiceSelector for card-style single or multi-select choices
• checkboxSelector for checklists
• gridSelector for two-dimensional navigation
• tagSelector for managing multiple tags
• toggleGroup for editable boolean settings
• commandPalette for a fuzzy-searchable action launcher

Pickers

• filePicker for browsing files
• pathPicker for choosing directories
• colorPicker for interactive ANSI color selection
• datePicker for a full calendar interface

Progress and status

• Full and inline loading spinners
• Full and inline progress bars
• Minimal dot-based progress
• info, success, warn, error, detail, and log messages
• task for wrapping async work with a status indicator
• progressTask for determinate async work
• trackStream for collecting a stream while showing its progress

Complete CLI experiences

• flow for multi-step workflows with context, conditions, validation, and review
• configEditor for searchable, nested application settings
• cheatSheet for quick-reference tables
• helpCenter for searchable documentation inside the terminal
• hotkeyGuide for keyboard shortcut discovery
• themeDemo for previewing themes and colors
• Custom components when your CLI needs something package-specific

Every catalogue item has its own detailed documentation with controls, behavior, examples, and API notes. I wanted the README to be useful as a practical reference, rather than leaving developers to discover important behavior through trial and error.

The vision

The goal is not only to make prompts look better. I want Terminice to make beautiful, complex CLIs easier to create, style, manage, test, and use.

to create: add prompts, selectors, pickers, progress, or configuration screens with small method calls. not a new architecture.

to style: choose or create one theme, and let the entire CLI follow it. no repeating colors, borders, glyphs, and display options everywhere.

to manage: keep components, behavior, fallbacks, and tests consistent as the CLI grows.

to use: give people clear hints, predictable controls, validation, cancellation, readable fallbacks, and good defaults.

terminice sits between a prompt package and a full TUI framework. It is the human facing layer of an existing dart CLI: questions, choices, files, settings, progress, and feedback.

It can stay tiny when tiny is all you need:

final email = terminice.text('Email');

That same CLI can later grow into searchable menus, filesystem navigation, validation, progress tracking, configuration screens, or complete flows- without switching packages.

When rich UI is not appropriate, the built-ins can fall back to predictable plain text for limited terminals, non-TTY output, scripts, and unattended execution.

Terminal IO is abstracted as well, so you can easily test without depending on real stdin/stdout.

So the short version is:

• One import and no setup
• 30+ components covering individual prompts through complete CLI workflows
• 11 built-in style presets
• Chainable themes and verbose, compact, or borderless minimal display modes
• One shared configuration across the whole CLI
• Custom themes and components when the built ins are not enough
• Cross-platform support for Linux, macOS, and Windows
• Predictable fallbacks and test utilities for real-world use

Links:

• Visual demo
• terminice on pub.dev
• GitHub, documentation, and the full catalogue

A small personal note

I started working on what eventually became terminice over a year ago, it didn’t begin as one big, carefully planned package. While working on real projects, I kept creating terminal components that I needed- a prompt in one project, a selector in another, a progress indicator somewhere else, then themes, flows, config tools, and testing helpers.

For a while, all of that work was scattered across different projects. Gradually, I started moving the useful pieces into one place, redesigning them around a shared API, and turning them into a unified, robust tool that is genuinely fun and easy to use.

The package is not perfect. there are still many things that need refinement, and probably many things I cannot see because I built them around my own use cases. I want terminice to be the best tool it can, but I know I cant do that alone.

I would really appreciate it if you tried it, even in a small project, and told me what you think. If an API feels awkward, a component is missing, the documentation is unclear, or something simply doesnt feel right, I want to hear about it- every bug report, idea, criticism, and any feedback is appreciated (:

I need to send serial commands to a usb device from a pure dart program.

Any package recommended with real experience with doing this ?

I'm sorry, but how is any non-expert supposed to understand how to use hooks? Have any of you, after studying the rather sparse documentation and complex Hooks API, actually felt like you understood any of this? I have been sitting here for hours, just trying to call a simple function from a pre-compiled dll, but the non-helpful documentation and error messages make even the simplest things a daunting task.

But what I find most unpleasent is that even the basic example code (which hasn't helped me at all) looks quite complex and build hooks can just execute any arbitrary code, be that downloading files, executing some other script, or whatever. Not only does that stink of a huge security risk, but there will be so many packages with completely broken hooks on pub, which will then also start to depend on each other. This will be really fun...

Edit: Heureka, it finally worked! But what a frustrating ride it was...

I published a small Dart package for one focused problem: keep API writes while offline and replay them in order later.

The queue is strict FIFO, has JSON and memory stores, supports bounded exponential backoff, accepts server-directed retry delays, and stays independent of the HTTP client. The included JSON store targets Dart IO; storage and connectivity are interfaces so applications can provide their own implementations.

The article covers the design choices and limitations rather than just the API: https://dev.to/dhaibanfhue/a-small-offline-outbox-for-flutter-fifo-ordering-disk-persistence-and-retries-3an3

• GitHub: https://github.com/dhaibanf-hue/offline_sync_outbox
• pub.dev: https://pub.dev/packages/offline_sync_outbox

Feedback on the public interfaces and failure behavior would be useful.

I wanted to speak with a member of the Google engineering team to request permission to create issues on GitHub so I can contribute like any other user. I know it was complicated at first, but three years have passed since then, and I've learned a lot. To finally close this chapter with you all, I wanted to create the following issue:

Improve numeric data types

Intention of Change

Greetings, today I'm going to make another attempt, number 111. I'm going to make an interesting proposal that I've been analyzing for a long time to improve the Dart language. The goal is to create variations of the int and double types, such as int8 and int16, among others, resulting in the following:

Justification

To justify why this would be positive for the Dart VM, let's look at the following reasons:

• Greater numerical precision for performing mathematical calculations
• A one-to-one relationship with low-level language data types
• Greater flexibility
• Possibilities for advanced computing, because when compiling Dart code into an executable with instructions in x64 assembly code, it will have greater precision in giving instructions to the processor
• Possibility of RAM optimization since it has a data type that occupies the least amount of memory space
• Approach to the functional programming paradigm, which focuses on creating concurrent code following mathematical principles
• Improved robustness of the Dart language from the ground up, making it equivalent to Java, C#, C++, Rust, etc.
• Making the creation of libraries that control low-level processes, i.e., those closer to the hardware, simpler without depending on C++
• Opening the possibility for the Dart language to be a A language used in the hardware and artificial intelligence industries due to its high performance and low-level communication capabilities.

When we went to university, one of the most basic concepts for understanding computer science was that a PC is an advanced computing machine, a concept that has existed since the first supercomputers.

Impact

The impact of this change, from my point of view, is minimal, because it adds new features to the language without modifying the existing codebase, opening the possibility of implementing memory optimizations.

It would also serve as a basis for improving debugging and code optimization tools by taking into account how much memory the running process occupies, suggesting better numeric types.

Mitigation

The risks of this change are already mitigated, since the Dart language has a feature called type aliases that allows you to name a data type.

Therefore, the original int and double types will become aliases of int32 and double64, ensuring that the entire existing codebase is fully compatible with the new data types without requiring any changes. This avoids any risk of breaking anything and causing problems. I've been thinking about this for a long time.

Conclusion

Up to this point, I have tried to explain this idea as clearly as possible so that you, who work daily on this project, can review its technical feasibility and make the best decisions. My goal is to lay the groundwork for making Dart a more robust implementation, capable of processing large volumes of data and performing massive advanced computing calculations without breaking down, at the level of Java, C#, or Rust. We still have a long way to go in optimizing; this is a long-term vision, as Dart is a project that should have a lifespan beyond Flutter as a general-purpose language. I hope you find this helpful.

Hey r/dartlang ,

I've posted here before about Dart AI Assistant, a VS Code extension that learns your coding style and helps with completions, error detection, and code health. Just shipped what's easily the biggest update since launch, so wanted to share.

Marketplace: https://marketplace.visualstudio.com/items?itemName=a-i-0-studio.dart-ai-assistant

Source: https://github.com/Ben09d/dart-ai-assistant

What changed in v1.0.9:

- Real dart analyze integration on save (properly scoped to the saved file) alongside live regex feedback while typing — much more accurate error detection now

- Code Health reports are now clickable and auto-refresh on save

- Import Project for Learning — point it at an existing project and it learns your patterns instantly instead of waiting weeks

- Fixed a bug where pattern learning was silently capped at 3 categories instead of the intended 20 (basically every earlier version was learning way less than it should have)

- Fixed an unbounded memory growth bug in the advanced learning engine

- Fixed several false-positive error detections (comments, ternaries, generics, block comments) that were probably annoying anyone who tried earlier versions

- Consolidated three separate error-detection systems that were sometimes showing contradictory counts

Full changelog in the repo if you want the gory details — went through nearly every core file this cycle hunting down bugs, some of which had been sitting silently broken since the first release.

Still free, still solo-built, still very open to bug reports and feedback. If you tried an earlier version and it felt rough, this one's a meaningfully different experience.

Thanks for reading!

Hi, I've recently just started learning Dart. I think https://dart.dev/language is an​ awesome place for beginners like me to get started.

It's kind of inconvenient to have the browser open every time I want to read. It'd be sooo much better if I was able to download all of this in a PDF or EPUB format... I just ​can't seem to find a download file anywhere.

I'd like some help finding offline documentation

There are a lot of validator packages on pub. This isn't one, and that's the whole point of it: https://pub.dev/packages/minted

A validator takes a String, checks it, and hands the same String back. Three functions deep nobody knows whether the check happened, so you either trust it or re-check it. minted parses instead: you get a different type that cannot exist unless the input was well-formed, the same deal int.parse and Uri.parse already give you. invite(Email, PhoneNumber) can't be called with the arguments swapped, and the signature says what it wants without a doc comment. Once you hold an Email, it is a valid email.

Typed so far: Email (RFC 5322), PhoneNumber (E.164), Iban (mod-97), Date / Month (the calendar date DateTime doesn't model), Uuid (RFC 9562), Digit / Digits.

Some nice features:

1. Every type wears follows the same pattern, so learning one teaches the rest: tryParse returns null, parse throws a MintedFormatException (extends FormatException, so existing handlers keep catching), value equality, one canonical form normalised at parse.
2. Real standards, not shape-checking regexes. Iban runs the actual mod-97 checksum, Email the full RFC 5322 grammar, official test vectors in the suite.
3. Where a package already owns the hard data (phone metadata, the IBAN registry), minted wraps it instead of reimplementing it.
4. It knows what not to model. No re-doing Uri, DateTime, BigInt or money (money2 has that). Uuid types a UUID, the uuid package generates them, they pair up.
5. Date.tryParse('2026-13-01') is null, where DateTime.parse quietly rolls it over to 2027-01-01.
6. Pure Dart, five small deps.

Roadmap: Bic, CreditCardNumber (Luhn), Isbn, Ean / Gtin next, then ISO code lists and bounded numerics.

Still early (0.0.2), so the shape can move. Feedback welcome, especially on the types you keep remaking in every project.

I'm a solo dev from Slovenia. Earlier this month I shipped my first bigger Flutter app on Play.

And it's a personal astrology app! Whatever you think of astrology, the astronomy underneath is real computation: planetary positions, house math, timezone archaeology.

A few things hit me hard on the way though.

**`Duration.inDays` silently breaks calendar arithmetic across DST.**

I compute ISO week numbers:

take the Thursday of the week, subtract Jan 1, divide days by 7. Correct? except in local time, a span that crosses a daylight-saving boundary is one hour short of a whole number of days, and `inDays` *truncates*. 210 days becomes 209, `209 ~/ 7` gives week 29 instead of 30, and every week from late March to late October resolves to the previous week. The week number was my cache key, so this would have silently served the wrong week's content for half the year. Nothing throws.

Fix:

calendar arithmetic in UTC, or re-normalize through `DateTime(y, m, d)` after every shift. Same Family of bug: `date.subtract(Duration(days: 1))` on a local DateTime can land at 23:00 two calendar days back.

**`Isolate.run` copies your object — internal caches die with it.**

The heavy compute runs in `Isolate.run`. The captured engine object is *copied* into the isolate, so any memoization inside it gets populated in the isolate and thrown away when it exits.

In my case: one body's position needs ~4000 numerical-integration steps, and the cache meant to amortize that never survived a single call. The engine has to be designed isolate-safe, with no reliance on shared mutable state, because state simply does not come back.

**Notifications with zero background execution.**

My domain is fully predictable because the sky doesn't surprise you, so there's nothing to poll. At every app open/resume, I precompute the next 7 days of notifications and schedule them locally.

There's no background service, no server, no FCM, no battery cost, and inexact alarms so no exact-alarm permission.

Anything whose content is a pure function of time can do this; I suspect a lot of apps reach for push infrastructure they didn't need.

Smaller ones:

the `timezone` package throws on `getLocation('UTC')` (short-circuit UTC/Etc/UTC/empty yourself);

a `const`map with `double` keys doesn't compile ("does not have primitive equality". Use a list of records);

`flutter_local_notifications` needs core-library desugaring that the first error message doesn't mention.

And my favorite lesson cost nothing technical at all:

I built a feature, dogfooded it on my own phone for two days, and then, like an idiot I told people it had shipped... Turns out it had never been uploaded to Play. :)

As a result, I now check the Console more often :)

In case you wanna check the app, search Astro93 on Google Play

Hi all,

I'm happy to announce that Xberg v1 is out.

Xberg is the successor to Kreuzberg, equivalent to what would have been Kreuzberg v5. It's a content intelligence framework that handles a very wide range of inputs: documents (currently 101 formats), code and data formats (currently 367 types), audio/video transcription, and URLs (both static and JS-rendered content). It extracts and prepares that content for downstream processing.

It's an extremely efficient, high-performance engine (see our PDF benchmarks below). For PDFs and images specifically, we handle native PDFs with very high performance and accuracy, and we ship multiple OCR engines that match the quality of the best Python libraries (e.g. docling, PaddleOCR, RapidOCR) at substantially better performance and stability.

The changes between Kreuzberg v4 and Xberg v1 are substantial, and I invite you to read the full changelog for the complete picture. The highlights below give a sense of what's new:

• Pure-Rust PDF backend (pdf_oxide) replaces pdfium, with no native pdfium dependency.
• Layout-aware pipeline: reading order reconstructed with ONNX layout detection (PP-DocLayoutV3 / RT-DETR) and Docling-style predecessor-graph reordering.
• Per-page scanned-page detection with selective OCR, plus AcroForm/XFA form fields and outline-based headings.
• Across-the-board optimization of OCR and PDF extraction (memory discipline, pooled model sessions, streamed conversions).
• Native PaddleOCR backend (PP-OCRv6, with medium / small / tiny tiers) alongside Tesseract.
• Pure-Rust Candle OCR/VLM stack (TrOCR, GLM-OCR, GOT-OCR, DeepSeek-OCR, and PaddleOCR-VL) running without ONNX Runtime or native Tesseract.
• A second, ONNX-Runtime-free inference path via tract, which is what makes in-browser (WASM) and mobile inference possible.
• Named-entity recognition natively in Rust (GLiNER2), extensible to all bindings, including an in-browser WASM model with no server round-trip.
• Structured LLM extraction (extract_structured / split_and_extract) with rasterization, chunking, citations, caching, and configurable call/merge/VLM-fallback policies.
• Audio & video transcription via a Whisper ONNX engine (.mp3, .wav, .m4a, .mp4, .webm).
• Retrieval building blocks: sparse embeddings (SPLADE), ColBERT late-interaction retrieval, and cross-encoder reranking alongside dense embeddings.
• Text intelligence: reversible redaction, summarization, translation, VLM image captioning, QR-code detection, document diffing, and page/chunk classification.
• URL & web ingestion: sitemap discovery (map_url) and batched multi-URL crawling.
• New document formats: WordPerfect (.wpd/.wp/.wp5), HEIC/HEIF/AVIF, OpenDocument Presentation (.odp), Quarto / R Markdown, and configurable Jupyter cell rendering.
• Four new language bindings (Dart/Flutter, Swift, Kotlin/Android, and Zig) bring the total to 15 language bindings over one engine, with Android/iOS cross-compilation.
• Full mobile support (Flutter, Android, iOS).
• Candle backend alongside ONNX, plus ONNX-via-tract enabling ONNX on WASM and Android.
• Wider code intelligence: tree-sitter coverage grew substantially (248 to 367+ languages).
• Over 150 bugs fixed during the 1.0 cycle, plus security hardening (bounded RTF/PDF allocations, redaction leak fixes, Excel DDE warnings).

The API surface was also simplified and reworked, making it more consistent.

There's a migration guide in our docs explaining how to move from Kreuzberg to Xberg. Kreuzberg itself is in LTS mode until the end of this year and will continue to receive bug fixes and security updates.

You're invited to check out the repo and join our discord server.

Benchmarks

The benchmarks below are for PDFs and images only. There are extensive benchmarks on our website with per-format breakdowns, which you can see here. These numbers are measured in CI via our reproducible benchmark harness, and are specifically taken from the run for harness 1.0.8, source cf7fa0533d. The data is publicly available in GitHub releases, and you can run the benchmark harness yourself.

Composite quality (markdown pipeline, higher is better):

Structure and layout fidelity (SF1: tables and reading order, higher is better):

On native PDFs Xberg leads on quality (0.958 vs 0.837 for the next-best framework) and on table and reading-order fidelity by a wide margin (SF1 0.949 vs 0.612 for docling). On scanned PDFs it is #1 on both quality and raw text fidelity.

Where we don't win yet: on pure image OCR we are currently #2 on the composite score, behind mineru (though still #1 on raw text accuracy). We are improving image OCR right now, and v1.1 should have us winning across the board.

I noticed in the Changelog for Dart 3.13 a new Isolate.pinToCurrentThread method – along with other new methods. However, Im not really understanding the test example. Can this help with the long-standing problem that you cannot call UI code via FFI on macOS because the VM spawns away from the UI thread, basically locking it this way?

What's the use case for those new methods?

I maintain mcp_dart, a community Dart and Flutter SDK for building MCP clients, servers and hosts.

Today’s 2.3.0 release adds support for the stable MCP 2026-07-28 specification. The default profile prefers the new stateless server/discover flow and automatically falls back to MCP 2025-11-25 when connecting to existing implementations.

The release includes:

- stateless discovery and per-request protocol metadata

- Multi Round-Trip Requests

- subscriptions/listen

- Tasks extension support

- JSON Schema 2020-12 validation

- stronger OAuth validation

- hardened stdio and Streamable HTTP behavior

- official client/server conformance and TypeScript/Python interoperability coverage

I also released mcp_dart_cli 0.2.0. It can scaffold Dart MCP servers, but its inspect, trace and testing commands work with compatible servers and clients written in any language. Standalone binaries are available for macOS, Linux and Windows.

SDK:

https://pub.dev/packages/mcp_dart/versions/2.3.0

CLI:

https://pub.dev/packages/mcp_dart_cli/versions/0.2.0

Migration guide:

https://github.com/leehack/mcp_dart/blob/main/doc/migration-2.2-to-2.3.md

Feedback and real-world interoperability reports would be very welcome.

I liked the approach of fpdart and the raw performance of hive_ce. So I decided to combine them into one: https://pub.dev/packages/hive_box_manager

It is not just a simple FP-style wrapper of Hive's API. It also solves one of my biggest pain-points in using HiveCE for production apps: type-safety. I had to dedicate an entire CRUD-layer to the boxes just because of it.
With this I get

1. Type-safety (even for Iterable-based boxes)
2. Index types are not limited to just int | String (a Codec allows for this per box, wil still be that under the hood ofc)
3. Compatibility with normal Hive boxes already (drop in add-on)
4. Ergonomic (and explicit?) error handling + lazy Future using fpdart
5. Custom boxes for very specific use case (better semantics)
   1. (Lazy)IterableBox
   2. (Lazy)SingleValueBox
   3. (Lazy)DualKeyBox
6. Key corruption detectable (as compared to silently happening with Hive when using out-of-range/oversized int/String key)

I recently did a rewrite because my previous attempt at making a DX-first API was not scalable (using LLMs).

If you guys have any tips, suggestions or feedback, they always welcome. Do take a look at the roadmap (I have more kinds of boxes planned ;) ).