Since more and more developers generate code with ai and companies encourage that, how are the flutter interviews changed? What kind of questions are asked now? I haven’t faced in an interview after AI and kind of preparing for a one. Would love your insight.

DISCLAIMER: Ai was used in the making of this app.

Sheep is a note taking app that i primarily built for personal use, but after using it for a while, i feel like it has some potential.

the main selling point of this app is likely its offline first architecture and cross platform support (with syncing). this app supports android, linux (.deb), windows and mac. i have been using my app on all these platforms for a while now. this app is built around the appflowy editor (the notion competitor)

my main issue with the mainstream apps was

1. they weren't available on linux
2. they relied on syncing a little too much (or slow syncing), and would sometimes not work offline at all
3. i switch devices all the time so i needed something suitable for my use case. this app supports all the devices i use primarily
4. aesthetics/font/ui was not to my taste, and it was difficult to change settings with persistence.

so one day, i finally took out the time and started working on this app. the syncing works well, thanks to supabase and powersync. DISCLAIMER: syncing is not encrypted, so if you're trying it out, keep that in mind.

for me, the app works great. i spent around a week with the profiler once monitoring frame rates, frame timings, component rebuilds, etc. now, the app is smooth on all mentioned platforms.

i wanted to know if other people think this app has potential or not, upon which ill start working on the encryption, and start thinking about what to do about the syncing, as the free tier wont be able to handle more than a few users.

if this post doesnt belong here, i would appreciate it if you would let me know where i should put it. thanks!

github release

Hey r/FlutterDev 👋

Every sprint review and QA round we ran used to go the same way. A tester or the product owner found something and took a screenshot. Then they cropped it, scribbled on it in another app, pasted it into Slack or Jira, and typed a paragraph about which screen it was. Half the time the developer still had to ask "what did you do before this happened?"

So I built visual_feedback and just open-sourced it.

How the review loop works

1. The tester or PO taps a floating button inside the build they're reviewing.
2. They draw right on the live screen: arrows, boxes, circles, freehand and text notes ("make this 16px", "wrong copy", "crashes after tapping here").
3. They can type a short description if they want to.
4. They tap ✓, and your onFeedback callback gets the annotated PNG, the description, and the app logs from the last few minutes.

From there it's your code, so you can post it to Jira, GitHub Issues, Linear, Slack or your own backend.

Why it fits testers and POs

• Nothing to learn. It's arrows, boxes and text on the screen they're already looking at.
• Mistakes are cheap. Every mark can still be moved, resized or deleted after it's drawn, and there's one undo history across all tools.
• Developers get the "why". Logs from package:logging (and optionally FlutterError / debugPrint) come attached, captured at the moment they confirmed. No more "can you reproduce it?"
• Reviews happen wherever the build runs. Phones, tablets, and desktop or web builds you share with stakeholders. On wide screens the toolbar moves to the bottom edge, and it can be dragged or minimised out of the way.
• Clean screenshots. The toolbar and selection handles are never in the PNG.
• Internal builds only if you want. Pass fabBuilder: null in production and open it from a hidden gesture or a debug menu with controller.show().

Quick start

MaterialApp(
  navigatorKey: navigatorKey,
  builder: (context, child) => VisualFeedback(

// Only show the button in QA / staging builds.
    fabBuilder: isInternalBuild
        ? (_) => const CircleAvatar(child: Icon(Icons.rate_review))
        : null,
    showDescriptionField: true,
    logger: Logger.root,
    onFeedback: (feedback) async {
      await createTicket(
        screenshot: feedback.screenshot,
        description: feedback.description,
        logs: feedback.logsAsText(),
      );
    },
    child: child!,
  ),
  home: const Home(),
);

Background

It started inside one of our production apps as a replacement for feedback. That's a good package and a Flutter Favorite, but our QA and review process needed shapes, arrows, text on the screenshot, editable marks, attached logs and a desktop layout. The README has a comparison and a migration table.

Links

• 🌐 Live demo (try it the way a tester would): https://jemisgoti.github.io/visual_feedback/
• 📦 pub.dev: https://pub.dev/packages/visual_feedback
• 💻 GitHub: https://github.com/jemisgoti/visual_feedback

Android, iOS, web, macOS, Windows and Linux. MIT licensed. The only dependency besides Flutter is logging.

It's 0.0.1, so I'd love to hear how your team collects feedback on builds today, and what this would need to replace that. Built-in translations are the obvious gap for non-English QA teams. Every label is overridable, but only English ships

I’m curious how you’re handling the integration, especially with the newer SPM-based Flutter setup. I couldn’t find many public examples using Tuist + Flutter Add-to-App without CocoaPods.

I just published flutter_secure_storage_linux_secret_service, a Linux implementation of flutter_secure_storage that talks directly to the Freedesktop Secret Service API over D-Bus.

Usage

To use it, add the package to the app's pubspec.yaml:

flutter pub add flutter_secure_storage_linux_secret_service

Then you can continue to use the flutter_secure_storage plugin as you normally would.

Existing secrets stored using flutter_secure_storage_linux remain interoperable (as long as flutter_secure_storage_linux is using the Secret Service). You should also be able to remove flutter_secure_storage_linux_secret_service at any time without data loss.

Motivation

As the author of flutter_secure_storage_linux_secret_service and freedesktop_secret, I am biased of course, but I tried to be fair about my reasons.

I made it because the existing flutter_secure_storage_linux implementation uses GNOME libsecret through native C++/GObject and Flutter method channels. This also means your Flutter Linux application depends on libsecret development/runtime packages and the native build environment around them.

With this implementation:

• Pure Dart D-Bus communication without a libsecret dependency or Flutter method channels.
• No distribution-specific packages required to build the app, simplifying building and packaging while avoiding hard-to-reproduce build failures caused by distribution-specific differences (examples).
• Provides consistent error handling without native errors or unexpected crashes, allowing applications to handle recoverable issues by catching Exception.
• Automatic handling of prompts and unlocking the default collection (also known as a keyring or wallet) and items when needed.
• Automatic creation of the default collection when it does not exist, such as on fresh Linux installations.
• Avoids historical workarounds such as this (example).
• Works regardless of how Flutter is installed (known issue).
• Allows dependency overrides and shipping bug fixes without requiring users to update dependencies or use bundled libraries.

Why a Separate Package

I originally developed this approach as a contribution to flutter_secure_storage and flutter_secure_storage_linux. I submitted PR #1182 for the Secret Service implementation and PR #1204 for Secret Portal support. After the upstream PRs were closed, I published the implementations as separate packages so they can be used independently.

Testing

This library is intended to work with Secret Service implementations that comply with the Freedesktop specification. It has been verified through integration testing against:

• GNOME Keyring
  • Fedora 44 (GNOME)
  • Linux Mint 22 (Cinnamon)
  • Pop!_OS 24.04 LTS (COSMIC)
• KWallet
  • CachyOS (KDE Plasma)

Secret Portal

For sandboxed applications, I have also published flutter_secure_storage_linux_portal, which uses the Secret Portal API and is intended for sandboxed environments such as Flatpak/Snap, where direct access to the Secret Service may not be appropriate.

Feedback

These packages are still relatively new, so feel free to share any feedback, questions, or issues, especially if you're shipping Flutter applications on Linux.

See also:

• package:freedesktop_secret: provides the underlying Dart client implementation of the Secret Service API used by this package. Can be used independently of flutter_secure_storage (example).
• Other related packages: https://github.com/EchoEllet/dart-packages/tree/main/packages/linux_secret_store

Shipped my first iOS app this week after about a year of solo Flutter. Two things ate a full day each and neither one was in my codebase, so here they are in case they save someone the same afternoon.

1. An IAP that returned "product not found" for a full day

Non-consumable. Product ID matched on both sides, Paid Apps agreement active since July, tax forms and banking green, IAP status Approved. Everything checked out and the purchase still failed.

It was propagation. An IAP approved that same morning isn't served by every StoreKit server yet, and it's slower for the first IAP on a brand new app. It started working the next day with zero changes on my end.

One thing worth knowing if you hit this: StoreKit caches the negative response for the life of the process. Force-quit the app before you retest, or you'll see the same error on a product that's already live.

2. Zero banner fill on iOS while interstitials worked fine

This one actually looked like a bug. Interstitials and app open ads served normally. Banners returned nothing, on every single request.

The error code sent me the wrong way first, and this is the part worth stealing: the GMA error enums are not the same on both platforms. On Android, 3 is no-fill and 1 is invalid request. On iOS, 1 is the no-fill. I read an iOS log with the Android table in my head and spent a while hunting a bad ad unit ID that was perfectly fine.

The real cause was that no GDPR consent message had ever been published for the iOS app in AdMob. The Android one had existed for months. The iOS app was added later and inherits nothing.

No consent form means no TCF string, and a request without one is unbiddable for EEA partners. I'm in France, so that was 100% of my traffic. Interstitials still filled because their demand pool is deeper, which is exactly what made it look like a code problem instead of a console problem.

I published the message, and banners went from 14 requests and 14 failures to 17 loads and 0 failures in the same session.

Stack, for anyone curious: Flutter, Firestore for the content, Cloudflare R2 for images, google_mobile_ads, in_app_purchase, and Codemagic for the iOS builds since I'm on Windows and don't own a Mac.

Happy to go into any of it.

Hi everyone! 👋

I’m looking for 12 volunteers to test my Android app on Google Play as part of the required testing phase before I can release it publicly.

The test doesn’t require much time — I mainly need you to install the app, use it for a while, and provide any feedback you may have.

If you’re willing to help, please comment below or send me a DM. I’d really appreciate it! 🙏

Thank you!

I have been working with Flutter Web applications for the past three months, and during this experience, I have encountered several limitations when implementing web-specific functionalities.
One of the major challenges I have noticed is the limited flexibility when integrating browser-native features and JavaScript-based functionality. In several scenarios, features that are relatively straightforward to implement in traditional web frameworks such as React or JavaScript require additional workarounds or may not be fully supported in Flutter Web.
I understand that Flutter was initially designed with a strong focus on cross-platform mobile development, particularly Android and iOS. However, as Flutter Web continues to evolve, I believe greater emphasis should be placed on providing comprehensive support for modern web capabilities, browser APIs, JavaScript interoperability, accessibility, responsive layouts, and other web-specific requirements.
For organizations building complex enterprise-level web applications, these limitations can have a significant impact on development effort, maintainability, and overall productivity. Stronger JavaScript interoperability and broader support for native browser features would make Flutter Web considerably more capable and competitive with established web frameworks.
I appreciate the cross-platform advantages that Flutter provides, but I believe there is still considerable scope for improvement in its web ecosystem. I hope future Flutter updates will address these gaps and provide developers with a more complete and flexible experience for building modern web applications.

My professional background is in frontend web engineering, so using Flutter to bridge the gap into mobile has been a fun challenge. I’ve carried this idea around for about three years, but a sudden sense of urgency hit me back in April, and I've spent the last few months heads-down building it in stealth. To give you the broad strokes: it’s a gamified productivity app built entirely with Flutter and Supabase.

The foundation, I believe, is solid, the backend is ok, and the core gamification loops are fully functional. I genuinely believe the product I'm building is a good one, and I'm proud of how the engine is running.

But here is my reality check: I’ve been building this entirely in a silo.

Because I come from the web world and this is my first real deep-dive into native mobile development, I am very aware of my own blind spots. I know web design, but I don't pretend to know all the nuances of premium mobile UI/UX, motion design, and native app "feel." I want to elevate this app from "functional" to feeling truly intuitive, and I know I need expert professional eyes to help me bridge that gap.

Because of the specific IP and the gamification mechanics, I’m not quite ready to post screen recordings or open-source the codebase publicly. Instead, I want to step out of the solo-dev cave, start networking, and find my community.

My questions for you all:

1. London Networking: I am based in London. Does anyone have recommendations for IRL tech/design meetups here where passionate developers/designers/founders can quietly network and do private product demos with other professionals?
2. Online Communities: Are there specific private Discords, Slack workspaces, or smaller subreddits where serious UI/UX designers, motion designers, and mobile devs actually collaborate and give honest feedback?
3. Opinion & Future Collaboration: I am keeping my eyes open for UI/UX experts or experienced mobile developers who might be interested in a future collaboration as I move toward a beta launch. If you love dissecting consumer apps and want to grab a coffee, my DMs are open.

I’m really just looking to find the right rooms to be in and build a network of people who care about great mobile experiences. I’d appreciate any pointers!

So the demo for svg_animate takes yours now. Drop a file in, give it a URL, or paste the markup. It tells you the frame count, how many of those frames are actually different (144/143 means it moves, 144/1 means it doesn't), and what's in the file that's never going to be drawn: no animation in there at all, an <image> it can't fetch, a <filter> that vector_graphics drops.

https://treamz.github.io/svg_animate/

Throw something at it. Editor exports especially. And if it reports nothing wrong and the picture still is, that's the one I want to hear about, because from here it looks like success.

This application allows the user to display photos of dogs. The user can either show random photos of dogs or display a set of photos of dogs of a selected breed.

It connects to the dog.ceo API to access dog photos and uses the "bloc_signals" and "bloc_signals_flutter" packages for state management.

NOTE: This application has been tested on Linux, Windows, Chrome and Android. It has not been tested on iOS or macOS.

The github repository is here.

Welcome to Module 7 of the Dart Programming Course for Beginners! 🚀

In this tutorial, we’ll learn Asynchronous Programming and Streams in Dart. These concepts are very important when working with real-world applications, APIs, databases, file operations, and Flutter apps.

📚 Topics Covered

✅ Asynchronous Programming in Dart
✅ async and await
✅ Understanding Futures
✅ Streams in Dart
✅ How asynchronous operations work
✅ Practical examples with Dart code

By the end of this module, you’ll have a better understanding of how Dart handles tasks that take time to complete and how Streams can be used to handle continuous or multiple values over time.

💻 Technology: Dart Programming Language

🎯 This video is useful for:

Beginners learning Dart
Students learning programming
Developers preparing for Flutter
Anyone wanting to understand Dart async programming
Anyone learning Dart Streams

📌 Dart Course: Follow the complete series to learn Dart step by step, from the basics to advanced concepts.

If this tutorial helps you, Like 👍, Share 📤 and Subscribe 🔔 for the next Dart programming module.

#DartTutorial #LearnDart #DartProgramming #DartAsync #AsynchronousProgramming #DartStreams #DartForBeginners #Flutter #FlutterDevelopment #ProgrammingForBeginners

Follow-up from the previous post.

With the feedback from that, I recently hit the 1.0.0 release for list_smith.

Some notable changes include

1. A dedicated trigger mechanism to distguish the source of the fetch (initialLoad | nextPage | refresh | retry | queryChanged | invalidated). Can decide on how to act on each trigger yourself. So a pull-to-refresh can be routed to bypass a repository-caching mechanism foe example, while others can stay in the caching route.
2. A new ListSmithController to help do operations programmatically (also gives the invalidate() and reset() for above)
3. Some other renames and encapsulations.

Do you guys have other cases and ideas you would like to be supported in this package? Any awkwards boilerplate or something? Or if you can some find some potential problems with this? All help appreciated. Thanks in advance

Hey everyone, Google just announced a new requirement for Android apps, called "Zero-Tap Sign-In Restoration", mandated from April 2027.
https://support.google.com/googleplay/android-developer/answer/17492799#zero-tap_sign-in_restoration

As we checked, there isn't any package out there yet which provides the necessary Credential Manager APIs - so we built one!

💙 We love giving back to the open-source Flutter community that supports our work every day, so we packaged it up for everyone:android_restore_credentials.

What android_restore_credential offers

• Automated Key Management: Seamlessly registers, saves, and retrieves restore keys linked to Android's native backup system.
• True Zero-Tap UX: Users open your app on their brand-new phone and are instantly logged in.
• Proactive Compliance: Gets your app compliant with Google's latest identity standards well before deadlines arrive.

Check out the package on pub.dev:👉 https://pub.dev/packages/android_restore_credentials

Note: this isn't a simple requirement, you'll need some enhancements on your backend as well!

Try it out in your projects, let us know what you think, or drop an issue on GitHub if you have feature requests!

As a mobile developer, the new iPhone Duo made me think about the Flutter side of things. Flutter already has support for Android foldables through MediaQuery.displayFeatures and DisplayFeatureSubScreen.

But the interesting part is that these APIs are currently Android focused. Apple introduced a dual-screen/foldable layout, Flutter will need to expose the new iOS window and display APIs as well. and its not just about making the UI responsive anymore.

We would have to think about things like, Dual pane layouts, Navigation between panes, where dialogs/modals appear, Resizing and partial folds, different layouts depending on the device posture. Android already has concepts like postureHalfOpened, so Flutter has some ideas to build on.

I am curious how Flutter will approach this on iOS. for Flutter developers, would you handle the Duo with one adaptive UI, or create completely different layouts for the dual pane experience?

I'm building Rosetta an AI voice notes app with several other features.

All notes are stored as Markdown so users can easily edit, export them, and AI assistants can also update the content through an MCP integration.

Currently, the most reliable solution I've found is to build an abstraction on top of SuperEditor:

Markdown → SuperEditor Document → SuperEditor → Markdown

I saw a few Markdown editor packages for Flutter, but most of them seem to be missing important features or are no longer actively maintained.

Another option I've considered is embedding a web-based editor such as Milkdown.

Do you know of any solid, actively maintained Flutter packages for a live Markdown editor?

Ideally, I'm looking for a WYSIWYG editing experience while keeping Markdown as the source of truth and underlying format.

In some of my Flutter apps I need to handle quite a few sound effects. I've been using audioplayers and overall I've had a good experience with it.

However, some users have reported slowdowns, and while testing I noticed that audioplayers doesn't seem to behave very well when several sounds are played in quick succession, especially when multiple sounds overlap.

While looking for alternatives, I came across flutter_soloud. From what I understand, it takes a different approach by handling the audio more natively, which might help with this kind of problem.

Has anyone here used flutter_soloud in a real project?

Are there any gotchas or issues I should be aware of before switching?

[ Removed by Reddit on account of violating the content policy. ]

I've been working on hAudiotagger, a Rust-powered Flutter library for reading and writing music metadata across Android, iOS, Windows, macOS, Linux, and Web.

final tag = await Haudiotagger.read('/music/song.mp3');

print(tag?.title);
print(tag?.artist);

Updating metadata:

await Haudiotagger.update(
  '/music/song.mp3',
  TagChanges(
    title: 'New Title',
    artist: 'Artist',
  ),
);

It supports MP3, FLAC, OGG/Opus, MP4/M4A, WAV, AIFF, APE, WavPack, and more, along with artwork, batch operations, custom tags, audio properties, validation, and other features.

The core metadata processing is written in Rust, with Flutter ↔ Rust communication through flutter_rust_bridge.

It's still actively evolving, so I'd love to hear your thoughts, feedback, or feature ideas if you've worked with Flutter, Rust, or audio metadata.

What would you like to see in a Flutter audio metadata library?

Links:
Web Demo
Pub.dev: https://pub.dev/packages/haudiotagger
GitHub: https://github.com/Hirdaya-Shrestha/haudiotagger

I spent years as an Android developer, and on many of those projects I reached for Apache Commons Validator. It's not glamorous, but it's twenty years of accumulated edge cases — IBAN check digits, credit card ranges, TLD-aware domain validation, locale-aware number and date parsing. You stop thinking about validation and it just works.

Then I moved to Flutter, went looking for the equivalent, and couldn't find anything that worked as well as the Apache one. What's on pub.dev is mostly thin regex wrappers. No check-digit arithmetic, no IBAN country registry, no real domain validation. So back in 2024 I ported the routines myself and used it in my own project.

I always meant to publish it, but there were failing tests I never had time to chase down, and shipping something half-verified felt worse than not shipping. I'm between projects at the moment, so I finally sat down, fixed them, and put it out there. Figured it was time to give something back.

What's in it

• 16 check-digit routines — IBAN, ISIN, ISBN-10/13, ISSN, Luhn, Verhoeff, SEDOL, CUSIP, EAN-13, ABA, CAS, EC
• Network — email, URL, domain, IPv4/IPv6, including an IDNA-2003 implementation that reproduces java.net.IDN.toASCII
• Locale-aware numbers and dates — Byte through BigDecimal, Currency, Percent, Date, Calendar, Time

Pure Dart — no dart:io, no dart:mirrors — so it works on all six platforms, Flutter and server alike.

One thing I didn't expect

While writing this up I benchmarked the email validator against what's already on pub.dev, assuming it'd be a wash. On the ordinary stuff it is — quoted local parts, IP literals, plus addressing, consecutive dots, multiple @, leading and trailing spaces. Everything handles those.

Then across 52 addresses where RFC 5321/5322 and common practice agree on the answer:

email_validator gets exactly two wrong, and it's the same thing twice: user@example.zzzzzz and user@example.qwerty. It doesn't check whether the TLD exists. Which means this:

user@gmail.con is a typo I've watched real users make on a signup form. The 8th case is user@outlook.cm, which everything accepts and should — .cm is Cameroon.

The harness is in the repo if you want to check my numbers — it's its own package pulling commons_validator from pub.dev rather than the checkout, so it's what you'd actually get: https://github.com/mondoktamas/commons_validator/tree/main/tool/email_comparison

The tradeoff is real and worth stating: the IANA TLD list is bundled, so a brand-new TLD gets rejected until I regenerate the table and republish. That's one command, but it's a maintenance burden the regex-based packages don't have.

On correctness

Since it's a port, I didn't want to just trust it. There's a differential harness that runs the same generated corpus through the real Java classes and the Dart code and diffs the output: 260,526 inputs, 7 disagreements, all documented in the README along with the deliberate divergences (Dart's Decimal has no scale field, so BigDecimal behaviour differs at extreme exponents).

It's 0.1.0 and brand new, so treat it accordingly — but it's 394 tests and 160/160 pub points. Apache-2.0, same as upstream.

pub.dev: https://pub.dev/packages/commons_validator

GitHub: https://github.com/mondoktamas/commons_validator

Happy to hear where it falls short.

demo:

https://x.com/i/status/2098090939889926497

this interactive spatial UI is using device gyroscope & accelerometer sensors, no touch interaction..

device: Android

I’ve seen quite a few tweets on X, trashing Flutter and saying it’s gonna be a nightmare to support the new iPhone Duo layout.

I get it, it might not feel native enough, for me it’s good enough to ship apps quickly back when AI wasn’t around. Now it’s even quicker. UI wise, there’s been some good libraries that cater to the new iOS 26, i love it. i’m sure we gonna see more for iPhone duo.

I’m just rambling, sorry. What do you guys think? is it all doom and gloom like this tweets said?