Skip to content

FAQ

Jump to bottom
Angel G. Olloqui edited this page Oct 26, 2017 · 2 revisions

In this section, I have compiled some of the questions I have gotten on my email about SwiftKotlin

Question: There is some code in my app that is quite generic and not related to the UIKit framework. In my dreams, I would be able to automatically translate this generic code from Swift to Kotlin. If the Swift files are updated in the future, then I'd like to regenerate the Kotlin files. I'm hoping I can adjust my existing Swift files as necessary and continue writing Swift in a way that the generated Kotlin files will not need editing. I know that might mean giving up some of Swift's features but the ability to automatically generate Kotlin files would be much more valuable.

I am sorry to tell you that this is too big a dream. The goal of SwiftKotlin is to help you converting the file, but it will always require some manual edition. This is on purpose and is due to technical limitations and decisions:

  1. Swift and Kotlin are different languages, with different features. As you said, you could try to use a subset of the Swift features to get a “common factor” for both languages (and implemented by SwiftKotlin), but that will be difficult to enforce and, in my opinion, it will damage your project quality. You will end up with a badly written Swift project to get a low quality Kotlin translation.

  2. Frameworks are different. This is obviously true when comparing UIKit with Android Views, but there are differences all over other libraries. For example, in the foundation, the flatMap monad in Swift has a different signature for the lambda that the one found in Kotlin, or things like adding a value to an array is call append or add in each language. The list of framework differences is almost infinite, and despite it is my plan to cover the most common ones (in foundation) with next versions of SwiftKotlin, it will never be exhaustive.

  3. Lack of context. Related to the previous comment, there is a big issue that will never be solved (as far as I can see right now at least), which is the lack of context on the code snippets. For example, in Swift you can use classes from other files and packages without importing them, while Kotlin requires imports for each one of them. The compilers can solve this by having a complete inference system and having access to all the libraries and frameworks in your project, so they can know the exact types to be imported (even then sometimes they require you to explicitly indicate the package if there is a name conflict). In a tool like SwiftKotlin, this will not be possible and hence we will not be able to resolve imports or to infer the exact type when calling a method of an external class.

That being said, if you do the manual editing, IDEs like Android Studio can help you fixing the issues in a matter of seconds. For example, if you select auto imports, Android Studio will resolve most of them (if not all), and differences in APIs will be marked in red as compilation issues that will be very trivial to resolve by a human. But it is, again, a manual process that will be improved over time but will never be automated for all cases.

Question: Choosing tech dependencies is important. If I choose to depend on SwiftKotlin, that will be an important choice in my life. :-) Is your project SwiftKotlin the right tool for my job?

The purpose is to help you translating the languages, so the ideal scenario is:

  1. You have an app developed in Swift and you want an Android version in Kotlin
  2. Your source code follows SOLID principles and it is properly architectured, reducing dependencies to external frameworks or limiting them to some specific layers.
  3. Your developer team is multiplatform, so the same people writing Swift will write the Kotlin version.

The benefit of choosing SwiftKotlin is that it does not modify your technology stack, you can keep using your favourite tools and take advantage of any future development by Android or iOS. If for some reason you have to stop using SwiftKotlin in the future, your source code will still be perfectly valid, and both platforms can also diverge with time if required or even be developed completely apart from each other. It is just a tool to save some of your time, but it does not force you to use it for the rest of your project lifetime (as opposed to other solutions like ReactNative, Xamarin, etc). An extra benefit is that SwiftKotlin will work best when the architecture of your app is properly designed, so it encourages developers to follow best practices because they can get a real and immediate benefit from it.

Question: Do you use SwiftKotlin in your work at Syltek Solutions or elsewhere for production apps?

We do. We have been using it for almost a year now, and we are very satisfied and performant (example here: https://itunes.apple.com/es/app/mypadel/id888675303?mt=8).

To give you an overview, what we did is to architect both apps with CleanArchitecture principles in mind, so we have basically a View layer that does not translate easily but the rest of the layers are really quick to translate. Even the UnitTests (which covers more than 50% the code) are just a copy&translate&paste from platform to platform. In order to make this possible, we abstracted some of the things in our own facades and implemented them for each platform but with the same interface. Some examples of facades we made:

  • Promises: For async handling
  • Navigation Manager: For dealing with navigation (push presenters in navigation, dismiss them, etc)
  • Network client: For making HTTP calls
  • Location Manager: For dealing with GPS.

We spent like 3 weeks creating these ground bases on both platforms when we started (and while the product definition was still incomplete), and since then we are just implementing features very quickly. With this in place, translating Presenters, Routes, tests, etc takes us less than 30min, and it is just the view layer that gets most of the time. In average, when implementing a new module, we spend about 30% the time it took in iOS to convert to Android (and this is just because of the View layer, the simpler your view the less time it will take).

An added benefit is that having both code bases so similar results in common bugs, so makes maintenance much simpler and browsing the code is a pleasure! You know exactly where to look at, and questions like “how we did this in Android compared to iOS?” do not arise anymore.

Question: What are your coming plans for ongoing SwiftKotlin development?

Regarding the plans for SwiftKotlin, it makes no sense to mark a day as an official release because the work is infinite and resulting code requires manual editing anyway, so I am working on it more in an agile way where I improve it step by step. I am using the tool daily, and I am myself deciding what to build next. The tool is not yet mature, but it is getting better every month, so less and less manual editing is required and better Kotlin code produced. If you have a feature you would like to be implemented first, just open a Github issue with the details and some example code so I can evaluate the impact, or if you feel brave enough, download the project and implement it yourself, PRs are always welcome.

Question: My overall motivation is to provide an escape hatch for my companies use of the RemObjects swift compiler, which is free but entirely closed source, and full of bugs which is very frustrating

I think they are both different approaches to the problem of code sharing. With SwiftKotlin you will always have to keep 2 code bases, and many parts of the code will defer per platform. Besides, some features of Swift can not be implemented in Kotlin (like the extensions conforming protocols) and system libraries will always be different enough to have to change the code slightly after conversion in most cases. So, overall, the tool will be of great help but not a fully replacement to something like Rem. On the other hand, you have benefits of it as well, especially not depending on a 3rd party (dependency on SwiftKotlin does not count as the transformed code will always work even if this project disappears) and keeping both platforms fully native and with the official tools and practices encouraged by Apple/Google. It is all a trade off that depends on the company and team ideals.

Clone this wiki locally