4 ms·

Or you could abstract out the model, networking, persistence, and other services logic from your app into a reusable library,—and then consume that from a nativ

Or you could abstract out the model, networking, persistence, and other services logic from your app into a reusable library,—and then consume that from a native, unshared frontend. I'm hoping that Swift becomes sufficiently viable on Android that I can reuse library code across iOS and Android sometime in the next few years.

kitsunesoba 8y ago
Yeah, that wouldn’t be too bad. The main need when doing something like this would be a networking library that uses system provided networking (NSURLSession, etc) under the good rather than curl or something like that — not that curl or whatever else is bad exactly, but you’d be losing out on radio use optimizations among other things.
hliyan 8y ago
> abstract out the model, networking, persistence, and other services logic from your app into a reusable library,—and then consume that from a native, unshared frontend Oddly enough, this is what we're going with...
fstephany 8y ago
Looks like Kotlin gets the lead in this area with Kotlin Native. Jetbrains moves pretty fast and the integration works surprisingly well for something this young.
- kitsunesoba 8y ago
  As great as jetbrains is, I think Swift has much better long term potential in terms of FOSS tools. The Swift language server Apple is currently working should bring an open tooling avalanche. In fact I think the high quality of jetbrains IDEs might actually impede Kotlin tooling development… why bother when first party tools are so good?
  - oblio 8y ago
    The thing is, developers outside of Apple platforms don't really adopt Apple techs. Objective C never took off and the same seems to be happening to Swift. I don't know anyone using it on Linux.
    - kitsunesoba 8y ago
      Objective-C’s cross platform use was crippled due to half of its essentials being tied up in Cocoa. Objective-C by itself doesn’t even have memory management. Swift doesn’t suffer this issue — it’s been built for multiplatform use from day 1. There are still some discrepancies, but today Swift on Linux is about as usable as Swift on Apple platforms. There’s even several (4+ last I checked) modern web frameworks for Swift and even GTK+ bindings. On top of this, its Windows port recently reached a useable state and there’s work being done on a Win32 bindings. Once that’s done, it will be possible to write an app with a common core and 3 different UI layers all in Swift which connects to a web API written in Swift. That’s already leagues beyond what was ever achieved with Obj-C and momentum is continuing to build.
      - saagarjha 8y ago
        > Swift on Linux is about as usable as Swift on Apple platforms Eh, I wouldn’t say that. I don’t see it significantly ahead of say GNUstep is for Objective-C; Swift on any platform other than macOS is still pretty much a second-class experience.
      - oblio 8y ago
        Ok. But the questions now is: why would you adopt it? You could use Java/OpenJDK or even Kotlin/OpenJDK. You could use dotnet core. You could use Node.js with Typescript. Or Python/Ruby/PHP/... All those are mature and support all major operating systems way better than Swift does. I'm not sure what Swift's Unique Selling Proposition is. From where I'm looking it seems to be: "it's backed by Apple".
- hliyan 8y ago
  Have you attempted cross platform development with Kotlin [1]? If so, how is your experience? [1] https://proandroiddev.com/we-built-our-ios-and-android-apps-in-java-kotlin-one-year-later-b0df37274b75 https://proandroiddev.com/we-built-our-ios-and-android-apps-...
- pjmlp 8y ago
  I consider a big mistake that Kotlin/Native doesn't share the same semantics with pure Kotlin. However since it is still beta, this might eventually change. And it does require getting licenses for Clion and AppCode, for the full developer experience regarding Kotlin/Native, versus C++ that is already there in XCode and Android Studio.
saagarjha 8y ago
I’d suggest using C++ or a language with C bindings if you want this today (or even in the future).
- aaronbrethorst 8y ago
  And then I’d have to write C++. No thanks :-/
jon-wood 8y ago
This is much what Xamarin does, encouraging you to have a common core, and then implement the UI for each target platform separately to fit the platform’s style.

kitsunesoba 8y ago

Yeah, that wouldn’t be too bad. The main need when doing something like this would be a networking library that uses system provided networking (NSURLSession, etc) under the good rather than curl or something like that — not that curl or whatever else is bad exactly, but you’d be losing out on radio use optimizations among other things.

hliyan 8y ago

> abstract out the model, networking, persistence, and other services logic from your app into a reusable library,—and then consume that from a native, unshared frontend Oddly enough, this is what we're going with...

fstephany 8y ago

Looks like Kotlin gets the lead in this area with Kotlin Native. Jetbrains moves pretty fast and the integration works surprisingly well for something this young.

kitsunesoba 8y ago
As great as jetbrains is, I think Swift has much better long term potential in terms of FOSS tools. The Swift language server Apple is currently working should bring an open tooling avalanche. In fact I think the high quality of jetbrains IDEs might actually impede Kotlin tooling development… why bother when first party tools are so good?
- oblio 8y ago
  The thing is, developers outside of Apple platforms don't really adopt Apple techs. Objective C never took off and the same seems to be happening to Swift. I don't know anyone using it on Linux.
  - kitsunesoba 8y ago
    Objective-C’s cross platform use was crippled due to half of its essentials being tied up in Cocoa. Objective-C by itself doesn’t even have memory management. Swift doesn’t suffer this issue — it’s been built for multiplatform use from day 1. There are still some discrepancies, but today Swift on Linux is about as usable as Swift on Apple platforms. There’s even several (4+ last I checked) modern web frameworks for Swift and even GTK+ bindings. On top of this, its Windows port recently reached a useable state and there’s work being done on a Win32 bindings. Once that’s done, it will be possible to write an app with a common core and 3 different UI layers all in Swift which connects to a web API written in Swift. That’s already leagues beyond what was ever achieved with Obj-C and momentum is continuing to build.
    - saagarjha 8y ago
      > Swift on Linux is about as usable as Swift on Apple platforms Eh, I wouldn’t say that. I don’t see it significantly ahead of say GNUstep is for Objective-C; Swift on any platform other than macOS is still pretty much a second-class experience.
    - oblio 8y ago
      Ok. But the questions now is: why would you adopt it? You could use Java/OpenJDK or even Kotlin/OpenJDK. You could use dotnet core. You could use Node.js with Typescript. Or Python/Ruby/PHP/... All those are mature and support all major operating systems way better than Swift does. I'm not sure what Swift's Unique Selling Proposition is. From where I'm looking it seems to be: "it's backed by Apple".
hliyan 8y ago
Have you attempted cross platform development with Kotlin [1]? If so, how is your experience? [1] https://proandroiddev.com/we-built-our-ios-and-android-apps-in-java-kotlin-one-year-later-b0df37274b75 https://proandroiddev.com/we-built-our-ios-and-android-apps-...
pjmlp 8y ago
I consider a big mistake that Kotlin/Native doesn't share the same semantics with pure Kotlin. However since it is still beta, this might eventually change. And it does require getting licenses for Clion and AppCode, for the full developer experience regarding Kotlin/Native, versus C++ that is already there in XCode and Android Studio.

saagarjha 8y ago

I’d suggest using C++ or a language with C bindings if you want this today (or even in the future).

aaronbrethorst 8y ago
And then I’d have to write C++. No thanks :-/

jon-wood 8y ago

This is much what Xamarin does, encouraging you to have a common core, and then implement the UI for each target platform separately to fit the platform’s style.