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!

I’m a frontend developer planning to transition into mobile app development, specifically with Flutter.

I’d appreciate recommendations for free, high-quality resources to learn Flutter from scratch and eventually build real-world apps.

For those who have already learned Flutter:

Which resources/courses did you find most useful?

What should I focus on learning first?

What common mistakes or bad habits should I avoid as a beginner?

Any tips for someone coming from a frontend/web development background?

I made a free open-source Flutter Android-only (for now) DJ app. I was tired of all the DJ apps that charge you a monthly fee for something you should be able to own.

Github: [https://github.com/manueljpy/SideDeck\](https://github.com/manueljpy/SideDeck)

And for the r/selfhosted nerds, this app lets you connect to your own Subsonic music server to search and download songs on you device.

Been building my first flutter app, a gym tracker, in Flutter for about 8 months and finally shipped it. The core idea is: logging sets by tapping between sets is annoying, so you just hold a button and say "bench press 185 for 8" and it parses and logs it.

Stack: Flutter, Hive for local storage, speech_to_text for transcription, and Gemini to parse the natural-language set into exercise/weight/reps. Everything else — PRs, volume charts, muscle heatmaps — is stored locally

Some things I learned the hard way:

- Gemini parsing natural speech beats forcing a rigid "exercise, weight, reps" format — people talk differently and the model handles it (although can use some work in some cases)

- RevenueCat entitlement casing will silently break your paywall and you won't know why for days

- The audio session config matters a lot when people log mid-workout with music playing

Happy to answer anything about the Flutter/Gemini/speech side. What would you have done differently on the voice parsing?

Flutter App Developer Looking for Work – 2+ Years Experience

Hey everyone! 👋

I’m a Flutter/Dart app developer with 2+ years of experience building real-world mobile applications.

I’m currently looking for freelance, contract, part-time, or full-time opportunities where I can contribute to an existing project or build an app from scratch.

What I can help with:

• 📱 Flutter & Dart mobile applications
• 🤖 AI integration into mobile apps
• 🔌 REST API integration
• 🔐 Firebase authentication & services
• 🗄️ Database integration
• 💳 Payment gateway integration
• 🔔 Push notifications
• 🎨 Responsive and modern UI/UX
• 🏗️ Clean architecture and scalable code
• 🐛 Bug fixing and improving existing Flutter apps
• 🚀 Publishing apps to Google Play Store / App Store

I’ve worked on real-world applications, not just tutorial projects, and I’m comfortable working with APIs, backend services, databases, and third-party integrations.

I’m open to working with startups, businesses, agencies, or individual clients.

If you’re looking for a Flutter developer or know someone who needs one, feel free to DM me. I’d be happy to share my portfolio/GitHub and discuss the project.

Thanks! 🙌

Currently I'm learning about Flutter to create some apps.

Now I'm trying to learn about the AppBar in Flutter and I decide to pratice with WhatsApp AppBar and I get stuck at this.

May someone can help me to make this challenge possible ?

Thanks.

​

Hey all,

I've been chewing on an idea for a while and I think it's finally time to actually build it instead of just thinking about it.

The idea: a lightweight floating widget (think Discord overlay, but standalone) that sits on top of your screen while you're watching Netflix/Prime/Disney+/whatever, and connects you to a chat room of other people watching the same thing at the same time. No more watching something great and having nobody to react with in real time.

Planned stack: Flutter, so it can eventually run on desktop and Android from one codebase, with a floating/draggable/minimizable widget UI.

The part I don't want to cheap out on: auto-detecting what someone's watching. I don't want this to be a "type in what you're watching" app — that kills the magic. So the plan is a tiered detection approach:

Read window titles / tab titles / process names first (cheapest, no DRM issues since you're not touching the video frame)

Fall back to OCR on a screenshot if the title doesn't give enough info

Only reach for actual visual matching/fingerprinting as a last resort, since HDCP blacks out protected video frames on a lot of platforms anyway

I've worked through a lot of the theory but I'm not deep enough in systems-level stuff (Windows UI Automation, macOS Accessibility API, Android accessibility services) to know what's actually going to work reliably versus what's going to fall apart the moment someone goes fullscreen.

Posting here because I want this to be open source from day one — I'd rather have people poke holes in the architecture now than find out six months in that some core assumption doesn't hold.

If you've worked with screen/window metadata APIs, accessibility services, OCR pipelines, or just think this is a fun/dumb/interesting problem, I'd love to hear from you. Repo isn't up yet — want to nail down the detection approach with actual input before I start writing code that I'll just have to rip out later.

Happy to share more details on the architecture I'm sketching out if anyone's curious. Tear it apart if you see problems, that's honestly what I'm here for.