Viability for x-platform with Swift

I’m starting to build a large project (a point-of-sale) that need to be on Web(API), iOS/Android, and Windows/Linux/Mac command line tools. I wish to do all in native swift, including the Web/Api. My only serious problem is target android.

I’m ok with build the GUI for each target, but need to clarify some things:

  • I can use/call thirdy-party libraries just fine (coocapods, nugets, whatever-use-android)? I will need to call several apis, as georeferencing, printers, barcode scanners, maps, and more important, RDBMS (sqlite, postgresql)
  • I can do the bulk of coding in xcode and “just” compile with fire for windows/android?
  • For android, is possible to use xamarin apis?
  • How is the stability of silver backend? Is something I could rely on or is still worked on?
  • Is possible to do code on silver and reusing it on native swift/.net/java?
  • Any hints or gotchas in doing some project like this?

And finally:

  • Can fire allow to put a font size directly? “Ginormous” Is too small for my 32" 4k monitor :slight_smile:
1 Like

of course. (specific TO each platform, of course)

probably not, no.

You can use our Swift compiler for .NET, with Xamarin. If you use our Swift compiler for Java, you can only use Java APIs, not .NET ones (which is what Xamarin is)

Silver is the front-end, not the back-end, ftr. it’s “just” the language parser. the backend is shared with all Elements languages and as solid as our support for each respective platform is old (eg ~10 years for Java, ~14 years for .NET, etc). Of course it is constantly being worked on and improved, on all levels.

Not sure what you’re asking, but yeah thats exactly what Silver does.

I had a few blog posts about cross platform strategies, a couple months back, I suggest checking those out.

yeah, you can manually override this with any number, in the settings plist — but, I have a hard time believing Ginormous really is too small, unless there’s a bug. whats your DPI (or how far are you away from your screen)? are you NOT running in Retina mode (but then, all the rest of macOS would be even less readable).

whats your DPI (or how far are you away from your screen)? are you NOT running in Retina mode (but then, all the rest of macOS would be even less readable).

This is vs. SublimeText 3:

I have iMac 2560 * 1440 (Low Resolution)

In 4k is even smaller.

I can do the bulk of coding in xcode and “just” compile with fire for windows/android?

I was not clear enough. I think the answer is yes, but only for bussines logic. The idea is do the common core, db access in xcode and then the android/windows parts on fire, but then I will need to share the common parts of the project.

Not sure what you’re asking, but yeah thats exactly what Silver does.

I mean if I do a .NET/Silver code I could call it from any .net language? And similar for other platforms? This certainly could mean to share the compiled libs.

hm, but his is not the rest of the OS way too small as well then? Sure, sublime is larger. but even Ginormous in Fire is way bigger that the standard OS texts (such as in the sidebar, or even the top bar in Sublime. What am I missing here — or do you really just want the code 5x the rest of everything else (which is a fine wish in and of itself)?

oh, for that, sure.

That said, I think you’ll fare better just doing both the iOS and the Android project in Fire, as that way you get a lot more sharability than you use Xcode for iOS (such as if #defined(COCOA), Shared Projects, Elements RTL for shared base types, and a lot more multi-platform magic that Elements provides that Xcode/Swift won’t care about.

The common parts can be a lot more common and cover a larger surface area of your whole project, if you can use Elements RT and your own mapped types. Check out https://blogs.remobjects.com/2017/08/16/strategies-for-cross-platform-code-sharing-with-elements/ for some of that.

hm, but his is not the rest of the OS way too small as well then?

Is small, sure. But most of the time I need to read code, web, terminal and all of them allow me to have big fonts. How I hack the plist to do this?

Edit ~/Library/Preferences/com.remobjects.fire.plist, you’ll wanna change/add this value:

	<key>CodeEditorFontSize</key>
	<real>16</real>

Let me know how it goes and if you run into any rendering issues at larger values — as this is untested ;). but in theory any value here should work.

(oops, sorry for the delay, I meant to send this off yesterday but somehow it didn’t post)

I do the change and full restart but not see any difference (I try with 18, 22, 24, 30)

Reproduced. I’ll need to investigate…

Freaky. looks like the system gets confused when one edits the plist file by hand, even when Fire is not running. try running this from Terminal instead:

defaults write com.remobjects.Fire CodeEditorFontSize -float 48

where 48 is whatever value you want.

big enough for ya? :wink:

I don’t see any changes. I confirm is set on the plist but the editor look the same.

hmm. that’s strange…

Now returning to topic, how exactly is possible to do this? How I can use a pod file or swift package manager and use it from elements? (the same with android).

1 Like

Android Gradle refererences, you can just reference my name, and EBufs Gradle support will pull them in. For cocoa, it’s a bit more manual; you can import frameworks with FXGen, from Fire’s Tools menu. Right now that’s Objective-C frameworks only since Apple Swift does not have a stable ABI yet and their binary format, literally, breaks with each for release - so we don’t support linking to Apple Swift-compiler. Inatirs yet; we”ll add that when/if Swift 5 brings a stable ABI.

1 Like

I check there and its all gray except “Import SDKs from Xcode”.

Then you need a newer Fire, iirc this is new in 2253.

I download today, version 10…0.0.2249 (develop)

do you have beta access? if not, PM me your account name on remobjects.com and i’ll get you set up (but probably not until the morning, as i need to run out now…)

As noted in Swift libraries with Silver, Swift 5 has now ushered in ABI stability at long last. Here’s to hoping for extended Swift package/library support before long… :innocent: