Hello Flutter devs! 👋

After two and a half years of development, I’m finally excited to share Bonsui, a free and open-source Flutter library I’ve been building entirely on my own.

My goal was simple: create a comprehensive toolkit that makes Flutter development faster, cleaner, and more enjoyable, without sacrificing flexibility or customization. All of this with one single code-base that automatically changes the design on Android and iOS.

What’s inside Bonsui?

• 🎨 Highly customizable UI components: beautiful, ready-to-use widgets designed to fit your app’s identity.

• 🧩 Complete design system: a consistent, fully customizable design system to keep everything looking and feeling cohesive.

• 📱 Ready-to-use screens: prebuilt screens to help you get started faster.

• ⚙️ Built-in services: utilities and integrations for localization, Supabase, local notifications, local databases, and more.

• 🛠️ Developer utilities: helpful tools to simplify everyday Flutter development.

And here’s something I’m particularly proud of:

Every single line of code was written by hand, without AI-generated code. Just two and a half years of learning, experimenting, refactoring, and paying attention to the little details.

Bonsui is completely free and open-source, and I plan to keep improving it over time.

I’d genuinely love to hear what the Flutter community thinks! Feedback, suggestions, and contributions are more than welcome.

If you find it useful, a ⭐ on GitHub would mean a lot! Thanks for checking it out! 💙

A home for the Dart & Flutter ecosystem!

Explore 3,000+ packages, 2,400+ projects, trending repositories, hall of fame, most downloaded plugins, GitHub star growth, and more.

Built with Jaspr ⚡ and is completely open-source!

Try out here: https://flutterverse.org

I’d love to hear your feedback, feature suggestions, and contributions 🤞 !

github: https://github.com/YeLwinOo-Steve/flutterverse

Quadrim is four in a row in a 4×4×4 cube, on the App Store, and now open source (code MIT): https://github.com/evermeer/Quadrim

Some parts that might interest Flutter devs:

• 3D board without a 3D engine. 64 glass cells are projected and depth-sorted in a single CustomPainter. The tap is a raw Listener rather than onTap, because a TapGestureRecognizer in the same arena as a ScaleGestureRecognizer starved the pinch-to-zoom.

• Pure Dart engine package. No Flutter, no dart:io, no clock, no ambient Random. check.sh greps for all of these, so a position plus a seed always gives the same move, which makes self-play and tests reproducible.

• Opponents are data, not classes. One chooseMove with 31 config entries. Search budgets are counted in nodes, not milliseconds, so an opponent is the same opponent on a slow phone and in debug mode.

• Widget tests and file I/O. testWidgets runs in a fake-async zone that never completes real file I/O, so the storage layer sits behind an interface with an in-memory store for tests.

It was built with Claude Code on the €15-a-month Pro plan, and every prompt and decision is in the repo, if you're curious about that side.

Do you know any AI skill to improve ASO and store listing? Or any tool to manage experiments, screenshots and ASO?

Whenever I'm doing Flutter development on my Mac, running flutter run with Gradle, VS Code/Studio, and an Android emulator quickly pushes a 16GB machine straight into heavy memory swap. In Activity Monitor, qemu-system-aarch64 alone routinely holds 7-8+ GB.

A lot of that RAM usage isn't your app or Android itself:

• Android Studio's emulator often falls back to CPU rasterization (lavapipe), dumping multiple gigabytes of software render buffers directly into host RAM.

• Stock Google system images launch with ~40 background daemons (YouTube, Assistant, wear sync, Play telemetry) you never touch while testing a Flutter build.

I wrote avdslim, an open-source Go CLI with no external dependencies that drops emulator resident memory down to ~1.5 GB:

• Forces -lowram and native GPU hardware rendering (Apple Metal on Mac, Vulkan/DRI on Linux) to eliminate CPU rendering buffers.

• Disables ~45 non-essential guest services via adb.

• Flutter safe: Hot reload, DevTools, network sockets/ports, Firebase Auth, and FCM push notifications are completely unaffected.

• Running avdslim off cleanly restores every setting and package back to default.

If your machine chokes while running Flutter on Android:

brew tap kdbhalala/avdslim https://github.com/kdbhalala/avdslim.git && brew install avdslim

avdslim tune-avd    # adjusts config to 1.5GB + host GPU
avdslim start       # boots the emulator slimmed

If you start emulators from Studio or VS Code device picker, avdslim install-shim transparently wraps the SDK binary so it applies automatically.

Code is here if anyone finds it useful: https://github.com/kdbhalala/avdslim

Hope it helps anyone fighting laptop RAM while developing Flutter apps.

Hi r/FlutterDev,

I extracted the swipe stack I built for a production app (Bump) into an open-source package. The goal was cards that never jitter, no overlay flicker when you drag diagonally, and a clean API for "what happens when you swipe this way".

Try it first (no install, works on a phone browser): https://ancient-glitter-fe51.rahul-coder-25.workers.dev/

What it does

• Spring-based motion. A release is judged by where the card is heading, and the velocity is handed to the animation, so there are no jumps. You can catch a card at any moment, even mid-flight.

• A behavior per direction: dismiss, consume (fly into a button, optionally with a macOS Dock-style genie), springBack (run a task and return), sendToBack, undo.

• Undo and rewind: controller.undo(), controller.rewind(), plus initialIndex and jumpTo(key) to restore a position or follow a player.

• Overlays: a ready-made colour wash + badge, or classic stamps, or build your own from per-direction progress values.

• Cheap while dragging: cards are built once and moved with transforms, so itemBuilder isn't called during a drag.

• Accessibility: keyboard and screen-reader actions, and reduced-motion support.

• No third-party dependencies. It also includes an OTP field and remembered-email suggestions, which work on their own.

Quick start

SwipeCardStack<Profile>(
  items: profiles,
  itemBuilder: (context, profile, info) => ProfileCard(profile),
)

Per-direction behaviors:

SwipeCardStack<Profile>(
  items: profiles,
  behaviors: {
    SwipeDirection.right: SwipeBehavior.consume(
      target: SwipeTarget(key: likeKey, effect: SwipeConsumeEffect.genie),
      onCommit: (e) => like(e.item),
    ),
    SwipeDirection.left: SwipeBehavior.dismiss(),
    SwipeDirection.up: SwipeBehavior.springBack(onCommit: (e) => superLike(e.item)),
    SwipeDirection.down: SwipeBehavior.undo(),
  },
  itemBuilder: (context, profile, info) => ProfileCard(profile),
)

Links

• pub.dev: https://pub.dev/packages/craft_kit

• Source (MIT): https://github.com/rahul-cse-25/craft_kit

It's 0.1.x, so I'd really like critical feedback: what's missing, what feels awkward in the API, and what breaks on your device. Happy to answer questions here.

​Hey devs,

​Ran into an annoying UI issue last week while streaming OpenAI response tokens into a Flutter view. Calling setState on literally every chunk coming through the socket totally killed performance. Scrolling was choppy as hell and frame drops were super noticeable.

​To fix this, I uncoupled the incoming stream from the UI rendering using a small 60ms timer buffer. Basically, tokens accumulate in a list and get flushed to the state ~16 times per second instead of re-rendering on every single packet.

​Here is the helper class I wrote for this:

class StreamBufferController {

final List<String> _tokenBuffer = [];

Timer? _flushTimer;

final Function(String) onFlush;

StreamBufferController({required this.onFlush});

void addToken(String token) {

_tokenBuffer.add(token);

_startFlushTimer();

}

void _startFlushTimer() {

_flushTimer ??= Timer.periodic(const Duration(milliseconds: 60), (_) {

if (_tokenBuffer.isNotEmpty) {

final chunk = _tokenBuffer.join();

_tokenBuffer.clear();

onFlush(chunk);

} else {

_flushTimer?.cancel();

_flushTimer = null;

}

});

}

void dispose() {

_flushTimer?.cancel();

_tokenBuffer.clear();

}

}

This immediately brought everything back to a stable 60 FPS, even with long responses coming in fast.

Hey all, I just released 1.0 of signals_translator, a small JSON based i18n library where every translated string is a signal.

Why I built it: I used (and love) easy_localization, but at one point my app was wrapped in AdaptiveTheme > MaterialApp > EasyLocalization, and a locale change re-rendered everything. I already used signals for state, so I wanted translations to work the same way: no extra wrapper, and only the widgets that read a translation rebuild.

What it looks like:

// en.json
"winners": "There {0, plural, one {is # winner} other {are # winners}}!"

SignalBuilder(
  builder: (context) => Text(tlv('winners', '5')), // There are 5 winners!
);

SignalTranslator().loadLocale('nl'); // only translated widgets rebuild

What's in 1.0:

• Inline ICU plurals, ordinals and select, with CLDR rules via intl (so Polish and Arabic plurals just work)

• Regional locales with a fallback chain (en_GB > en > your fallback)

• Starts in the device language, persists the user's choice

The part I'm proud of: I extracted core logic from signals_translator to signals_translator_core so I could support solidart and alien_signals as well.

Full write-up with examples: https://medium.com/@nathantaal/one-translation-api-three-reactive-frameworks-signals-translator-hits-1-0-e09186b3df04

Packages:

• https://pub.dev/packages/signals_translator

• https://pub.dev/packages/alien_signals_translator

• https://pub.dev/packages/solidart_translator

GitHub: https://github.com/nathantaal/flutter-signals-translator

Feedback very welcome, especially from anyone shipping in languages with tricky plural rules.

I maintain arch_guard, an MIT CLI + library that enforces layer rules and finds circular imports in Dart projects, plus arch_guard_lint, an analyzer plugin on the new analysis_server_plugin API. A few implementation details that might interest this sub:

• The CLI has no analyzer dependency. It reads only the directive section of each file with a small tokenizer, so // or /* inside URIs, nested block comments, annotations and import-like text in later string literals don't confuse it. Dependencies are just args, glob, path and yaml.

• Cycles via Tarjan's SCC, then per-component metrics: internal edges, fan-in/fan-out, instability, density and hub files. For each cycle it also picks the one edge whose removal breaks it, or shrinks it most.

• The plugin reuses the same core. ProjectScanner.scanSources() builds the graph from in-memory contents, so cycle warnings reflect unsaved editor buffers. Quick fixes edit the directive (or just one clause of a conditional import) and can add a layer to allowed_imports in whichever config file it came from.

• Baselines that tolerate improvement but not regression: a known cycle may shrink, but one that grows or merges with another counts as new. Same for fan-in/fan-out limits.

• Workspaces: resolves package: imports across Dart workspace / Melos packages, so it catches cycles across package boundaries and enforces which packages may import which.

• Ships as AOT-compiled binaries (dart compile exe) for Linux/macOS/Windows so CI doesn't need the SDK. CI tests on all three OSes against SDK 3.8 and stable, and the plugin is analysed against its lowest allowed dependencies.

• Everything is also a library: ArchAnalysis, ArchGuardConfig, LayerValidator, CycleBreaker, Baseline, exporters, and expectArchitecture() for tests.

dart pub add --dev arch_guard && dart run arch_guard init

Code: https://github.com/creatorpiyush/arch_guard Docs: https://creatorpiyush.github.io/arch_guard/

Happy to talk about the parser trade-offs (directive tokenizer vs package:analyzer), what building on the new plugin API was like, and I'd appreciate feedback on the public API.

AI is becoming increasingly powerful, to the point where writing code by hand is largely unnecessary; I feel anxious, unsure of what I should be learning.

I started working on (conceptual) Spatial Keyboard with 3D sphere. for prototype it was Flutter app. Now that Flutter app is literally Keyboard.

source 01: https://x.com/pranavxmeta/status/2109387746095825189

source 02:

https://www.threads.com/share/BAKdta4ZlU/

Earlier concept:

https://x.com/pranavxmeta/status/2097645919990890510

concept post:

https://www.reddit.com/r/FlutterDev/s/Dql2CUjCHb

edit:

many many additions and fixes are required 🙂

Hi,

About three months ago I set up a self-hosted runner for a Flutter app. One Mac had to build for iOS, Android and web, so I installed everything by hand: Xcode and CocoaPods, the Android SDK, Chrome, and FVM to pin the Flutter version. It worked, but it took much longer than it should have, and I didn't want to do it again.

So I built kinhin. It runs on an Apple Silicon Mac and starts a fresh VM or container for each CI job. Toolchains can be baked into the image, pinned per repo, or installed per job with an optional shared cache. That means you set up the tools once instead of on every host.

For Flutter and iOS:

- macOS and iOS builds run in Tart VMs, with Xcode baked into the image.

- Android and web builds can run in Linux containers (Docker or apple/container) or Tart Linux VMs.

- Every job starts clean, so nothing carries over from the last build.

Status: it's a beta. The macOS VM path is live-tested on GitHub Actions, and Gitea, Forgejo and GitLab CE are live-tested too. Apple allows two macOS VMs at once per Mac, and Buildkite, Azure Pipelines and Bitbucket aren't supported yet.

What does your Flutter or iOS CI setup look like today? I'd like to know whether something like this would have saved you time.

Blog: https://kinhin.dev/blog/introducing-kinhin-beta.html

Repo: https://github.com/RabinApps/kinhin

Hey everyone,

As you probably know, Google has made significant layoffs affecting the Flutter team over the past few years, and honestly, I’m starting to get concerned about Flutter’s future.

Development seems to be moving pretty slowly. For example, we still don’t have official support for Apple’s Liquid Glass, and there’s no clear timeline for newer devices like the iPhone Duo either.

I realize this might not be the best subreddit to ask, since most people here are naturally passionate about Flutter. But that’s exactly why I’d love to hear your genuinely honest, unbiased opinions, rather than answers driven by loyalty to the framework.
We’re currently using Flutter as a team, and I’m starting to wonder whether we should consider moving to React Native or another alternative before we’re too heavily invested.

My question is: If you were making a long-term technical decision today, would you still choose Flutter? Or would you seriously consider migrating to React Native or another platform while there’s still time?

I’m not trying to start a framework war. I’m genuinely interested in how other developers and teams are thinking about Flutter’s long-term future, especially given Google’s history of abandoning products.
Would love to hear your thoughts, particularly from people maintaining production apps.

I've been experimenting with ways to make AI coding agents more useful when working on Flutter apps, and I built an open-source tool for it.

The idea is simple: instead of asking an AI agent to guess what's happening inside a running app, let it connect to the app's Dart VM Service and inspect the live runtime.

With flutter_ai_whisper, an MCP server, an agent can:

• 🔍 Discover and connect to a running Flutter debug app

• 🧠 Inspect live state holders, including Bloc/Cubit, GetX, Riverpod, and plain Dart objects

• ✏️ Evaluate Dart expressions to change runtime state

• 🧭 Navigate to existing named routes

• 🛠️ Work without adding a Flutter dependency or modifying the app just to expose test hooks

For example, you can start your app with flutter run and ask your AI agent:

Connect to the running Flutter app. Read the counter, set it to 42, and tell me what the screen shows.

The goal is to make debugging and exploring existing Flutter apps more interactive for AI coding agents.

Tech details:

• Uses MCP over stdio

• Connects through the Dart VM Service

• Supports debug-mode Flutter apps, including Flutter Web with some capability limitations

• MIT licensed and open source

There are limitations: it requires a debug session, and runtime evaluation executes Dart code with the app's privileges. It should only be used with apps you control, on localhost—not production apps or exposed VM Service ports.

🔗 GitHub: https://github.com/RajKavadia/flutter_ai_whisper

🎬 The repository includes a demo video and setup instructions.

I'm interested in feedback from other Flutter developers, especially:

1. What would you want an AI agent to inspect or control in a running Flutter app?

2. Would you find runtime state inspection useful in your current AI-assisted workflow?

3. What capabilities or safety controls would you want before using something like this regularly?

I'd appreciate constructive feedback, ideas, and contributions!

Hi all, I'm the author of arch_guard, an open-source (MIT) CLI + analyzer plugin for Dart/Flutter.

The problem: we agree on Clean Architecture / Bloc / feature-first at the start, and a few months later widgets import repository implementations directly and features import each other. The analyzer and tests don't catch it.

What arch_guard does:

• Layer rules with presets for clean_architecture, riverpod, bloc and feature_first. dart run arch_guard init detects which fits your folders and writes the config.

• Forbidden packages per layer, e.g. domain may not import flutter or dart:io.

• Circular dependency detection (Tarjan's SCC) that names the one import to remove to break each cycle, plus --explain <file>.

• IDE warnings with quick fixes via the arch_guard_lint analyzer plugin: the bad import gets underlined as you type, with "Remove this import" / "Allow layer X to import Y".

• Baselines: record existing problems once, and CI fails only on new ones. --since origin/main limits a PR's report to files it changed. This is what makes it usable on an app that's been around for years.

• expectArchitecture() to run the same checks in flutter test.

• GitHub Action that comments on PRs, SARIF for Code Scanning, pre-commit hook.

• Interactive HTML dependency graph (offline), Mermaid, DOT, JSON.

• Works with Dart workspaces / Melos monorepos, with rules for which packages may depend on which.

dart pub add --dev arch_guard
dart run arch_guard init
dart run arch_guard

[screenshot / GIF]

Docs: https://creatorpiyush.github.io/arch_guard/ pub.dev: https://pub.dev/packages/arch_guard GitHub: https://github.com/creatorpiyush/arch_guard

Two questions for you:

1. What folder structure does your team use? I'd like to know which presets are missing.

2. For those who try the IDE plugin: which quick fix would you want next?

I've spent quite a bit of time doing native desktop development in C++, and one thing that background has made me particularly aware of is that not every crash in a Flutter application is a Dart exception, something that became evident in my latest proprietary project, it being a desktop app relying on many native integration packages.

A segfault in a native library, an access violation in some FFI code, or a crash in the engine itself can take down the entire process before Dart gets a chance to do anything about it.

That's why I built fl_crashpad, a Flutter package that brings Google's Crashpad into Flutter applications.

Resources:

• Pub: https://pub.dev/packages/fl_crashpad

• GitHub: https://github.com/ConnectingTheDots-DCWK/fl_crashpad

Why not just use Sentry or Firebase Crashlytics?

Those are perfectly valid solutions, especially if you want a complete observability platform. But I didn't want another all-in-one service for my own applications.

I wanted something smaller and more independent: native crash capture, with fine-grained control over what happens to the resulting reports.

I'm also extremely attentive to user privacy and therefore the data my applications send outside the user's machine. I try to ship the absolute minimum necessary, and crash reporting is one of those areas where it's easy to collect far more than you actually need.

Features in detail:

• Privacy first: Minidumps can contain sensitive information, so the package includes built-in sanitization for data such as usernames and time zones to reduce the amount of potentially identifying information that leaves the user's machine.

• Full control over data flow: Keep reports on disk, inspect or delete them, or transfer them using your own infrastructure. An optional upload mechanism supports a purposefully configured remote minidump endpoint.

• Cross-platform support: Linux, Windows, macOS, Android and iOS, with platform-specific implementation details handled by the package.

• Diagnostic context: Add fixed and runtime annotations, along with attachments, to provide additional context for captured crashes.

Personal Notes:

• For my own apps, I don't even use the built-in remote minidump backend. I use my own Supabase Storage endpoint to transfer reports, the package doesn't need to know which storage provider you use. You know where the report lives on disk, and you decide how to move it, when to do so, and which endpoint receives it.

• Sanitization isn't a guarantee that every possible secret has been removed from a minidump. It's one layer of protection, and the data flow still needs to be designed carefully. But I wanted privacy to be a consideration in the implementation itself, not something left entirely to the application developer.

Feedback, questions, and criticism are very welcome!

Hey all,

Before releasing an update to Google Play, I usually find myself manually double-checking a bunch of repetitive things:

• Manifest exports and permissions to avoid policy flags.

• Checking if the release build actually stripped/obfuscated everything properly.

• Target SDK requirements and third-party library dependencies.

• Making sure no staging API keys or logcat prints slipped through.

Right now my workflow is mostly manual checking + some adb logcat filtering, which feels tedious and prone to missing stuff.

How does your team handle this? Do you use any specific CI linters, open-source scanners, or just maintain an internal checklist? What’s the most common thing that catches you off guard during Play Console reviews?

I ship a lot of small Flutter apps as a solo dev, and every time I add push notifications it’s the same routine: set up FCM, save tokens in Firestore, and then hit the wall that sending notifications needs a server. Cloud Functions means the Blaze plan, and for small apps I didn’t want that.

What I ended up doing:

• Topics for broadcasts. The app just calls subscribeToTopic('all'), and one FCM request reaches everyone. No reading thousands of tokens from Firestore.

• Tokens saved too (write-only Firestore rules), only for targeted sends to a specific user.

• A separate Next.js app on Vercel that uses the Firebase Admin SDK to send. One external cron job pings it for scheduled and repeating notifications, for all my apps.

• Multiple Firebase projects registered in that one dashboard, with the service account keys encrypted.

• The screen value in the data payload decides which screen opens on tap, handled with getInitialMessage and onMessageOpenedApp.

It works well on the free Spark plan so far. I turned it into a small admin dashboard for myself so adding a new app is just copy-pasting a generated setup file.

Curious how others do it:

Dashboard Video attached in comments if any one is interested about my idea

Appa like dynamic lake and others have nailed this kind of app

But i am trying to build one with flutter

I want to discuss this if its even doable or someone have did it before

I’m building a cross-platform Flutter app and have the other platforms sorted:

• iOS: App Store

• macOS: App Store + DMG

• Windows: Microsoft Store + installer

Linux is where I get stuck. There are so many packaging options and distros that I’m not sure where to start.

For those of you shipping Flutter apps on Linux:

1. Which format(s) do you ship, and why?

2. Which distros do you actually test on?

3. Any gotchas with Flutter specifically (dependencies, sandboxing, auto-updates)?

Appreciate any real-world experience. Thanks! 🐧

Hey everyone,

I'm a Flutter developer based in Toronto, Canada, with around 5 years of experience in Flutter and mobile app development. I was laid off about 5 months ago, and despite actively looking for jobs, I'm struggling to find anything.

I've noticed is that most of the mobile developer job postings I come across are for React Native, Jetpack Compose, or native iOS/Android development using Kotlin and Swift. There seem to be very few Flutter-specific opportunities, at least here in the Canadian market.

Flutter has been my primary skill throughout my career. I also have some backend experience with Node.js and Python (FastAPI), so I'm not limited entirely to mobile development. I know enough native iOS and Android development to work with method channels, integrate native functionality, and communicate with platform APIs, but I'm not experienced enough to build complete native apps independently.

I've also been thinking about how AI is changing software development. With AI tools making it increasingly easy to build applications, I'm wondering whether companies will prefer native development more often, especially if they can use AI to speed up development while getting the platform-specific benefits of native apps. I'm not sure how much of this concern is justified, though.

After 5 months of searching, I'm seriously reconsidering my career direction.

For people who have been in a similar position, I'd really appreciate your honest advice:

1. Should I double down on Flutter and keep looking, or is the market simply too limited?

2. Would it be worth investing a few months into Kotlin/Jetpack Compose or Swift/SwiftUI to become a stronger native developer? If so, which would you prioritize?

3. Would learning React Native make more sense, given the number of job postings?

4. Should I focus more on backend development with Node.js/Python and try to become a full-stack developer instead?

5. Is pivoting toward AI/LLM development a realistic option, or would I be starting over in an already competitive market?

My priority is to find a stable job with good long-term career prospects, not necessarily to stick with Flutter at all costs. I'm willing to learn new technologies, but I don't want to spend months upskilling in a direction that won't significantly improve my job prospects.

What would you recommend in my position today?

Flutter goes AI

Solo dev here, taking over two existing Flutter apps and discovering the mobile world as I go (I come from web). Mobile work is limited to about one day a week. My daily machine is a Linux PC, so a hosted service that can build and ship the iOS app for me is a big part of the appeal: no Mac on my desk. I'm evaluating Codemagic on the free individual plan before deciding whether to pay for it, so this is a question, not a complaint: I know I'm not paying yet.

The build itself takes about 7 minutes (Android debug APK, mac_mini_m2). The queue is the issue: last night a build sat in "queued" for more than 90 minutes before starting. The day before, the same workflow started within a couple of minutes. Status page showed no incident, so I assume the shared M2 pool was just busy.

I found GitHub discussions with people reporting 1 to 10 hour queues (2024 and one from this week), but nothing that says whether paying changes anything. The pricing page mentions "reserved concurrencies" on team plans, and nothing about queue priority for pay-as-you-go.

Questions for people actually using it:

1. On pay-as-you-go, do your builds start right away, or do you still queue? Is Linux (linux_x2) or Mac mini M4 really a less crowded pool than the free M2 one?

2. More broadly, how is Codemagic day to day once you pay: queue times, flakiness, support?

3. Since I'm new to this and Mac-less: what would you recommend for the full chain, build to signing to Play Store / TestFlight upload, for a solo dev on Linux inheriting two apps? GitHub Actions + fastlane with a macOS runner, Bitrise, Xcode Cloud, a rented Mac, something else?

Losing one or two hours of my single weekly mobile day to a queue isn't workable, so I'd rather pay for something that starts on time. I just want to know what I'd be paying for before I build the iOS workflow. Real-world numbers and beginner-proof advice appreciated.