Christoph Wiesner
07/07/2022, 12:00 PMCodable
in iOS: currently nearly all models of our native iOS app implement that protocol and therefore shared KMM models cannot be used in those models (unless you manually write (de)serialization for that shared objects - which is a blocker for us) - seems like a known issue - but i wonder why there is not much more noise around that.
other issues he mentioned:
• Operator overloads do not translate to Swift
◦ e.g. cannot overload operators such as +
, -
, <
etc. (required for conformance to Comparable
for example)
• Cannot take advantage of other protocol conformances, e.g. inheriting from the protocol Sequence
gives a huge amount of functionality such as map
, flatMap
, forEach
etc.
• Integers are all represented as Int32
in Swift - annoying to do conversions to a regular Int
everywhere
• Cannot create non-final classes, meaning we cannot implement any class as Codable
or Strideable
(needed to allow us to loops over calendar dates in a calendar date range)
• Unable to have “Swifty” function names as it’s not possible to remove parameter names, and parameter labels have to be the same as the parameter names. i.e. we cannot have a function like func date(in timeZone: TimeZone) -> Date
would be great if someone can confirm this limitations or provide guidance on how to overcome those.Sam
07/07/2022, 3:03 PMChristoph Wiesner
07/07/2022, 3:13 PMCodable
heavily in their Swift classes.
if we now share a Time
KMM class - every (codable) Swift Entity which uses that Time
class would need to manually write serialization to support it beeing used as codable in the iOS world.
are you suggesting to remove Codable from iOS all along?tylerwilson
07/07/2022, 4:51 PMAlex Acosta
07/07/2022, 5:13 PM