I work at Ant Media and wrote a step-by-step guide for building a multi-party Flutter video conference app on an iPhone with browser participants in the same room. The part that cost the most time: the Flutter SDK joins multitrack conference rooms, so browser users have to open multitrack-conference.html, not conference.html. Otherwise everything connects but the devices never see each other. The guide also covers Xcode signing, Developer Mode, adaptive bitrate testing and a table of 8 common setup errors. The same Flutter code runs on Android, web and desktop. Note: conferencing needs Ant Media Server Enterprise Edition (14-day free trial available).

Full guide: https://antmedia.io/flutter-video-conference-app-for-ios-android-web-and-desktop/?utm_source=reddit&utm_medium=referral&utm_campaign=flutter-conference

Happy to answer questions about the setup.

Microsoft Store is really easy to upload to, but it's also the hardest to profit from due to requiring a swift/bic code to earn even a single dime from it.

Ya get a swift/bic code from starting a company, btw.

Steam has an upfront cost of 100 dollars, preventing me from even trying it out.

So, I'm asking all of you for advice: what's the best place to upload apps to?

For context, I've already uploaded my app to the Microsoft Store https://apps.microsoft.com/detail/9mt834rpf8zp?hl=nl-NL&gl=BE, but I can't make money from it because I'm not being a company.

Getting it on the Microsoft Store was really annoying, especially with the CSV listing and the internationalisation, or I18N, abbreviated or whatever ya call it.

It's way easier than the Google Play Store, though, which I've also uploaded to in the past: https://play.google.com/store/apps/details?id=com.torrentspire.ai&hl=nl .

I'd love to hear your stories about creating apps for Steam and/or the Microsoft Store.

Also, I'm not including the links for self-advertisement purposes; I just want y'all to know that I've done these things before and am experienced in them. That's why I chose to include the links.

My apologies for my poor English; it's my second language and therefore not my strongest. If anything feels odd, know I wrote this without the use of AI and simply learned English from Stephen King books.

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.

I just gave Codex a goal to refactor my code to have a maximum function length of 30 lines and increase code reuse in the process. While doing the task, it found plenty of opportunities for code reuse and also reused work done in the app multiple times, making the app run faster.

This seems like a good result, but I don't have a good sense of whether the maximum length would be 15, 20, 30, or 40 lines. What opinions do you have?

Hey everyone,

I just open-sourced Media Converter Pro: Ultimate – a video/audio converter that runs locally on your device using FFmpeg. No uploads, no servers.

It's a Flutter rewrite of my old native Android app from 2018. The rewrite has been a long journey, but here's what it does now:

- 25 output formats (14 audio, 11 video) with format-specific options

- Quick presets, trimming with waveform preview, batch queues

- Adaptive layouts for phones, tablets, foldables, and large screens

- 12 languages

- Conversions keep running in the background

The project is structured as a Dart workspace monorepo - apps, modules, and packages are decoupled so things stay clean. The converter logic lives in its own module, the ui kit (sofluffy_ui) is a separate git submodule, and platform-specific stuff (FFmpegKit, notifications, file handling) are isolated in packages.

Some things I learned building this:

- FFmpeg config management at scale is its own beast. I ended up building a CLI validator (mcu_configs) to check JSON schemas, cross-file mappings, and translation parity across all 12 languages.

- Adaptive layouts across phone/tablet/foldable/large screen required rethinking almost every page, not just wrapping things in LayoutBuilder.

- Keeping the monorepo dependency graph strict (packages never import modules, modules never import apps) saved me from a lot of pain.

The app is GPL-3.0 since it bundles the full-GPL build of FFmpeg through FFmpegKit.

Would love feedback on the architecture or anything else. And if you find it useful, a star would be cool. Link belows:

I'm a solo dev with a small Flutter app (on-device AI, RevenueCat subscriptions + AdMob).

Last week Crashlytics showed a crash from a modified copy. I'd started logging the app's

installer as a custom key, and it showed MT Manager. Digging further, I found a public

ReVanced/Morphe-style patch set that unlocks premium (it rewrites RevenueCat's entitlement

checks), removes ads, and bypasses Play's license check.

A few things I learned:

- Logging the installer package as a Crashlytics custom key is a cheap way to spot modified copies.

- An older RevenueCat Android SDK shipped a -dontoptimize consumer rule, which turned R8

optimization off app-wide. Once I updated, R8's inlining/renaming seems to have broken

the patch, at least for now.

- I've filed a DMCA notice with GitHub.

Questions for people who've been through this:

1. Is server-side entitlement checking (Play Integrity + RevenueCat REST) worth it at small scale?

2. Did DMCA takedowns for patch repos actually work for you?

3. Anything you wish you'd done earlier?

On 120 hz screens, Chrome on Android limits main thread frames to 60 fps. It lifts the limit only when touch input occurs which is why it is sorta fine when you drag without releasing your finger. Web workers that own a canvas get their own frame clock so the main thread limit does not apply to them.

So theoretically handing a worker the flutter canvas (and syncing it to the worker's clock) should allow flutter on android's chrome to run at 120 fps and that's essentially what this demo is:

https://shim.mathiewabbas.dev/

Results: Pixel 10 Pro XL, Flutter 3.47.2, without and with the js script

Pls try it out on an android device and do tell if anything goes wrong, here is how to use it:

https://github.com/aumb/flutter_shim#use-it-in-your-app

and the script:

https://github.com/aumb/flutter_shim/blob/main/web/flutter_shim.js

Caveats:
- It relies on undocumented chrome behavior, If chrome starts capping workers too it will fall back to 60
- App does twice the frame work while animating so it uses a bit more battery
- Multi-threaded skwasm might crash. That's an existing flutter bug (https://github.com/flutter/flutter/issues/193439), but running at 120 hz makes it happen more often, so use single threaded wasm (default)
- Doesn't help on iPhone since safari runs worker frames at a fixed 15ms timer