Reworked app update algorithm
I just updated the Goodnotes app on Windows from the Microsoft Store, only to find another update waiting for me inside of the actual app.
You might ask yourself "Hm, that's odd. Why would it do that?" - easy answer: the app is still a web app just hidden in a native Windows app's window, meaning while you do get the native Windows title bar for the app, the app is still the website.
The team seriously needs to streamline this updating progress, and there are two ways to do that:
1) Turn the app into a true native Windows app
I know this is probably not happening. The team is small, the Windows app frameworks are unreliable & replaced every few months...but it would at least limit app updates to a single, centered source - the Microsoft Store.
2) Limit app updates to the in-app update framework
This has already worked semi-reliably before. So why now implement two ways that are incredibly confusing?
kerim
shared this idea
-
Elizabeth Taylor
commented
The two update paths may serve different layers, but the app should explain that instead of presenting both as generic updates. Showing which component is changing, what the update fixes, and whether a restart is needed would make the current setup much less confusing, even before the update process is redesigned.