Description
Proposal: Improve register-app-for-start-at-log-in Experience (UWP App Model)
Summary
Using the StartupTask API app developers can register their app to automatically start at log-in. The API is available for both UWP apps and DesktopBridge apps (MSIX-packaged Win32 apps). Depending on the "app model" this API has a different User Experience and I want to highlight one major difference in this proposal.
The linked documentation above states the following:
UWP apps must call RequestEnableAsync from a UI thread to trigger a user-consent dialog. If the user consents, the UWP app will then start on startup or user log in. Note that UWP startup apps will start minimized.
If RequestEnableAsync is called from a packaged desktop app, no user-consent dialog is shown.
It is this user-consent dialog which is at the heart of this proposal.
If the user has granted an UWP app start at log-in permission in the Windows Settings app, every subsequent API pair call of StartupTask.Disable() and permission-granting StartupTask.RequestEnableAsync() will trigger this user-consent dialog (*1). You can observe this behavior in the following GIF below. In this GIF the app initially has its start at log-in permission granted in the Settings app.
(*1) (If the user has denied the app this permission in the Settings app or denies the request using the user-consent dialog, the next call to StartupTask.RequestEnableAsync() will fail and show no such dialog.)
Now observe how the API behaves when calling it from a DesktopBridge app given the documentation above. Again, the app already was granted start at log-in behavior by the user in the Settings app (or the Task Manager):
As stated in the documentation, as long the app start at log-in has been disabled with a StartupTask.Disable() call, a subsequent call to StartupTask.RequestEnableAsync() will enable app start at log-in without asking for user consent again.
This does not feature the, what I consider, bad UX of UWP apps where a user is asked twice if they really want to enable automatic app start. (First ask is the user clicking the ToggleSwitch button, second ask is the user-consent dialog prompt.) The UX here should be fast and straight-forward and should not require by default to have the user confirm their choice whenever they want to enable start-at-log-in for the app in question.
Proposal: UWP apps should feature the same straight-forward register-app-for-start-at-log-in experience as DesktopBridge apps come with as shown in the GIF above.
It is important to note that this proposal will not result in the user losing control over their apps! As long as the user denies the app start at log-in permission in the Settings app, a call to StartupTask.RequestEnableAsync() will not succeed:
As this GIF shows, if the user denied the app permission in Windows Settings at the time of the request, the app cannot programmatically set itself as a startup app.
For each UWP app, the system default is that the user has not granted the app permission to start at log-in. As such, even without the user actively denying the app permission, the app's very first call to StartupTask.RequestEnableAsync() since installation will also fail. It will, of course, require the user to first actively grant the app this permission in the Settings app.
No malicious app can use the absence of the user-consent dialog as outlined in this proposal to just do as it pleases. The user still rules!
Scope
| Capability | Priority |
|---|---|
| This proposal will allow apps to set themselves as start-at-log-in apps without showing a user-consent dialog when the user has not denied the app this permission in the Settings app (*2) after actively granting the app this permission in the Settings app before. | Must |
| This proposal will allow apps to just set themselves as start-at-log-in apps as they please. | Won't |
(*2) Or denied the request using the user-consent dialog prompt.
Additional Context
@BenJKuhn Feedback Hub entry here.
Attached Files
I created a sample project showcasing the current behavior for both UWP and DesktopBridge apps. Please check that out if you still have questions regarding the different behavior:
StartupSandboxDemo.zip