A long time ago, when I first started doing iOS development, I realized that I needed to work with SQLite databases a lot. Now, there might be other ways you can store data and manage information – but I come from a database background and so SQLite appealed to me and that’s what I went with.

I looked around for existing solutions and found a couple – this was way back in 2009 or so when iOS development was kind of still in its infancy and so there weren’t as many third-party libraries and frameworks around as there are now. While some of the solutions I found worked, they were just not simple enough for my taste. So I decided to write my own. Thus was born the original SQLiteDB.

The original SQLiteDB was written completely in Objective-C and it was simply a wrapper around the necessary API calls that needed to be made via the SQLite C API. There was nothing fancy about it and while it got the job done, it wasn’t very pretty 🙂 I continued to use SQLiteDB in various projects of mine but never thought of sharing the code with anybody else since I thought it was just too rough and dirty to be shared with others.

Then came Swift in 2014. I was totally caught up in the promise of Swift before even the first Apple presentation about Swift at WWDC 2014 was over 😉 I wanted to work with Swift and I was determined to get to work right then. I looked around for something meaty to do that used Swift and one of the first things to occur to me was to convert SQLiteDB to Swift. And thus was born SQLiteDB Swift, or as it is known today, simply SQLiteDB 🙂

I believe WWDC was at the very beginning of June, around June 2nd, in 2014. The first commit I see to GitHub for SQLiteDB is from the 13th of June. So I must have gotten started very early. I just don’t remember much about what happened during that period except that I was caught up in the joy of creating something totally new using a totally new programming language. I felt like an explorer discovering new lands and blazing my own trails. I had to figure out quite a bit of Swift functionality on my own since the documentation for making C API calls from Swift was a bit sparse at that point and there weren’t a lot of examples around showing how things worked. But I managed to get things working …

In the next few weeks and months, with each successive iteration of the Xcode betas, Swift changed and SQLiteDB changed along with it. I enjoyed making the changes and updating SQLiteDB to continue to work with every new iteration of Swift. I continued to use SQLiteDB in personal projects over the next year or so but development slowed down since I was happy with things as they were and I was busy with other things.

By about the next year, lots of new Swift libraries had appeared to use SQLite. There were much more complicated and elegant solutions than mine out there. And there were also alternatives to using SQLiteDB, like Realm. I was looking at Realm at this point and was not really interested in maintaining SQLiteDB any longer. So I thought I’d let the project die. In fact, I think I posted that the project will not be maintained any longer at one point.

However, after working with Realm for a while, I realized that it didn’t meet my personal requirements as much as SQLiteDB had. So I gave up on Realm. But I was reluctant to go back to SQLiteDB either because I thought that my time might be better spent coding new apps instead of trying to maintain a library that might not be the best possible code out there. I wanted the maintenance work on the library to be done by somebody else and for me to reap the fruits 😀 (I was going to discover that things aren’t that easy but read on …)

I tried most of the other SQLiteDB libraries available on GitHub for Swift. A lot of them were very beautifully coded and had some quite complex functionality. They were just brilliant in terms of the coding and the functionality. Unfortunately, I missed the simplicity of SQLiteDB 🙁 I wanted something where I didn’t need to delve through the code to figure out how the framework functioned. I wanted something where it was just a few lines of code to get going with SQLite.

So, I decided to revive SQLiteDB. But I wasn’t content to just go back to using the old code. I wanted to revamp things so that SQLiteDB would be even easier to use – I wanted to eliminate the standard boilerplate that I had had to write to manage add, edit, delete functionality when records were added to a table. It turned out that Swift made writing this new functionality a breeze and I was able to get the new changes in place pretty quickly. That was sometime around the end of 2015.

I’ve been using the new SQLiteDB with the new table handling functionality for about a year now and I’m very happy with it. I’m considering another revamp to SQLiteDB, this time to add in cloud functionality so that the same data can be stored locally or be accessed from a cloud database such as Apple’s CloudKit. Will I add it? Probably? But I don’t know when I will actually get around to it …

But what I’ve learnt in developing and using SQLiteDB (and here, I mean the Swift version, the Objective-C version was in uses for much longer but had a much less interesting life …) has been that I should develop my own components and libraries myself if I don’t find a good fit out there. Don’t use somebody else’s code just because you’re too lazy to write your own. You will probably spend way more time struggling with code that doesn’t quite do what you want it to do than if you’d just sat down and written the code you need in the first place 🙂 Plus, if the code is something that you can use over and over again, then the time saving are multiplied.

And that’s the story of SQLiteDB, at least so far …