Seeking Suggestions: How well this scales? Will this work with gradle9.0+ AND web app (wasm/js) ?

[hp922-jm]

Hi,

Thanks for building this library.

I am considering to use it in my KMP project. I have a few questions:-

1. How well does this scale? Can this work for a social media app ?
2. Will this work for gradle9+ ?
3. I dont think this works for web app, right? In this case, would you recommend me to build platform-specific code itself OR use this library for android and ios but build something for web ?

Thanks your guidance and help.

Thanks for the kind words, and great questions! Let me address all three.

1. Web (wasm/js) support

Not supported today, and this is more than a missing target — it's architectural. The library's targets are Android (androidTarget) and iOS (iosX64/iosArm64/iosSimulatorArm64) only. The core BackgroundTaskScheduler is backed by AndroidX WorkManager on Android and BGTaskScheduler on iOS. Browsers have no real equivalent of "guaranteed, deferrable background work that survives the app/tab being closed." The closest is Service Workers + the Background Sync API, which has no constraint engine, no exact alarms, and no task chaining.

So my recommendation matches your second option: use this library for Android/iOS, and build a separate web layer (Service Worker + Background Sync, or push the work server-side into a job queue). Wrapping a web implementation behind the same BackgroundTaskScheduler interface isn't on the near-term roadmap because the semantics don't map cleanly.

2. Gradle 9.0+

Not yet officially supported. The project currently builds on Gradle 8.14.3 with AGP 8.13.2, Kotlin 2.1.21, and a JDK 17 toolchain. There's no architectural blocker — the JDK 17 toolchain already satisfies Gradle 9's runtime requirement — but moving to Gradle 9 typically means bumping AGP alongside it, and that combination hasn't been verified here yet. I'd treat it as "upgrade + verify" work rather than a redesign. I can open a tracking issue for the Gradle 9 bump if that's useful to you.

3. Scalability for a social-media app

Worth clarifying what "scale" means here, because this library is a background task scheduler, not a sync engine or backend. It scales well for the kind of work it's designed for — deferred, durable, constraint-aware background jobs:

• Good fits: photo/video uploads, retry-on-reconnect, periodic sync, cache cleanup, prefetching. The iOS path is built for durability (append-only queue with CRC32, atomic writes, O(1)-RAM streaming) with a deliberate MAX_PARALLEL_TASKS = 4 cap to respect iOS BGTask CPU/network budgets.
• Not a fit: the realtime backbone of a social app (live feed, messaging, presence). Those need WebSockets / push / a backend and are out of scope for this library.

So for a social-media app: use it for the background/offline-resilience pieces on mobile, and pair it with your own realtime + backend stack.

Hope that helps — happy to dig into any of these further.

[vietnguyentuan2019]

Follow-up on the Gradle 9 question: I've opened #57 to track the upgrade + verification work. Feel free to subscribe there for progress.