support swift as native language on all platforms

[renanyoy]

Is there an existing issue for this?

• [X] I have searched the existing issues
• [X] I have read the guide to filing a bug

Use case

using same native code on all platforms, using an universal package manager and using all the swift ecosystem.

Proposal

Would be nice to have swift supported on all platforms (darwin, android, linux, windows). Given that swift has a nice package manager with SPM, and that swift can be linked with C, C++ and objectiveC libraries, it will provide an universal package manager for native code on all platforms.

Flutter swift linking is already implemented on darwin platfoms. It just need to be extended on all platforms.

[stuartmorgan]

Several of my comments in https://github.com/flutter/flutter/issues/112677 (in particular this and this) apply equally here.

Would be nice to have swift supported on all platforms (darwin, android, linux, windows).

This is a proposal, not a use case; what is the use case that this proposal enables?

Flutter swift linking is already implemented on darwin platfoms. It just need to be extended on all platforms.

Flutter builds Swift code using the same Xcode toolchain that it uses for the rest of the application build process. What specifically are proposing when you say "extended on all platforms"? How would the existing Xcode integration be extended to building an Android application from a Windows host, for instance?

[renanyoy]

@stuartmorgan With swift package manager you don't need xcode on non darwin platforms. here the universal toolchain https://www.swift.org/download/ and for android https://github.com/apple/swift/blob/main/docs/Android.md

a swift packages indexer https://swiftpackageindex.com/ just an helper not needed by SPM as it requires only git example https://github.com/aestesis/Aether/blob/master/Package.swift

also SPM can handle decencies on apt, brew, yum, nuget, etc.. and it's open source, so flutter team, devs.. etc.. could add more features on it for flutter if needed.

SPM Package.swift doc https://github.com/apple/swift-package-manager/blob/main/Documentation/Usage.md

[stuartmorgan]

With swift package manager you don't need xcode on non darwin platforms. here the universal toolchain https://www.swift.org/download/ and for android https://github.com/apple/swift/blob/main/docs/Android.md

I'm aware that it's possible to build Swift code for other platforms; I was asking about your comment that we "just" need to "extend" our exist Swift support for iOS/macOS (which is just to let Xcode handle it) to other platforms. When you say "just extend", what does that mean, specifically? The only way I am aware of to support this would require a lot of completely new code in the flutter tool that doesn't look anything like the current iOS/macOS support (and would also require every Flutter developer to have new tooling in their installation that is currently not required), which is fundamentally different from just enabling existing code for other host platforms.

As for the other links, they don't address my primary question from my previous comment: what is the use case for this proposal?

[renanyoy]

I agree it will need some work, but it's to get a simpler and unified build process on all platforms.. the use case is to have same package to handle native code on all platform.. for example if I build a 3d engine for flutter, I can handle all the dependencies from all platform directly from one main swift library package.. that will use metal on ios and vulkan on other platforms.. and same for all kind of dependencies.. as swift handle already all platforms.. and can be linked with nearly all native libs available on earth, without any work.. swift can even import python codes.. also swift is near dart in syntax.. easier and safer than c++, c, etc..

[renanyoy]

the alternative is to make a 3d engine in swift for darwin, and in C for other platforms, it requires a lot more work for all plugin developers...

btw, what is swift https://en.wikipedia.org/wiki/Swift_(programming_language)

"The platforms Swift supports are Apple's operating systems (Darwin, iOS, iPadOS, macOS, tvOS, watchOS), Linux, Windows, and Android.

A key aspect of Swift's design is its ability to interoperate with the huge body of existing Objective-C code developed for Apple products over the previous decades, such as Cocoa and the Cocoa Touch frameworks. On Apple platforms,[51] it links with the Objective-C runtime library, which allows C, Objective-C, C++ and Swift code to run within one program."

[cmkweber]

If the use case is a 3d engine, you may want to follow flutter:gpu - which will allow this low level development from Dart on platforms supported by Impeller.

[stuartmorgan]

btw, what is swift

The Flutter team is familiar with Swift; that's not the question here.

the use case is to have same package to handle native code on all platform.

This is still more of a proposal than a use case. For instance, what does "native code" mean exactly in this context? Dart AOT compiles to native code, and has the same package manager and build system across platforms.

for example if I build a 3d engine for flutter

Is this a real use case, or a hypothetical? It would be helpful to ground this in an actual use case where we can drill into specifics. In the abstract, if the use case is just a hypothetical "build a 3D engine from scratch for Flutter in a cross-platform way", it's not clear to me that Dart and/or https://github.com/flutter/flutter/issues/129757 doesn't address that use case.

Also, if that's the use case, then things like:

A key aspect of Swift's design is its ability to interoperate with the huge body of existing Objective-C code developed for Apple products over the previous decades, such as Cocoa and the Cocoa Touch frameworks.

aren't going to apply. This is why it's hard to evaluate proposals outside of the context of concrete use cases.

as swift handle already all platforms.. and can be linked with nearly all native libs available on earth, without any work.

How would introducing Swift (which is harder to call from Dart, and requires extra tooling compared to what we alreday have) as an intermediate layer reduce work relative to having Dart call native libraries directly via FFI?

[renanyoy]

A key aspect of Swift's design is its ability to interoperate with the huge body of existing Objective-C code developed for Apple products over the previous decades, such as Cocoa and the Cocoa Touch frameworks.

it works I have already lots of code in swift that link with C and C++ code on all platforms.

3d engine, is an example of extensive cpu and gpu usage code, that can only be done in native code.. it applies for AI, and all kind of heavy process needed by Apps (ex: image editor, audio editor, video editor, 3d editor, etc..) if you want flutter to not just be a client for server app.. it's needed.

3d engine isn't hypothetical. I'm planning to build a 3d engine for flutter, if not too much work involved.. as I have already a metal->vulkan wrapper and the foundation of a 3d engine in swift.

for the interop flutter <-> swift, it only needs hi level functionalities between UI and core engine.. as all the low level dependencies are managed by SPM.. also this kind of separation helps to produce clean code..

the main reason for this proposition. it's because on darwin platform you need swift to access all the apple APIs.. You can't do it in C. So if swift can be linked with flutter on all platform it helps to have a common native language for all platforms. and reduce a lot the work for making native code part integrated with flutter. It gives a single code using Apple APIs on darwin, and linking with external C or C++ libraries giving same functionalities on android, linux, windows.

[stuartmorgan]

3d engine, is an example of extensive cpu and gpu usage code, that can only be done in native code.. it applies for AI, and all kind of heavy process needed by Apps (ex: image editor, audio editor, video editor, 3d editor, etc..)

As mentioned above, Dart is compiled to native machine code. If you have performance issues with Dart please file detailed issues with reproducible test cases in the Dart issue tracker.

the main reason for this proposition. it's because on darwin platform you need swift to access all the apple APIs.. You can't do it in C. So if swift can be linked with flutter on all platform it helps to have a common native language for all platforms.

Weighing the very specific niche of wanting to write cross-platform, green-field code that also needs to interact with Apple-specific APIs (which is generally not going to be the case for cross-platform code) against the broad ecosystem concerns described in the links above, I don't see this as being something that we would support within Flutter itself.

Third-parties are always welcome to build their own interop layers for clients who choose to take on the added tooling complexity (such as https://github.com/flutter/flutter/issues/112677#issuecomment-1266181178).

[renanyoy]

As mentioned above, Dart is compiled to native machine code. If you have performance issues with Dart please file detailed issues with reproducible test cases in the Dart issue tracker.

performance isn't an issue but other problems emerge:

• thread management is a lot more painful in dart/flutter than in native code..
• in dart automatic linking on external dependencies (c++,c) without any wrapper isn't possible
• swift has already a vast list of open source libs (gnu and other..) already available to link against
• contrary to dart, SPM can use near all other package managers as dependencies

Weighing the very specific niche of wanting to write cross-platform, green-field code that also needs to interact with Apple-specific APIs (which is generally not going to be the case for cross-platform code) against the broad ecosystem concerns described in the links https://github.com/flutter/flutter/issues/139563#issuecomment-1841080914, I don't see this as being something that we would support within Flutter itself.

if you want to create AI, image processing, audio, video, 3d apps, you need to interact with apple APIs on darwin platforms as they are optimized for Mx processors.. And I don't think that all this apps are just niche...

In my case I don't find dart interop as easy than SPM interop... takes me a lot more time in dart.. I think I will backup on porting swiftUI on vulkan, should be faster...

btw, seems like flutter team likes complexity over simplicity...

[stuartmorgan]

• thread management is a lot more painful in dart/flutter than in native code..

Please file relevant feature requests against Dart.

• in dart automatic linking on external dependencies (c++,c) without any wrapper isn't possible

Automatically linking Dart code to Swift isn't possible either, so interposing Swift between Dart and C/C++ code does not solve that problem, it just moves it up a layer (and makes it harder, because Swift doesn't easily expose C ABI entry points as far as I can tell).

• swift has already a vast list of open source libs (gnu and other..) already available to link against

Every language has its own ecosystem; this argument is not specific to Swift. The comments I've linked to previously address this general topic.

• contrary to dart, SPM can use near all other package managers as dependencies

Please file feature requests against pub for features that you believe pub lacks relative to other package managers.

if you want to create AI, image processing, audio, video, 3d apps, you need to interact with apple APIs on darwin platforms as they are optimized for Mx processors.. And I don't think that all this apps are just niche...

I did not say that every use case involving platform APIs is niche, only that the specific use case you are describing of:

• green-field development for Flutter
• not in Dart
• intended to be fully cross-platform
• but directly built on inherently non-portable platform APIs (rather than factoring the cross-platform pieces and the platform-specific pieces into separate components)

is a niche use case.

There are many plugins that do things on your list which are not built in the way you are describing. video_player, for instance, would not benefit from this proposal, and is the most widely used video plugin.

btw, seems like flutter team likes complexity over simplicity...

Please take a moment to read the comments of mine that I've linked to above (several times) where I explain the substantial developer-facing complexity of what you are proposing, as well as our code of conduct.

[renanyoy]

due to the limit of flutter, that you surely know. I think it would be smart to incorporate an other ecosystem to speedup the dev of flutter.. I think swift is the right choice.. what do you propose as alternative otherwise ?

I have already invested 3y in flutter I don't want to loose this years like I have lost with xamarin..

anyway, I will try to create my own builds and import the flutter engine into my SPM tooolchain swift code..