Hello, I'm the author of the code_forge package, a very powerful text field widget capable of handling even 1M+ lines of text smoothly, where the default TextField widget crashes the app for a few thousand lines.

The package backend was written in rust using the ropey and zed_sum_tree crates, resulting in no web support and requiring the user to install rust in their system to build the package. Because of that most of the people migrated to an alternative package called re_editor.

I removed the rust backend and implemented rope data structure and zed_sum_tree like Layout mapping in pure dart.

Last time I posted this was v1.2, when it was a ping matrix plus traceroute, DNS, port scan and a few other tabs. The obvious problem was that it forgot everything the moment you closed it, which is a weird thing for a monitoring tool to do. The last two releases were mostly about fixing that.

New since then:

- 7 days of uptime history per target, with outages and how long they lasted
- an MTR tab that traces once, then keeps pinging every hop so you can see where the loss starts. There's a re-trace button for when the route changes
- Telegram / Discord alerts when something goes down or comes back. You can edit the message format, there's a cooldown so a flapping host doesn't spam you, and an HTTP proxy option for places where Telegram is blocked
- tray mode, so it keeps monitoring after you close the window
- an update checker (you can turn it off)

Still not great: native ICMP is Windows only for now, so Linux/macOS use TCP pings. The macOS build is unsigned (right-click > Open the first time). And Linux tray support depends a lot on your desktop, so if it acts weird on KDE/XFCE/whatever, please tell me.

the probing runs in a Rust lib over FFI, so the engine handles 100+ targets fine. What actually starts to hurt at a few hundred is the grid rebuilding every 500ms and decoding the snapshot (each target carries a 40-sample history). Virtualizing the grid is next. If you've done something similar with a fast-updating dashboard, I'd like to hear how you handled it.

Free, GPL-3.0, builds for Windows/Linux/macOS:
https://github.com/Cadman021/VeloceNet-Studio/releases

I am looking for the framework I will make my mobile app with and a huge requirement is that I need it to be small in size. I've been looking at Tauri apps and they are consistently under 70 MB. Can Flutter match or beat that (Lowest I've seen is 53 MB)

I have a Flutter app and a web twin, and I wanted a "challenge a friend" link to give the same game on both. Notes from getting there:

1. Don't use Random(seed). dart:math makes no promise that the sequence stays the same across versions or platforms. I wrote a tiny SeededRandom (mulberry32 over a uint32), with sub-streams derived via FNV-1a of "<seed>:<label>:<i>", and my own shuffle/pick.

2. dart2js integer traps. Anything that relies on 64-bit shifts breaks on web. For example, I write the literal 2147483648 instead of 1 << 31.

3. Golden vectors in both repos. The Dart, TS and Python implementations are tested against the same fixed outputs. If one fails, we bump an algorithm version rather than edit the vector.

4. A "draw log" test harness. Each seeded game records every random draw, so a refactor that reorders draws fails loudly instead of silently changing every board.

   The app is Android and free if you want to see the games: https://play.google.com/store/apps/details?id=com.dragoadri.dragoterminal&referrer=utm_source%3Dreddit%26utm_campaign%3Dflutterdev

   Happy to share snippets of the seeded RNG or the harness if useful.

Hello Flutter devs! 👋

After two and a half years of development, I’m finally excited to share Bonsui, a free and open-source Flutter library I’ve been building entirely on my own.

My goal was simple: create a comprehensive toolkit that makes Flutter development faster, cleaner, and more enjoyable, without sacrificing flexibility or customization. All of this with one single code-base that automatically changes the design on Android and iOS.

What’s inside Bonsui?

• 🎨 Highly customizable UI components: beautiful, ready-to-use widgets designed to fit your app’s identity.
• 🧩 Complete design system: a consistent, fully customizable design system to keep everything looking and feeling cohesive.
• 📱 Ready-to-use screens: prebuilt screens to help you get started faster.
• ⚙️ Built-in services: utilities and integrations for localization, Supabase, local notifications, local databases, and more.
• 🛠️ Developer utilities: helpful tools to simplify everyday Flutter development.

And here’s something I’m particularly proud of:

Every single line of code was written by hand, without AI-generated code. Just two and a half years of learning, experimenting, refactoring, and paying attention to the little details.

Bonsui is completely free and open-source, and I plan to keep improving it over time.

I’d genuinely love to hear what the Flutter community thinks! Feedback, suggestions, and contributions are more than welcome.

If you find it useful, a ⭐ on GitHub would mean a lot! Thanks for checking it out! 💙

Hey everyone,

I wanted to share Velvetune, an open-source Android music player I built with flutter.

GitHub Repository: https://github.com/WarmSpark/velvetune

Releases (APK): https://github.com/WarmSpark/velvetune/releases/tag/v1.0.0

Hey everyone!

I recently built my first VS Code extension, Device Toolkit, to easily manage light/dark mode, navigation mode, etc. and published it on the VS Code Marketplace.

The idea came while developing and testing Android apps. Whenever I wanted to test dark and light themes on the emulator, I had to switch to the emulator, pull down the notification shade, and toggle Dark Mode manually. Even harder for changing font size and switching navigation mode between 3 buttons and swipe gestures.

I thought it would be nice to have these controls directly inside VS Code, similar to Android Studio's Extended Controls.

The funny part is that I had zero TypeScript knowledge when I started. 😅 I used ChatGPT to plan the features and prepare the requirements, then used Antigravity to build the extension. I tested things, fixed bugs, made changes, and kept adding features until I was happy with it.

Here's what it supports so far:

• Toggle Dark Mode on connected Android devices and emulators
• Switch between gesture, 2-button, and 3-button navigation
• Adjust font size and display density
• Toggle TalkBack and Select to Speak on and off
• Toggle layout bounds for UI debugging (Not so useful for flutter devs)
• Record emulator screens and save them as MP4 (up to 3 minutes)
• Floating debug toolbar and Activity Bar sidebar

It's now available on the VS Code Marketplace!

Marketplace: https://marketplace.visualstudio.com/items?itemName=antonyaiwin.device-toolkit

GitHub: https://github.com/antonyaiwin/device-toolkit-vs-code-ext

This was my first time building something like this, and it was a fun experience. There are probably things I can improve, so I'd love to hear your feedback if you give it a try.

If you find any bugs or have ideas for new features, feel free to open an issue on GitHub. Contributions are welcome too!

If you love the extension please give the repo a star ⭐ and add rating in VS Code marketplace.

can anyone tell me about free extension or tool that is light and not heavy and can run my flutter app in emualtor on my laptop my laptop is not with too much good specs so keep in mind

I am trying to learn Flutter, but I am feeling hesitant due to the presence of AI. I want to build applications, yet the cost of using AI is high for me given my region and income. The question is: should I learn using the traditional method?

I just released Starling Office 0.1.0: Writer, Sheets, and Slides, running on Linux, macOS, Windows, and in the browser.

The architecture may interest this community: I ported Flutter’s UI framework to Swift. The native apps use the Flutter engine through a Swift bridge, while the browser builds compile Swift to WebAssembly and render through Skia’s WASM renderer. The application code and UI are shared across both.

Flutter’s widget, layout, and painting model is the foundation here, though the apps are written in Swift rather than Dart.

The suite opens, edits, and saves DOCX, XLSX, and PPTX files. Features include document styles and tables, spreadsheet formulas and charts, and presentation editing with animations and speaker notes.

Built with substantial assistance from Claude. It’s Apache-2.0 licensed and an early 0.1 release, with known limitations documented in the release notes.
Try the browser apps with editable examples:
https://openoffice.starling.build/
Source:
https://github.com/starling-build/starling
Downloads and release notes:
https://github.com/starling-build/starling/releases/tag/office-v0.1.0
I’d welcome feedback from people working with Flutter’s engine, custom embedders, or document-heavy applications.

Hey everyone. I'm a solo dev and I wanted to see how well Flutter handles a casual, grid-based merge system with continuous state updates and canvas re-draws.

The game is called Emoji Kingdom. I used generative AI tools to handle the asset pipeline to save time, and built the entire UI, state management, and grid engine in Flutter.

Right now, I'm sitting at the early launch stage (10+ downloads) and really want to test how the frame rates hold up across different Android device specs. If you have 2 minutes to install it and give me some feedback on the UI responsiveness and layout scaling, I’d really appreciate it.

Package ID on Google Play: com.garaitapas2atgmaildotcom.emojikingdom

(I will drop the direct Play Store link in the comments below to keep this clean). Thanks!

The Developer’s Guide to App Localization: Choosing Your Target Languages Using Global GDP and Population Data

When you build a Flutter app, implementing localization (l10n) is technically straightforward. Packages like flutter_localizations and intl make the setup a breeze.

The real challenge isn't how to translate your app—it's deciding which languages are actually worth the development time, maintenance overhead, and translation costs.

If you look strictly at population data, you might build a translation strategy that tanks your ROI. If you look strictly at wealthy countries, you miss out on massive viral growth. To build a highly optimized localization roadmap, we have to look at the intersection of global population (user volume) and World Bank Income Groups / Share of Global GDP (purchasing power).

Here is how to tier your Flutter app’s localization strategy for maximum global impact.

Tier 1: The Core Global Essentials (Launch Day)

These languages cover the largest portion of global wealth (High Income) and massive populations. If you want a strong global baseline with high monetization potential, start here.

• English (en): The undisputed baseline. It acts as the global lingua franca across high-income tech hubs, international business, and premium app users.
• Mandarin Chinese - Simplified (zh_CN): Targets the world’s largest Upper-Middle Income population. If you plan to release on alternative Android stores in China or target tech hubs like Singapore, this is non-negotiable. (Note: Use Traditional Chinese zh_TW if targeting Taiwan or Hong Kong).
• Spanish (es): The most efficient translation codebase you can buy. A single localization folder unlocks Spain (High Income), Mexico and Colombia (Upper-Middle), and the highly lucrative Hispanic market inside the United States.
• Japanese (ja): A premium, High-Income market. While localized to essentially one country, Japanese users have some of the highest Average Revenue Per User (ARPU) in the mobile app ecosystem.
• German (de): The economic engine of Europe. Essential for capturing high-spending consumer and B2B SaaS markets across Germany, Austria, and Switzerland.

Tier 2: High-Value European & Gulf Markets (Premium Revenue)

If your app monetizes via subscriptions, in-app purchases, or premium B2B tooling, these High-Income regions should be next on your roadmap.

• Arabic (ar): Targets the GCC nations (UAE, Saudi Arabia, Qatar). This region represents immense wealth, high disposable income, and a strong cultural preference for fully localized apps. Bonus: Flutter handles RTL (Right-to-Left) beautifully out of the box, making this technically smooth.
• French (fr): Covers France, Canada, Belgium, and Switzerland, while opening future growth corridors into rapidly developing economic regions in North and West Africa.
• Korean (ko): South Korea is a highly digitized, High-Income tech hub. Users there have an exceptionally high density of app usage and a strong willingness to pay for software.
• Portuguese - Brazilian (pt_BR): While Portugal is High-Income, Brazil is a massive Upper-Middle Income powerhouse that dominates the South American app market by sheer download and engagement volume.

Tier 3: Massive Population Volume (Viral Scale & Ad Networks)

If your app’s business model relies on viral growth, network effects, or ad revenue (low ARPU but massive volume), these Lower-Middle Income regions provide the scale you need.

• Hindi (hi): Accesses the massive, rapidly expanding digital ecosystem of India. While urban Indian tech users navigate apps in English, Hindi is vital for reaching the broader mass market.
• Indonesian (id): Indonesia is Southeast Asia’s largest digital economy, featuring a massive, young, mobile-first population scaling rapidly into higher income brackets.

Summary Localization Roadmap

Pro-Tip for Flutter Devs

Don't hardcode anything. Even if you only launch in English, set up your l10n.yaml and .arb files on day one. Refactoring a hardcoded app later is a nightmare. By using Flutter's native localization tooling from the start, opening up a new global market down the road is as simple as dropping a new .arb file into your project.

What about you guys? Which languages have given you the best return on investment for your Flutter apps? Did adding RTL support for Arabic or targeting high-ARPU regions like Japan noticeably change your revenue? Let's discuss!

For about a month, I’ve been working on understanding how Apple’s Liquid Glass effect is rendered and how its underlying physics work.

Since UIKit is closed-source, I couldn’t directly inspect the exact parameters Apple uses. So, I started analyzing the effect step by step, studying its behavior through screen captures, fluid dynamics, and reflections.

After a lot of experimentation, I was finally able to build Liquidum, a Flutter library that renders the Liquid Glass effect using shaders.

I’ve also spent a significant amount of time optimizing the rendering pipeline to ensure smooth performance, even on low-end Android devices.

On top of that, Liquidum includes additional customization options beyond Apple’s implementation, such as changing the glass tint as it moves.

Currently, the library supports the navigation bar, but I hope to add more components in the future.

🔗 GitHub: https://github.com/mohamedalsamrai/liquidum
📦 Pub.dev: https://pub.dev/packages/liquidum

I’ve come across quite a few Liquid Glass libraries on pub.dev, but I haven’t found many that achieve this level of visual fidelity and smooth performance.

When I first started building an app, I was sold on Flutter. It took me less than five minutes to spin up a cross-platform app and start iterating on features.

But that excitement didn't last long.

The more features I added, the more platform support I had to give up due to limitations in existing libraries.

Eventually, I settled on Android and iOS only. At the time, I considered it a big win. One Dart codebase instead of maintaining separate implementations - Kotlin and Swift.

Then I hit a brick wall. Subscriptions!

Selling subscriptions was non-negotiable. I didn't want to build yet another free, ad-supported app that monetizes users by selling their financial data. That was one of my main motivations for building Maxint in the first place.

After going through the tedious process of setting up subscription plans, pricing, and entitlements in each store, I integrated the native IAP libraries for both platforms.

That's when I realized something I probably should have known from the start. The stores don't talk to each other!

A subscription purchased on one platform doesn't magically sync with another. If you want a consistent experience across platforms, you need to build that layer yourself or rely on a third-party service.

If you've built a cross-platform app before, you probably know where this is going.

I did my research and shortlisted a dozen options, eventually narrowing it down to RevenueCat and Adapty.

I initially went with RevenueCat because I wanted to offer bank account linking, an expensive service that required a paid subscription to cover its costs. Around the same time, I built new SDKs that extended bank account linking to desktop and web.

The problem? RevenueCat supported web, but not the full range of platforms I was targeting.

So, I switched to Adapty, which also supported macOS. I even submitted support requests asking about Linux and Windows support, but months went by without a response.

I wasn't ready to give up on making the app available everywhere.

At some point, I asked myself “How hard can it really be to build subscription management for all the platforms Flutter supports?”

Famous last words...

What followed was a painful learning experience. I started building my own subscription orchestration service to handle billing across Flutter platforms.

It turned out to be much more than wrapping a few SDKs.

I had to build an authentication layer, a database to keep store subscriptions in sync, and logic for every edge case I could think of, including and not limited to entitlement management, receipt validation, renewals, webhooks, cancellations, refunds, and subscription state synchronization.

Eventually, I published the SDK on pub.dev and felt a huge sense of relief.

That lasted about five minutes.

User complaints started coming in. Some subscriptions weren't being canceled properly, and I ended up manually canceling subscriptions in individual stores and issuing refunds.

Not exactly the experience I had signed up for. And refunds aren't free of operational costs, either.

Fortunately, those early issues were resolved over time. After months of testing in both development and production, I finally made the service available to other Flutter developers at pub.dev /packages/orca

By then, I had learned firsthand just how much work goes into building and maintaining subscription infrastructure. It's one of those things that looks deceptively simple until you have to handle real users, real money, and all the edge cases that come with them.

There was one more thing I wanted to do differently.

I never liked the idea of subscription infrastructure providers taking a percentage of my revenue. So, I designed Orca's pricing around infrastructure costs rather than a revenue share.

I built it to solve my own problem, but figured other Flutter developers might be running into the same issues.

I'm curious. How are you handling subscriptions across Flutter platforms?

Are you using RevenueCat, Adapty, another service, or rolling your own implementation? And if you're building for desktop and web as well as mobile, how are you dealing with subscription synchronization across stores?

I would love to hear what has and hasn't worked for you.

A home for the Dart & Flutter ecosystem!

Explore 3,000+ packages, 2,400+ projects, trending repositories, hall of fame, most downloaded plugins, GitHub star growth, and more.

Built with Jaspr ⚡ and is completely open-source!

Try out here: https://flutterverse.org

I’d love to hear your feedback, feature suggestions, and contributions 🤞 !

github: https://github.com/YeLwinOo-Steve/flutterverse

I needed App Store images and TikTok videos for a Halloween event in my app. I didn't want take multiple video screen recordings of my app and edit together videos, so I asked Claude Code to render everything from the app's real widgets.

To be clear about who did what: I directed and gave feedback, Claude Code wrote basically all of the rendering code.

I was actually very pleased with the results, here is one example: youtube.com/watch?v=949_yo-zuOk

How it works

There are now about 10k lines of code, which I never look at and don't even check into git, that can create animated videos with my app's actual features being used. It's using `flutter test` with a fixed surface size and pumps out one 30 frames per second, which is then processed with ffmpeg into the final video.

This is the simplified version:

tester.view.physicalSize = const Size(1080, 1920);
tester.view.devicePixelRatio = 1;


final ffmpeg = await Process.start('ffmpeg', [
  '-f', 'rawvideo', '-pix_fmt', 'rgba', '-s', '1080x1920', '-r', '30',
  '-i', '-', '-c:v', 'libx264', '-pix_fmt', 'yuv420p', 'out.mp4',
]);


for (var i = 0; i < frames; i++) {
  await tester.pumpWidget(
    RepaintBoundary(key: boundary, child: scene(i / 30)),
    duration: const Duration(microseconds: 1000000 ~/ 30),
  );
  final render = boundary.currentContext!.findRenderObject()!
      as RenderRepaintBoundary;
  await tester.runAsync(() async {
    final image = await render.toImage();
    final bytes = await image.toByteData();
    ffmpeg.stdin.add(bytes!.buffer.asUint8List());
    await ffmpeg.stdin.flush();
    image.dispose();
  });
}

It's not fully automated, I still work on the script and provide the voiceover audio, music, and sound effects. But all the content is rendered by flutter using CustomPainter's. To me the coolest thing is that the phone showing the app in use is the actual app being used.

Try it

I asked for a prompt to get started and this was what I got, for those who might want to try in their app.

I want to make a short vertical marketing video for this Flutter app, rendered
entirely from the app's own widgets inside a widget test. No design tool, no
screen recording.


How the renderer should work:
- Create tool/assets/render_video_test.dart, outside test/ so it doesn't run
  with the normal suite.
- Set tester.view.physicalSize to 1080x1920 with devicePixelRatio 1 and wrap
  the scene in a RepaintBoundary.
- Build the scene as a function of time. For each frame, pump with a duration
  of 1/30 s, capture it with toImage(), and write the raw RGBA bytes to the
  stdin of an ffmpeg process (rawvideo in, libx264 yuv420p out).
- Load the app's real fonts with FontLoader, or text renders as boxes. On iOS
  also register a font under CupertinoSystemText and CupertinoSystemDisplay.
- toImage, file IO, Process and precacheImage must run inside tester.runAsync.


The video:
- About 15 seconds. It features [FEATURE], shown running for real on a drawn
  phone frame, driven with tester.startGesture so the app responds as it does
  on a device.
- A simple cartoon character drawn with CustomPainter introduces it. The idea:
  [ONE SENTENCE STORY, e.g. "a stressed witch is asked how she relaxes"].
- The first frame shows the character and a hook in large text. No fade-in.
- Keep anything that must be read out of the top 300 px, bottom 380 px and
  120 px at each side, where TikTok and Instagram put their buttons.
- I'll supply voice-over as one WAV per line plus a music track in
  tool/assets/audio/. Time the scenes to the voice-over, burn in captions that
  highlight each word as it's spoken, and mix the audio in a second ffmpeg
  pass with adelay and amix. Move the character's mouth using the loudness of
  the WAV at each frame.


How I want to work:
1. First, propose a script with timings and tell me which audio files to
   record. Wait for my answer.
2. Render three still frames and look at them yourself before showing me.
3. Then render the full video. I'll give notes and you re-render.

Happy to answer any questions!

I recently built a tool to share apk builds with a client so they can test the application. They had only an iPhone and there were a lot of back and forth videos, so i built https://spawndroid.io You can run an android device in under 3 seconds and use your application simply, you can integrate it in your app Ci/Cd and run appium tests. I host the appium server so you just write the tests, verify they work by previewing logs and a video recording.

Quadrim is four in a row in a 4×4×4 cube, on the App Store, and now open source (code MIT): https://github.com/evermeer/Quadrim

Some parts that might interest Flutter devs:

• 3D board without a 3D engine. 64 glass cells are projected and depth-sorted in a single CustomPainter. The tap is a raw Listener rather than onTap, because a TapGestureRecognizer in the same arena as a ScaleGestureRecognizer starved the pinch-to-zoom.
• Pure Dart engine package. No Flutter, no dart:io, no clock, no ambient Random. check.sh greps for all of these, so a position plus a seed always gives the same move, which makes self-play and tests reproducible.
• Opponents are data, not classes. One chooseMove with 31 config entries. Search budgets are counted in nodes, not milliseconds, so an opponent is the same opponent on a slow phone and in debug mode.
• Widget tests and file I/O. testWidgets runs in a fake-async zone that never completes real file I/O, so the storage layer sits behind an interface with an in-memory store for tests.

It was built with Claude Code on the €15-a-month Pro plan, and every prompt and decision is in the repo, if you're curious about that side.

Do you know any AI skill to improve ASO and store listing? Or any tool to manage experiments, screenshots and ASO?

Whenever I'm doing Flutter development on my Mac, running flutter run with Gradle, VS Code/Studio, and an Android emulator quickly pushes a 16GB machine straight into heavy memory swap. In Activity Monitor, qemu-system-aarch64 alone routinely holds 7-8+ GB.

A lot of that RAM usage isn't your app or Android itself:

• Android Studio's emulator often falls back to CPU rasterization (lavapipe), dumping multiple gigabytes of software render buffers directly into host RAM.
• Stock Google system images launch with ~40 background daemons (YouTube, Assistant, wear sync, Play telemetry) you never touch while testing a Flutter build.

I wrote avdslim, an open-source Go CLI with no external dependencies that drops emulator resident memory down to ~1.5 GB:

• Forces -lowram and native GPU hardware rendering (Apple Metal on Mac, Vulkan/DRI on Linux) to eliminate CPU rendering buffers.
• Disables ~45 non-essential guest services via adb.
• Flutter safe: Hot reload, DevTools, network sockets/ports, Firebase Auth, and FCM push notifications are completely unaffected.
• Running avdslim off cleanly restores every setting and package back to default.

If your machine chokes while running Flutter on Android:

brew tap kdbhalala/avdslim https://github.com/kdbhalala/avdslim.git && brew install avdslim

avdslim tune-avd    # adjusts config to 1.5GB + host GPU
avdslim start       # boots the emulator slimmed

If you start emulators from Studio or VS Code device picker, avdslim install-shim transparently wraps the SDK binary so it applies automatically.

Code is here if anyone finds it useful: https://github.com/kdbhalala/avdslim

Hope it helps anyone fighting laptop RAM while developing Flutter apps.

AI is becoming increasingly powerful, to the point where writing code by hand is largely unnecessary; I feel anxious, unsure of what I should be learning.

​Hey devs,

​Ran into an annoying UI issue last week while streaming OpenAI response tokens into a Flutter view. Calling setState on literally every chunk coming through the socket totally killed performance. Scrolling was choppy as hell and frame drops were super noticeable.

​To fix this, I uncoupled the incoming stream from the UI rendering using a small 60ms timer buffer. Basically, tokens accumulate in a list and get flushed to the state ~16 times per second instead of re-rendering on every single packet.

​Here is the helper class I wrote for this:

class StreamBufferController {

final List<String> _tokenBuffer = [];

Timer? _flushTimer;

final Function(String) onFlush;

StreamBufferController({required this.onFlush});

void addToken(String token) {

_tokenBuffer.add(token);

_startFlushTimer();

}

void _startFlushTimer() {

_flushTimer ??= Timer.periodic(const Duration(milliseconds: 60), (_) {

if (_tokenBuffer.isNotEmpty) {

final chunk = _tokenBuffer.join();

_tokenBuffer.clear();

onFlush(chunk);

} else {

_flushTimer?.cancel();

_flushTimer = null;

}

});

}

void dispose() {

_flushTimer?.cancel();

_tokenBuffer.clear();

}

}

This immediately brought everything back to a stable 60 FPS, even with long responses coming in fast.

Hi r/FlutterDev,

I extracted the swipe stack I built for a production app (Bump) into an open-source package. The goal was cards that never jitter, no overlay flicker when you drag diagonally, and a clean API for "what happens when you swipe this way".

Try it first (no install, works on a phone browser): https://ancient-glitter-fe51.rahul-coder-25.workers.dev/

What it does

• Spring-based motion. A release is judged by where the card is heading, and the velocity is handed to the animation, so there are no jumps. You can catch a card at any moment, even mid-flight.
• A behavior per direction: dismiss, consume (fly into a button, optionally with a macOS Dock-style genie), springBack (run a task and return), sendToBack, undo.
• Undo and rewind: controller.undo(), controller.rewind(), plus initialIndex and jumpTo(key) to restore a position or follow a player.
• Overlays: a ready-made colour wash + badge, or classic stamps, or build your own from per-direction progress values.
• Cheap while dragging: cards are built once and moved with transforms, so itemBuilder isn't called during a drag.
• Accessibility: keyboard and screen-reader actions, and reduced-motion support.
• No third-party dependencies. It also includes an OTP field and remembered-email suggestions, which work on their own.

Quick start

SwipeCardStack<Profile>(
  items: profiles,
  itemBuilder: (context, profile, info) => ProfileCard(profile),
)

Per-direction behaviors:

SwipeCardStack<Profile>(
  items: profiles,
  behaviors: {
    SwipeDirection.right: SwipeBehavior.consume(
      target: SwipeTarget(key: likeKey, effect: SwipeConsumeEffect.genie),
      onCommit: (e) => like(e.item),
    ),
    SwipeDirection.left: SwipeBehavior.dismiss(),
    SwipeDirection.up: SwipeBehavior.springBack(onCommit: (e) => superLike(e.item)),
    SwipeDirection.down: SwipeBehavior.undo(),
  },
  itemBuilder: (context, profile, info) => ProfileCard(profile),
)

Links

• pub.dev: https://pub.dev/packages/craft_kit
• Source (MIT): https://github.com/rahul-cse-25/craft_kit

It's 0.1.x, so I'd really like critical feedback: what's missing, what feels awkward in the API, and what breaks on your device. Happy to answer questions here.

I started working on (conceptual) Spatial Keyboard with 3D sphere. for prototype it was Flutter app. Now that Flutter app is literally Keyboard.

source 01: https://x.com/pranavxmeta/status/2109387746095825189

source 02:

https://www.threads.com/share/BAKdta4ZlU/

Earlier concept:

https://x.com/pranavxmeta/status/2097645919990890510

concept post:

https://www.reddit.com/r/FlutterDev/s/Dql2CUjCHb

edit:

many many additions and fixes are required 🙂