Hi everyone, I am planning to use Fire with Elements to set up a cross-platform app. I want to use Swift in the whole project. For apple apps, I want to create something similar to the “Apple Multiplatform” project template in Xcode and use SwiftUI for creating UI. For android, I would either use Cooper or .NET MAUI (or Xamarin.Forms). For windows, I can either use .NET (via Echoes), Island or .NET MAUI. I have yet to decide how I would create the Linux app.
I have a few doubts in my mind before I get started.
How to create a Apple Multiplatform Project with SwiftUI in Fire?
What is the performance and size overhead of final android build with Cooper? I am sure there must be a Java runtime for Silver embedded in the final android APK. What is the size of that runtime?
Will there be any such performance or size overhead in the final iOS and Mac build with Fire?
Is there any performance and size overhead in a .NET application, other than that of .NET itself?
Is it possible to create a .NET MAUI (or Xamarin.Forms) project in Swift?
Do you have any other suggestions for me to make cross-platform development easy?
Firstly, RemObjects Swift currently does not support SwiftUI, as it’s an Apple Swift-only framework, and Elements (for now) only supports Objective-C-based frameworks from the Apple SDKs. Unfortunately, Apple’s ABI for Swift frameworks is still undocumented, fragile (despite being called stable) and really tough ti support by other compilers — largely by design). Although we have not given up on supporting it eventually, it is not currently an area if focus for us.
So that leaves you with two choices: (a) you can use UIKit (and AppKit or Mac Catalyst, for Mac) for the Apple side of you UI or (b) you can build a static library with your core app functionality in Elements, and then use that from Swift UI in an Xcode project. AT this stage’s would still recommend option (a), as Swift UI — despite having gotten better — from all I hear is still far from production-ready for anything but trivial small apps.
On the Android side, there should ne no discernible performance difference between using Elements (Swift, or any other language) vs using Java or Kotlin with Android Studio. In both cases, your code will be compiled to Java byte code, and then converted to DEX/Dalvik byte code tureen on device — the resulting binaries should be virtually indistinguishable.
The same goes for the Apple (iOS and Mac) side. your code will compile to native arm64 (and/or x64) machine code, on the same level as code generated by Objective-C in Xcode. As such, it will probably be more efficient that Apple Swift in many areas, especially where inter-operating with the native Objective-C-based frameworks of the platform — where Apple Swift can have some large bridging costs when you’re not being very careful.
Again the same is the case for .NET — your code will compile to .NET (Core) MSIL code, same as it would if you were using Visual C#.
You should be able to use MAUI from any Elements language, but I have to admit I do not have any personal experience with this scenario.
My personal suggestion would be going a similar route as we do with Fire/Water (for Mac/Windows) and I went for a personal mobile ap for iOS/Android: Structure your code so that
(a) the majority of non-UI code uses Elements RTL APIs and can compile for .NET, Java and Cocoa
(b) abstract your views/windows/UI using a concept lime MVC (or similar design principles), where you have a split class for each view, Wirth common code shared between platforms, and there for each platform you have a partial class (“extension”, in Swift parlance), and potential code GUI file, that handles the platform-specific actual UI, designed for that platform.
For example, below you see one window (sheet) in Fire/Water, the breakpoint manager. The AddBreakpointSheetController.cs ha the bulk of the code that manages the view, platform-independent. Then there’s AddBreakpointSheetController.Cocoa.cs and AddBreakpointSheetController.WPF.cs partial classes that handle a couple platform specific things (these could also be if-def’ed in a single file — for Fire I opted to always use partials, no matter of the per-platform code is substantial (as it is for some) or minimal (as it is in this code). These three files together make up the “view controller”.
Then there’s the .xib file (for Mac) and the .xaml file (for Windows/WPF; and it comes with its own partial .cs class, because thats how WPF works), and those are the platform-native “views”, in MVC parlance.
The upside to this approach is that I can share up to 99% of the code for each view (depending on complexity and per-platform needs) between platforms, but still have the ability to (a) provide fully native and separately designed actual view (as XIB or XAML) and, more importantly (b) easily provide custom platform-specific behavior, where needed/desired.
Similar (not shown here) concept could be applied to separate between an iOS (.xib/storyboard) and Android (xml layout) view instead, or even combining all four.
Below are two (bit older) blog posts that cover these topics, as well:
