I’m working on a WinUI 3 desktop app that gets packaged as MSIX and distributed through the Microsoft Store. The app needs to run a few recurring jobs – nothing crazy, just things like polling an API every couple of minutes, cleaning up old files at night, or retrying failed requests after a short delay.

In a plain .NET server app I’d just pull in Hangfire or Quartz.NET and be done with it. Here, though, the app has to pass the Windows App Certification Kit (WACK) checks, and I’m honestly not sure what’s actually allowed and what’s going to blow up in certification.

What’s giving me a headache:

1. The app lifecycle is a buzzkill – a packaged desktop app can be suspended or killed by the system whenever it feels like it. A plain while(true) loop with a Task.Delay or a System.Threading.Timer is basically dead the moment the app gets suspended. I looked at ExtendedExecutionSession to keep things alive, but Microsoft’s docs more or less say “we might revoke this at any time.” That doesn’t exactly scream “reliable scheduler.”

2. The built-in background task system is way too coarse – I know Windows App SDK has IBackgroundTask with a TimeTrigger, but the minimum interval is 15 minutes. I need to poll an endpoint every 2–5 minutes, so that’s a non‑starter. Plus background tasks run in a separate process, so I’d have to set up some kind of IPC just to share state with the main app. Feels like overkill for a simple timer.

3. WACK paranoia – I’m worried that a persistent background thread doing work while the app is “minimized” might be flagged as excessive resource use, or that something like Hangfire’s SQLite storage (with native interop) will trip the API checks. I can’t find clear documentation that says “yes, you can run a background scheduler from inside a Store app, here’s how.” Most examples assume an unpackaged app that can do whatever it wants.

4. Persistence and recovery – Even if I manage to keep the app alive while it’s in the foreground, a reboot or a crash will wipe all scheduled jobs if I’m just using an in‑memory store. I could use SQLite or LiteDB to persist them, but again – is a local database inside an MSIX package fine from a WACK perspective, or am I opening another can of worms?

I’m trying to understand if anyone has actually shipped a WinUI 3 Store app that contains a reliable, built‑in job scheduler. Is the only truly safe route to move all scheduling to an external web service (or a separate Windows Service installed outside the Store)? If an in‑process solution is possible, what combination of APIs and lifecycle handling actually passes certification and survives real‑world suspension/reboot cycles? I’d love to hear from someone who’s been through this and didn’t get stuck in certification limbo.