it’s a reasonable question. But the answer is not so great.
”The thing being requested here—being able to load an arbitrary number of different copies of Flutter into an iOS or macOS application—is fundamentally unworkable”
Thank you for your reply. I have carefully studied the specified forum thread #104144.
My task is a bit different.
Development for Windows, Linux and Android platforms.
The intended usage pattern of Flutter User Interface + JUCE OpenGL backend.
The user interface, including menus and buttons on Flutter, and on JUCE C/C++ and OpenGL, all background rendering, multithreading, interaction with various interfaces, and receiving commands from the Flutter UI.
The functionality of the backend of the application being developed is far from limited to the use of OpenGL. Implementing and maintaining all cross-platform functionality in the future will become an overwhelming distraction from the development of useful functionality and application development.
Therefore, it was decided to search for a cross-platform framework written in C++, preferably open source, and a bunch of other search options.
JUCE doesn’t have many competitors here, and JUCE is perfect for most parameters.
My starting point is a project that I managed to build for one of the target platforms, Android. I’m working on this project to try to put together my own example github/flutter_jucer. In parallel, I’m reading Flutter/Flutter Embedder/Flutter Linux Embedder.
If anyone has seen similar projects where Flutter is used as a User Interface for the target Linux platform, please share the information.
An ideal solution could be a generic JUCE module enabling cross-process embedding of a native view. The plugin process (A) would forward all input to the child process (B), which would render onto a shared GPU surface displayed in A. This is technically possible (Chromium?), but a substantial engineering effort. Such an approach would make it possible to embed Flutter, or actually any UI toolkit not originally designed for plugin environments.
This is a simplified analysis, and there are likely additional complexities to solve. However, it potentially scales beyond a single toolkit and therefore involve multiple contributors.
Finally, there would need to be RPC for the application logic itself, which is comparatively straightforward and likely similar to what I expect the JUCE web view component implements (I haven’t used it yet).