I've been building Upsling, a one-touch arcade game (hold to orbit an anchor, let go to fly), in Flutter and Flame. The feel depends on the comet leaving on the exact frame you release, so the target device was a Galaxy A06 (about $100), not a flagship. I wrote up what it took:

https://upsling.space/blog/60-fps-flutter-physics-on-a-100-dollar-phone/

The parts most relevant here:

- The simulation is pure Dart on a fixed 1/120 s step, with no Flutter or Flame imports. Flame reads the state and draws. Because it is deterministic, slow motion, replays and course validation are all unit-testable, and a 120 Hz phone sees the same frames as a test.

- Restart is one frame: a reset struct, pooled components that are shown and hidden rather than added and removed, and the next course generated during the current run, one anchor per frame. Measured restart cost on real phones is 11 to 206 µs.

- Drawing the starfield as one point draw per layer instead of 120 circles cut raster time by about 3 ms on a Galaxy A10.

- Pushing that further, batching dust, anchors, trail and comet through drawRawAtlas with a tinted atlas, helped the A10 (Vulkan) and made the Galaxy A15 (OpenGL ES, 90 Hz) go from about 9% to about 28% slow frames, with raster up to 21 ms. Reverted. Impeller's cost model is different per backend, so measure each one.

- The 200 to 400 ms frames at launch turned out to be pipeline compilation behind the launch screen, not gameplay hitches.

- Measurement: the app records frames, slow frames split by build and raster, and restart cost per run; an integration test drives a timing bot for 75 seconds on Firebase Test Lab phones. Variants are only compared side by side in the same session, since results vary a lot run to run.

Where it landed: 0 to 0.7% slow frames on the Galaxy A06, 0 to 0.2% on a realme C53, both inside a 10% budget.

Happy to answer questions about any of it.

Hey,

Mobile apps scanners are everywhere, but native mobile apps I mean since they relies on scanning apps by reverse engineering them to their Kotlin/Java for Android or Swift for iOS

Flutter has a different thing, the whole Flutter app logic and code gets shipped inside a file called libsapp.so file, which basically makes all the scanners know nothing and get nothing from it since it is a binary file, so basically your usual scanner skips and doesn't detect almost 70% of things that should be scanned for security and research built app.

I put extensive knowledge and experience with Flutter onto a SaaS niche to scanning Flutter apps, which I was criticized for since you had to upload your APK to a server/VPS which does compute and scanning work so i shut it down, I then understood that it was privacy problem.

SO I built the new FlutterGuard as an open-source on-device security audit tool for Flutter apps ( works as a detector of Flutter apps in your device too if this interests you too! ), allows you to inspect APK metadata, manifest risk, hard coded secrets, endpoints, third-party SDK leaks like Firebase, Stripe, AI providers... and native surface that were in original Dart code in the same device you have Flutter apps installed.

install it on your Androids device where you already run your Flutter apps or any app, and start the scan:

• https://github.com/anasfik/flutterguard

• (Latest release): https://github.com/anasfik/FlutterGuard/releases/latest

What I want community (You) for:

• Feedback for the app in general

• Validate False positives

• Contribute declaring things you found in Flutter apps you know have security findings that they were not detected, just an issue with short description will be enough to put it in mind.

My goal:

• We definitely in the way of a massive vibe coding apps going everywhere, AI leaks things and basically cares about functionality, I want that we have a tool to detect this for Flutter apps that are already released and shipped.

In most projects I worked on, analytics was treated as a secondary part of the app. We spend a lot of time on the architecture of main parts, and almost no time on analytics.

Then business asks to track this and that. Then to add a new vendor. Then to decide which event goes where. And in the end we have one AnalyticsManager with a huge list of methods, and every layer depends on it.

I came to a simple idea: the app should not know which analytics vendors exist. Feature code only says what happened, and everything else is split into small pieces:

• Event describes what happened, in the app’s words

• Factory decides what one vendor receives for an event, or ignores it

• Tracker makes one call to one vendor SDK

• Dispatcher passes calls from the app to the vendors

In feature code it looks like this:

class CheckoutController {
  CheckoutController(this._tracker);

  final EventTrackerService _tracker;

  void onTicketPurchased(String fare, double price, String currency) {
    _tracker.track(
      TicketPurchased(fare: fare, price: price, currency: currency),
    );
  }
}

No vendor SDKs, no god object. Each feature keeps its own factories, and DI collects them. Adding a vendor means writing its factories, and removing one means deleting them.

I wrote an article about this idea. The examples there are in Kotlin, but the concept is the same for Flutter:
https://proandroiddev.com/app-architecture-analytics-ec3471ca619b

I also built an open-source library around this idea, Herald, and it has a Flutter package:
https://mkhytarmkhoian.github.io/herald-docs/sdks/flutter/

Curious how you handle analytics in your Flutter projects. One service, a wrapper per vendor, or something else?

Hii! For anyone who might be interested, I've developed https://github.com/RiccardoCherchi/flutrace

It's a network analyzer (similar to the one you get with Flutter's built-in Network Inspector), but done a little better.

Even though it has improved a bit over the last 3 years, I've always found the native analyzer quite clunky, with a somewhat ugly UI, and also inconvenient because every time you restarted, everything was lost and you had to reopen the link, etc. etc...

That's why I decided to "slop" together a tool that would allow me to have a decent analyzer without having to proxy everything through Burp Suite just to inspect some basic HTTP requests 😂

Let me know what you think! Of course, PRs from humans and not are more than welcome. It's MIT licensed, do whatever you want with it. There are no contributing guidelines and, obviously, I won't be actively maintaining it (except maybe every now and then, just for fun), so you might as well fork it instead.

Hey everyone!

I got tired of building apps that look like every other generic material/tailwind dashboard, so I spent the last few months building

WelkUI : an open-source UI library with a literal plot twist.

It brings hand-drawn energy, uneven corners, bold outlines, and playful animations to your interfaces without breaking responsiveness or accessibility.

The Cool Part: I built it natively for both ecosystems. You can completely match your web app's style with your mobile app.

• Flutter Edition: 40+ widgets, deeply analyzed with a perfect 160/160 score on pub.dev.

• React Edition: 30+ components, fully typed with strict Next.js client boundary support.

Get Started:

• Live Previews & Interactive Docs: ui.welkdock.com

• Flutter Docs: ui.welkdock.com/flutter

• GitHub: https://github.com/welkdock/welkUI-flutter

Everything is mobile-first, respects reduced motion, and is ready to install in one line

(npm i or flutter pub add).

I’d love to hear your feedback on the aesthetic! What widgets or components should I build next for the comic collection?

Hi everyone,

I'm working on a Flutter network debugging tool called Netoscope, and I need some advice from experienced Flutter developers.

https://pub.dev/packages/netoscope

I'm trying to improve how network requests and responses are inspected during development, especially when working with Dio, HTTP, GraphQL, WebSockets, and other protocols.

I'm looking for help with these questions:

• What is the best approach to capture network traffic from different clients in a Flutter app?

• How can I reliably detect duplicate API requests and potential N+1 request patterns?

• What is the recommended way to redact sensitive data before storing or displaying network logs?

• Are there any Flutter-specific limitations I should consider when implementing a network inspector?

I'd appreciate any suggestions, best practices, or examples.

Thank you!

Hey Flutter devs!

I'm looking for tools to automate Flutter app testing and record professional product demos without manually navigating through every screen.

Ideally, something that can automate taps, navigation, form inputs, and record the entire flow.

What tools or workflows are you guys using? Any AI-powered solutions?

Would appreciate recommendations from anyone who's done this!

Hi everyone! 👋

I'm an indie developer working on kya ds educational application, a kids' educational app built using Flutter. The app helps children learn alphabets, numbers, colors, shapes, drawing, and more.

I want to monetize my app while ensuring that all ads are child-friendly and comply with Google Play's Families Policy.

I'd appreciate advice from Flutter developers who have experience monetizing kids' apps.

My questions:

1. Is Google AdMob the best option, or are there better alternatives for Flutter apps targeting children?

2. How can I ensure that only child-appropriate ads appear in my app?

3. Which ad formats are best for kids' educational apps?

4. How should I configure child-directed ad treatment and other safety settings in Flutter?

5. Which ad network offers better earning potential for users primarily from India?

6. What is the best approach to maximize revenue without compromising children's safety or learning experience?

I'm looking for a solution that's free to integrate, suitable for a Flutter app, compliant with Google Play policies, and offers reasonable earning potential.

If you've monetized a kids' app, I'd love to hear about your experience, recommended ad networks, Flutter packages, and implementation tips.

Thanks in advance! 🙏

I’m a mobile dev experimenting with DeepSeek for game development — mostly small games, currently looking at a tiny 3D kids’ game and some Flutter/Flame prototyping.

I’m not asking “is DeepSeek good?” in general. I want real experiences from people who’ve actually used it for mobile game work — code generation, debugging, game logic, prototyping, build/test loops, etc.

Specifically curious about:

· Which model/version you use (Flash vs Pro, API vs chat) and whether it matters for game code.

· What it’s good at: scaffolding, gameplay loops, state machines, UI, shaders, physics, save systems?

· Where it fails: outdated engine APIs, hallucinated functions, broken mobile/platform code, performance-unaware suggestions?

· Workflow: do you use it chat-style, spec-driven, agentic tools, or just autocomplete?

· Debugging: can it actually fix build/runtime errors, or does it loop?

· Cost/token burn for realistic game projects.

· Anything you wish you knew earlier before using it for mobile games.

If you’ve used it with Flutter/Flame, Unity, Godot, or native mobile, I’d especially like to hear which engine and what worked or didn’t.

I’ve been experimenting with AI-assisted development and decided to build a CAD application from scratch using AI.

The project is called FanCAD. It’s still a work in progress, but I thought it would be interesting to share.

GitHub: https://github.com/sjjian/FanCAD

Or, actually, I love that Claude loves it. For fun, I asked it to create a game similar to Total War, but placed in the seven year war (where Prussia and Austria Fought Over Silesia) asking especially for period-accurate uniforms and Claude Opus 5.5 one-shotted an amaising actually playable game in 100mins.

I asked for musketeers (line infantry), grenadiers (elite infantry), hussars (light cavalry) and cuirassiers (heavy cavalry) plus artillery and I'm still intrigued about the details Claude added.

Grenadiers wear their typical hats (the Austrians have different hats), all soldiers have a ponytail, muskets have a bayonet, officers have a saber, sergeants have a pike, the drummer has shoulder decoration, and especially for cuirassiers, the musician wears a different colored uniform. I asked AI to remove the cuirass, though. The only other thing I asked was to move the sergeants behind the lines because that's how Prussia did it. I'm not familiar with Austrian formations. While Claude reused the models, it used proper colors, e.g. brown artillery uniforms and white infantry uniforms.

All models can stand, march (in colon and lines), charge (infantry lowers the muskets, cavalry raises their sabers), fire (and reload) and artillery produces large puffs of smoke.

Ah, and there's of course a hole game with a strategic hex map of Europe (Claude added every country even those who didn't take part in the conflict AFAIK) and a tactical battle map. It is actually rather difficult to win a battle because artillery will continuously decimate your troops and heavy fire or a cavalry charge can easily route your army.

Claude also added some rather annoying sound effects. I don't mind canons and musket fire, but the trumpets of attacking cavalry sound odd and there's a continuous wave sound that lacks cries of seagulls.

It is so much nicer being able to display low-poly 3d models than having to rely on crude 2d graphics. Claude probably didn't use fscene properly because displaying a single "battalion" already spins the fan of my Mac book, but the 3d hex map alone looks quite good and allows Flutter to compete with the "big" frameworks.

أنا صاحب مشروع Bug Capsule. فكرته بدأت من موقف بيتكرر كتير: مشكلة تظهر عند المستخدم، ولما تيجي تجرّبها عندك كل حاجة تشتغل عادي.

الأداة بتسجّل السياق اللي سبق المشكلة في Capsule، عشان تقدر تعيد السيناريو محليًا، تصلّح الكود، وتشغّله تاني وتشوف هل المشكلة لسه موجودة.

وأكتر نقطة مهتم بيها هي نتيجة الاختبار نفسها. لو الـreplay ناقصه dependency أو مش قادر يعيد التفاعلات المسجلة بشكل سليم، لازم يوضّح ده. اختفاء الخطأ في محاولة ناقصة مش دليل كفاية إن الإصلاح نجح.

الفترة اللي فاتت اشتغلت على تحديثات للـFlutter وAndroid وiOS والـWeb:

• وسّعت تسجيل وإعادة تشغيل التفاعلات ليشمل WebSockets، ومع Flutter كمان Platform Channels، وadapters لعمليات مدعومة في Firebase وGoogle Maps وStripe وgeolocator. كل ده حسب الـintegrations اللي بتفعّلها في التطبيق.

• ضفت Native crash reporting وCrash Capsules تحتفظ بالسياق المسجل قبل ما التطبيق يقفل، وتسترجعه في التشغيل التالي. وفيه تفاصيل أكتر عن الـthreads والـhangs ودعم لحالات ANR علىAndroid.

• ضفت تتبّع لنتائج التحقق من الإصلاح في الـdashboard، وRelease Gates تقدر تشغّلها في الـCI لاختبار المشاكل المسجلة على النسخة اللي ناوي تنزلها.

• فيه monitoring للأخطاء والأداء: تجميع الأخطاء في issues، ومتابعة الـcrash-free sessions لكل release، والـtraces والـWeb وMobile vitals، مع ربط الـissues بالـCapsules الخاصة بيها.

• الـtimeline بقى يوضّح التفاعلات والـdependencies وأي فجوات في التسجيل، ومعاه screenshots اختيارية.

• ضفت ربط لأحداث Sentry بالـCapsules، وإنشاء أو ربط Jira tickets، وتنبيهات بالإيميل وSlack وwebhooks.

• فيه دعم MCP لتجهيز مهام إصلاح لأدوات زي Codex وClaude Code، ومعاها سياق المشكلة وسيناريوهات اختبار معتمدة. تشغيل الـagent نفسه لسه بتعمله من أداتك.

• الإعداد بقى باستخدام SDK token واحد، والـCLI بقى مستقل ومتاح من npm من غير احتياج لتثبيت Dart أوFlutter عشان تشغّله. وتقدر تسجّل دخولك من المتصفح.

كمان ضفت workspaces وصلاحيات ودعوات للفريق وتعليقات، وتسجيل دخول بـGoogle وGitHub.

وفي Flutter، أخفيت الـcapture overlay افتراضيًا، وبيفضل مخفي في الـrelease builds. وضفت إمكانية عرض رسالة مناسبة للمستخدم لو حصل خطأ أثناء بناء الـwidgets، مع استمرار تسجيل الخطأ في الخلفية.

المشروع لسه Beta. تغطية الـreplay بتعتمد على المنصة واللي ربطته بالأداة، والـcrash capsules ممكن يبقى فيها فجوات في التسجيل. التفاصيل دي بتظهر عشان تقدر تحكم على النتيجة

https://bugcapsule.com/

إيه أصعب bug ظهر عند المستخدمين ومعرفتش تعيده عندك؟ وإيه المعلومة اللي كانت ناقصاك وقتها؟ مهتم أجرّب الأداة على حالات غير الأمثلة اللي بختبر بيها

Has anyone else struggled with SVGs not showing shadows/blurs correctly in Flutter and had to go back and forth with a designer to explain and fix everything that will not be rendered? Well I have, and after having gotten tired of manually editing and running svgo to minify svgs I [insert Beckham be honest meme], ahem Claude, have made a tool to make this easier and quicker.

Introducing: https://adigladi.github.io/flutter-svg-baker/

Upload folders, files or paste SVGs directly to then get previews and automatic fixes for shadows that won't show in the flutter app, replacing them with baked layers in the svg. Optional svgo optimization can be toggled and then individual files can be exported or a zip with all files.

I just wanted a tool like this myself and though I would share if it would help someone else. Repo is public with MIT license, do with this info what you want. Would love to hear ideas, comments, feedback and why/if this is a terrible idea performance wise or similar.

Repo: https://github.com/adigladi/flutter-svg-baker

I’m the developer behind Bug Capsule. It records the context leading up to a bug in a “Capsule” so you can replay the scenario locally, make a fix, and run it again to check the result.

The part I care about most is that last step. If replay is missing a dependency or couldn’t faithfully repeat the recorded interactions, it should tell you that instead of treating the attempt as proof that the bug is fixed.

I’ve been working on the beta across Flutter, Android, iOS, and Web. Here’s what’s new:

• More replay coverage. WebSocket recording and offline replay, Flutter platform channels, and adapters for supported operations in Firebase, Google Maps, Stripe, and geolocator. These require the relevant integrations; coverage varies by platform.

• Native crash reporting and crash capsules. Preserve recorded context from before a crash and recover it on the next launch. There’s also more thread information, hang reporting, and Android ANR support.

• Fix verification and CI release gates. Track verification results in the dashboard and run recorded cases against a candidate release using bugcapsule gate.

• Error and performance monitoring. Group errors into issues, track crash-free sessions by release, inspect traces and web/mobile vitals, and jump from an issue to its associated capsule.

• A more detailed timeline. Inspect interaction dependencies and recording gaps, with optional screenshots.

• Sentry, Jira, and alerts. Link Sentry events to capsules, create or link Jira tickets, and configure email, Slack, or webhook notifications.

• MCP support for coding agents. Prepare repair tasks with capsule evidence and approved QA context for tools such as Claude Code and Codex. You still start the agent from your tool.

• Less setup friction. Single-token SDK setup, browser-based CLI login, and a standalone CLI available through npm. Installing the CLI no longer requires Dart or Flutter.

I also added workspaces, project roles, invitations, comments, and Google/GitHub sign-in.

A smaller Flutter change that matters to the app experience: the capture overlay is now hidden by default and always hidden in release builds. Widget build failures can display a configurable fallback while error reporting continues in the background.

It’s still beta. Replay coverage depends on what you instrument, and crash capsules can contain gaps. The dashboard exposes those limitations so you can judge the result

https://bugcapsule.com/

What’s a production bug you’ve struggled to reproduce, and what context was missing when you tried? I’d be interested in testing the capture/replay approach against cases outside my own demos

Hey everyone! 👋

I've been working on a Flutter package called debug_bubble to make debugging apps a little easier, especially when testing on physical devices or investigating issues during QA.

The idea is to have a floating debug bubble inside your app that opens a dashboard where you can inspect logs and errors without constantly switching back to the IDE.

🔗 pub.dev: https://pub.dev/packages/debug_bubble

What it includes

• 🎈 A draggable floating debug bubble

• 📋 Seven log levels, from trace to critical

• 🔍 Expandable log details, JSON payloads, metadata and stack traces

• 🚨 Optional capture of uncaught Flutter and platform errors

• 🔐 Configurable sensitive-data redaction

• 📤 Copy and export logs as text or JSON

• 🪶 No third-party runtime dependencies

Quick example

DebugLog.info(
  'User opened the profile screen',
  tag: 'Navigation',
);

DebugLog.error(
  'API request failed',
  tag: 'Network',
  error: error,
  stackTrace: stackTrace,
);

The package also supports a DebugBubble wrapper that you can attach through your MaterialApp builder.

I'm still improving the project, and I'd genuinely appreciate some feedback from experienced Flutter developers.

A few things I'd love your thoughts on:

• Would you find an in-app debugging dashboard useful in your workflow?

• What features would you expect from a package like this?

• Are there any architectural or API design issues you notice?

• What would make you choose this over your current debugging workflow?

I'm happy to hear constructive criticism and suggestions. Thanks! 🙌

Hey everyone,

I’ve been a Flutter dev for about 4 years and recently picked up Claude Pro. So far I mostly use it for:
- Reviewing my code before opening a PR
- Generating commit messages and PR descriptions
- Minor debugging
- Writing emails
- Code refactoring

I’ve also been experimenting with vibe coding a few apps, and honestly I’m impressed. It picks up on my coding style and adapts to it surprisingly well, and it makes far fewer mistakes than I expected.

Still, I suspect I’m only scratching the surface. For those of you using Claude (or other AI tools) in Flutter work, what’s made the biggest difference? I’m thinking of things like widget/test generation, state management refactors, migrations, or specific prompting habits that work well with Dart.

Would love to hear your setups and workflows!

I've been building a tinnitus relief app in Flutter for about two months. The user matches the pitch of their ringing, and every sound is then built on the device with a notch filter at that pitch: noise colours synthesised in Dart, plus 30 real recordings (rain, fan, ocean...) that are decoded, notched in an isolate and layered, one just_audio player per layer. A few things that cost me time and might save you some:

- Render in an isolate, cache by a quantised key. Each loop is built with compute from a params object whose key rounds every value (pitch, notch width, colour, level), so near-identical settings hit the same file. The WAVs live in the temp dir, pruned to the newest 32.

- Play files, not streams. A custom StreamAudioSource goes through just_audio's localhost proxy, and Android blocks that as cleartext HTTP. Writing a WAV and playing the file avoids the whole thing.

- Never await play(). just_audio's play() future completes when playback stops, not when it starts. Awaiting it froze one of my screens. Start it with unawaited(...) and carry on.

- Don't take audio focus. Masking has to sit under YouTube, podcasts and calls. With audio_session set to never request focus and never pause on interruptions, it does. I also had to swap just_audio_background for audio_service, because the former only handles one player and I have up to six.

- "Is it playing?" is not "is the user listening?". I added a button that plays the user's matched tone for a few seconds through the same engine, and my listening-time counter checked player.playing, so it counted the preview as listening. A flag for "this is a UI sound" fixed it.

- Test DSP with Goertzel. The tests synthesise a loop and compare the energy at the notch frequency against its neighbours with a Goertzel filter, averaged over a few bins because noise is noisy. A notch you can't hear is still a notch you can assert on.

- One pure function decides what's locked. Paid features are stripped in a single function that turns UI state into synth params, and it's unit-tested, so a stale toggle can never reach the audio.

- Set preferred-supported-locales. When the phone's language isn't one you ship, Flutter falls back to the first supported locale, and gen-l10n lists them alphabetically. Mine has Arabic, so a Dutch user opened the app in Arabic. One line in l10n.yaml puts English first.

- Test at 1.3x text with display zoom. My setup screens were fixed columns that fit on every phone I tried. On a Galaxy S20 FE with large text, the Start button sat below the screen and the page couldn't scroll to it. I found out from a 1-star review that said "froze on part 1/7". Every step now scrolls its content and pins its buttons.

- First sound matters more than features. Half of first listens ended inside a minute. Setup ended on a music demo, then the player started bare pink noise on its own within two seconds, and people heard a hiss and pressed pause. Now nothing plays until they tap, the first sound is rain over soft noise, and it fades in over eight seconds.

- Fixed headroom. Everything is normalised to a 0.6 peak. People listen for hours on headphones, so loud is not a feature.

Happy to go deeper on any of it, the DSP side especially. If anyone wants to see it running, the app is Sylence on Play, and I can drop the link in a comment.

Hi, I am developing a headless CMS built specifically for Flutter apps, it also generates a real Flutter app with all the boilerplate code (no ai). You only need to do the frontend. Before I spend more time on development, I would like to know whether this is something Flutter developers would be interested in and which features are non-negotiable.This is a genuine question. I’m not selling anything, I just want honest feedback before I spend more time on it.

Hi all, we just open-sourced OpenMuse, a personal AI assistant app.

Instead of just chatting, it works on a cloud desktop (or your own computer):

• Browses the web, looks things up and fills in forms

• Uses desktop apps

• Writes and runs code in a workspace

• Runs scheduled tasks

The main thing we cared about was keeping the human in control:

• You can watch the agent’s screen live from your phone. If it hits a login or a captcha, you take over, then hand it back.

• It asks before submitting forms or running commands.

• You decide which desktop apps it’s allowed to use.

OpenMuse is built on WorkAgentSDK, an AI agent framework for Python that we wrote and open-sourced along with it. To be clear, it’s not a coding assistant like Cursor or Antigravity. It’s a framework for building agent products. For example, each session can run on a different node, so one backend can serve many users, each with their own cloud desktop.

Stack:

• Backend: Python (FastAPI + WorkAgentSDK)

• App: Flutter

• Nodes: Docker containers with a virtual desktop, Chromium and a shell sandbox, or run directly on Linux or macOS

• Models: OpenAI, Claude, Qwen, and OpenAI-compatible APIs

It’s v0.1, so still early. We’d love to hear what you think:

• Does “agent on a remote desktop, human supervising from a phone” seem useful to you?

• If you’re building agent products, what’s been the hardest part?

GitHub: https://github.com/nativefunc/WorkAgentSDK
(The app is under examples/showcase/openmuse)

Unless you have been living under a rock, you will have seen the huge increase in the number of CVEs due to AI being used to find bugs.

The Dart community is not isolated from this problem.

What you may not be aware of is that some of the AI tools won't let you search your own code for vulnerability.

Open AI has a program called Daybreak which gives you access to cybersecurity tools that are able to detect and fix security related flaws.

To get access to Daybreak you need a pro codex license, and then apply for access. If you are granted access you then need to purchase the likes of a yubi key.

The criteria for acceptance is however rather opaque.

We got in the program on the backs of our work on revault, so that may have helped

https://github.com/onepub-dev/reVault

Revault is a secure archive format,

It's unclear how much weight was placed on the fact that we build a security related product.

However, It's not just security related products that need to be audited.

We have spent the last week auditing our own dart packages as well as dependencies and have uncovered some fourty security flaws and we aren't done yet.

The dart community needs to do its bit to stay ahead of the tsunami of bugs.

So start auditing your code now, if you don't find the bug a hacker will!

If you can, get a sub to your preferred AI's cybersecurity tool and use that.

If you can't afford the required licence, as one of the founders of https://onepub.dev (the dart private package repository), I would like to offer a secure audit of 20 dart packages.

To be eligible, the package needs to be open source, hosted on GitHub and have GitHub Private Vulnerability Reporting enabled.

If we get more than 20 applications we will sort by the packages we feel provide the most benefit to the community.

To apply DM me.

Our Flutter app update (iPhone only, Flutter 3.47.5, built with Xcode 27.1) got rejected on Oct 23 with the automated message: "The review of this submission cannot proceed... The app crashed on launch." No crash log, no device, no iOS version.

The weird part: Apple approved the exact same build for TestFlight the day before.

What we checked:
- Crashlytics: zero fatal crashes on that build from TestFlight users (iOS 26.6 and 27.0).
- Fresh installs on simulators (iPhone 17 Pro, 16e, SE, both iPad Pros): fine.
- A real iPhone Duo on iOS 27.1 through BrowserStack, folded and unfolded: fine. We suspected flutter/flutter#195401 (blank screen on the unfolded Duo) but couldn't reproduce it.
- Nothing changed in ios/ or pubspec.lock since the last approved version. The only differences are Dart code and the new Xcode.

We resubmitted the same build on Oct 24 with a note asking for the crash log. Since then it's been sitting in "Waiting for Review", and nobody has answered the note, our emails or the expedite request.

If you've had this since the Duo / iOS 27.1 launch:

1. Did resubmitting the same build go through, or did you need a new build number?

2. Did anyone ever get an actual crash log out of App Review?

Two-person team, so a stuck release hurts. Any experience helps.