Hi @Diogo Costa Maranhao Rodrigues ,
Thanks for reaching out.
Both AppInstallManager.SearchForUpdatesAsync() and StoreContext.GetAppAndOptionalStorePackageUpdatesAsync() are remote async Store operations, so they depend on Store services rather than a simple local check. Because of that, response times in the range of a few seconds, including variation like 3 to 10 seconds, can be normal depending on network conditions and backend load. See Microsoft’s API docs for AppInstallManager.SearchForUpdatesAsync() and StoreContext.GetAppAndOptionalStorePackageUpdatesAsync():
This is consistent with the Microsoft documentation for AppInstallManager.SearchForUpdatesAsync() and StoreContext.GetAppAndOptionalStorePackageUpdatesAsync().
One important detail is that StoreContext.GetAppAndOptionalStorePackageUpdatesAsync() is throttled by design. Microsoft notes in the API remarks that it checks no more than once every 30 minutes and no more than ten times in 24 hours, and if called more often it can return the last known result instead of doing a new check.
So the main improvement is usually in how the APIs are used rather than replacing them:
- Check less often and avoid frequent polling.
- Cache the last result and timestamp.
- Run the check in the background instead of on a performance-sensitive path.
- Since this is a Windows Service, consider moving the update check to a user-context component because StoreContext is designed around the current app and user context.
If you need very fast and predictable update detection, there is not really a faster Store API for that scenario. In that case, you may want to look at a different update model such as MSIX App Installer, depending on how the app is distributed.
Hope this helps! If my answer was helpful, I would greatly appreciate it if you could follow the instructions here so others with the same problem can benefit as well.