6 ms·

I love Kotlin, but being able to develop libraries in one language and use them in both Android and iOS is huge. I have been using J2Objc for this until now, an

by Fargren 11y ago

I love Kotlin, but being able to develop libraries in one language and use them in both Android and iOS is huge. I have been using J2Objc for this until now, and while it's a great tool, it forces me to use Java, which I don't love. I would prefer being able to use Kotlin on iOS, but using Swift for Android development is a great boon.

untog 11y ago
Could you develop libraries that way, though? It would have to be absolutely pure Swift, not using any iOS libraries, like NSURL etc. etc. - surely incredibly limiting.
- LeoNatan25 11y ago
  Not true. Both Foundation and Core Foundation libraries will be eventually ported and open sourced.
  - bluejekyll 11y ago
    This feels a little like wishful thinking. Remember YellowBox back when Apple originally bought NeXT? YellowBox was going to be a cross-platform updated version of the OpenStep APIs. While I remember some alphas of it, it basically got nixed. http://www.roughlydrafted.com/RD/RDM.Tech.Q1.07/4B800F78-0F75-455A-9681-F186A4365805.html http://www.roughlydrafted.com/RD/RDM.Tech.Q1.07/4B800F78-0F7... As much as I enjoy using Apple products, their history says that they would not directly support something like this.
    - LeoNatan25 11y ago
      We are long long days since that. https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-libdispatch https://github.com/apple/swift-corelibs-libdispatch Works is well under way.
      - bluejekyll 11y ago
        Omg, I had no idea. Awesome!
- Fargren 11y ago
  Absolutely I could. In fact, as I said, I already am, albeit with a more limited technology. For building multiplatform apps I build all the business logic in a Java library which I then convert to iOS using J2Objc. IME this is always between a third and half of the code that is now shared between platforms. For classes that will depend on platform specific stuff, like newtork requests that are handled differently by iOS and Android I use interfaces that I later implement (as protocols) on each side. iOS does end up feeling as a second class citizen though, because J2Obj is not exactly fast; if I need a change in the library, a recompile can take a few minutes
- josephearl 11y ago
  You could this for your own libraries, but I would strongly recommend against doing this for a public lib if you want traction (e.g. if you are making a bunch of SDKs for your APIs) - in this case you should publish your lib in the most popular language(s) for the platform(s) you are targeting.
moonchrome 11y ago
>but being able to develop libraries in one language and use them in both Android and iOS is huge I have no doubt that there are mobile only apps that would find this valuable - but swift is still only linux/android and osx/ios - if you want truly portable code - that can compile to browser/mobile/server/desktop you're stuck with C++ for the foreseeable future.
- unfamiliar 11y ago
  How so? Doesn't this port to Android show that a Windows port is surely possible? Swift is already running on servers afaik. As for compiling to "browser," Swift is based on LLVM so should be just as capable of this as C++.
  - moonchrome 11y ago
    What's "possible" and what's available and tested in production right now are two very different things. These kinds of ports take at least a year to get over the initial troubles and become usable and then you're at least that time away from a decent size of community libraries to spring up for the mentioned platforms. By that time Rust will also mature enough and webasm will land so Rust will probably be a better candidate (since it's OSS and developed by a browser company that needs to run on as many platforms as possible they have much better incentives to maintain ports than Apple). Also in that time C++ will probably get modules working on clang and many c++17 features. And you might see Xamarin merge into CoreCLR and rolled up into VS integration. A lot of things are possible - but what's available right now is C++ on every platform and not much else.
    - mastazi 11y ago
      What's the canonical way of targeting Android with C++?
      - moonchrome 11y ago
        Write shared logic in C++ and use JNI/JNA ? Or are you asking about something more specific ?
trollingineer 11y ago
> develop libraries in one language and use them in both Android and iOS is huge Because you like not taking advantages of either platform's strengths and using some "tool" to make you an iOS AND Android developer?
josephearl 11y ago
AFAIK there's nothing stopping you using Kotlin on iOS with RoboVM since it is a JVM language - https://robovm.com https://robovm.com.
- Fargren 11y ago
  True enough, but I really don't like depending on closed source solutions for something so fundamental as getting my code to run on a platform. I feel like I am betting the future of the product on the future of this company. Of course, I am already betting on the future of iOS and Android, but I have a lot more confidence on those too than on RoboVM
  - mwcampbell 11y ago
    On top of that, RoboVM uses its own LLVM-based compiler rather than Apple's. So if Apple throws us a new compilation requirement, similar to the requirement to provide bitcode for watchOS and tvOS, then we're stuck until RoboVM is updated. With j2objc, you're using Apple's compiler to produce the machine code.
shams93 11y ago
Yeah for an example of what I would love to be able to use on both android and ios : http://createdigitalmusic.com/2015/01/free-audiokit-lets-ios-mac-developers-code-synths-sound/ http://createdigitalmusic.com/2015/01/free-audiokit-lets-ios...

by Fargren 11y ago

untog 11y ago

Could you develop libraries that way, though? It would have to be absolutely pure Swift, not using any iOS libraries, like NSURL etc. etc. - surely incredibly limiting.

LeoNatan25 11y ago
Not true. Both Foundation and Core Foundation libraries will be eventually ported and open sourced.
- bluejekyll 11y ago
  This feels a little like wishful thinking. Remember YellowBox back when Apple originally bought NeXT? YellowBox was going to be a cross-platform updated version of the OpenStep APIs. While I remember some alphas of it, it basically got nixed. http://www.roughlydrafted.com/RD/RDM.Tech.Q1.07/4B800F78-0F75-455A-9681-F186A4365805.html http://www.roughlydrafted.com/RD/RDM.Tech.Q1.07/4B800F78-0F7... As much as I enjoy using Apple products, their history says that they would not directly support something like this.
  - LeoNatan25 11y ago
    We are long long days since that. https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-libdispatch https://github.com/apple/swift-corelibs-libdispatch Works is well under way.
    - bluejekyll 11y ago
      Omg, I had no idea. Awesome!
Fargren 11y ago
Absolutely I could. In fact, as I said, I already am, albeit with a more limited technology. For building multiplatform apps I build all the business logic in a Java library which I then convert to iOS using J2Objc. IME this is always between a third and half of the code that is now shared between platforms. For classes that will depend on platform specific stuff, like newtork requests that are handled differently by iOS and Android I use interfaces that I later implement (as protocols) on each side. iOS does end up feeling as a second class citizen though, because J2Obj is not exactly fast; if I need a change in the library, a recompile can take a few minutes
josephearl 11y ago
You could this for your own libraries, but I would strongly recommend against doing this for a public lib if you want traction (e.g. if you are making a bunch of SDKs for your APIs) - in this case you should publish your lib in the most popular language(s) for the platform(s) you are targeting.

moonchrome 11y ago

>but being able to develop libraries in one language and use them in both Android and iOS is huge I have no doubt that there are mobile only apps that would find this valuable - but swift is still only linux/android and osx/ios - if you want truly portable code - that can compile to browser/mobile/server/desktop you're stuck with C++ for the foreseeable future.

unfamiliar 11y ago
How so? Doesn't this port to Android show that a Windows port is surely possible? Swift is already running on servers afaik. As for compiling to "browser," Swift is based on LLVM so should be just as capable of this as C++.
- moonchrome 11y ago
  What's "possible" and what's available and tested in production right now are two very different things. These kinds of ports take at least a year to get over the initial troubles and become usable and then you're at least that time away from a decent size of community libraries to spring up for the mentioned platforms. By that time Rust will also mature enough and webasm will land so Rust will probably be a better candidate (since it's OSS and developed by a browser company that needs to run on as many platforms as possible they have much better incentives to maintain ports than Apple). Also in that time C++ will probably get modules working on clang and many c++17 features. And you might see Xamarin merge into CoreCLR and rolled up into VS integration. A lot of things are possible - but what's available right now is C++ on every platform and not much else.
  - mastazi 11y ago
    What's the canonical way of targeting Android with C++?
    - moonchrome 11y ago
      Write shared logic in C++ and use JNI/JNA ? Or are you asking about something more specific ?

trollingineer 11y ago

> develop libraries in one language and use them in both Android and iOS is huge Because you like not taking advantages of either platform's strengths and using some "tool" to make you an iOS AND Android developer?

josephearl 11y ago

AFAIK there's nothing stopping you using Kotlin on iOS with RoboVM since it is a JVM language - https://robovm.com https://robovm.com.

Fargren 11y ago
True enough, but I really don't like depending on closed source solutions for something so fundamental as getting my code to run on a platform. I feel like I am betting the future of the product on the future of this company. Of course, I am already betting on the future of iOS and Android, but I have a lot more confidence on those too than on RoboVM
- mwcampbell 11y ago
  On top of that, RoboVM uses its own LLVM-based compiler rather than Apple's. So if Apple throws us a new compilation requirement, similar to the requirement to provide bitcode for watchOS and tvOS, then we're stuck until RoboVM is updated. With j2objc, you're using Apple's compiler to produce the machine code.

shams93 11y ago

Yeah for an example of what I would love to be able to use on both android and ios : http://createdigitalmusic.com/2015/01/free-audiokit-lets-ios-mac-developers-code-synths-sound/ http://createdigitalmusic.com/2015/01/free-audiokit-lets-ios...