Skip to content

Wow, is this a future replacement for SkipSQL? #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
stodevCoding opened this issue Nov 30, 2024 · 3 comments
Closed

Wow, is this a future replacement for SkipSQL? #1

stodevCoding opened this issue Nov 30, 2024 · 3 comments

Comments

@stodevCoding
Copy link

Currently evaluating Skip for a potential migration from a SwiftData-based application. As part of our POC, we're investigating critical architectural components that could be potential blockers.

We're planning a robust SQL architecture as a SwiftData alternative, but before moving forward with SkipSQL, we'd like to understand:

  1. Is swift-sqlite intended to be a future replacement for SkipSQL?
  2. If yes, is there an estimated timeline for a stable release?

This information would help us make the right architectural decisions for our database layer and evaluate Skip's viability for our use case.

Thanks for your amazing work 💛

@marcprux
Copy link
Contributor

marcprux commented Dec 3, 2024

Thanks for the positive words. We haven't written much about this project yet, but we did just publish a blog post on using native Swift in Android apps (https://skip.tools/blog/skip-native-tech-preview/), as well as documentation on the technology preview of the native toolchain (https://skip.tools/docs/native/).

In short, the difference between the two projects is:

  1. skip-sql is designed to be used with transpiled Swift, where the entire app's module stack is transpiled from Swift to Kotlin using the Skip toolchain. It utilizes skip-ffi to handle the interaction between the Kotlin and SQLite's C interface.
  2. swift-sqlite is a pure-Swift interface to SQLite, and doesn't know anything about Skip. But due to being cross-platform, it can be used by a Swift module that is compiled directly to Android (or Windows or Linux or iOS/macOS).

You might take a look at the Skip Notes sample application, whose model layer uses swift-sqlite to provide the persistence interface for the data that the app manages. It is under-documented at the moment, but you can get a sense of how the API is being used in the ViewModel.swift.

Let us know if you have any questions or would like to discuss any details. We are excited to see your excitement!

@qsd-faris
Copy link

@marcprux can we replace adding SQLCipher installed by Cocoapods with this library installed by SPM?

@marcprux
Copy link
Contributor

marcprux commented Mar 5, 2025

@marcprux can we replace adding SQLCipher installed by Cocoapods with this library installed by SPM?

It depends on what you intend it do with it. If you just want to use the low-level C API for sqlite, or are happy with our SQLiteDB Connection API, then yes: you can just use this library. It builds everything from source using pure SwiftPM.

But if you want to use it with another sqlite-dependent library like GRDB (which is work in progress: groue/GRDB.swift#1708), then you may need to do some additional integration work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants