GRDB.swift VS CoreStore

I'm using GRDB , you can use existing pre-populated sqlite DB file. https://github.com/groue/GRDB.swift/wiki/Performance .

Not quite exactly sure what you mean but if its a .sqlite3 file then you can use it with this easy to use library https://github.com/groue/GRDB.swift

The 3rd party library I use GRDB SwiftyUserDefaults Kingfisher SwiftDate Popovers

The other thing is that it could be an overkill for your app if you just need to basically "store an array of 100 objects". Then you could probably consider other solutions like SQLite (with wrappers like GRDB) or plain JSON files.

https://github.com/groue/GRDB.swift#readme https://github.com/groue/GRDB.swift/tree/master/Documentation https://swiftpackageindex.com/groue/grdb.swift/documentation/grdb/

https://github.com/groue/GRDB.swift/blob/master/Documentation/AssociationsBasics.md might be interesting to look at for how it handles relationships between entities.

I recently used GRDB.

Check the performance comparison page. GRDB comes with a convenient and ready-made support for Swift Codable that performs quite well. When needed, it is possible to write less convenient but optimized record types that add very little overhead to SQLite, and perform really well.

Hey all. So I just got done developing an app that does visitation tracking. Basically the user creates an account with email, name, password etc.. the info is then saved to a SQLite database (using GRDB) with a table named "User" and then injected into the next view controller and so on... I plan on allowing the user to store their account in icloud in the future.

It’s not from Apple, but there’s a framework called CoreStore which you might find easier to pick up initially.

Core Data (and CoreStore, which is backed by Core Data) is an object persistence system (so objects can survive between application sessions), which lets you work with the objects in a more database-like way. For example, you can ask for all the instances of a Person object which match a predicate like the pets relationship is not nil. You can think of it like a more advanced version of arrays and sets.

If you’re just starting out with Core Data, you may want to take a look at CoreStore. It’s an external dependency, but it does feel much more at home in Swift. Less of the constant optional unwrapping, for one.

CoreStore (though iCloud support is still in the works)

More complicated than that is Core Data. It’s extremely powerful, but pretty weird to use at first. Doesn’t feel very Swift-y (Check out CoreStore for a more Swift feel). This is great for hundreds or thousands of objects. You can retrieve objects which match a particular search predicate, objects can have relationships to one another (e.g, a manager object can have an employees relationship to multiple employee objects), which you can traverse a lot like normal objects-which-contain-objects. This is massive overkill for storing strings, but great for something like a Twitter or Reddit client.

All the issues in the article had been solved by CoreStore since Swift’s inception. Check it out

CoreStore works really well for pure Swift models: https://github.com/JohnEstropia/CoreStore/blob/develop/Playground_iOS.playground/Contents.swift

CoreData through CoreStore. Full disclosure: I’m the author of the lib

Source: I am the author of the CoreStore library. The faulting behavior of NSManagedObjects are what makes them incompatible with redux-type architecture (ex: SwiftUI) which is why CoreStore exposes an ObjectSnapshot as a struct wrapper layer for live objects.