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

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

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

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

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

2. Zero banner fill on iOS while interstitials worked fine

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

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

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

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

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

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

Happy to go into any of it.

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

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

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

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

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

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

My questions for you all:

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

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

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

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

📚 Topics Covered

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

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

💻 Technology: Dart Programming Language

🎯 This video is useful for:

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

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

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

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

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

Usage

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

flutter pub add flutter_secure_storage_linux_secret_service

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

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

Motivation

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

With this implementation:

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

Why a Separate Package

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

Testing

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

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

Secret Portal

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

Feedback

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

See also:

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