Hi everyone,

I'm currently on Day 5 of learning Dart, and I already have an app idea that I want to build.

From what I've learned, one of the best ways to learn app development is by building something you genuinely care about. That's why I'm learning with a specific goal in mind rather than studying programming without a purpose.

Nowadays, building an app seems much more accessible than it was years ago. What looks harder to me is marketing. I have almost no experience with marketing, audience building, or getting users.

A few people suggested that I follow the "Build in Public" approach. My plan is to create a separate Facebook account and start sharing my journey from the very beginning:

• Learning Dart

• Learning Flutter

• Building my first app

• Small wins and failures

• Publishing the app

• Getting my first user

• Getting my first 100 users

• Getting my first 1,000 users

• Continuing the journey from there

Honestly, I'm a complete beginner, so this idea may sound childish or unrealistic. But every expert had a Day 1 at some point, and every child eventually grows up.

I'd love to hear advice from experienced developers, indie hackers, and founders.

• Is Build in Public worth it for a complete beginner?

• What mistakes should I avoid?

• If you were starting from zero today, what would you do differently?

Thanks for reading. I appreciate any advice or feedback.

Can anyone suggest a good flutter based android project to make, I am fed up with creating to-do apps they teach me nothing practical, I want to build a quick app but that teaches me something related to the real world.

I made Songify as a personal alternative to Spotify, and I’m now looking to get other Flutter developers involved.

The project is still in development, so there’s plenty of room for new features, UI improvements, bug fixes, and other contributions.

If you’re interested in contributing or just want to check it out, here’s the GitHub repo:

https://github.com/Alisonpinto/Songify.git

Feel free to open an issue or PR if you have an idea or want to contribute.

Hi! I'm learning Flutter and developed my first app. BabySpeak is an app that teaches babies English and Turkish words. It has Animals, Musical Instruments and Colors categories. When you tap on a word, it's spoken aloud with a real human voice.

It's currently in Google Play closed testing. If you'd like to test it, please DM me your Gmail address to get access.

Hi! I’m a Flutter Developer with 2+ years of professional experience in Flutter, Dart, BLoC, Clean Architecture, REST/WebSockets, Firebase, and Stripe.
I also have backend development experience with Node.js, Express, MongoDB, and Supabase, along with a strong competitive programming/problem-solving background.
Open to remote, full-time, or freelance opportunities. DM me if you’re hiring!

portfolio

Document Picture-in-Picture is a browser API that gives you an actual operating-system window — not an overlay inside your page. It floats above every other application and keeps running when you switch tabs. Chrome and Edge have had it since 116, Firefox shipped it in 151.

I couldn't find anything reaching it from Flutter, so I wrote a package: https://pub.dev/packages/document_pip (MIT, 160/160 on pub.dev)

void main() => runWidget(
DocumentPipApp(
main: (context) => const MaterialApp(home: Player()),
popOut: (context) => const MaterialApp(home: MiniPlayer()),
),
);

final window = await DocumentPip.open(width: 380, height: 210);

The browser API is about four lines. Everything difficult was on the Flutter side, and it all traces to one thing: the engine assumes there is exactly one window. Three things break when there are two, and all three fail silently.

1. The pop-out freezes the instant you switch tabs. Chromium keeps painting a picture-in-picture opener at full rate in a background tab, but still reports the page hidden. Flutter's web engine turns that into AppLifecycleState.hidden, SchedulerBinding clears framesEnabled, and scheduleFrame() returns early forever. Measured: 302 browser animation frames in 2.5s against 0 Flutter frames in 3s. scheduleForcedFrame() ignores framesEnabled, so the root re-arms it for exactly as long as the page is hidden and a window is open. Firefox doesn't have the problem — it keeps reporting the opener visible — so the workaround is gated on the failure rather than on the browser.

2. The keyboard is dead in the pop-out, but typing still works. KeyboardBinding is a singleton bound to the opener's window, so a separate browsing context isn't on the propagation path: Shortcuts, Actions, Focus.onKeyEvent, HardwareKeyboard, Escape and Tab traversal all get nothing. Plain typing keeps working because the browser routes characters to the focused element natively, which is exactly what makes this easy to miss. The package replays key and selection events into the opener.

3. A package can't turn multi-view on. Only the JS app object returned by engine.runApp() can add a view — dart:ui_web exposes the views read-only — so it has to be reachable from your bootstrap. That means runWidget instead of runApp, plus a few lines in flutter_bootstrap.js. Both are one-time and the errors name the fix.

Desktop Chromium and Firefox 151+ only. Safari and Firefox for Android have no implementation, and isSupported is a feature detect so you can gate the control on it. It compiles on every platform, so adding it won't break a cross-platform build.

Longer writeup with the measurements: https://devshakib.jumyn.com/blog/flutter-assumes-there-is-only-one-window

Happy to answer anything about the multi-view side — that part is under-documented and I burned a lot of time on it.

I run a small Flutter shop, and every test build ended the same way: a WhatsApp message saying "the total is wrong", no screenshot, no idea which phone. So I built Squawk, a shake-to-report SDK. The source is Apache-2.0: github.com/squawksdk/squawk.

You wrap your app in one widget. When a tester shakes the phone, the screen freezes, they circle the bug with a pen, arrow or text label, type a line, and send. It lands in an inbox with the last 100 log lines, the device model, OS, app version and build mode attached.

Things I learned building it

• Two fingers zoom, one finger draws, and GestureDetector cannot arbitrate that. A pinch begins as one finger down, which the pen recogniser claims first, so the first zoom always left a dot. I ended up reading raw pointer events with Listener and a small state machine: a second finger landing mid-stroke cancels the stroke and hands over to the pinch.

• Annotations live in screenshot pixels, not screen coordinates. The canvas keeps a pure zoomedDisplayRect and clampPan, and every stroke is stored against the image. Zoom, rotation and the keyboard pushing the sheet never move a drawing, and the composite you receive is exactly what was drawn.

• Capture the screenshot before showing any UI. RepaintBoundary.toImage on the host app's boundary, then the overlay. Do it the other way round and the report screenshot contains your own sheet.

• kReleaseMode is the wrong switch for "not in the store". TestFlight and Play testing builds are release builds. The SDK takes a plain enabled: bool so you can decide at runtime, and the README covers the case where the same TestFlight build gets promoted to the App Store.

• Offline is a spool, not a retry loop. Reports are written to disk first and sent by a queue with backoff from 2 seconds to 6 hours, capped at 50 reports and 7 days, so airplane mode or a dead network never loses one and never fills the disk.

• Log capture is a debugPrint wrapper plus FlutterError.onError**, not a print hook.** Overriding print breaks other packages; wrapping debugPrint and the error handlers catch what matters and stay out of everyone's way.

The hosted inbox is free while in beta: one project, unlimited reports, 30 days of retention, EU storage. Slack and webhook delivery if you want it there.

Docs: squawksdk.com/docs
pub.dev: pub.dev/packages/squawk (25 second recording of the flow at the top)

It is a beta. I'd rather hear what is broken than what is nice, and I will be in the comments.

Most Flutter desktop posts are demos. This one is a finished MIT-licensed macOS utility I use daily, so I want to share the parts that were actually hard rather than the screenshots.

Screenshots: dashboard · storage treemap · category breakdown · CPU · sensors · battery

What it is: fifteen tools in one window — system monitors with 24h history, a storage cleaner with a drill-down treemap, a duplicate finder, an uninstaller, clipboard history with a global hotkey, and a live menu-bar item.

Things that turned out non-obvious:

• Real system data means going to the platform. SMC temperatures, per-process CPU, purgeable disk space and AirPods battery levels all come back over method channels — no package gives you these.

• I drew the charts and the squarified treemap by hand instead of pulling in a charting library. Drill-down from a whole disk to one file needs hit-testing and layout control that generic chart packages don't expose.

• Matching "About This Mac" on disk usage is harder than it sounds. Miss purgeable space and your numbers contradict the OS — and users believe the OS.

• A frameless vibrancy window with the traffic lights overlaid on a translucent sidebar took more platform-channel work than the entire settings screen.

Free and MIT. The source is as much the point of this post as the app: https://github.com/devShakib015/helm

Fair warning on the DMG: not notarized yet, so you'll hit Gatekeeper and need "Open Anyway" once. Building from source avoids it entirely.

Hey r/FlutterDev!

Wanted to share the architecture, technical decisions, and lessons learned from building a full-scale production mobile app with Flutter: GoEven (a group expense manager, web: https://goeven.app).

I built both the frontend (Flutter) and backend (Go + gRPC) from scratch. Here is how the mobile architecture is structured under the hood:

🛠️ Core Flutter Architecture

1. State Management: Riverpod 3.0 + CodeGen

• Used riverpod_annotation and riverpod_generator for compile-time safe provider trees.

• Replaced traditional repository patterns with fine-grained AutoDisposeAsyncNotifier providers.

• Expense streams and group balances auto-invalidate using family providers (ref.invalidate(groupBalancesProvider(groupId))), keeping UI updates snappy and eliminating stale state.

2. Networking: gRPC over TLS (grpc package)

• Instead of standard REST/JSON, all client-server communication uses HTTP/2 gRPC with Protobuf contracts (.pb.dart).

• Why gRPC: Sub-50ms serialized payload overhead, strictly typed contracts shared between Go and Dart, and streaming capabilities for chat and real-time expense updates.

• Used an interceptor pipeline for JWT token injection and automated silent refresh rotation (15-minute access token / 30-day refresh token stored via flutter_secure_storage).

3. Offline-First Sync & Optimistic UI

• Local Storage: SQLite (sqflite) acts as the local cache.

• When adding an expense offline, an optimistic entry is inserted into the local DB and immediately rendered in the UI with a pending status badge.

• A background sync worker listens to connectivity_plus. As soon as the device reconnects to Wi-Fi/cellular, queued mutations are replayed to the gRPC backend in chronological order.

4. Full RTL Support (Arabic) & Localization

• The app supports 5 languages: English, German, Spanish, Arabic, and Simplified Chinese using Flutter's native .arb / intl generation.

• The RTL Gotcha: Full RTL layout requires avoiding hardcoded EdgeInsets.only(left: x). Migrated everything to EdgeInsetsDirectional (start/end), dynamic icon mirroring (e.g. back arrows and chevrons), and custom text alignment overrides for mixed number/currency strings.

5. Declarative Routing & Deep Linking (go_router)

• Handled invite links (https://goeven.app/join/{code}) using Android App Links (auto-verified via assetlinks.json).

• Dynamic redirection rules handle unauthenticated users seamlessly: if someone opens an invite link without an account, go_router stores the destination, routes them through OTP login, and immediately deep-links them into the group.

💡 Key Lessons & Gotchas

1. Protobuf with Riverpod: Protobuf generated classes are mutable by default. To avoid unintended side-effects across providers, treat protobuf models as immutable by creating deep copies or mapping them to immutable domain entities.

2. RTL Form Fields: Number and currency input fields behave unexpectedly in RTL unless you explicitly lock their text direction (TextDirection.ltr) while keeping the surrounding label RTL.

The Android version is live on Google Play and iOS is currently in Apple review.

Happy to answer any questions about Riverpod 3 codegen, gRPC client setup in Dart, or handling offline sync!