Eliminate black screen after launch storyboard on iOS

[collinjackson]

Steps to Reproduce

Use this to run on iOS:

flutter create myapp
cd myapp
flutter run

The app will show the (white screen) contents of LaunchScreen.storyboard, followed by a black screen, followed by the app.

The problem is that we have a surface created but we haven't drawn pixels to it yet. We should try to show the contents of the LaunchScreen.storyboard instead.

Flutter Doctor

flutter doctor
[✓] Flutter (on Mac OS, channel unknown)
• Flutter at /Users/jackson/git/flutter
• Framework revision 04e7446 (3 months ago), 2016-11-07 15:48:50
• Engine revision 16077d4
• Tools Dart version 1.21.0-dev.3.0

[✓] Android toolchain - develop for Android devices (Android SDK 23.0.3)
• Android SDK at /Users/jackson/Library/Android/sdk/
• Platform android-N, build-tools 23.0.3
• ANDROID_HOME = /Users/jackson/Library/Android/sdk/
• Java(TM) SE Runtime Environment (build 1.8.0_91-b14)

[✓] iOS toolchain - develop for iOS devices (Xcode 8.2.1)
• XCode at /Applications/Xcode.app/Contents/Developer
• Xcode 8.2.1, Build version 8C1002

[-] IntelliJ IDEA Community Edition (version 2016.3.1)
• Dart plugin not installed; this adds Dart specific functionality.
• Flutter plugin not installed; this adds Flutter specific functionality.
• For information about managing plugins, see
https://www.jetbrains.com/help/idea/2016.2/managing-plugins.html

[✓] Connected devices
• iPhone SE • 3075EA0A-334E-4125-83FA-7DE6BA24C9ED • ios • iOS 10.2 (simulator)

[eseidelGoogle]

FYI @cbracken @xster.

[xster]

Would be really cool to just do cross platform splash screen inside the framework. Don't know how feasible it is in terms of latency.

[collinjackson]

I think that because launch screens cannot run code, we're not really adding much value by providing a cross-platform way to configure them. However, we should have the template app created by "flutter create" include a preconfigured launch screen image storyboard on iOS and a possibly a splash screen activity on Android so that devs can drop new assets on top of the default ones and be on their merry way. (The Flutter logo seems like a fine placeholder since that's what we're doing for the app icon already.)

That is a separate issue from the iOS black frame though, so I'll create a new bug for it.

[xster]

ya, I think there are 2 issues and depending on best time to first frame, we can do either or both. I don't have a good idea of the underlaying mechanisms and how feasible it is but I'm assuming:

0
->[iOS draws splash screen] <- the white screen in your example
->[absolute first moment the shell is up and we can run dart code] <- the black screen in your example
->[we did the first layout and paint of user's main()]

We can make a nice way of letting users do step 2 (maybe in the pubspec, point to some asset, compile time tweak them, create the necessary storyboard and Android splash hook ups dynamically during flutter run and the user never has to open xcode).

Though I was wondering whether we can split step 4 where we draw the real app and migrate some stuff into a step 3 with a super lean draw-1-image-in-dart-space. If the latency for that can possibly be low, we might not need to do step 2 (i.e. also instruct the users to not directly add a storyboard into xcode if our dart splash screen is fast enough).

[abarth]

I'm not sure we want to get into the business of providing splash screens. In order to do that well, you need pretty deep hooks into the platform, which is why both Android and iOS provide these mechanisms. Rather than having two splash screens (one OS-integrated and another from Dart), it seems cleaner to transition directly from the OS-integrated splash screen to the real running app.

[xster]

Discussed offline, will use native splash screens and transition into a fully rendered flutter app

[Hixie]

I would prefer if we would launch fast enough that dart could draw before the OS has had s chance to draw the first frame of its animation...

[abarth]

I would prefer if we would launch fast enough that dart could draw before the OS has had s chance to draw the first frame of its animation...

That's unfortunately not always possible on Android or iOS. These platform provide these OS splash screens for this reason.

However, I agree with the goal of starting as fast as possible. :)

[eseidelGoogle]

Speculatively punting to M3. The reason to consider this for M2 is to make presentations look nicer at I/O.

[eseidelGoogle]

FYI @xster

[tvolkert]

FYI, this is affecting customer six internally.

[franklinharper]

I am having the same issue on Android.

[vlidholt]

I think this is a pretty major one. I'm using a dark loading screen just to hide this issue, but I'd much rather use a lighter theme.

[harveynick]

What's the current status of this? I have a simple fix from a previous project which I think could easily be ported to either Flutter itself or a plugin.

[eseidelGoogle]

@collinjackson re-confirmed with Posse just now that this is a blocker for their current application.

[tvolkert]

@xster is working with @harveynick to try to bring Nick's fix into the fold.

[xster]

Looking at it now

[gavindoughtie]

One thing that a lot of applications do (and what would be nice to have in Flutter) is to grab the splash screen bitmap and use it in your initial application code. That way the app can start out displaying the splash screen bitmap, then fade it out, draw atop it, etc.

[harveynick]

This is more or less the plan. It's much easier to do if you use a launch storyboard instead of bitmaps, though.

[Hixie]

@xster Were you working on this? I'm assigning this to you because I believe you're working on a fix, please let me know if that's not right.

[xster]

Ya, sending a patch soon

[pishguy]

I am having the same issue on Android. #65654

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.