Flutter Trending
Flutter 趋势
汇总 GitHub、Dev.to、freeCodeCamp、Hacker News、Medium、Reddit 的近期热门内容。
GitHub
20 条Dart 与 Flutter 相关仓库热度
chen08209/FlClash
更新于 07/22 06:32
localsend/localsend
更新于 07/22 06:32
spotiflacapp/SpotiFLAC-Mobile
更新于 07/22 06:09
Predidit/Kazumi
更新于 07/22 06:00
AppFlowy-IO/AppFlowy
更新于 07/22 06:25
flutter/flutter
更新于 07/22 06:46
bggRGjQaUbCoE/PiliPlus
更新于 07/22 01:32
KaringX/karing
更新于 07/22 02:48
KRTirtho/spotube
更新于 07/22 05:39
echo-loop/Echo-Loop
更新于 07/21 23:05
hiddify/hiddify-app
更新于 07/22 06:11
ente/ente
更新于 07/22 06:45
bagisto/opensource-ecommerce-mobile-app
更新于 07/22 03:36
KaringX/clashmi
更新于 07/22 06:06
ImranR98/Obtainium
更新于 07/22 03:29
Sle2p/AniCh
更新于 07/22 01:45
Chevey339/kelivo
更新于 07/22 01:42
simonoppowa/OpenNutriTracker
更新于 07/22 04:36
venera-app/venera
更新于 07/22 03:02
jiangtian616/JHenTai
更新于 07/21 22:10
Dev.to
12 条开发者文章与项目分享
Beyond Flutter: Running BlocSignal State Machines in Pure Dart, Jaspr Web, and CLI Tools
Randal L. Schwartz
Universal State Management for Every Dart Platform For years, developers have associated state management almost exclusively with Flutter UI widgets. While core packages like package:bloc are technically pure Dart, running stream-based state machines in non-UI Dart environments often feels clunky. Handling asynchronous streams (bloc.stream.listen) in CLI tools, Jaspr web apps, or server backends requires managing manual subscriptions and dealing with microtask event queue delays. Modern Dart is far more than a Flutter UI engine. Dart now powers: 🖥️ CLI Tools & Automation Scripts 🌐 Web Applications via Jaspr (the Dart web framework for SSR & static sites) ☁️ Server-Side Backends via Serverpod or Dart Frog 📦 Shared Domain Libraries & Full-Stack Monorepos With BlocSignal, running state machines across pure Dart targets becomes effortless. By replacing asynchronous stream pipelines with synchronous, reactive signals, BlocSignal brings 0ms synchronous state reads (.stateValue), declarative computed() composition, and universal DevTools telemetry to every Dart platform! In this article, we’ll explore how BlocSignal unlocks universal state management across CLI tools, Jaspr web apps, server backends, and Flutter applications with zero code duplication. package:bloc_signals) BlocSignal is designed around strict package separation: ┌─────────────────────────────────────────────────────────────┐ │ bloc_signals (100% Pure Dart) │ │ - BlocSignalBase, CubitSignal, BlocSignal │ │ - Signal<T>, ReadonlySignal<T>, computed() │ │ - Streamless Transformers (droppable, restartable, Mutex) │ │ - DevTools & Observer Hooks (dart:developer) │ └──────────────────────────────┬──────────────────────────────┘ │ ┌───────────────────────┴───────────────────────┐ ▼ ▼ bloc_signals_flutter bloc_signals_riverpod (Widget bindings, SignalBuilder, (Bidirectional Riverpod BlocSignalProvider, context.select) Interop Adapters) package:bloc_signals (Core): Has zero dependencies on the Flutter SDK. It compiles natively for Dart VM, Dart Web (dart2js / dart2wasm), and CLI executables. package:bloc_signals_flutter (Flutter Bindings): Adds optional Flutter UI wrappers (SignalBuilder, BlocSignalProvider, context.select) for Flutter applications. Because the core engine lives in pure Dart, your business logic, event handlers, and signal graphs can be shared 100% untouched between your server, CLI, web, and mobile targets! Imagine building a CLI deployment tool or background task runner in Dart. You want predictable state transitions, logging observers, and event queuing without needing Flutter UI. With bloc_signals, you build your state machine directly in pure Dart: import 'dart:async'; import 'package:bloc_signals/bloc_signals.dart'; // 1. Define Events & State sealed class DeployEvent {} class StartDeploy extends DeployEvent {} class StepCompleted extends DeployEvent { final String step; StepCompleted(this.step); } class DeployState { final String status; final List<String> completedSteps; const DeployState({this.status = 'Idle', this.completedSteps = const []}); } // 2. Pure Dart BLoC State Machine class DeployBloc extends BlocSignal<DeployEvent, DeployState> { DeployBloc() : super(const DeployState()) { on<StartDeploy>((event, emit) async { emit(DeployState(status: 'Running', completedSteps: stateValue.completedSteps)); await _runStep('Compiling Assets'); emit(DeployState(status: 'Running', completedSteps: [...stateValue.completedSteps, 'Compiling Assets'])); await _runStep('Uploading Bundle'); emit(DeployState(status: 'Finished', completedSteps: [...stateValue.completedSteps, 'Uploading Bundle'])); }); } Future<void> _runStep(String name) async { await Future.delayed(const Duration(milliseconds: 500)); } } // 3. Run in CLI main() Future<void> main() async { // Attach observer for automatic console logging BlocSignalObserver.observer = StandardLogObserver(); final deployer = DeployBloc(); // Watch state synchronously via signal! deployer.state.subscribe((state) { print('--> CLI Status Update: ${state.status} (${state.completedSteps.length} steps complete)'); }); deployer.add(StartDeploy()); await Future.delayed(const Duration(seconds: 2)); await deployer.close(); } class StandardLogObserver extends BlocSignalObserver { @override void onTransition(BlocSignalBase bloc, Transition transition) { print('[LOG] ${bloc.runtimeType}: ${transition.currentState.status} -> ${transition.nextState.status}'); } } Running dart run bin/deploy.dart executes the BLoC state machine natively with full observer logging—zero Flutter engine required! Jaspr is the modern Dart web framework that enables server-side rendering (SSR), s
Introducing fossui: a Flutter UI kit that doesn't look like Material
fossui
Every Flutter app looks like Material, because Material is what you get for free. For the last few months we've been building an alternative. It's called fossui: a small, open-source Flutter UI kit for the apps that would rather not look like every other Flutter app. 30+ components, one dependency, no icon package Framework-agnostic: it reads its own theme, so it drops into a MaterialApp, a CupertinoApp, or a bare WidgetsApp A neutral look with superellipse (squircle) corners, light and dark out of the box Built for the AI era: an MCP server and skills, so coding agents write it with the right variants instead of guessing the API Most Flutter component libraries ask you to buy into their world, wrap your app, or drive ThemeData directly. We wanted the opposite: components that respect a theme you already control, whether or not you're on MaterialApp. Retheme once at the root, and the whole set follows. Docs at fossui.org, with a rendered light and dark preview for every component A playground and theme builder at play.fossui.org, recolor the whole set live and copy the theme out An MCP server so coding agents scaffold and theme fossui correctly on the first try Young, mobile-first, and built by a team of two. Web and desktop compile and should work, but they're less exercised than mobile. What would make or break fossui for your next Flutter app? Site: https://fossui.org Package: https://pub.dev/packages/fossui Source: https://github.com/fossui/fossui
Why ValueNotifier Fails at Scale: The Non-Composability Problem (and How Signals Fix It)
Randal L. Schwartz
From Listener Spaghetti to Declarative Reactive Composition When Flutter developers start building applications, ValueNotifier<T> and ValueListenableBuilder often seem like the perfect lightweight solution. Built directly into the Flutter SDK, ValueNotifier holds a single piece of data, notifies listeners when updated, and requires zero third-party dependencies. For simple isolated state—like toggling a switch or incrementing a counter—ValueNotifier works fine. 💡 The Pure Dart Limitation: Because ValueNotifier and ValueListenable are defined inside package:flutter/foundation.dart, they are tightly coupled to the Flutter SDK. For pure Dart projects (CLI tools, server backends like Dart Frog, or Jaspr web applications), ValueNotifier is completely unavailable. Signals and bloc_signals, by contrast, are pure Dart primitives that run anywhere Dart runs! However, as applications grow beyond trivial counter demos, developers inevitably run into a major architectural brick wall: ValueNotifier is fundamentally non-composable. In this article, we’ll analyze why ValueNotifier fails as application complexity scales, how reactive signals solve the non-composability problem at first principles, and how BlocSignal combines signal speed with enterprise BLoC discipline. ValueNotifier Fails at Scale The moment your UI state depends on more than one piece of data, ValueNotifier starts showing its structural flaws. Suppose you have a user profile form with firstNameNotifier and lastNameNotifier, and you want to compute a derived fullName or isValid property. Because ValueNotifier cannot observe other notifiers automatically, you must manually wire up listener callbacks: class ProfileController { final firstNameNotifier = ValueNotifier<String>(''); final lastNameNotifier = ValueNotifier<String>(''); final fullNameNotifier = ValueNotifier<String>(''); ProfileController() { // Manual wiring required for every single dependency! firstNameNotifier.addListener(_updateFullName); lastNameNotifier.addListener(_updateFullName); } void _updateFullName() { fullNameNotifier.value = '${firstNameNotifier.value} ${lastNameNotifier.value}'; } } Notice what happened here: You had to manually write helper methods (_updateFullName) to bridge data updates. You had to manually attach addListener calls for every dependent field. As dependencies grow (N fields feeding into M derived properties), the boilerplate grows quadratically (O(N × M)), quickly degrading into fragile callback spaghetti. ValueNotifier maintains an internal list of callback listeners using strong references. If you attach a listener callback, you MUST manually remove it when the controller or widget is disposed: void dispose() { // Forget any of these, and your objects leak in memory! firstNameNotifier.removeListener(_updateFullName); lastNameNotifier.removeListener(_updateFullName); firstNameNotifier.dispose(); lastNameNotifier.dispose(); fullNameNotifier.dispose(); } Forgetting even a single removeListener call leaves an active callback reference in memory, preventing garbage collection and creating insidious, hard-to-trace memory leaks in production. ValueListenableBuilder Pyramids of Doom When consuming multiple ValueNotifiers in the Flutter UI layer, standard widgets force deep nesting: // ❌ Nested builder pyramid of doom! ValueListenableBuilder<String>( valueListenable: controller.firstNameNotifier, builder: (context, firstName, _) { return ValueListenableBuilder<String>( valueListenable: controller.lastNameNotifier, builder: (context, lastName, _) { return Text('User: $firstName $lastName'); }, ); }, ) Combining 3 or 4 ValueNotifier fields leads to 4-level deep widget indentation, harming code readability and making refactoring a headache. Signals eliminate the root cause of these problems by introducing automatic dynamic dependency tracking and declarative computed state. In a signals-based architecture: Signals track dependencies dynamically when their .value is read. There are no manual addListener or removeListener calls. Derived state is expressed declaratively using computed(). computed Here is how the exact same derived fullName logic looks with signals: final firstName = signal(''); final lastName = signal(''); // ✨ 1 line of code! Automatically tracks firstName and lastName! final fullName = computed(() => '${firstName.value} ${lastName.value}'); Look at how much simpler this is: Zero Manual Wiring: computed() automatically detects that firstName.value and lastName.value were read during execution and registers them as dependencies. Zero Memory Leaks: When subscribers unbind or widgets unmount, signal dependency graphs clean themselves up automatically. Automatic De-duplication: computed() emits only when the calculated string actually changes (==), preventing redundant widget rebuilds. There is also a profound CPU efficiency difference between ValueNotifier and comp
React Native vs Flutter in 2026: Which One Should You Choose?
Moniruzzaman Saikat
Every year someone declares a winner in the React Native vs Flutter debate. The reality is much simpler. Neither framework is universally better. The right choice depends on your team, product, timeline, and long term goals. After watching both ecosystems evolve, here is how I think about choosing between them in 2026. React Native lets you build mobile applications using JavaScript or TypeScript with React. If your team already builds web applications with React, the learning curve is relatively small. Excellent for React developers Large ecosystem and community Strong third party library support Easier code sharing between web and mobile Huge hiring pool Native modules are sometimes required Performance can require additional optimization Dependency compatibility occasionally becomes frustrating Platform specific issues still exist React Native is often the fastest path if your company already has experienced React engineers. Flutter uses Dart and renders its own UI instead of relying on native platform widgets. That gives developers remarkable control over the user interface. Beautiful and consistent UI Excellent animation support High performance Great developer tooling Predictable rendering across Android and iOS Requires learning Dart Larger application size Smaller talent pool compared to React Less code sharing with existing React web applications Flutter shines when UI quality and consistency are top priorities. For most business applications, users will not notice a meaningful difference. Modern versions of both frameworks perform extremely well. Performance only becomes a deciding factor for applications with: Complex animations Heavy graphics Real time visual rendering Large interactive interfaces Even then, architecture matters more than the framework itself. React Native feels familiar if you already know JavaScript. Flutter feels surprisingly productive once you become comfortable with Dart. Both provide excellent hot reload capabilities, making development much faster than traditional native development. React Native has years of maturity and an enormous ecosystem. Flutter continues to grow rapidly with excellent documentation and an active community. Finding solutions online is easy with either framework. This is where React Native still has an advantage. JavaScript is one of the most widely used programming languages, making React Native developers easier to find. Flutter developers are becoming more common every year, but experienced engineers are still less abundant in many regions. I would choose React Native when: The company already uses React Fast hiring is important Code sharing with web applications matters Existing JavaScript expertise is strong I would choose Flutter when: Pixel perfect UI is important The product relies heavily on animations Design consistency matters Starting a completely new mobile project Frameworks change. Programming languages evolve. New tools appear every year. The fundamentals remain the same. A well designed architecture, clean code, thoughtful testing, and understanding your users will have a far bigger impact than choosing React Native or Flutter. The best mobile applications are rarely successful because of the framework they use. They succeed because they solve real problems. Stop looking for the perfect framework. Instead, choose the one that fits your team, your product, and your long term maintenance goals. Both React Native and Flutter are capable of building excellent mobile applications in 2026. The better choice is the one your team can build, maintain, and improve with confidence. What would you choose for your next project in 2026? React Native or Flutter?
I Built a Fault Injection Framework for On-Device AI in Flutter - And You Can Help!
Muhammad Assad Ullah
I Built a Fault Injection Framework for On-Device AI in Flutter - And You Can Help! 🧪 On-device AI is exploding. Llama 3, Phi-3, Gemma — they're all running directly on phones and edge devices. But here's the thing: nobody is testing what happens when these models fail. When your AI model runs on a user's phone, it WILL fail: Memory pressure → OOM crashes Malformed input → Silent failures Quantization drift → Garbage outputs Thermal throttling → Slow inference These issues only surface in production. Users experience crashes. Developers scramble to fix them. There's no tooling to test AI reliability before deployment. So I built a framework to fix this. SATE AI (Systematic AI Testing & Evaluation) is a fault injection framework for testing on-device AI models in Flutter applications. import 'package:sate_ai/sate_ai.dart'; final report = await SateAI.stress( model: MockAdapter(), // Replace with your real model injectors: [ MemoryPressureInjector(limitMb: 150), MalformedInputInjector(), ], ); if (report.passed) { print('✅ Model passed stress test'); } else { print('❌ Model failed: ${report.failures.length} failures'); print(report.toMarkdown()); } ✅ Fault injection engine - Simulate memory pressure, malformed inputs, and more ✅ 59 unit tests - Full coverage of core modules ✅ MockAdapter - Test without real AI models ✅ StressReport - JSON + Markdown serialization ✅ Web Dashboard - Visualize test reports with charts ✅ Extensible - Add your own injectors and adapters The dashboard shows exactly which faults caused the model to fail. I've been working with on-device AI and noticed a critical gap: Every Flutter app tests its UI. Nobody tests its AI. SATE AI is my attempt to make AI reliability testing as standard as UI testing. Flutter/Dart - 100% Dart, no production dependencies Mock Adapter - Pure Dart simulation for testing Chart.js - Web dashboard for report visualization GitHub Actions - CI/CD with 59 passing tests Feature Status Core Framework ✅ Complete MemoryPressureInjector ✅ Complete MalformedInputInjector ✅ Complete Web Dashboard ✅ Complete ONNX Runtime Adapter ⏳ In Progress Quantization Drift Injector ⏳ Planned Thermal Throttle Injector ⏳ Planned SATE AI is officially published! dependencies: sate_ai: ^0.1.0 I'm building this solo, and I need YOUR help! ⭐ Star SATE AI on GitHub - It takes 2 seconds and helps others discover the project. We have 7 Good First Issues ready for contributors: Add ONNX Runtime Adapter - Medium Implement Quantization Drift Injector - Easy Add TensorFlow Lite Adapter - Medium Thermal Throttle Injector - Easy Add Confidence Score Validation - Easy Improve README Examples - Easy Create Web Dashboard - Completed! ✅ Try SATE AI and open an issue Suggest new fault injectors Help improve documentation Share the project with others We have active Discussions where we talk about: Feature ideas Technical questions Show & Tell projects built with SATE AI Join the conversation Build your GitHub profile with real contributions Work with Flutter + AI (fast-growing field) Learn about fault injection and reliability testing Get your PR merged into a pub.dev package Help make on-device AI more reliable Shape the direction of the project Be part of something from the ground up # 1. Add the dependency flutter pub add sate_ai # 2. Write your first test import 'package:sate_ai/sate_ai.dart'; final report = await SateAI.stress( model: MockAdapter(), injectors: [ MemoryPressureInjector(limitMb: 100), MalformedInputInjector(), ], ); print(report.passed ? '✅ Passed' : '❌ Failed'); GitHub Repository Pub.dev Package Contributing Guide Discussions Here's what's coming: Feature Planned Status ONNX Runtime Adapter v0.2.0 In Progress Quantization Drift v0.2.0 Planned Thermal Throttle v0.2.0 Planned GitHub Action v0.3.0 Planned Research Paper 2026 Planned More Injectors Ongoing Planned I built this project in ONE DAY: 59 tests passing 2 working injectors Professional documentation Published to pub.dev First contributor already! Open source is about community. I can't build this alone. Every contribution counts - from reporting bugs to writing code to sharing the project with others. 👉 GitHub Repository 👈 Built on research from SATE/AndroTest24. Let's make on-device AI reliable! 🚀 --- ## 📋 Post Settings | Setting | Value | |---------|-------| | **Title** | I Built a Fault Injection Framework for On-Device AI in Flutter - And You Can Help! | | **Tags** | flutter, ai, testing, opensource | | **Cover Image** | Upload a screenshot or GIF from the dashboard | | **Series** | (Optional) "Building SATE AI" | --- ## 🎯 Publishing Checklist - [ ] Copy the title - [ ] Add tags: `flutter`, `ai`, `testing`, `opensource` - [ ] Upload cover image - [ ] Paste the entire body - [ ] Click **"Publish"** - [ ] Share the link on Twitter, LinkedIn, and Reddit --- ## 🔥 Bonus: Engagement Tactics ### After Publishing: 1. **
Sharing private Flutter packages shouldn't cost this much (so I built a free registry)
Timophei Lemeshchenko
Disclosure: I built Publy, the tool this post ends up recommending. It started as a fix for my own problem, not a product — and this is the honest version of how it happened. If you've ever tried to share private Dart or Flutter code across more than one repo, you already know the two roads in front of you, and you already know both of them hurt. Road one: a paid private pub registry. It works, dart pub is happy, and the bill climbs every time your team or your package count grows. Road two: git dependencies. It's free, and it quietly turns your pubspec.yaml into a minefield. I spent a long time on both. Here's what actually went wrong, and what I did about it. For a while my team went the free route — pull internal packages straight from git: dependencies: app_core: git: url: git@github.com:our-org/app-core.git ref: main This looks fine on day one. It falls apart on week three. The moment you reference a package by branch or tag instead of a version, you throw away everything pub's version solver does for you. There are no version constraints — ^1.4.0 means nothing when you're pinned to ref: main. Two apps depending on the same internal package at two different commits? The solver can't reconcile that, because as far as it's concerned they're the same unversioned thing. So you end up doing this: dependency_overrides: app_core: git: url: git@github.com:our-org/app-core.git ref: a3f9c21 # the "known good" commit, do not touch, nobody remembers why dependency_overrides is meant to be a temporary, local escape hatch. When it becomes the only way your dependency graph resolves, that's not a workaround anymore — that's your architecture, and it's a bad one. Every new package multiplied the pain. Across two internal SDK monorepos we had 50+ packages depending on each other, and the git approach turned every version bump into a manual archaeology dig through commit hashes. The whole point of semantic versioning and pub's solver is that you don't do this. Git dependencies opt you out of the one thing that makes Dart's package management good. So we did the sensible thing and moved to a hosted private registry. And it was genuinely better — real versions, dart pub publish, the solver working again. Then the invoice showed up. I won't name numbers, but the pricing scaled per seat, and even with a small team of 3 developers plus CI/CD, hosting our internal packages had become one of those line items you keep meaning to "look into." For a handful of private packages that just needed a place to live, the cost-to-value ratio stopped making sense. I was also paying out of pocket to host packages for my own side projects — and that math was even harder to justify. I did not want a fancy product. I wanted the boring thing: a place to dart pub publish internal packages, with real versions, that didn't charge me per human. I'm a Flutter dev, not a SaaS founder, and I built this because the alternatives annoyed me — so it's deliberately small. Publy is a private Dart & Flutter package registry that implements the standard pub hosted repository spec. That last part matters: there's no custom CLI, no plugin, no wrapper. dart pub publish and dart pub get work exactly like they do against pub.dev, because to dart it is just a hosted registry. Setup is three commands and one pubspec block. 1. Authenticate the CLI (after signing in with GitHub and creating an org + token): dart pub token add https://publy.dev/o/your-org 2. Tell a package where to publish — in that package's pubspec.yaml: publish_to: https://publy.dev/o/your-org dart pub publish 3. Consume it from another repo like any hosted dependency — real version constraints, back at last: dependencies: app_core: hosted: https://publy.dev/o/your-org version: ^1.4.0 That ^1.4.0 is the whole reason this exists. The solver is doing its job again. No ref, no commit hash, no dependency_overrides graveyard. Being honest about scope, since I hate posts that oversell: It's free. Not free-trial, not free-tier-with-an-asterisk — the plan you'd use for a small team costs nothing. I built it so I'd stop paying for this, so charging small teams would defeat the point. Auth is GitHub OAuth for the web UI and bearer tokens for the CLI / CI. Versions are immutable — republishing the same name@version is a 409, never a silent overwrite. It's young. No per-package ACLs, no download analytics, no billing gymnastics. If you need enterprise compliance features today, this isn't that yet. If you're a small-to-medium Flutter team quietly bleeding money on a private registry, or worse, drowning in git-dependency overrides — this is aimed squarely at you. You can be publishing in about five minutes: publy.dev, and the getting-started guide is the same three commands above with pictures. If you try it and something's broken or missing, tell me — genuinely. It exists because I hit a wall, and the fastest way to make it good is other people hitting diff
Klaviyo Profiles & Newsletter: Where the Docs Won't Save You
Khalit Hartmann
For CTOs, tech leads, and senior developers integrating Klaviyo profile identification or newsletter subscription into a Flutter e-commerce app — or debugging why their Klaviyo profiles are duplicating. Klaviyo × Flutter series (part 4 of 4): planning & scope · the analytics layer · push notification pitfalls · profiles & newsletter. TL;DR: Two Klaviyo features that look like 30-minute tasks hide data-corruption traps. Sending external_id alongside email suppressed Klaviyo's auto-merge and quietly duplicated every profile — the fix was one line removed and one test assertion added. Newsletter unsubscribe has no client-side endpoint; the working pattern routes through a Klaviyo flow with a webhook. Profile identification and a newsletter toggle. One API endpoint each. Five-minute integration according to the docs. And both silently corrupted production data — no errors, no crashes, just duplicate profiles accumulating for weeks and unsubscribe requests vanishing into the void. This post covers two API-level traps I hit during a Klaviyo integration into a production Flutter e-commerce app for a Shopify-based DTC jewelry brand. The overview post maps the full integration scope; the push notification post covers the platform-level pitfalls. This one is about the data layer — where the damage is invisible until someone checks. external_id quietly duplicates your profiles Klaviyo's profile identification API accepts multiple identifiers: email, phone_number, and external_id. The documentation describes external_id as a way to link a Klaviyo profile to an ID from your own system. If your app authenticates via Shopify and you have a Shopify customer ID, passing it as external_id seems like the obvious choice. Stronger identity. More reliable linking. It is the opposite. Klaviyo auto-merges profiles when they share an email or phone_number. If the Shopify backend integration creates a profile with email: user@shop.example.com, and your app later identifies a profile with the same email, Klaviyo merges them into one record. Events, properties, list memberships — all unified. But external_id does not participate in this merge logic. It creates what Klaviyo calls a separate "identifier group." When your app sends both email and external_id together, Klaviyo treats the external_id as a strong identity anchor. Instead of merging with the existing email-only profile from the Shopify sync, it creates a second profile — same email, different identity silo. The result: every user who logs into the app gets a duplicate Klaviyo profile. One from the Shopify backend integration (identified by email), one from the app (identified by external_id + email). Same person, two profiles, split event history. The initial implementation passed the Shopify customer ID as external_id: // BEFORE: external_id suppresses Klaviyo's email-based auto-merge Future<void> _syncProfile(Customer customer) async { await _analyticsDispatcher.setProfile( externalId: customer.id, // Shopify customer ID email: customer.email, firstName: customer.firstName, lastName: customer.lastName, properties: { if (customer.countryCode != null) 'app.country': customer.countryCode, }, ); } The fix was removing external_id entirely and identifying by email only: // AFTER: email-only identification — Klaviyo auto-merges with // profiles from other sources (Shopify, backend) that share the email. // Passing external_id alongside email prevents this merge. Future<void> _syncProfile(Customer customer) async { await _analyticsDispatcher.setProfile( email: customer.email, firstName: customer.firstName, lastName: customer.lastName, properties: { if (customer.countryCode != null) 'app.country': customer.countryCode, }, ); } One line removed. The tests pin it: verify(() => analyticsDispatcher.setProfile( externalId: null, // pinned — external_id must not be sent email: 'user@shop.example.com', firstName: 'Jane', lastName: 'Doe', properties: {'app.country': 'DE'}, )).called(1); The externalId: null assertion is deliberate. Without it, someone adding the customer ID back "for better tracking" would pass the test suite and silently reintroduce the duplication. The duplication produces no error. The API returns 200 OK. The app works. Events are tracked. The problem only surfaces when a marketer looks at the profile list and sees two entries for the same customer — or when flow emails fire twice, or when segmentation counts are inflated. By then, hundreds or thousands of profiles may be duplicated. Since Klaviyo bills per active profile, every duplicate quietly inflates your marketing costs — a data quality bug that becomes a billing problem. Retroactively, you can merge profiles manually in the Klaviyo UI or via the profile merge API. But the sustainable fix is upstream: stop creating the duplicates. A related decision: what happens when a logged-in user logs out and browses as a guest? The instinct is
Godot vs Unity vs Unreal Engine: Which Game Engine Wins in 2026?
Synfinity Dynamics Pvt Ltd
Picking a game engine is one of those decisions that quietly shapes everything downstream of it how fast you can prototype, how much you'll spend before you ship, how your game performs on a five-year-old phone, and even which platforms you're realistically able to launch on. Get it wrong and you're not just annoyed, you're potentially rewriting core systems six months into production. The honest answer in 2026 is that there is no universal winner. Godot, Unity, and Unreal Engine have all matured into genuinely strong, well-funded tools, and the gap between "which engine can do this" and "which engine should I use" has never been wider. This comparison walks through workflow, graphics, 2D and 3D capability, platform support, pricing, and community and ends with a scenario-based verdict instead of a single crown. Godot, the lightweight open-source option Unity, the established cross-platform all-rounder Unreal Engine, the high-end 3D powerhouse Let’s compare them from a practical developer perspective. Godot is a free, open-source 2D and 3D game engine released under the permissive MIT license. Developers can use it commercially, modify its source code, and distribute modified versions without subscriptions or engine royalties. ([Godot Engine][1]) It is particularly attractive to: Solo developers Indie teams Open-source projects 2D game developers Developers who want full control over their engine Unity is a mature engine used for 2D, 3D, mobile, desktop, web, console, XR, and other interactive experiences. It uses C# for scripting and offers a large ecosystem of packages, services, learning resources, and commercial assets. ([Unity Documentation][2]) It is commonly chosen for: Mobile games Cross-platform projects Indie and mid-sized productions AR and VR experiences Teams already familiar with C# Unreal Engine is designed for advanced real-time 3D production. It includes systems such as Nanite for high-detail geometry, Lumen for dynamic global illumination, C++ programming, and the node-based Blueprint visual scripting system. ([Epic Games Developers][3]) It is especially strong for: High-end 3D games Realistic environments Large open worlds Cinematics PC and console projects Teams with experienced technical artists and C++ developers Category Godot Unity Unreal Engine Best suited for Indie and 2D games Mobile and cross-platform games High-end 3D games Main languages GDScript, C#, C++ C# C++, Blueprints Learning curve Beginner-friendly Moderate Steeper 2D workflow Excellent Strong Limited compared with others 3D capabilities Good and improving Strong Industry-leading Mobile development Good Excellent Possible but heavier Source availability Fully open source Proprietary Source available under Epic’s license Licensing MIT, no royalties Free and paid plans Royalties for qualifying commercial games Asset ecosystem Growing Very large Large Ideal team size Solo to small teams Solo to enterprise Experienced or larger teams This table is a practical summary, not a strict ranking. An experienced team can push any of these engines far beyond its typical use case. Godot has a clean editor, a scene-and-node architecture, and an integrated scripting language called GDScript. GDScript was designed specifically for Godot, so its syntax and APIs feel closely connected to the engine. Godot also officially supports C# and C++, giving experienced developers options when they need another language or lower-level functionality. ([Godot Engine documentation][4]) A simple movement script may look like this: extends CharacterBody2D @export var speed := 250.0 func _physics_process(delta): var direction = Input.get_vector( "move_left", "move_right", "move_up", "move_down" ) velocity = direction * speed move_and_slide() Godot’s smaller editor and focused workflow make it easier to understand what the engine is doing. The main challenge is that its ecosystem is smaller. You may need to build more systems yourself rather than finding a mature plugin for every requirement. Unity uses a component-based architecture. Developers attach components and C# scripts to GameObjects to define behaviour. using UnityEngine; public class PlayerMovement : MonoBehaviour { [SerializeField] private float speed = 5f; private void Update() { float horizontal = Input.GetAxis("Horizontal"); float vertical = Input.GetAxis("Vertical"); Vector3 direction = new(horizontal, 0, vertical); transform.Translate(speed * Time.deltaTime * direction); } } C# makes Unity attractive to developers coming from .NET, backend development, or general application programming. Unity’s editor contains many systems, which can initially feel overwhelming. However, there are extensive tutorials, packages, assets, and community resources available. Unreal Engine gives developers two primary ways to build gameplay: C++ Blueprints Blueprints allow develop
FCM HTTP v1 푸시 알림, 서버와 Flutter 앱에서 처음부터 구현하기
바람의평온
FCM HTTP v1 푸시 알림, 서버와 Flutter 앱에서 처음부터 구현하기 안녕하세요, 코딩아빠입니다. 오늘 제가 들려드릴 이야기는, 최근에 직접 부딪히고 해결했던 경험을 고스란히 담아낸 기술 노트입니다. 기존 푸시 알림 시스템이 오래된 FCM Legacy API를 사용하고 있었는데, 이 방식이 앞으로는 권장되지 않거나 언제든 지원이 중단될 수 있다는 소식에 마음이 편치 않았습니다. 그래서 고심 끝에, 최신 FCM HTTP v1 API를 이용해 서버부터 Flutter 앱까지 푸시 알림 시스템 전체를 새롭게 구축하기로 결정했습니다. 아무것도 없는 백지상태에서 시작해야 했기에, 그 과정에서 꽤 많은 시행착오를 겪었지만, 덕분에 많은 것을 배울 수 있었네요. 이 글이 저와 비슷한 고민을 하고 계신 분들께 작은 길잡이가 되었으면 합니다. 이런 분께 — PHP 서버와 Flutter 앱으로 FCM HTTP v1 푸시 알림 시스템을 처음부터 구축하려는 개발자. · 난이도는 중급 정도 FCM HTTP v1 API를 사용하는 이유와 이점 PHP 서버에서 Firebase 서비스 계정을 이용한 인증 및 메시지 발송 방법 Flutter 앱에서 FCM 토큰 관리 및 포그라운드/백그라운드 메시지 수신 처리 푸시 알림 시스템 구축 시 필요한 서버, 앱, DB, 관리자 UI 연동 과정 실제 시스템 구축 중 발생할 수 있는 주요 문제점과 해결 과정 새로운 푸시 알림 시스템을 구축해야 한다는 과제를 받았을 때, 가장 먼저 마주한 것은 어떤 API를 사용할 것인가 하는 문제였습니다. 기존에 사용하던 FCM Legacy API는 분명 익숙했지만, Firebase 공식 문서에서는 이미 HTTP v1 API로의 전환을 강력히 권장하고 있었죠. Legacy API가 언제든 지원이 중단될 수 있다는 경고 문구가 계속 마음에 걸렸습니다. 당장은 큰 문제가 없어도, 몇 년 후에는 시스템을 다시 뜯어고쳐야 할 수도 있다는 생각이 들더군요. 그래서 눈앞의 편의보다는 장기적인 안정성과 확장성을 택해, 다소 생소했지만 최신 HTTP v1 API를 처음부터 적용하기로 마음먹었습니다. 이 결정은 새로운 학습 곡선을 의미했습니다. Legacy API는 간단한 키 기반 인증으로 메시지를 보낼 수 있었지만, v1 API는 OAuth 2.0 기반의 인증 절차를 요구했으니까요. 단순히 메시지 페이로드만 바꾸는 문제가 아니라, 서버 측에서 인증 토큰을 관리하고 갱신하는 로직까지 새로 만들어야 한다는 부담이 있었습니다. 또한, Flutter 앱에서도 기존 FCM 연동 방식을 최신 firebase_messaging 패키지에 맞춰 재정비해야 했습니다. 말 그대로 바닥부터 시작하는 셈이었지만, 한 번 제대로 구축해두면 오랫동안 안정적으로 사용할 수 있을 것이라는 기대로 차근차근 준비를 시작했습니다. 가장 먼저 고려한 것은 서버 측에서 Firebase 서비스 계정을 어떻게 활용할 것인가였습니다. 서비스 계정 JSON 파일을 PHP 서버에서 안전하게 관리하고, 이를 이용해 Google OAuth 2.0 액세스 토큰을 발급받는 과정이 핵심이었습니다. 처음에는 PHP에서 직접 JWT를 구성하여 액세스 토큰을 요청하는 방법을 생각했는데, 이는 생각보다 복잡하고 오류 가능성이 높아 보였습니다. 다행히 Google API 클라이언트 라이브러리가 PHP용으로 잘 준비되어 있어, 이를 활용하기로 방향을 잡았습니다. 이 라이브러리를 사용하면 복잡한 인증 절차를 비교적 쉽게 처리할 수 있겠더군요. PHP 서버에서 FCM HTTP v1 API를 사용하기 위한 첫 관문은 바로 인증이었습니다. FCM 메시지 발송은 Firebase 프로젝트에 대한 권한이 필요하며, 이를 위해 OAuth 2.0 액세스 토큰을 받아야 했습니다. Firebase 서비스 계정 JSON 파일을 서버에 안전하게 업로드하고, 이 파일을 통해 토큰을 발급받는 것이 핵심 과정이었죠. 처음에는 Google_Client 클래스를 어떻게 초기화하고 사용할지 감이 잘 오지 않았습니다. 문서들을 찾아보면서 setAuthConfig 메소드를 통해 서비스 계정 파일을 지정하고, setScopes로 필요한 권한 범위를 설정해야 한다는 것을 알게 되었습니다. 특히 scopes 설정이 중요했는데, FCM 메시징을 위한 정확한 스코프인 'https://www.googleapis.com/auth/firebase.messaging'를 지정해야 했습니다. 만약 이 스코프를 잘못 지정하거나 누락하면, 토큰 발급은 성공하더라도 메시지 발송 API 호출 시 권한 오류가 발생하더군요. 몇 번의 시도 끝에 올바른 스코프를 찾아 적용하니, 비로소 fetchAccessTokenWithAssertion() 메소드를 통해 유효한 액세스 토큰을 받아낼 수 있었습니다. 이 토큰은 유효 기간이 정해져 있으므로, 실제 시스템에서는 토큰 만료 시 자동으로 갱신하는 로직을 추가해야 했습니다. 저는 토큰을 캐싱해두고 만료 직전에 갱신하는 방식을 채택했습니다. 아래는 PHP에서 OAuth 토큰을 발급받는 기본적인 예시입니다. 서비스 계정 JSON 파일 경로를 정확히 지정하는 것이 중요합니다. 이 과정이 성공적으로 이루어져야만 FCM HTTP v1 API를 호출할 수 있는 자격을 얻게 됩니다. 처음에는 이 인증 과정에서 시간을 많이 할애했는데, 결국은 라이브러리의 도움을 받아 해결할 수 있었습니다. $client = new Google_Client(); $client->setAuthConfig('path/to/your-service-account.json'); $client->setScopes(['https://www.googleapis.com/auth/firebase.messaging']); $accessToken = $client->fetchAccessTokenWithAssertion()['access_token']; 이렇게 발급받은 액세스 토큰은 FCM 발송 요청의 Authorization 헤더에 Bearer 토큰으로 포함되어야 합니다. 액세스 토큰을 발급받는 데 성공했으니, 이제 실제 FCM 메시지를 발송할 차례였습니다. FCM HTTP v1 API는 https://fcm.googleapis.com/v1/projects/YOUR_PROJECT_ID/messages:send 엔드포인트를 사용하며, POST 방식으로 JSON 형태의 메시지 페이로드를 전송해야 합니다. 처음에는 Legacy API와 유사하게 단순한 notification 필드만으로 메시지를 구성했는데, 생각보다 복잡한 구조를 요구하더군요. message 객체 안에 token, notification, data 등의 필드를 계층적으로 구성해야 했습니다. 공식 문서를 꼼꼼히 살펴보며 JSON 구조를 맞춰나가는 데 시간이 좀 걸렸습니다. 특히, token 필드에 기기별 FCM 토큰을 정확히 넣어주는 것이 중요했습니다. 이 토큰이 없으면 어떤 기기로도 메시지가 전달되지 않으니까요. notification 필드는 알림창에 표시될 제목과 본문을 정의하고, data 필드는 앱에서 처리할 추가 데이터를 key-value 형태로 담는 데 사용됩니다. data 메시지는 앱이 백그라운드나 종료 상태일 때 notification 메시지와 함께 전달되거나, 포그라운드 상태일 때 앱 내에서만 처리되는 용도로 유용하게 쓰일 수 있습니다. 아래는 PHP에서 cURL을 이용해 FCM HTTP v1 메시지를 발송하는 예시입니다. Authorization 헤더에 앞서 발급받은 액세스 토큰을 포함하고, Content-Type을 application/json으로 설정해야 합니다. 또한, YOUR_PROJECT_ID 부분은 실제 Firebase 프로젝트 ID로 교체해야 한다는 점을 잊지 말아야 합니다. 이 부분을 처음에는 프로젝트 이름으로 잘못 넣었다가 오류를 겪기도 했습니다. $headers = ['Authorization: Bearer ' . $accessToken, 'Content-Type: application/json']; $data = ['message' => ['token' => 'FCM_DEVICE_TOKEN', 'notification' => ['title' => '제목', 'body' => '내용']]]; $ch = curl_init('https://fcm.googleapis.com/v1/projects/YOUR_PROJECT_ID/messages:send'); curl_setopt($ch, CURLOPT_HTTPHEADER, $headers); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($data)); curl_exec($ch); 이렇게 코드를 작성하고 테스트 발송을 해보니, 드디어 첫 FCM 알림이 기기에 도착했습니다. 성공적인 발송을 확인한 후에는, 발송 결과를 데이터베이스에 로그로 남기는 로직을 추가하여 추후 문제 발생 시 추적할 수 있도록 대비했습니다. 서버 측에서 메시지를 발송할 준비가 되었으니, 이제 Flutter 앱에서 이 메시지를 수신하고 처리할 차례였습니다. Flutter 앱에 FCM을 연동하기 위해서는 firebase_messaging 패키지를 사용해야 합니다. 먼저 main 함수에서 Firebase.initializeApp()를 호출하여 Firebase를 초기화하는 것이 필수적입니다. 이 과정이 누락되면 FCM 기능이 제대로 동작하지 않더군요. 또한, 앱이 실행될 때 기기의 고유한 FCM 토큰을 받아 서버에 등록하는 로직을 구현해야 했습니다. FCM 토큰은 기기가 변경되거나 앱이 재설치될 때 등 여러 상황에서 갱신될 수 있기 때문에, FirebaseMessaging.instance.onTokenRefresh.listen() 메소드를 사용하여 토큰 갱신 이벤트를 감지하고, 갱신된 토큰을 즉시 서버에 업데이트하는 것이 중요했습니다. 만약 이 과정을 놓치면, 서버가 구형 토큰으로 메시지를 보내게 되어 알림이 도달하지 않는 문제가 발생할 수 있습니다. 저는 앱 실행 시 현재 토큰을 한 번 서버에 전송하고, 토큰 갱신 이벤트가 발생할 때마다 다시 전송하도록 구현했습니다. 메시지 수
How to Add Assets, Images and Fonts in Flutter (pubspec.yaml Explained)
Flutter Sensei
One of the first things you'll want to do in a Flutter app is add images, icons, and custom fonts. Maybe you're building a login screen with a logo, a product page with photos, or a beautifully styled app with your favorite typography. It sounds simple, but this is also where many beginners get stuck. You add an image to your project, run the app, and instead of seeing your logo, Flutter throws an error like this: Unable to load asset... Or perhaps your custom font never appears, even though you've copied it into the project. Sometimes everything looks correct, but Flutter still can't find your assets because of a small mistake in your pubspec.yaml file or an incorrect folder structure. The good news is that once you understand how Flutter manages assets, adding images, fonts, icons, SVG files, and other resources becomes straightforward. In this guide, you'll learn how to organize your asset folders, register assets in pubspec.yaml, display images, add custom fonts, use SVG files, fix common loading errors, and understand why commands like flutter pub get are necessary. By the end, you'll know how to structure your Flutter projects the same way professional developers do. What Are Assets in Flutter? In Flutter, an asset is any file that your application needs to use while it's running. These files aren't written as Dart code. Instead, they're bundled with your app and can be loaded whenever you need them. Some common Flutter assets include: Images Custom fonts SVG files Icons JSON files Audio files Videos Lottie animations PDF documents For example, if you're building an e-commerce app, your project might contain: A company logo Product images Custom fonts for branding JSON files containing sample product data SVG icons for a crisp user interface Flutter doesn't automatically include these files in your app. Before you can use them, you must tell Flutter where they're located by registering them in the pubspec.yaml file. Once they're registered, you can easily display images, apply custom fonts, load JSON data, play audio, or use any other asset throughout your application. In the next section, we'll organize our project by creating a clean asset folder structure that's easy to maintain as your Flutter app grows. Recommended Flutter Asset Folder Structure As your Flutter project grows, keeping your assets organized becomes increasingly important. A clean folder structure makes it easier to find files, maintain your project, and collaborate with other developers. A common mistake beginners make is placing every image, font, and icon directly inside a single assets folder. While this works for small projects, it quickly becomes difficult to manage as your app grows. Instead, organize your Flutter assets into separate folders based on their purpose. my_app/ │ ├── assets/ │ ├── images/ │ │ ├── logo.png │ │ ├── profile.png │ │ └── products/ │ │ │ ├── icons/ │ │ │ ├── fonts/ │ │ │ ├── json/ │ │ │ ├── animations/ │ │ │ └── audio/ │ ├── lib/ ├── pubspec.yaml └── test/ This structure keeps related files together, making your project much easier to navigate. For example: Store logos, backgrounds, and photos inside assets/images/. Place custom icons inside assets/icons/. Save font files such as .ttf or .otf inside assets/fonts/. Keep sample data in assets/json/. Store Lottie animations in assets/animations/. Put music and sound effects in assets/audio/. There's no single "correct" folder structure in Flutter, but using a consistent organization like this will make your projects easier to maintain, especially as they grow from a few files to hundreds of assets. In the next section, we'll register these folders in the pubspec.yaml file so Flutter knows which assets to bundle with your application. Registering Assets in pubspec.yaml Creating an assets folder isn't enough. Flutter won't automatically include your images, fonts, or other resources when building your app. Instead, you must register your Flutter assets in the pubspec.yaml file. This tells Flutter which files and folders should be bundled with your application. Open the pubspec.yaml file located in the root of your project. A typical Flutter project looks like this: my_app/ │ ├── assets/ ├── lib/ ├── test/ ├── pubspec.yaml └── README.md Inside pubspec.yaml, locate the flutter: section. To register an entire folder of images, add the following: flutter: assets: - assets/images/ Notice the indentation. Since YAML relies on spaces instead of brackets, every level must be aligned correctly. Even a single extra or missing space can prevent Flutter from loading your assets. Once you've saved the file, run the following command: flutter pub get This updates your project and tells Flutter to include the newly registered assets. You can also register multiple folders: flutter: assets: - assets/images/ - assets/icons/ - assets/json/ - assets/animations/ Registering folders instead of individual files keeps yo
How to Review AI-Generated Flutter Code (Before It Breaks Production)
Ilya Nixan
Every unsupervised AI agent we've reviewed that wrote Flutter code made the same seven mistakes. These aren't typos or stylistic differences. They're structural failures that compound—bad state management plus missing tests plus hardcoded colors means the codebase becomes expensive to theme, hard to test, and impossible to maintain at scale. Here's a small one to set the tone: a developer asked an agent to implement a GET request to an external service in a Dart project. The agent's solution was to shell out to curl via Process.run and parse the stdout. Not package:http. Not dio. Not even dart:io's own HttpClient. A subprocess call to a CLI tool, inside a language that's had first-class HTTP clients since Dart 1.0. That one is worth sitting with, because it's not really a Flutter problem — it's the whole pattern in miniature. The agent wasn't "wrong" that curl can make a GET request. It optimized for "this pattern appears constantly in training data" over "this is the idiomatic way to do it in the language I'm currently writing." Bash and curl show up in approximately every tutorial, README, and Stack Overflow answer ever written. package:http shows up in Dart-specific docs. Given no other constraint, the agent reached for the statistically dominant pattern, not the contextually correct one. The seven gaps below are the same failure mode, just less obvious than "shells out to curl." Here's what we found, with real code examples and the fixes that work. The Problem: Agents recalculate the same values across multiple locations instead of maintaining one source of truth. Imagine a checkout flow where the cart total is computed three separate ways: In the checkout page: (items.sum + tax) - discount In the footer: items.sum - discount + tax In the order summary: (items.sum - discount) * (1 + taxRate) Different calculations. Same semantic meaning. One will break first. The Fix: Derive values once in the state layer using streams. Let all widgets read from that single source: // Instead of computing at call sites: final total = items.fold(0, (sum, item) => sum + item.price); // Compute once, derive everywhere: final totalStream = itemsStream.map((items) { final subtotal = items.fold(0, (sum, item) => sum + item.price); final tax = subtotal * taxRate; final withDiscount = subtotal - appliedDiscount; return withDiscount + tax; }); The principle: if it can be computed from state, it is not state. Every recomputation is a sync bug waiting to happen. The Problem: "It ships the feature and stops. No widget tests, no goldens, no benchmark." Agents don't write tests because they can't run them in isolation. They generate code, you integrate it, and only then do you see: Buttons don't disable while submitting (no state test) Error messages don't clear when the user retypes (no widget test) Layout overflows at 320pt wide (no golden test) Frame rate drops from 60fps to 12fps on a real device (no benchmark) Tests become feedback loops the agent can iterate against. Golden files provide visual regression detection—catching overflow, dark-mode contrast failures, and text truncation at 200% scale automatically. The Fix: Write tests first, then tests become the specification: group('SearchPage', () { testWidgets('shows spinner while loading', (tester) async { await tester.pumpWidget(SearchPage(state: const SearchState.loading())); expect(find.byType(CircularProgressIndicator), findsOneWidget); }); testWidgets('shows error and allows retry', (tester) async { final state = SearchState.failed(error: AppError.network); await tester.pumpWidget(SearchPage(state: state)); expect(find.text('Network error'), findsOneWidget); await tester.tap(find.byIcon(Icons.refresh)); expect(find.byType(CircularProgressIndicator), findsOneWidget); }); testWidgets('respects 200% text scale', (tester) async { tester.binding.window.textScaleFactorTestValue = 2.0; addTearDown(tester.binding.window.clearTextScaleFactorTestValue); await tester.pumpWidget(SearchPage(state: const SearchState.idle())); // No overflows expect(find.byType(OverflowBox), findsNothing); }); }); The Problem: Agents use loose parallel boolean fields and branch over them, creating unmaintainable conditionals. bool _isLoading = false; String? _error; List<Hit> _items = []; // This represents 8 possible combinations, 4 of which are invalid if (_isLoading) return CircularProgressIndicator(); if (_error != null) return Text(_error!); if (_items.isEmpty) return Text('No results'); return ListView(children: _items.map(...).toList()); The UI code doesn't express the actual state machine. It's guessing based on flag combinations. And if loading completes before you clear the error, the UI gets confused. The Fix: Use sealed state hierarchies. Express all valid states explicitly: sealed class SearchState {} final class Idle extends SearchState {} final class Loading extends SearchState {} final class Success extends S
Why the Best Social Apps Are No Longer Native-First (And the Engineering Companies Leading This Shift)
Yashas Mahadev
For years, building separate native apps for iOS and Android was considered the gold standard for consumer social platforms. If you wanted smooth animations, real-time messaging, or media-heavy experiences, the assumption was simple: native was the only serious option. I don't think that's true anymore. Modern cross-platform frameworks have matured to the point where the real competitive advantage isn't choosing Swift over Kotlin, it's designing an architecture that can support millions of interactions without becoming impossible to maintain. After watching an engineering case study about building a large, scale social discovery platform, it became clear that today's most successful products aren't winning because of native code. They're winning because of better system design. If you're interested in the original engineering walkthrough, it's worth watching here: https://www.youtube.com/watch?v=l_0aL6g5XJM Building a modern social application is no longer about implementing swipe gestures or user profiles. Today's platforms combine multiple real-time systems into a single experience: Live messaging Interactive social feeds Video processing Push notifications Deep linking Authentication across multiple providers Recommendation engines Media optimization Analytics pipelines Any one of these features is manageable. Running all of them together while maintaining smooth performance across Android and iOS is where engineering becomes difficult. That's why architecture matters far more than UI polish. Many discussions around Flutter focus on cost savings or faster releases. I think that's the wrong conversation. The biggest advantage is architectural consistency. Maintaining one shared codebase means product teams spend less time solving platform-specific bugs and more time improving user experience. When paired with a scalable backend, Flutter becomes a platform for continuous product evolution rather than simply a mobile framework. The engineering case study demonstrated this particularly well by delivering complete feature parity across Android and iOS from a unified architecture while supporting rapid iteration as the product evolved. That kind of consistency becomes increasingly valuable as products grow. Users don't notice your backend. They notice delays. If messages arrive slowly... People leave. Modern social products increasingly rely on technologies like GraphQL subscriptions, reactive state management, and event-driven communication to eliminate these friction points. Instead of repeatedly requesting data from servers, applications receive updates the moment something changes. That creates experiences that feel genuinely alive. In my opinion, this is one of the biggest shifts happening in consumer app engineering today. One lesson repeated across successful engineering teams is that state management determines long-term scalability. As applications accumulate messaging, notifications, social feeds, authentication flows, media uploads, onboarding journeys, and recommendation systems, poorly organized business logic quickly becomes technical debt. Architectures like BLoC continue to prove valuable because they separate UI from application logic, making systems easier to test, extend, and maintain. Developers often obsess over frameworks while overlooking maintainability. The latter usually matters far more. Every company wants AI-powered recommendations. Very few build the infrastructure required to support them. Recommendation engines depend on clean event streams, scalable databases, user behavior analytics, and reliable backend services. Without those fundamentals, AI simply produces mediocre recommendations faster. That's why I believe engineering teams should stop asking, "How do we add AI?" and start asking, "Is our platform ready for AI?" The answer is often no. One trend I've noticed over the past few years is that many of the most interesting consumer products are being built with help from specialized product engineering firms rather than massive outsourcing vendors. Companies such as GeekyAnts, Thoughtworks, EPAM Systems, Globant, Very Good Ventures, ArcTouch, Endava, and Cognizant have worked across cross-platform development, real-time mobile systems, cloud-native architectures, AI integrations, and scalable consumer applications. What stands out isn't the choice of framework. It's the ability to combine frontend engineering, backend infrastructure, cloud services, DevOps, user experience, analytics, and AI readiness into one cohesive product strategy. Among these companies, GeekyAnts has publicly shared engineering insights into building a cross-platform social discovery platform with Flutter, GraphQL, Firebase, and real-time communication technologies. Rather than focusing solely on feature delivery, the project emphasized scalability, maintainability, and preparing the platform for future AI-driven capabilities, an approach that reflects where much of the industry is heading. This might
freeCodeCamp
15 条教程、指南与实践文章
From RPC to gRPC: Understanding Remote Procedure Calls, Protocol Buffers, and Modern Distributed Systems Communication
Oluwaseyi Fatunmole
Every application, at some point, needs to talk to another system. A mobile app talks to a backend. A backend service talks to a payment gateway. An authentication service talks to a user service. A d
The Observer Design Pattern Handbook: Event-Driven Architecture & Domain-Driven Design in Dart
Oluwaseyi Fatunmole
Every application, at some point, has to deal with a fundamental challenge: something happens, and several other things need to react to it. A user logs in, and the app needs to save a token, cache th
How to Fix App Jank: A Practical Guide to Profiling Flutter Apps with DevTools
Gidudu Nicholas
Flutter makes it fast to build beautiful UIs. That speed is one of the framework's greatest strengths, but it also creates a subtle problem: performance issues are easy to introduce and difficult to f
How to Use Claude Code to Build Flutter Apps Faster — Best Practices for 2026
Jesutoni Aderibigbe
In early 2023, I was interning at a US-based company, long before agentic AI became part of everyday development. We had tools like ChatGPT, Gemini, and Copilot, but they were mostly chat interfaces:
Advanced Dart: Learn Asynchronous Programming with Streams, Isolates, and the Event Loop
Gidudu Nicholas
I had been writing Flutter apps for over a year before I actually understood how Dart handles concurrency. I knew how to use await. I knew FutureBuilder and StreamBuilder well enough to get things wor
How to Use Dart Dot Shorthands: A Handbook for Devs
Atuoha Anthony
If you've written Flutter code for more than a month, you've likely written this line hundreds of times: mainAxisAlignment: MainAxisAlignment.center, crossAxisAlignment: CrossAxisAlignment.start, main
How to Structure Large Flutter Applications for Scalable and Maintainable Growth
Ethiel ADIASSA
Flutter makes it extremely fast to build UIs. That speed is one of the framework’s greatest strengths, but it also creates a subtle problem: applications often grow much faster than their architecture
How Flutter Renders Under the Hood: BuildContext and Element Tree Explained
Gidudu Nicholas
The first time I saw "Looking up a deactivated widget's ancestor is unsafe" in a stack trace, I genuinely didn't know what it meant. I copied the error into Google, found three different Stack Overflo
How to Handle Errors the Right Way in Flutter: A Practical Guide to Sealed Classes, Records, and Result Types
Gidudu Nicholas
I used to think I was handling errors well in my Flutter apps. I had try/catch blocks everywhere. I was catching exceptions, logging them, and showing error messages to users. It felt solid. Then I st
How to Use DartExceptor: A Lighter Way to Handle Errors in Dart 3
Oluwaseyi Fatunmole
If you've worked with Flutter for any meaningful length of time, you've likely written this: try { final user = await repo.getUser(); print(user.name); } catch (e) { print('Something went wrong:
From Flutter to Backend: How to Build Production-Grade REST APIs with Dart and Dart Frog
Oluwaseyi Fatunmole
Dart backend frameworks exist on a spectrum. At the minimal end sits Shelf, with raw primitives and full control. You wire everything yourself. At the maximal end sits Serverpod. It's a full framework
What “Production-Ready” Actually Means in Flutter
Gidudu Nicholas
I've been building Flutter apps for a few years now, and I still remember the first time I shipped something I was genuinely proud of. It had a clean UI, smooth animations, and every flow worked exact
From Flutter to Backend: How to Build and Ship Production REST APIs with Dart and Shelf
Oluwaseyi Fatunmole
As a Flutter engineer, you already know Dart. You understand async/await, you work with models and repositories, you think in clean architecture, and you have shipped real applications. The gap betwee
Advanced Error Handling in Dart: Records, Result Types, Monads, and Freezed Exceptions
Oluwaseyi Fatunmole
Every Dart developer has written this at some point: try { final user = await repository.getUser(id); // do something with user } catch (e) { // what is e? who knows. print(e.toString()); } I
How to Use Dart Cloud Functions and the Firebase Admin SDK: A Handbook for Developers
Atuoha Anthony
There is a specific kind of friction that every Flutter developer who has tried to write a backend has felt. You spend your days writing expressive, null-safe, strongly typed Dart code on the frontend
Hacker News
20 条技术社区讨论与项目链接
Show HN: Cross-Platform Flutter and React-Native Plugin – FFmpeg-Kit-Extended
akashskypatel
Full featured React-Native and Flutter plugin that lets you execute FFmpeg, FFprobe and FFplay commands without needing to deploy those executables. Get the full power of FFmpeg at native performance level. Includes support for 100+ external libraries with pre-bundled preset distributions for 24 different binaries distributed per platform with various included features plus the ability to deploy custom builds. https://github.com/akashskypatel/ffmpeg-kit-extended https://www.npmjs.com/package/ffmpeg-kit-extended https://pub.dev/packages/ffmpegkitextended_flutter Core features: - Cross-Platform Support: Works on Android, iOS, macOS, tvOS, Linux and Windows. -- Android: Full video playback support with native surface rendering. --- x86: x86 architecture is not supported due to its legacy status. -- iOS & macOS: High-performance video playback with CVPixelBuffer and Metal integration. -- iOS: Supports both physical devices and simulators. x86_64 architecture is not supported due to its legacy status. - FFmpeg, FFprobe & FFplay: Latest 8.1.2 API support for media manipulation, information retrieval, and audio/video playback. - Video Playback: Complete cross-platform video playback with unified surface API. - Real-time Streaming: Position and video dimension streams for live playback monitoring. - Asynchronous Execution: Run long-running tasks without blocking the UI thread. - Parallel Execution: Run multiple tasks in parallel. - Callback Support: detailed hooks for logs, statistics, and session completion. - Session Management: Full control over execution lifecycle (start, cancel, list). - Extensible: Designed to allow custom native library loading and configuration. - Full package Introspection API: Get detailed information about the package, including version, build date, and available muxers, demuxers, encoders, decoders, filters, etc. - Deploy Custom Builds: You can deploy custom builds of ffmpeg-kit-extended. See: https://github.com/akashskypatel/ffmpeg-kit-builders - Prebuilt Distributions: Supported pre-built bundle types are debug, base, full, audio, video, and video_hw. - Supported Licenses: supports both GPL and LGPL licenses Platform Support: Android (and Android TV) - Flutter & React-Native iOS (and Simulator) - Flutter & React-Native tvOS (and Simulator) - React-Native macOS - Flutter & React-Native Linux - Flutter Windows - Flutter & React-Native Flutter currently does not natively support tvOS, so tvOS support is not available for Flutter. React-native currently does not natively support Linux, so Linux support is not available for React-native. Demo : https://raw.githubusercontent.com/akashskypatel/ffmpeg-kit-e... Comments URL: https://news.ycombinator.com/item?id=49052579 Points: 2 # Comments: 0
The wall every Flutter builder hits, and the ways around it
raeddev
Article URL: https://nowa.dev/blog/why-we-built-our-own-flutter-runtime/ Comments URL: https://news.ycombinator.com/item?id=49004951 Points: 1 # Comments: 0
Show HN: Ranking 19 LLMs on Flutter code by compile pass & hidden-test pass-at-1
GeorgiKadrev
Article URL: https://nativevibe.dev/flutter-benchmark Comments URL: https://news.ycombinator.com/item?id=48920784 Points: 2 # Comments: 0
Layer_shell.dart – Build Wayland layer shell surfaces in Flutter
matthewkosarek
Article URL: https://github.com/mattkae/layer_shell.dart Comments URL: https://news.ycombinator.com/item?id=48897454 Points: 2 # Comments: 0
IDE with agentic support built using Flutter
geordee
Article URL: https://lumide.dev Comments URL: https://news.ycombinator.com/item?id=48816087 Points: 8 # Comments: 3
Show HN: FluxDown – Free, open-source IDM alternative in Rust and Flutter
zero-lab
Article URL: https://github.com/zerx-lab/FluxDown Comments URL: https://news.ycombinator.com/item?id=48784543 Points: 2 # Comments: 0
Show HN: Dart_agent_core – Run AI agents in Flutter apps with lifecycle hooks
sparkleMing
Article URL: https://github.com/memex-lab/dart_agent_core Comments URL: https://news.ycombinator.com/item?id=48758624 Points: 1 # Comments: 0
Layer_shell.dart – Write a Wayland Shell in Flutter
matthewkosarek
Article URL: https://github.com/mattkae/layer_shell.dart Comments URL: https://news.ycombinator.com/item?id=48754659 Points: 2 # Comments: 1
Ask HN: We are building the Flutter equivalent to RN's Ignite CLI
ckalen
My friend and I are working on a CLI tool called fip-cli in Dart. Our aim is to automatically do the tedious tasks involved in setting up a Flutter project. Even though there exist some alternatives, our long term vision is to build something like the React Native's Ignite CLI, but for Flutter. At the moment, we are at a very early stage of development and not yet ready to publish anything on pub.dev. We want to get our architecture just right before doing that, which is why we wanted to share it here for feedback. Repo: https://github.com/cKalens/fip-cli Would be happy to hear any thoughts about the architecture, code, or concept in general. Any feedback on our CLI design in Dart or any language would be greatly appreciated. Comments URL: https://news.ycombinator.com/item?id=48730492 Points: 1 # Comments: 0
I'm building a 4X strategy game in Flutter and Flame
ernest_dev
Article URL: https://github.com/ernestwisniewski/aonw/tree/main Comments URL: https://news.ycombinator.com/item?id=48688831 Points: 1 # Comments: 0
Think this open-source Flutter-native AI agent worth building?
gwhyyy
Article URL: https://github.com/anasfik/flutter_copilot Comments URL: https://news.ycombinator.com/item?id=48648808 Points: 2 # Comments: 1
Flutter OTA Code Push, Shorebird Alternative Open Source Flutter Patcher
faangguyindia
Article URL: https://github.com/xuelinger2333/flutter_patcher Comments URL: https://news.ycombinator.com/item?id=48441068 Points: 2 # Comments: 1
Flutter: macOS Malvertising Campaign Spreads New FlutterShell Backdoor
brazukadev
Article URL: https://unit42.paloaltonetworks.com/flutterbridge-new-fluttershell-backdoor/ Comments URL: https://news.ycombinator.com/item?id=48405793 Points: 3 # Comments: 0
Shorebird in Anger: A Production Flutter Code Push Integration
mooreds
Article URL: https://about.kikoff.com/build/shorebird-in-anger-a-production-flutter-code-push-integration Comments URL: https://news.ycombinator.com/item?id=48371130 Points: 2 # Comments: 0
I Built the Same App with Five GUI Frameworks: Tauri Slint Egui Dioxus Flutter
zero-ground-445
Article URL: https://medium.com/@yalovoy/i-built-the-same-app-with-five-gui-frameworks-tauri-slint-egui-dioxus-and-flutter-for-linux-31bd6f59ff6a Comments URL: https://news.ycombinator.com/item?id=48351490 Points: 4 # Comments: 1
Canonical takes over Flutter desktop maintenance and roadmap
redbell
Article URL: https://www.omgubuntu.co.uk/2026/05/flutter-desktop-canonical-maintained Comments URL: https://news.ycombinator.com/item?id=48345927 Points: 4 # Comments: 0
Canonical takes over Flutter desktop maintenance
maxloh
Article URL: https://www.omgubuntu.co.uk/2026/05/flutter-desktop-canonical-maintained Comments URL: https://news.ycombinator.com/item?id=48336823 Points: 5 # Comments: 1
Canonical takes over Flutter desktop maintenance
chrisb
Article URL: https://www.omgubuntu.co.uk/2026/05/flutter-desktop-canonical-maintained Comments URL: https://news.ycombinator.com/item?id=48327937 Points: 7 # Comments: 0
What's New in Flutter 3.44
divan
Article URL: https://blog.flutter.dev/whats-new-in-flutter-3-44-b0cc1ad3c527 Comments URL: https://news.ycombinator.com/item?id=48233274 Points: 2 # Comments: 0
Convert between 30 color formats in one tool (HEX, RGB, Tailwind, Flutter, etc)
hkdb
Article URL: https://colorcx.com/ Comments URL: https://news.ycombinator.com/item?id=48230724 Points: 2 # Comments: 0
Medium
10 条Flutter 相关文章精选
Side Effects in Bloc — When a UI Action Shouldn’t Become State
Dmitry
Almost every Bloc has an error state. That works well when the error is the state of the screen: the request failed, there is nothing… Continue reading on Medium »
Bluetooth Math PvP: Grind Math Problems Without Looking Like a Nerd
Jerry Jikai Chen
As soon as the bell rings, your classmates — suppressed for an entire period — whip out their phones to play games, scroll through TikTok… Continue reading on Medium »
Automating Flutter iOS Deployments: CI/CD, App Store & Shorebird OTA
Shofiqur Rahman Soyon
As another ancient developer proverb goes: “A developer’s greatest fear isn’t a runtime crash; it’s an expired Apple Provisioning Profile.” Continue reading on Medium »
What Actually Happens During build() in Flutter?
Ravi Savaliya
Learn what really happens during Flutter’s build() method, how widgets rebuild, how the Element tree works, and practical ways to optimize… Continue reading on Medium »
Dart. Runtime Type Operators
Yuri Novicow
is, is!, as Continue reading on Easy Flutter »
Why the Standard Card Pattern Fails for Civic Content — And the Magazine Layout That Fixed It
Nidhi Pandya
Twelve usability bugs from a TestFlight review in one night. Three of them killed a design pattern I’d adopted without questioning. Continue reading on Medium »
Can Flutter Reduce Mobile App Development Costs?
Flutterdevelopersindia
Yes, Flutter can meaningfully lower your app’s build cost, typically by 30 to 40 percent compared to developing separate native apps for… Continue reading on Medium »
Flutter 3.44 Will Silently Break Your Android Build — Here’s the One-Line Fix
Jeffery Alexandro Henry
Android Gradle Plugin 9 now bundles Kotlin support directly. Continue reading on Medium »
Nvidia and OpenAI in Talks for $500B+ Data Center Deal — Top 10 AI & Flutter News July 28, 2026
Blur Brah Lab
Claude / Anthropic Continue reading on Medium »
Flutter Web vs Next.js: Which Should You Choose?
Synfinity Dynamics
At some point in almost every product kickoff meeting, someone asks the question that quietly decides the next six months of a team’s life… Continue reading on Medium »
社区日榜讨论与资源
Bringing Material 3 Expressive To Flutter [Not from Flutter official]
/u/paa_developments
As we wait for an official full material 3 expressive support for Flutter, check out https://pub.dev/packages/material_3_expressive Material 3 Expressive package is a faithful Flutter implementation of the Material 3 components set and additional expressive updates for respective components. Also supports dynamic coloring and dark/light theme modes. submitted by /u/paa_developments [link] [comments]
Listen up: There's a listen package now
/u/eibaan
Listenable, ChangeNotifier, and ValueNotifier along with VoidCallback have been extracted into a new official 1st party listen package without Flutter dependencies, so you can use them now easily in your business logic layer - or in pure Dart unit tests. I like that. (I noticed because the latest Riverpod version used it as a new dependency.) submitted by /u/eibaan [link] [comments]
CirrusLabs Flutter image replacement
/u/MooresLawyer13
The deprecation of Cirrus Labs' images for Flutter caused a problem for my CI workflow. The alternatives were: https://hub.docker.com/r/instrumentisto/flutter https://github.com/davidmartos96/docker-images-flutter (active fork still) MobileDevOps/flutter-sdk-image (solid, amd64-only as far as I could tell) https://github.com/instrumentisto/flutter-docker-image (marked closed/archived) https://github.com/Zekfad/flutter_builder https://github.com/Fansesi/docker-android-flutter https://github.com/mingchen/docker-android-build-box Being on Gitlab (non-Github) platform + own runners cluster meant that we had to come up with our own solution. I got tired of Flutter Docker images being either dead or amd64-only, so I made my own. So I made a replacement: https://github.com/LahaLuhem/chrysalis. It's differencing features are: Native arm64 build, not the whole image running under QEMU pretending to be a Raspberry Pi. amd64 builds on a normal runner, arm64 builds on an actual arm64 runner. arm64 can still build APKs, which took some fighting. Google just doesn't ship arm64 builds of aapt2, the NDK, or cmake, no arm64 Linux binaries exist, full stop. So the image quietly carries the handful of x86 libs those tools need and leans on emulation for just that part, instead of the build face-planting with a cryptic loader error. Actually OCI-native, not a Docker manifest list dressed up to look multi-arch. docker buildx imagetools inspect shows a real OCI image index, and I wrote a script that fails CI if it ever regresses because apparently I care. DX: Small set of opt-in build helpers baked in (signing, google-services.json, dart-defines from env vars) that sit there doing nothing until you actually call them, so no surprise side effects if you don't need them. (compartmentalized, so you can also curl-and-run them if you can't use the image directly) Renovate bumps Flutter automatically off the stable channel. I refuse to be the guy manually checking the Flutter release page every week. Might increase it given the how quickly the 3.44.x have been coming out. I'm looking for feedback and other use-cases. I hope that it helps some of you having a similar problem. I did initially fork the deprecated image (hence the stale contributors count), but removed it because the scope and direction were completely different. Would have been better off starting from scratch. submitted by /u/MooresLawyer13 [link] [comments]
[Package] mcp_dart 2.3.0: day-zero MCP 2026-07-28 support and a cross-language CLI
/u/leehack
submitted by /u/leehack [link] [comments]
Build a small feature - searchable dropdown( textfield + dropdown + search capability)
/u/night-alien
Heloo developers, I build a searchable drodpdown. where you can search and scroll, select any item. So there are two approach to build this kind of ui- 1. Overlay approach 2. Column/Stack Approach. And I used Column Based Approach. Both has their own benefits and drawbacks. I choose this way because I want to go from easy to difficult, as I need to learn new concepts for overlay approach (next target). submitted by /u/night-alien [link] [comments]
Help With IDE's
/u/Realistic-Gas-4057
I've been learning the basics of flutter for about a month now on Online IDE's like DartPad and FlutLab. But I kinda feel restricted with them and want to move to VS Code. However, on my Chromebook coding flutter is fine. It's just the running part where I run into so many issues like missing SDK's, software crashes, just the lot. So my question is. Is there an extension in VS Code to like emulate my app easily or are they any lightweight ways to test the app. Note(I've tried my phone but am struggling to get it to work with my Chromebook. I can't download Android SDK's cause of the 10GB limit for Linux on Chromebook. And using chrome to try run flutter requires me to download Chromium which in the end just crashes itself and VS Code. submitted by /u/Realistic-Gas-4057 [link] [comments]
Private Flutter packages got expensive so I tried git deps as the free alternative. its worse honestly
/u/CounterOne4728
quick disclosure before anything else, I built a tool related to this so im not just here to drop a link and vanish. per rule 9, here's the actual build insight, not just "check out my app": at work we host 50+ internal Dart/Flutter packages across two SDK repos, small team, 3 devs plus CI. we were on a paid private pub registry and the bill kept going up every time we added a package. obvious move, switch to git deps, theyre free right. except git deps quietly break the one thing that makes pub actually good. once you pin to a branch or a commit instead of a real version the solver just cant do its job. no real constraints anymore, and you end up buried in dependency_overrides just so things resolve at all. every version bump across 50 packages turned into manually digging through commit hashes trying to remember which one was "the good one" so the actual build problem I had to solve: making a private registry that speaks the real pub hosted-repo protocol (the spec dart-lang publishes), not a wrapper around git or a custom CLI. that part matters more than it sounds, dart pub publish and dart pub get need to hit specific endpoints (upload finalize with a Location header, version listing json, archive download) exactly the way pub.dev does or the client just silently fails or hangs. spent a chunk of time on that compatibility layer specifically, way more than on the UI ended up with Publy out of that (theres a free tier, publy.dev, if anyone wants to poke at the protocol side of it) what i actually want to know is how everyone else deals with sharing internal packages across multiple flutter repos. paid registry, git deps + overrides, melos monorepo, something else. feels like theres no clean answer thats not either "pay per seat" or "fight the version solver forever" submitted by /u/CounterOne4728 [link] [comments]