You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Eliminate black screen after launch storyboard on iOS #8127
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
[✓] 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
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.
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).
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.
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.
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.
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.
Activity
eseidelGoogle commentedon Feb 14, 2017
FYI @cbracken @xster.
xster commentedon Feb 14, 2017
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 commentedon Feb 14, 2017
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 commentedon Feb 14, 2017
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 commentedon Feb 14, 2017
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 commentedon Feb 15, 2017
Discussed offline, will use native splash screens and transition into a fully rendered flutter app
Hixie commentedon Feb 15, 2017
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 commentedon Feb 15, 2017
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 commentedon Apr 11, 2017
Speculatively punting to M3. The reason to consider this for M2 is to make presentations look nicer at I/O.
eseidelGoogle commentedon Apr 11, 2017
FYI @xster
5 remaining items
harveynick commentedon Jul 3, 2017
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 commentedon Jul 20, 2017
@collinjackson re-confirmed with Posse just now that this is a blocker for their current application.
tvolkert commentedon Jul 20, 2017
@xster is working with @harveynick to try to bring Nick's fix into the fold.
xster commentedon Jul 20, 2017
Looking at it now
gavindoughtie commentedon Jul 20, 2017
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 commentedon Jul 23, 2017
This is more or less the plan. It's much easier to do if you use a launch storyboard instead of bitmaps, though.
Hixie commentedon Jul 25, 2017
@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 commentedon Jul 25, 2017
Ya, sending a patch soon
pishguy commentedon Sep 11, 2020
I am having the same issue on Android. #65654
github-actions commentedon Aug 12, 2021
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 -vand a minimal reproduction of the issue.