Possibility of SwiftData? (Fuse-Lite Framework)

[amirsaam]

Hello there,

Firstly, thanks for your awesome project!

I've a question though, is there any chance that Skip can have a framework for translating SwiftData models into similarly local database for the Android side (like SQLite?)?

It would be a key factor for people like me that targeted iOS17+ just because of SwiftData, such framework doesn't need to make replica of SwiftData in Android for sure, just to translate how SwiftData codes works for the counterpart framework in Android.

There are macros that you know for sure that really make the work easy to use SwiftData and to make same data available in the Android with same code would be an awesome and epic work.

I know it's not a small request, but I would be truly happy to finally be able to use Skip to bring my apps into Android.

Thanks.

[marcprux]

I am going to move this issue to a discussion and post my response there so it can get better visibility.

[amirsaam]

Thanks!

[marcprux]

Thanks for raising this. SwiftData, which is an evolution of the legacy Core Data framework, is closed-source and constrained to Apple platforms, so as you've likely noticed, you cannot use it directly with Skip.

You may also have noticed that we do have our own SkipSQL framework, which is much simpler than SwiftData/Core Data but does include a minimal ORM layer to map your Swift types to a SQLite schema. It doesn't have many of the nice affordances of SwiftData (like CloudKit integration), nor can it import Core Data models, but it should be sufficient for many local persistence needs, and it does work with both transpiled Skip Lite and compiled Skip Fuse projects. Numerous production Skip apps are currently using it.

One ongoing project of interest is the pointfreeco sqlite-data project, which is much closer in breadth and functionality to SwiftData. We would like to get this working at some point (which would only work for Skip Fuse projects), but it is blocked on the underlying GRDB package's inability to support Android due to that platform's lack of a built-in SQLite module (which necessitates using a source build of sqlite, as we do in SkipSQL). We still hold out hope for this, but it might require forking sqlite-data to use a custom source build of SQLite.

Another option is the swift-sqlcipher project (which we maintain). This is a combination source build of SQLite+SQLCipher along with a fork of the venerable SQLite.swift that uses it. It will only work in Skip Fuse mode, but is a bit more flexible and capable that SkipSQL.

Finally, I should mention that if your real goal is to provide cloud synchronization of persistent data and don't care much about sqlite compatibility, we do support Firebase's FireStore through the SkipFirebase framework and Supabase through the SkipSupabase framework.

So that's the landscape of database persistence at this point. There are likely other options (such as building something yourself atop swift-sqlcipher), and we would love to hear more from the community about what persistence needs they have and how we can help achieve them!

[amirsaam]

Hello again and thanks for your detailed explanation!

First of all I need to mention that the CloudKit is not what I seek at all but the import/export somehow is.
But after reading your explanation I should say the the SQLiteData project is very promising from my POV because of the similarities with SwiftData and being easy to migrate, and if you do the things needed to implement it, I would say it will be the go-to option while it reduces the os version requirement.

Other options have very different approaches with the native syntax, I would not personally like to go that path.

For further explanation, I was not seeking to have SwiftData available for Android, what I hoped to achieve was to have a translation layer package to read the code and make it available for Android in different database like SQLite but as you mentioned the available options and introducing the SQLite-Data, now I would more likely replace my SwiftData with it even in my current projects to only lower the iOS version requirement and hopefully someday, it get supported in Skip and bring my projects there.

[amirsaam]

@marcprux any thoughts?

[marcprux]

In response to:

what I hoped to achieve was to have a translation layer package to read the code and make it available for Android in different database like SQLite but as you mentioned the available options and introducing the SQLite-Data

I think your best bet for what is available right now would be SkipSQL. There isn't any mechanism to automatically translate your existing data models, but depending on how complex they are, a manual translation of the types to the SQLCodable protocol should be possible.

[amirsaam]

!

In response to:

what I hoped to achieve was to have a translation layer package to read the code and make it available for Android in different database like SQLite but as you mentioned the available options and introducing the SQLite-Data

I think your best bet for what is available right now would be SkipSQL. There isn't any mechanism to automatically translate your existing data models, but depending on how complex they are, a manual translation of the types to the SQLCodable protocol should be possible.

I think you misunderstood me, I didn't want an "automatic translator".
As you described the options in your 1st message, I got interested in the SQLiteData project and I meant for the "implement it" part that Skip support that package.
Because I really want to migrate my data to that project anyway, same structure same syntax (close) and support from iOS13.
Maybe I misunderstood your message?