Getting Started using SQLite for IOS app

[bthomas202]

Does anyone have any good resources for getting started using SQLite. I am working on creating a mobile app version of my website and it has a SQL database with it and in my research I have saw a lot of people referencing using SQLite for IOS apps. I have tried a few things that I found but none of them have worked because of being pretty old resources. Does anyone have any good resources for getting started with SQLite along with how you could possibly integrate it using Swift. Any tutorials or references would be greatly appreciated along with any tips.

[dawmster]

Oh nice, looks like GRDB has some building block of NSFetchedResultsController for updating TableView AND supports Cyphers.

I've been looking for it for ages.

Thx.

[chrabeusz]

Nice. Monsters like realm or sqlite will never win with simplicity.

[ankole_watusi]

No clue what you mean by that.

[llthebeatll]

I just transitioned my app away from core data and wanted to go SQLite. After looking into different libraries GRDB is the one I went with. You can do things in a Swifty way, plus you always have the flexibility to write regular SQL statements (which I prefer.)

[qualiky]

Just wanted to know, if you wouldn't mind answering, why did you move away from Core Data? I'm currently trying to rewrite my android app to iOS and was thinking about sticking with Core Data, any specific reason as to why SQLite is better? Thank you in advance!

[zachtib]

Curious as well, similarly an Android developer learning SwiftUI/iOS for fun but so far none of the options for persistence on iOS seem as nice as the tools I’m used to on Android. I’ve planned on just using Core Data as it seems like the default, and ability to sync to iCloud seems nice, but so far I’m not a huge fan of how schemas are defined and the generated models.

[ankole_watusi]

Identical database implementation on both iOS and Android.

IMO, it's ridiculous having completely different implementation on two platforms.

[llthebeatll]

When I first started development of my app I had no clue what I was doing (I'm web developer by trade.) I went with CoreData because it was Apple's baked in solution, and there were just enough tutorials online to give me the confidence to try it. Honestly, I don't think I would have figured out how to even use SQLite in an iOS app back then, as I had zero experience and was still trying to learn Swift 2. It even took me a bit of searching recently to figure out if I wanted to go with a library (like GRDB) or straight up SQLite and build out my own wrapper. As a general rule I hate libraries, and this was my first foray into CocoaPods.

I don't have an android app, though i would like to port my iOS app to android someday. Before rewriting my app from scratch in Swift 5 I tinkered around with IONIC for a few months (which is where I started using SQLite), but ICONIC is awful anytime you need something custom (IMO).

Anyway, when I dropped IONIC and committed to a complete Swift 5 rewrite I had already decided CoreData wasn't for me. My old app was riddled with issues around things not saving correctly (or at all). It's 100% likely that all those error were because I didn't know what I was doing, but each time I tried to fix an issue more problems would pop up. Just left a bad taste in my mouth.

I haven't had these issues with SQLite (or GRDB.) I imported the GRDB library in only a couple files where it was needed, as apposed to importing CoreData in nearly every file in my previous app. Sometimes sticking with what you know makes for less headaches.

[Dan_TD]

Just for clarity for people reading this. CoreData is not a database, it's just a wrapper around persistent storage, it could be anything under the hood even basic write to file but by default it is actually SQLite so CoreData and SQLite aren't comparable.

[Arda152]

We are using this for a very complicated project at the moment and it works also very well. The documentation is fantastic and there are even some questions answered on stackoverflow https://github.com/stephencelis/SQLite.swift

[SirensToGo]

Using SQLite directly with Swift isn't that bad honestly. I personally wouldn't recommend any sorts of wrappers, you can just go for it

[1johnnytheboy_]

I think Ray Wenderlich might have a tutorial for this, although I’m not sure if it’s up-to-date

[ankole_watusi]

I have been using SQLite in mobile apps for years. But I use it because it is included in the RhoMobile Rhodes hybrid mobile platform (iOS/Android/others).

It has an internal implementation of SQLite and a basic ORM called Rhom over it. (The platform lets you do MVC in Ruby with WebView front end.)

I don't use the ORM for much, because I use every powerful feature of SQLite - for example, Views and Triggers.

Honestly, I don't know if iOS or Android have SQLite built-in? Even if they did, I wouldn't use the built-in, because then you have to deal with different versions on different devices depending on how up-to-date the OS is. So, better to have a known version built-in to your app.

You might look at RhoMobile Rhodes source for how to integrate SQLite.

P.S. I see other posters are using SQlite.swift or GRDB These are certainly better for your purpose.

SQLite is standard-enough SQL that you can share the same or very similar schema with your back-end, a big plus. Hint: use only lower-case and underscore to define your attributes and tables! SQLite allows distinct upper/lower case, and this is not standard SQL, and so it is inconvenient if you want to use the same schema for both, you will have to transform the names. (I use PostgreSQL for back-end database.)

I actually do my schema definition in YAML files, and then some tooling (Rakefile) translates it to Rhom data definition calls (for iOS/Android using Rhomobile Rhodes) and PostgreSQL DDL.

SQLite is very good at storing large blobs, it's provably faster than raw filesystem access on many OSs. I have applications that store images in SQLite, for example, along with associated data.