I realise you’ve hinted at it, but also think it’s worth explicitly pointing out that it’s more about the number of users writing than just user count. It can handle concurrent readers with little bother.

For those who’ve not seen it already, there’s a good guide on when to use SQLite here: https://sqlite.org/whentouse.html

Thanks! While it has been quite the career change, I am absolutely up for discussing both dairy farming, software development and their overlap. That’s where Base came from!

Thanks!

Auto-enabling foreign keys absolutely should be an option. I'll make a note of it.

I don't know about auto-loading extensions though. Will have a look. That might not mix well with the App Store rules and I'm reluctant to let the direct/app store versions drift apart in terms of features.

Thank you for answering. That's fair re. App Store rules. Feature flags FTW? :D

I was happy to see that FTS5 was always enabled as a compile-time option.

Sort of, yes. But mostly that I don't want the app to become the "everything to everyone" style of editor. I want it to remain tightly focused on the features that SQLite provides.

It's unlikely that I'll add a form builder or report generator to the app. I don't want it to grow until it can send email.

Thanks, I'll make a note of that. It's not a behaviour I've seen before.

I work a lot with syncing code for mobile apps, and use sqlite for local dbs on the app, which I guess is fairly standard. UUIDs make sync protocols much easier to write.

I see that this software is available for direct sale, the Mac App Store, and through Set App. What is your revenue breakdown from each if you don’t mind sharing?

It's a bit too soon to tell reliably, since I've shipped v3 as a new app and it hasn't settled down yet. For v2 it used to be 60% App Store and the remainder direct/Setapp. So far for v3 it is approximately 60% direct, 25% App Store and 15% Setapp.

This is a bit of a shift, but the numbers aren't really stable yet so it's hard to tell if it'll stay there.

Thanks for offering this app outside of the App Store too. Why don't you support older versions of macOS though? Does this app really rely on any new macOS APIs that it has to be built only for macOS 15+?

One of the things I found limiting in previous versions was supporting older versions of macOS. I’ve decided this time round to only try to support the latest and previous versions. Since the release of Tahoe is probably quite soon, I’m starting with just macOS 15 and will support that and macOS 26 to start.

From what I have observed, apps built for macOS Mojave (64-bits) or macOS Catalina all work fine on the latest versions of macOS. So I guess you must be hampered with App Store requirements ...

Apple frequently introduces new APIs that enable new functionality or make things easier and more maintainable. Also, testing software on older operating systems creates additional work. Unlike other OSes, macOS puts several limitations on running it under a VM, so in some cases you have to boot the OS up on real hardware. If you don't have 5 or 6 old Macs laying around this means setting up multi boot. There are also limitations on which versions the latest Xcode can target.

I understand. In this particular case, I am making an assumption that they aren't really using any new OS API's (this is, after all, a reasonably simple app) in which case they could just build and test on macOS Mojave or Catalina (the minimum OS version) and the latest macOS Whatever (the maximum OS version, for the APP store). As I highlighted, most older apps run without issue on newer macOS versions, and so that is a reasonable assumption to make and forego testing on all versions. Then, only if you get some bug report on some particular version, you can test for that ... (as you pointed out, the best approach - testing on all versions - can be very resource intensive, and this can be a practical middle-way approach for an independent developer).

Thank you for the support :)

To my (biased) mind the advantages are:

- It fits with the system better and behaves more like other macOS apps

- I believe Base has better create/alter table support

However Base doesn’t (currently) have support for SQLCipher.

Just to expand on the “behavior” bit, there’s a truckload of little things that native AppKit apps get you that nothing else will, not even other “native” toolkits like Qt. Things like Option-clicking a disclosure triangle in a nested list expanding/collapsing all children recursively, which one comes to use frequently and misses when absent. Foreign toolkits have spotty coverage of that kind of thing if they implement any at all.

As much as visually fitting in is important, behavior is perhaps bigger. Anybody who’s working on the Mac port of a cross platform toolkit would do well to replicate those little bits.

Wow! I just discovered option-click in Finder -- unrelated to sqlite :o . Thank you! thank you!

A lot of people use it as a step up from Excel.

I’ve got quite a few scientists using it for data analysis, a whole bunch of people importing sales data for querying.

A good number of folks never write any SQL and just use the GUI to sort/filter data.

I’ve also heard from people who use Base to design a schema and then export the SQL into their codebase.

EDIT: I should add that Base does nothing that that the command line tool can't. But it does offer more convenience, particularly for those who might be less comfortable writing SQL.

It's not required, but you can if you want :)

As others have said, this is written using AppKit and SwiftUI, which are only available for macOS.

This makes for a much nicer app for mac users, even if it does cut your potential audience.