feat: Add Native Splash Screen for Improved Startup UX

[djeddi-yacine]

PR Checklist

• My code adheres to AppFlowy's Conventions
• I've listed at least one issue that this PR fixes in the description above.
• I've added a test(s) to validate changes in this PR, or this PR only contains semantic changes.
• All existing tests are passing.

PR details

Hi AppFlowy Team,

This pull request introduces a native splash screen feature, as proposed in issue #7962 (#7962), to enhance the application's startup experience. By providing an immediate visual response, the splash screen aims to reduce perceived jank and improve the overall user experience while the main Flutter application initializes.

Key Changes:

• Integrated the native_splash_screen package.
• Configured the splash screen via native_splash_screen.yaml and CLI-generated native code for Linux, Windows, and macOS.
• Modified platform entry points (main.cc for Linux, main.cpp for Windows, and AppDelegate.swift for macOS) to display the splash screen as early as possible.
• The splash screen is closed programmatically from Dart once Flutter has rendered its first frame (or after app initialization).

Platform Testing:

• Linux: I have thoroughly tested the native splash screen functionality on Linux (Arch), and it is working as expected.
• Windows & macOS: Due to the complexities of AppFlowy's build environment, which relies on pre-made scripts and custom Rust builders, I was unfortunately unable to set up and fully test the splash screen implementation on my Windows and macOS VMs.

Request for Reviewers:

I would greatly appreciate it if the team could specifically test the native splash screen functionality on Windows and macOS to ensure it behaves correctly on those platforms before merging. This includes verifying:
1. The splash screen appears immediately on app launch.
2. The configured image and appearance (if customized per platform) are correct.
3. The splash screen closes smoothly when the Flutter UI is ready.
4. There are no adverse effects on the existing startup process for these platforms.

Future Work (Post-Merge):

If this initial implementation is accepted, I plan to investigate further optimizations for the main Flutter window's initialization on macOS and Windows. The goal would be to refine how the main window appears after the native splash screen closes, ensuring the smoothest possible visual transition from the native splash to the Flutter UI (e.g., preventing any brief white flashes or abrupt window appearance).

Thank you for considering this contribution! I believe native splash screens will be a valuable addition to AppFlowy.

Closes #7962

[CLAassistant]

All committers have signed the CLA.

[sourcery-ai]

🧙 Sourcery is reviewing your pull request!

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[LucasXu0]

Hi @djeddi-yacine, can you double-check your commits? They include 1 million lines of changes. Please take a video to demonstrate your changes.

[djeddi-yacine]

Hi @LucasXu0 ,

Thanks for taking a look at the PR!

You're absolutely right about the large line count in the changes. The vast majority of those lines come from the auto-generated C++/Swift files by the native_splash_screen_cli tool.

Here's why these files can become very large:

1. Embedded Image Data: The core of this plugin's approach for an immediate native splash is to embed the splash screen image data directly into compiled code. For macOS, this means the CLI converts the splash image (e.g., a PNG) into a raw array of [UInt8] pixel bytes (ARGB format) and writes this array into the generated Swift files.
2. Configuration-Specific Files: To provide different splash screens for Debug, Profile, and Release builds, the CLI generates a separate Swift file for each configuration, each potentially containing its own image byte array.
3. Image Size Impact: If the source splash image is large (e.g., high resolution), the resulting byte array will also be very large. For instance, a 500x300 pixel image with 4 bytes per pixel (ARGB) results in 500 * 300 * 4 = 600,000 bytes. When formatted as a Swift array literal (0xAB, 0xCD, ...), this can easily span hundreds of thousands of lines. The images I used for testing (especially for the example/placeholder release image) might have been on the larger side, leading to this line count.
4. Generated C++ for Linux/Windows: Similarly, for Linux and Windows, the CLI generates C++ files with embedded image data, though their line count contribution might be different.

In essence, these large diffs primarily represent the raw pixel data of the splash screen images being included as byte arrays in the source code for each platform and build configuration. This is a deliberate design choice of the native_splash_screen package to ensure the splash screen can be displayed immediately at native speed without needing to load image files asynchronously from disk at startup.

The actual manually written code changes to integrate the plugin (e.g., in AppDelegate.swift, main.cc, CMakeLists.txt) are relatively small.

I will prepare a video to demonstrate the splash screen working on Linux (where I could fully test) to show the intended effect and will post it shortly. This should help visualize the outcome.

Please let me know if you have any specific concerns about this approach or if there are preferred methods for handling large, embedded image data within the AppFlowy build system. I'm happy to discuss or adjust if needed!

Thanks!

[LucasXu0]

I've watched your demo videos in your native_splash_screen plugin repository.

To be honest, without heavily loading pre-processes, I don't think we need to integrate the native splash screen into our product, and I'll share your idea with our designer.