What do you expect from a Project Reunion Splash Screen API for Windows?

[samanthamsong]

Building on plans for windowing APIs as part of Project Reunion (Discussion#72) we on the Windows developer platform team are investigating whether there are improvements we can make to facilitate splash screen creation and management for all Windows apps. We would love to learn more about how you implement splash screens, and how that experience can be improved.

• How many of your apps use splash screens? Why do you choose to include a splash screen in your app experience? In what situation would you want to disable/not include a splash screen?
• Is it difficult to create a splash screen that meets your app's splash screen requirements? How often do you find yourself blocked by not having access to a platform involved splash screen? Which aspects of the experience do you wish were easier?
• Are there specific functionalities you expect to see from an add splash screen experience. What are they, and why are they important to you?
• For UWP splash screens: How well does the current UWP add splash screen experience satisfy your needs? How often do you feel like you need to create an extended splash screen, and for what purposes?

Answers to these questions will help us understand your splash screen needs better, and may result in improvements to this specific developer experience. We would love to hear any other thoughts, feelings, suggestions, you might have about splash screens in this thread as well.

Overview of current splash screen implementation strategies

The following are the existing methods of creating a splash screen for windows applications:

1. All UWP apps and Splash Screen Extension
2. WPF Apps
3. Other Win32 Apps: There is currently no platform involved way to create a splash screen. Create a splash screen by creating a window that is displayed while the app is loading its main content. You are responsible for where the window appears, and when it shows up and when it goes away.

[ArchieCoder]

Hi,

For UWP apps, the property uap5:Optional="true" is basically useless. 99% of the time, the splashscreen will be shown nevertheless.

Here is what I sent to the MVP WinDev DL last year:

With my new project, the optional splash screen would have been great to have since they want their own animation when the app launches. Tonight, I put more effort to see what was the culprit.

My steps:

• I commented everything in App.xaml.cs except the Frame creation and the Frame.Navigate to my own page.
• My page is just one empty grid with a red background (you can see the code from the video. I had to remove mostly everything to figure out what was causing the splash screen to show up.

It turns out that “DataContext={Binding Quote, Source={StaticResource Locator}}” was causing the splash screen to show. You can see the proof from the video. Side note for devs: when you deploy with F5, the splash screen will always show up. You need to launch the app outside the debugger to see it working.

So, this is weird to me that a page showing up and initializing will trigger the splash screen to show for few milliseconds. You can compare how beautiful is the launch of the Netflix app on the iPad versus the Windows app (not very smooth).

For now, I will give up usage of the optional splash screen. Please make it really optional and let the dev handle it. Seeing it for 50 ms is adding more noise than anything.

Optional.splashscreen.mp4

[samanthamsong]

Thank you for your highlighting this issue!

For UWP apps, the property uap5:Optional="true" is basically useless. 99% of the time, the splashscreen will be shown nevertheless.

Currently for UWP, the splash screen is only optional if your app loads fast enough.

With my new project, the optional splash screen would have been great to have since they want their own animation when the app launches.

The scenario you described perfectly encapsulates one of the pain points surrounding UWP splash screens that we are looking to solve with a Reunion splash screen API. Hopefully, future platform involved splash screen solutions will make it easier for developers to create the custom splash screen experiences that best suit their apps.

[wbokkers]

I have no need for a splash screen.
I'd rather see all possible windowing scenario's supported by the Windowing API and probably make some optional helpers/utilities/extensions for derived features like splash screens.

[dotMorten]

Are there specific functionalities you expect to see from an add splash screen experience. What are they, and why are they important to you?

Progress bar and/or load status text.

Example from Photoshop showing current load status:

[dotMorten]

I played a bit with adding this to WinUIEx, and it's totally doable to add a splashscreen to a WinUI app today. Might be a good place to play with some APIs.
With my extensions, this is all it really took to hook it up: https://github.com/dotMorten/WinUIEx/blob/6a692ee22fb8d98ecaa702d5d270d7e370926e53/src/WinUIExSample/App.xaml.cs#L46-L47
And the actual splashscreen code:
https://github.com/dotMorten/WinUIEx/blob/main/src/WinUIExSample/SplashScreen.xaml.cs#L32-L49

Just clone the repo and run the sample app to see a functioning splash screen

[marb2000]

This is nice. Thanks for sharing @dotMorten.

@samanthamsong, you should annotate that the Splash Screen should run in their own thread, to avoid frozen the main thread.

[mdtauk]

The SplashScreen should display as instantaneously as the app is launched to give the perception of performance, speed, and fluidity.

Once the app is ready, it should be possible to transition from the splash screen into an extended splash screen to display other UI like Loading bars, text status, or even login experiences.

If the SplashScreen content could be in a Page element or a UserControl - with basic support for window size breakpoints.

There should also be support for Acrylic splashscreen backgrounds with Light and Dark theme support.

[marb2000]

One question. Should a WinUI 3 Desktop app honor the Splash Screen defined in the application manifest?

var splash = new SplashScreen();
splash.Completed += OnCompleted;

For example, if I wrote this, the Image with the colors from the appx manifest showing up.

[dotMorten]

The above splashscreen class is an actual window with xaml content - not just an image. And an unpackaged app (which I hope we'll soon get?) won't have an appx manifest I assume?
It's definitely not the perfect API, but it's one way to create a view until the main view is ready.

[marb2000]

What about showing up the Splash Screen before the application packages (aka framework packages) are deployed and installed on the machine?
Scenario:
Reunion's package (which contains WinUI) is downloaded from the Store if the application packaged is not already installed. Should we have a Splash Screen to inform the user?

[dotMorten]

Isn't the installer experience a completely different scenario though? Does it make sense to mix the two up rather than treating them as two separate things to deal with?

[samanthamsong]

Splash screen is not consistently defined throughout Windows platforms. One understanding is that the the splash screen is the window that appears when the app is launched, and disappears when the app is done loading, the same every time. Which would not apply to installation, which is a unique experience.

[mdtauk]

Splash screen is not consistently defined throughout Windows platforms. One understanding is that the the splash screen is the window that appears when the app is launched, and disappears when the app is done loading, the same every time. Which would not apply to installation, which is a unique experience.

There should be a modern suggested design for Splash Screens, but allowing for variation if it makes sense for the app's brand. Like Office Apps sharing a splash design

[FrayxRulez]

In my experience users really dislike the built-in UWP splash screen.
To give you an example, I’m offering a UWP alternative to a Win32 instant messaging software built using Qt.
A cold boot on a slow/old laptop would display the splash screen for 3-5 seconds to then display the chat list, already populated. On the other side, the Qt app would display nothing for those 5 seconds, then the “empty” window would appear and just after few instants the chat list will be populated.

Still, even if the UWP solution is “smoother” on the paper, users prefer the latter: they’re used to wait few instants for a window to pop out, and for them the “real” waiting starts right after: if the window is empty but they can already interact with it, for them it’s ready already.

Then, if WinUI will still require a splash screen, I would love to see something iOS/Android like, where you can actually display the UI skeleton instead of the app logo: this would already provide more context.

[dpierangeli]

Same experience here, Win32 and UWP with the same starting time, the Win32 shows a full UI after 3s, the UWP shows a 3s splash and then the UI... For the users the UWP is slower and they prefers the Win32. Very strange...

[EP012014]

However, displaying nothing for seconds will let the user think that the application failed to start( especially if they double click the shortcut on Desktop instead of invoking it in the start menu, since they will think they didn't click fast enough), and do multiple attempts to start the app, which causes multiple instances launched, and drag the startup performance further.

[queequac]

Wanted to add some issue with the current UWP splash screen, which is present since the very first build of Windows 10 and confirmed by many people.
The splash screen has a certain color, which might be the system accent color or some specific color the app developer selected and put into the app manifest. In my case this is a strong red (#990000).

Unfortunately the splash screen seems to span the underlying window everything is painted on top. This means that enlarging your application's window will show the surface underneath for the fraction of a second. This is somehow annoying and this kind of flicker can be observed for nearly every UWP app (depending on the complexity of the UI and how long XAML will need to draw over the newly available space).
For reference, see also me tweet from 2 years ago: https://twitter.com/RolandoTedesco/status/1083800818854313984

Regarding the optional splash screen... that does really not work in most of the cases. Sure, app needs to be fast enough, but it's pretty impossible to get rid of it even if the app starts < 1 s. Showing the splash screen for 100-200ms will not really add to user experience.
Extended splash screen is good as it is today... I make use of it in one app where lots of stuff is initiallized and I want to show a rotating circle on the splash screen in meanwhile...

[crramirez]

Hello,

In my case that I have a UWP w/desktop ext app in the Store. I am just fine with the default UWP splash that shows my logo. For me, it is important because the user sees immediate feedback that the application is starting up.

To have this default UWP splash in WinUI 3 Win32 is enough for me.

Regards,
Carlos

[prayaas-a]

One consideration for a splash screen should be the ability to have a "boilerplate UI" maybe via a static image (scaling would be the dev's responsibility of course) or simple animation that mimics what the layout of the app will look like once fully loaded. Some app developers prefer this approach over having a logo splash screen which can feel sluggish. This is how iOS does it, I believe, and the Discord Electron app.

[ghost]

I'm going to be downvoted as hell for saying this, and I don't even use the technology, just lurking here, but I'm seeing @dotMorten and others showing Photoshop as an example, and I'm thinking:

Whytf do you need to add a splash screen to your app??

Unless you're doing something as complex as Photoshop, if users have enough time too see the splash screen, either you're apps is really bad, or the platform you're using really sucks.

On my windows 10 computer, Excel launches faster than the windows calculator.

[riverar]

So how do you account for the Photoshop complexity scenario?

[mdtauk]

Uwp has an extended splash screen scenario, so once the OS splash loads it can become user drawn, and can display text or progress bars and animations, whilst the rest of the app is loaded and the splash screen is manually dismissed?

[riverar]

Sorry, I was asking @phgmacedo. It seems if we can all agree Photoshop needs a splash, then discussing other apps is moot.

[FrayxRulez]

I think that he's just afraid to get a UX like the one that we have at the moment in UWP.
My personal opinion is that some splash screen component isn't really needed: if you're developing a simple app, you simply shouldn't need it: the framework should be fast enough to load and render the UI pretty much instantly.
If you're building a complex software, then you probably have the knowledge to spawn a frameless window to be used as a splash screen and do your asynchronous/lazy/delayed loading in the background.

[EP012014]

I think that he's just afraid to get a UX like the one that we have at the moment in UWP. My personal opinion is that some splash screen component isn't really needed: if you're developing a simple app, you simply shouldn't need it: the framework should be fast enough to load and render the UI pretty much instantly. If you're building a complex software, then you probably have the knowledge to spawn a You mean that the splash screen is not displayed in the window where the app content should be loaded? That's not a really good idea because the cost of creating or destroying a window is high.

[JaiganeshKumaran]

Splash screens for UWP apps are shown by the OS instead of the app itself which makes it more responsive when launching as it's instantaneous. Same thing should be available to desktop apps as an optional feature instead of them creating their own splash screen after the app starts

[amartens181]

The splash components:

• icon (PNG/SVG (with colors))
• animation (lottie / other animations) and the option to only show it once per boot / day / other
• skeleton (learned / developer-provided skeleton code / images)

There should be a robust default splash screen that lets the app creators control the splash components.
The ability to adjust the amount of time (both as milliseconds and as a percentage) the splash bits should be considered
Ideally, the apps would start fast enough that splash screens are extremely short / nonexistent.
Possibly consider a user preference like prefers-reduced-motion that would allow users to disable/slow splash screen motion or splash screens altogether.

Feedback on the current UWP splash screens: they last too long and are too bland.

[mdtauk]

Feedback on the current UWP splash screens: they last too long and are too bland.

Its the simplicity that allows them to show up immediately on tile/icon click. Whatever changes are done to the default Splash Screen, the immediacy should be retained. Then maybe additional animations or elements can be brought in after the splash is on screen, as the app loads in the background.

Most apps shouldn't need a long startup time, but more complex apps and UI like Office or Photoshop etc - will take longer to render UI and spin up any plugins or addings - which is where some indication of progress would be useful.

[JaiganeshKumaran]

UWP apps that show a long splash screen are because those apps are slow not because of the splash screen itself

[EP012014]

A splash screen shown in the app Window instantly after user invoke is really necessary, especially in case when the user mis-invoked a wrong app( common if you use Surface) . The user should be aware of it as soon as possible and close the app, instead of waiting for a few second to find the wrong app was started or it can't be closed before it fully loads. Showing nothing also results in multiple attempts to start the app and cause multiple instances started.

[simon-knuth]

Instant feedback after launch is super important when using Windows 11's centered taskbar layout. App instances appearing delayed can cause the taskbar icons to move around unexpectedly, which is awful for usability.
I'd also hope that transitioning from a splash screen to content that's actually ready can benefit the overall visual stability and bring back a part of that "native feeling" that's inherent to the UWP experience.

[YourOrdinaryCat]

I think the way iOS handles this would be a good starting point. You define a custom Storyboard (could be a no code behind XAML page here) and that's your splash screen:

https://developer.apple.com/documentation/xcode/specifying-your-apps-launch-screen

I do think the default behavior should still be just the app icon, but allowing developers to easily define a custom "splash page" would be great. You can somewhat emulate that on UWP by using uap5:Optional and navigating to a custom splash page, then navigating to the actual landing page, but the system splash screen may still show up, plus you have to define custom logic, which isn't ideal.

Also, as soon the splash screen/page goes away, the window shouldn't have any sort of weird color flashes, and it should be ready for interaction. To draw a simple comparison, launching the WinUI 3 Gallery isn't a very smooth experience compared to the WinUI 2 Gallery:

WinUI 2
WinUI 3

[castorix]

Also, as soon the splash screen/page goes away, the window shouldn't have any sort of weird color flashes, and it should be ready for interaction. To draw a simple comparison, launching the WinUI 3 Gallery isn't a very smooth experience compared to the WinUI 2 Gallery:

I had posted a sample wth a Layered window, with and a fade-out effect in x ms : WinUI3_SplashScreen
(a fade-in effect could be added too)

[AliShahesmaeili]

@samanthamsong
Any update?