One key part of this app is a custom framework tha...
# ios
One key part of this app is a custom framework that uses advanced Swift language features for meta-programming, and it's tightly coupled to UIKit. Otherwise we would just easily use a code translator and switch out the obvious frameworks. My team is looking for a consultant to guide us through and/or help us do this port
Hi Jazzy, I'd have to start by questioning the motivation for porting an App which - by your own description - is tightly coupled to Swift. Sounds like it could be an expensive reinvention of the App, so you'd want to make sure the business-case was there. Presumably it's to reduce ongoing maintenance costs; but know this could become effectively a rewrite, using the existing app as a 'living specification'.
💯 1
👍 1
For green-field, cross-platform mobile Apps, Kotlin Multiplatform is very easy to recommend. For porting existing Apps it's more complicated and very dependent on the App.
👍 1
Does the current App adhere well to Clean architecture, or other architectural pattern?
Knowing that would be a good starting point to know how to introduce a shared code module between the platform-native mobile projects; and then start bringing more code into.
What are the metaprogramming features you're using in Swift in your app @jazzyfresh?
@louiscad swift property wrappers & dynamic member lookup. (i'm not the one who built the app, just a backend engineer that got put on mobile recently!)
@jazzyfresh Property wrappers are called property delegates in Kotlin. Dynamic member lookup, there are many ways to avoid it, including using sealed interfaces in Kotlin, but if there's no way around, you can always make a compiler plugin (possibly taking inspiration from this old research project by JetBrains), or try with KSP, or, if limiting yourself to the JVM is fine, you can use Java reflection, or (heavyweight) Kotlin reflection, but be warned, this is very expensive on ART (the Android runtime), so better to stick to compile-time approaches.
@jazzyfresh: KMM is really only a part of a model layer for an app like yours. It's not horrible, but it likely isn't the bees knees either for the iOS developers using it either. I'll drop you my contact info on slack, but oftentimes "generate some shared resources" is the easiest answer. You might be surprised how generally awful automatic translation turns out though. I got a lot of really iffy kotlin/lack of ability to understand stubs out of a couple generators. It was truly faster to just vanilla rewrite a large portion of the app rather than to bother. There was a good chunk of logic which assumed fairly specific iOS models of doing a lot of places in the last app. Once you remove all of those from an iOS app, there can often not be enough "data and web code" to make "a singular library" 100% worth the cost of keeping kotlin compiling in a swift project.