Menial

Base 3.3.0 Released

Sun, 08 Mar 2026 09:00:00 +0000

Base now provides Quick Look previews for SQLite databases. When you’ve got a database selected in the Finder, pressing the spacebar will show a list of tables, views, triggers and indexes in that file.

I find this really useful when I’m working with multiple databases or just want to quickly check what’s in a file without opening it properly. The table and view items are expandable so you can see indexes and triggers belonging to each one.

All changes in this version:

New features

New Quick Look extension for previewing database schemas
Enable the Geopoly and RBU extensions for use

Changes and improvements

The page_size database option is now a dropdown instead of text field
Updated SQLite to v3.51.2

Fixed

The numpad enter key can now be used to execute queries
The selected row in the data browser jumps around less when editing data
Data browser table headers no longer overlap row numbers when scrolling
Table headers no longer get out-of-sync with columns when switching between tables
Fixed a crash which occurred when adding a filter in the data browser
Fixed a crash which occurred when removing certain columns in the table editor
Fixed overlapping text in SQL query results

You can download Base directly, get it on the Mac App Store or via Setapp.

Base 3.2.0 Released

Mon, 01 Dec 2025 07:00:00 +0000

Base 3.2 is now available for download.

This update contains mostly quality-of-life improvements, with improvements to the table schema editor, data browsing table and SQL autocompletion.

The full list of changes is as follows:

New features

The table schema editor has been simplified. Columns and table constraints are now presented in a single list with section titles dividing them. This more closely fits how tables are described in code. The buttons for adding/removing items now have text labels, making it easier to see what you’re changing.
You can now copy rows and cells from the data browser table from a right-click menu on the table
The data browser now has an “insert special” context menu for quickly inserting dates, UUIDs and NULL values
SQL autocompletions for SQLite functions has been expanded to cover all built-in functions
Added experimental options (opt-in from the settings window) for working with large tables:
- Disabling the counting of rows in a table
- Allow selecting which columns should be shown in the data browser

Changes and improvements

SQL autocomplete suggestions no longer automatically show when not needed (eg. after typing a semicolon or a complete keyword)
The sidebar now only shows database schema names when multiple non-empty databases are attached
The row editor preview column now resizes to fill available space

Fixed

The SQL editor no longer loses focus after executing a statement
Clicks in the space below text in the SQL editor now behave like other text views on macOS
Fixed the “Send to SQL” button not working
Database pragma values now update correctly after being changed
Tables containing columns with default value of a signed number are now displayed correctly
Fixed a UI misalignment in the autocomplete window

You can download Base directly, get it on the Mac App Store or via Setapp.

SQLite Dates

Mon, 17 Nov 2025 10:00:00 +0000

SQLite columns are flexibly-typed, you can put broadly anything in any column regardless of the declared type of that column. There also isn’t a specific type for dates or times. This means that when it comes to storing dates or times, we’ve got choices to make. I’ll go through the main options in this post.

To start with, we need to provide some context:

SQLite lets you put values of any type you want in a column¹
SQLite doesn’t have date- or time-specific column types
The date and time functions in SQLite work with TEXT, REAL and INTEGER values²

These three points might seem contradictory, since we’re saying on one hand that SQLite doesn’t care about types, but also that the date functions work only on certain types. That’s because the date functions have a few specific formats ("time values") that they can handle, so it’s less about the column types and more about the value formats.

The formats

ISO8601 (`TEXT`)	Julian day number (`REAL`)	Unix timestamp (`INTEGER`)
`-`	`-`	`-`

Dates as `TEXT`

If you want to handle dates as text, then you’ll need to format dates as ISO 8601 strings. The ISO standard describes quite a lot of options for formatting dates, but SQLite uses only a few of them. Thankfully it’s the ones I expect most people think of when ISO 8601 gets mentioned.

The full list of accepted formats is available on the SQLite website, but a few examples are:

Date and time: 2025-11-01T18:30:00.000
Date only: 2025-11-01
Time only: 18:30:00.000

These formats can also include a timezone specifier. Internally SQLite works with UTC, so when you use the date functions any dates with a timezone specified will be converted to UTC:

SELECT datetime('2025-11-01 18:30:00.000+09:00') AS utcValue;
-- Returns: '2025-11-01 09:30:00'

Dates as `REAL`

This one might sound odd to start with, but bear with it. You can store dates as Julian day numbers.

The Julian day number is the number of days since -4713-11-24 12:00:00³ and can include decimal places to cover units of less than a day. So it’s really just a timestamp, with the reference date set a long way in the past.

A few examples of Julian dates:

1^st January 2000 at 00:00 UTC: 2451544.5
1^st November 2025 at 18:30 UTC: 2460981.2708333335
The unix epoch date: 2440587.5

Dates as `INTEGER`

This one’s a bit more common: dates stored as unix time; the number of seconds since 1970-01-01 00:00:00 UTC.

SQLite can’t tell just from looking at a number whether it’s a Julian day number or unix timestamp and by default it assumes numbers are Julian days⁴. If you use unix time with the date functions you’ll need to tell the function by passing in an extra parameter:

SELECT datetime(1762021800, 'unixepoch');
-- Returns '2025-11-01 18:30:00'

Other formats

You can also store Julian day numbers as INTEGER values, or unix timestamps as decimals if you want. If you only need to store a specific day, not a time, an integer day number works just fine. If you want fractional seconds for a unix timestamp, you can store it as a REAL.

It’s also worth pointing out that you’re not limited to these formats for storage. You can represent dates and times in any way you want. You could choose to use the email date format (Tue, 01 Nov 2025 18:30:00 UTC) or perhaps Cocoa’s TimeInterval (the number of seconds since 1^st January 2001 as a decimal). These - and any others you might find - can be saved perfectly well in your tables.

If you do choose a different format though, the built-in date and time functions in SQLite won’t work with your data. This may or may not be a problem for you depending on how you use the database, but it’s important to consider when choosing a format.

Which to choose?

As usual, it depends.

You’ll want to consider things like:

How am I interacting with the database? Do I need people to be able to read dates by eye?
What systems will be using the database? What is their preferred serialisation format?
What precision do I need?
Do I care about storage space?

Generally my preference is to store dates as TEXT unless there is a good reason not to. I choose this because:

They’re human readable
They’re widely compatible with other tools
There’s little to no risk of getting them confused with other formats

There are disadvantages though:

Converting to/from strings may have performance costs
You use more storage⁵

Most of the time these drawbacks are not very significant to me, so I don’t worry about them.

Unless you’ve chosen to declare a table to be strictly typed ↩︎
See the SQLite documentation on data types ↩︎
You might notice an inconsistency here. The SQLite documentation says that the reference date is “noon in Greenwich on November 24, 4714 B.C.”, but datetime(0) returns -4713-11-24 12:00:00, which has a different year number. That’s because the proleptic Gregorian calendar doesn’t have a year zero, it jumps from 1BC to 1AD, while ISO8601 uses astronomical year numbering which does have a year zero. ↩︎
There is an auto modifier to date/time functions which will let SQLite try to auto-detect the date representation from an integer, based on its size. ↩︎
Sometimes quite a lot more. For the same date: 2025-11-01 18:30:00 is 19 bytes; 2460981.2708333335 is 8 bytes; 1762021800 is 4 bytes ↩︎

Rowids and Primary Keys

Mon, 20 Oct 2025 18:00:00 +0000

SQLite has the concept of a rowid. A special column with a unique integer identifier for each row. It’s present in most tables, but generally hidden from view. This post gives an overview of how rowids work and their relationship with primary keys.

All the SQL commands in this post can be followed along in sequence. You can either create a new database using Base or by using the sqlite3 command-line tool.

If you run the following SQL:

CREATE TABLE rowidExample (id INTEGER);

You’ll end up with a table containing only one visible column. But the rowid column is there too, just not shown by default. If we run these statements:

INSERT INTO rowidExample DEFAULT VALUES;
INSERT INTO rowidExample DEFAULT VALUES;
INSERT INTO rowidExample DEFAULT VALUES;
SELECT rowid, id FROM rowidExample;

You’ll get the following results:

rowid	id
1	NULL
2	NULL
3	NULL

At this point it might be tempting to think “Great! I don’t need to specify a primary key now, I’ve got this one anyway”. Suppress that thought. The rowid (mostly) isn’t for you or me. It’s for SQLite itself. If you rely on it as-is, you’ll run in to problems.

For example, rowids can change. If you run these statements:

DELETE FROM rowidExample WHERE rowid = 2;
VACUUM;
SELECT rowid, id FROM rowidExample;

You’ll get these results:

rowid	id
1	NULL
2	NULL

Which might seem odd, we just deleted the row with rowid 2 after all. But VACUUM can cause rowids to be changed¹.

So what do we do instead?

Make your own keys

You should always specify your own keys. If you need a unique reference for a row, then you’ll want to explicitly model that in your tables. A simple option is to add an integer primary key column, like this:

CREATE TABLE explicitPrimaryKey (id INTEGER PRIMARY KEY);

The natural follow-up is to try the same steps as before:

INSERT INTO explicitPrimaryKey DEFAULT VALUES;
INSERT INTO explicitPrimaryKey DEFAULT VALUES;
INSERT INTO explicitPrimaryKey DEFAULT VALUES;
SELECT rowid, id FROM explicitPrimaryKey;

rowid	id
1	1
2	2
3	3

This is mostly the same, except the rowid and id columns both have the same value. Taking the next step, we get:

DELETE FROM explicitPrimaryKey WHERE rowid = 2;
VACUUM;
SELECT rowid, id FROM explicitPrimaryKey;

rowid	id
1	1
3	3

Which is what we really wanted the first time! The rowids haven’t been changed by the VACUUM.

That’s because columns declared as INTEGER PRIMARY KEY become an alias for the rowid column. SQLite now knows that they shouldn’t be rearranged and leaves them alone.

Which is the “real” primary key?

That’s a fun question.

For you and me, creating and querying tables, the primary key is the one we declare. It might be a column with PRIMARY KEY as one of the constraints, or a PRIMARY KEY table constraint across multiple columns.

For the internals of SQLite though, the “real” primary key is the rowid. That’s the value that gets used in the internal data structures.

If you use a column declared as INTEGER PRIMARY KEY, then our “outside” primary key is an alias of the “internal” primary key. Most of the time, we don’t need to worry about that though².

What about `AUTOINCREMENT`?

For most cases, you don’t want or need it.

If you have an INTEGER PRIMARY KEY column, because it’s an alias for the rowid, SQLite will automatically provide a value for you if you don’t specify one. It’ll try to pick the next largest number in that column. If you’ve managed to use up to the maximum 64-bit integer value (9,223,372,036,854,775,807), it’ll pick numbers at random until it finds an unused one or gives up.

If you add the AUTOINCREMENT keyword to that column, the behaviour will change a bit. SQLite guarantees that values in this column will always be larger than existing values. If you insert the maximum integer value to this column, SQLite will not allow any more rows to be inserted in the table.

Other special or unusual things

Primary keys don’t have to always be integers. You can have all sorts:

-- A table of books, using the ISBN as the primary key
CREATE TABLE books (
    isbn TEXT PRIMARY KEY,
    title TEXT NOT NULL
);

-- A table matching students to enrolled courses.
-- The combination of studentId and courseId must be unique,
-- you can't have a student enrolling in any given course more than once.
CREATE TABLE enrollments (
    studentId INTEGER NOT NULL,
    courseId TEXT NOT NULL,
    enrollmentDate DATE,
    PRIMARY KEY (studentId, courseId)
);

It’s interesting to note that in these cases, the PRIMARY KEY is basically just a UNIQUE constraint. Because of this, SQLite allows NULL values unless the column is declared as NOT NULL. This isn’t standard SQL, but is a long-standing quirk of SQLite.

For example:

CREATE TABLE booksAllowingNull (
    isbn TEXT PRIMARY KEY,
    title TEXT,
    author TEXT
);
INSERT INTO booksAllowingNull VALUES (NULL, 'The Colour of Magic', 'Pratchett, T');
INSERT INTO booksAllowingNull VALUES (NULL, 'The Light Fantastic', 'Pratchett, T');

Will result in two rows being inserted into the table, both with a NULL value for isbn.

If we change this to:

CREATE TABLE booksWithoutNull (
    isbn TEXT PRIMARY KEY NOT NULL,
    title TEXT,
    author TEXT
);
INSERT INTO booksWithoutNull VALUES (NULL, 'The Colour of Magic', 'Pratchett, T');

The INSERT will fail, as we’d expected.

It’s worth noting that again, columns declared INTEGER PRIMARY KEY get special treatment and are automatically assumed to be NOT NULL even if you don’t specify it³.

Rowid aliases

You can refer to the rowid using the names rowid, _rowid_ or oid. But you can also create columns with those names. So for this table, the internal rowid value can’t be accessed from the outside:

CREATE TABLE rowidNames (rowid INTEGER, _rowid_ INTEGER, oid INTEGER);

I have no idea why anyone would choose do this, but it turns out you can!

`WITHOUT ROWID` tables

It is possible to declare a table as explicitly not having a rowid. This isn’t as common and deserves an article to itself. For now it’s enough to note that this is a thing that is possible. If you want to read more about this feature, there is an excellent description on the SQLite website.

References

The SQLite website has excellent, detailed information about:

Copying rows between tables with INSERT INTO table2 SELECT * FROM table1; won’t keep the same rowids either. ↩︎
You might sometimes care about this for performance reasons, since lookups made by rowid are usually faster than other primary key types. ↩︎
This automatic behaviour also happens for STRICT and WITHOUT ROWID tables. ↩︎

Base 3.1.0 Released

Mon, 06 Oct 2025 07:00:00 +0000

Base 3.1.0 is now available for download.

This update adopts the new Liquid Glass look on macOS 26 and contains a good selection of quality-of-life improvements to make using Base even nicer.

Because Base is now built for macOS 26, it adopts the new Liquid Glass design. This doesn’t radically change the appearance of the app - all the parts of the interface are still in roughly the same places. Many parts of the UI are a bit chunkier now, so to adapt to this the window size is slightly larger and the sidebar a bit wider by default.

The other changes and improvements are:

Updated SQLite to v3.50.4
Added a new button () which provides a way to clear any sorting or filtering options in the data browser
Adding a button to jump to a table in the database size inspector
Adding an option to always enable foreign keys when opening a database (defaults to off)
Adding an option to hide shadow tables (defaults to on)
Fixed a bug causing the add & remove filter buttons to disappear
Re-ordering filter predicates to put more commonly used ones at the top
When showing the table editor, the table name field is automatically selected
When importing or exporting finishes, the app will show a notification
Base will now sometimes, politely, ask for a review on the App Store

You can download Base directly, get it on the Mac App Store or via Setapp.

Retrospective on making Base 3

Mon, 29 Sep 2025 06:30:00 +0000

The first version of Base was released in late 2008. It grew into a v2 by early 2011 and kept going until the last feature release in 2020 (with a few bugfix releases after).

On the 4th July 2020, I started a new branch for Base v3.

Getting Started

In mid-2020, the codebase for Base was struggling a bit. It was mostly Objective-C (which I still love) with some tentative Swift adoption dotted here and there. Any individual unit of code wasn’t too bad, but the whole was a bit tangled and causing headaches for making larger changes.

So I decided a clean slate was needed.

I just know people will be wincing at that declaration. I do too now. Sometime in the last 20 years I had read Joel Spolsky’s blog post on how rewriting a product is the single worst strategic mistake a software company can make.

I didn’t think this really applied to me. Not for egotistical “I’m better than that” reasons, more because I didn’t think the situation was the same. Much of Spolsky’s post focuses on how reading code is more difficult than writing, on how teams need spend time figuring out how the code works. But that wouldn’t affect me, because I wrote all of it! I know why that weird edge case is there. I know what idiot (me) wrote that dodgy function.

With that in mind, I created a new app target in Xcode and made a start.

Mistakes I made

These are just the highlights. There were plenty of smaller ones that weren’t particularly notable and didn’t have much effect on the whole - except possibly in aggregate.

1. Rewriting functioning code

As we’ve already noted, I wrote the original code. I knew all the shortcuts and gnarly corners. Naturally I decided to fix all of them as I went along. The problem here turned out to be much simpler than you might expect: Time.

All of those shortcuts and gnarly corners had accumulated over 12 years. Yes, I knew why they were there and wouldn’t have to spend time rediscovering old problems, but I would still have to carefully preserve their behaviours in any new systems and ensure nothing was lost in translation. And that takes time.

2. Adopting SwiftUI too quickly

I decided to adopt SwiftUI in 2020. This was, in retrospect, optimistic at best.

SwiftUI was barely a year old, still evolving and changing with each OS release. What worked in one version would be tweaked in the next. UI that worked fine yesterday looked different today.

The learning curve was steep, and I was trying to build release-worthy software while simultaneously learning how to use the tools. And the new tools didn’t have all the features of the old way. And the tools changed between OS versions.

Over the course of building a feature I’d realise I was missing important functionality and have to back out huge chunks of work and switch back to AppKit¹.

Please don’t take this item as me blaming SwiftUI for the problems. Rather the problem was my not knowing when and when not to use it and ending up trying to force it into shapes it didn’t fit.

3. Aiming for perfection

Since this was a from-scratch rewrite, I wanted it to be done right². And I wasn’t happy with most of the progress. This led to frustratingly slow work and trying several times to get different parts right.

I’ve only recently come across a quote from Ira Glass on the taste-skill gap, describing a period of time where your skills haven’t caught up to your taste. And that’s totally where I was. I knew the app could be better, that was the reason for the rewrite! But I wasn’t moving on once it was better, because I felt it wasn’t better enough.

4. Taking the difficult path

More than once I had a choice to either accept an easy or quick solution with a compromise, or do it the hard way and try for a better result. Apparently my default is to choose the hard way - it requires active mental effort to take an easier, but “less ideal” route.

One example was the SQL editor. It’s a text view that needs syntax highlighting and autocomplete. There was an basic implementation in the existing app, which had reliability problems and did want an overhaul. There wasn’t a third party library that I could just drop in without customising, so I started making my own text view to do the job. Before long I was bogged down, trying to wrangle NSTextView to do my bidding, make the autocomplete work how it should and also keep working on the rest of the app. It never did end up the way I wanted.

This was far more work than using someone else’s existing control and customising it to my needs.

Stuff outside my control

2020 to 2025 has been an odd time to put it mildly. We’ve all seen a lot of changes. Some of those were disruptive and meant that I didn’t work on Base for longer stretches of time than I’d have liked. There’s very little I could have done to mitigate this, but it’s important to recognise that sometimes life just gets in the way of your plans.

Trying again

By 2023, almost exactly three years later, I had to acknowledge that I’d dug myself into a bit of a hole.

The original branch³, started in July 2020, had grown into something of a monster. Three years of off-and-on (mostly off) development, thousands of lines of new code, and still no useful product. The git history still contained a bunch of half finished features and experiments.

So after a bit of thinking, I started again. The git commit reads:

Add new Base3 target

I’m trying again. Again.
Back to basics this time. Try not to chase the new shiny.

What actually worked

A much simpler plan:

Translate the app, feature by feature, from Objective-C to Swift
Create Swift Packages for each feature and core components⁴
Rely on some third-party libraries

No sweeping architectural changes. No adopting of the latest frameworks. Just a methodical, mechanical translation of working code into a more modern language, with some tidying as we go.

Translating without actively rewriting

Translating from Objective-C to Swift improved matters quite a lot. Partly because Swift is more terse and so the code is more compact and readable. Partly because of the hundreds (if not thousands) of micro-improvements you pick up as part of the move.

Using plenty of packages

Swift Package Manager turned out to be really useful for this sort of thing for a few reasons:

It enforced better separation of concerns by stopping shortcuts. Code in another package isn’t as freely available to you, so you have to consider what you’re doing more carefully. Related: Adding a dependency to a package feels like a big decision and puts a psychological barrier in the way of potential bad habits.
It broke the process down into clearly definable steps. I could set a goal of migrating the table editor. Then, when it was done, there was a functioning table editor package and I could delete the original code. This was also incredibly helpful to help prevent myself from feeling overwhelmed.
It made testing much more routine. This could possibly come under point 1 above, but is worth pointing out explicitly. Testing isolated packages is just so much nicer than testing components within an entire app. I guess it’s not technically very different, but it feels different.

Third-party libraries

The key ones are GRDB and STTextView.

GRDB is an incredibly well made and popular SQLite toolkit. Base is only using a portion of what it can do and I’d like to write more about it in the future.

STTextView is a really great text editor with plenty of room for customisation. Trying to build my own - when libraries like this exist - is not justifiable.

Scheming

Base is distributed through this website, the Mac App Store and Setapp. Each comes with a different set of requirements for updating, licensing and distribution rules. The previous version of Base was developed before the App Store and Setapp were around. Each became a separate app target within Xcode, customised to build with slightly different files and settings.

This time, I have one target with three build schemes. Each has scheme has separate build configurations in .xcconfig files which link different libraries and apply different tweaks. It’s so much easier to reason about and maintain.

Some observations

The decision to start a rewrite again in 2023 was less hare-brained than the first time. This time I had a lot more pieces lined up for use. I was still working inside the same Xcode project, so that parts could easily be dragged from one app target to another for re-use. Most importantly, because it wasn’t so much a rewrite as a translation.

I did actually adopt some SwiftUI in places where it made sense. And (again) in a few places it didn’t. But this time I’d learned: If you’re trying to do something with SwiftUI and hitting problems that can’t be solved quickly, give up! Several times I saw a place where I thought it could save me time, only to hit problems. Each time I tossed the code and went back to AppKit.

What I learned

Spolsky was absolutely right and my circumstances weren’t as different as I thought⁵
Psychological traps are everywhere. When you know your own code intimately, you see all its flaws. The urge to fix everything can be distracting and almost overwhelming.
Code that works is valuable, even if it’s not pretty
I’m more easily distracted than I realised
I’m lucky that I don’t depend on the income from this project

None of this is new. Most of it has been industry dogma for years, yet we still fall into the same traps.

Base 3 eventually shipped. It took rather longer than I’d hoped.

The app is better for the rewrite - it’s faster, nicer to use, and has a few new features. Inside, it has better architecture and is more maintainable. People using it will only notice the first part, they can’t see inside - but I know.

Suggestions for others

Here I could try to lay down some rules - or at least guidelines - that I think others should follow when contemplating a rewrite of some software. To be honest, I don’t feel comfortable doing that.

If you’ve read this far, you can see the mistakes I made. You can tell yourself you’ll learn from them, or that you wouldn’t have made them in the first place. Or maybe you’ll be like I was and think that your circumstances are different. It may be worth taking a step back and checking whether that’s actually true.

Remember: If you can’t set a good example, you can at least be a horrible warning⁶.

Note that there’s nothing wrong with AppKit. Using it is not a defeat. It’s just that I should have been more judicious about where I didn’t use it. ↩︎
For my definition of “right”. Or at least better. ↩︎
The fact this branch had lived so long might be considered a red flag in and of itself. ↩︎
After reading a post by Simon B. Støvring. The post seems to be gone, but there’s a conference talk available ↩︎
I’d recommend the book How Big Things Get Done to pretty much anyone building anything. It specifically calls out people saying “but my project is different!”. With references and citations. It stings a bit. ↩︎
Quote by Catherine Aird. I always thought this came from Terry Pratchett, but when searching for a link I found the original. ↩︎

Base 3.0.2 Released

Sun, 31 Aug 2025 07:30:00 +0000

Base 3.0.2 is now available for download.

This is a bug-fixing release, containing the following changes:

From Base 3.0.1:

The last selected table and tab in a database is now remembered between launches
The database size inspector chart was missing the legend - it’s back now
When entering numbers with leading zeros in a TEXT column, the leading zeros are no longer removed

From Base 3.0.2:

The “show internal tables” option was being ignored - it is now respected and defaults to being switched off
Using the tab key to switch between editing table cells no longer causes the selected row to be changed
Whitespace is now ignored when checking license codes (direct-sale version only)

You can download Base directly, get it on the Mac App Store or via Setapp.

Base 3.0 Released

Sat, 16 Aug 2025 07:00:00 +0000

I'm incredibly happy to announce that Base 3.0 is now available for download.

The app has had a major overhaul to all areas while keeping a familiar UI.
Base 3 is faster, more capable and even nicer to use.

Highlights of this version include:

Working with multiple attached databases
Support for more SQLite features like:
- WITHOUT ROWID & STRICT tables
- Partial indexes (with WHERE clauses)
- Named table constraints
- Generated columns
Better syntax highlighting & autocomplete in the SQL editor
It’s faster at all operations, especially import & export

An overview of the application with screenshots is available on the product page.

Pricing and requirements

Base 3 is being distributed as a separate app to Base 2¹. It’s free to download with some features limited to those who purchase an unlock license.

Licenses are priced at £29.99 (or local equivalent) and can be purchased here.

People who are currently using Base 2 can continue to do so. It won’t auto-update to Base 3 and there will not be any more updates to Base 2.

Base 3 requires macOS 15 (Sequoia) or newer.

Except for people using Base via Setapp, which is subscription based. ↩︎

Base 2.5 Released

Thu, 02 Apr 2020 18:10:45 +0100

After a bit of a gap, I’m pleased to say a new update to Base is available to download.

The highlights include:

Modernising the UI a bit to bring it more in line with recent versions of macOS. It looks familiar, but feels less old fashioned.
Adding syntax highlighting themes. You can now have different text colours for light & dark modes which switch automatically.
Adding support for macOS Dark Mode throughout the app. No more eye glare!
All versions of Base now require macOS 10.14 (Mojave) and have enabled sandboxing

There’s other minor bugfixes in there too which sort out some UI glitches and misplaced buttons.

You can buy or download a trial version from the homepage. You can also buy Base from the Mac App Store or download from Setapp

Base 2.4.11 Released

Tue, 21 Mar 2017 20:03:00 +0000

Base 2.4.11 is now available to download for direct sale, Setapp and Mac App Store users.

This update fixes a bug causing Base to sometimes crash when re-opening a database on launch. It also updates to SQLite version 3.17.0.

Base 2.4.11 can be downloaded from the product page, Setapp or the Mac App Store.

As always, release notes are available and if you’ve found a bug or have a question, please do get in touch.

Base on Setapp

Wed, 25 Jan 2017 13:00:00 +0000

Base is now available on Setapp, a new service from MacPaw which gives you access to more than 50 great apps for $9.99 per month, with a month’s free trial to start.

When you subscribe to Setapp, you have unlimited access to a curated library of useful apps. There are no upgrade fees, no ads, and no in-app purchases. One fixed fee gets you all of it.

Go ahead and try Setapp. I think you’ll like it.

InkStamp - A rubber stamp sticker pack for iMessage

Tue, 13 Sep 2016 19:42:00 +0000

I’ve made something small and fun. A rubber stamp sticker pack for iOS 10!

It’s a collection of iMessage stickers in the style of rubber stamps. There are stamps for likes and dislikes, reactions, star ratings, and a bunch of other odds and ends.

Here’s a couple of images showing them in use:

The InkStamp sticker pack is a 99¢ (79p) download available from the App Store for iMessage.

Base 2.4.10 Released

Fri, 05 Jun 2015 07:53:00 +0000

Base 2.4.10 is now available to download for both direct sale and Mac App Store users. This update fixes some minor problems and updates to the latest version of SQLite.

Base 2.4.10 can be downloaded from the product page or from the Mac App Store.

As always, the full list of changes can be found in the release notes and if you’ve found a bug or have a question, please do get in touch.

Base 2.4.9 Released

Sat, 27 Sep 2014 09:45:00 +0000

Base 2.4.9 is now available to download for both direct sale and Mac App Store users. This is a bugfix release to prepare for OS X Yosemite.

Base 2.4.9 can be downloaded from the product page or from the Mac App Store.

As always, the full list of changes can be found in the release notes and if you’ve found a bug or have a question, please do get in touch.

Base Turns 5 Years Old

Sat, 16 Nov 2013 07:00:00 +0000

Five years ago today, Base 1.0 was released blinking into the internet. Since that day there have been 29 updates varying from minor patches to major upgrades.

There’s still a long way to go with this app. Development is still ongoing and I am looking forward to the next five years. I hope you will all join me.

To celebrate, Base is 50% off for the next three days. Until the end of 18^th November 2013 Base will be priced at £9.99 ($13.99 or regional equivalent). You can buy Base from the Mac App Store or from this website.

Thank you to all of you who have helped make Base what it is today and to those whose feedback, bug reports and suggestions are helping to make it even better in the future.

Base 2.4.8 Released

Sat, 02 Nov 2013 16:12:16 +0000

Base 2.4.8 is now available to download for those purchasing licenses via the web store. An update for Mac App Store users has been submitted and will hopefully be approved for sale quickly. While normally both versions will have updates released together, the bugs that are fixed in this version were annoying enough to warrant separate releases.

The main changes in this release are to disable smart quotes and smart dashes in the SQL editor. The SQLite version has also been updated to 3.8.1.

Base 2.4.8 can be downloaded from the product page or from the Mac App Store.

As always, the full list of changes can be found in the release notes and if you’ve found a bug or have a question, please do get in touch.

Base 2.4.7 Released

Fri, 18 Oct 2013 07:46:26 +0000

Base 2.4.7 is now available to download for both web and App Store users. This improves compatibility with Mac OS 10.9 Mavericks and files generated by iOS 7.

Base 2.4.7 can be downloaded from the product page or from the Mac App Store.

As always, the full list of changes can be found in the release notes and if you’ve found a bug or have a question, please do get in touch.

Base 2.4.6 Released

Sun, 21 Jul 2013 11:15:46 +0000

Base 2.4.6 is now available to download for both web and App Store users. This update fixes several display and export bugs.

Base 2.4.6 can be downloaded from the product page or from the Mac App Store.

As always, the full list of changes can be found in the release notes and if you’ve found a bug or have a question, please do get in touch.

Base 2.4.5 Released

Fri, 07 Jun 2013 17:41:16 +0000

Base 2.4.5 is now available to download for both web and App Store users. This update fixes a number of fiddly little bugs across most parts of the app. Notable changes include:

Tabbing between fields in the data browser now wraps from line to line
Failed CSV imports now report where and why failure occurred
Table list filtering no longer loses focus after each keystroke

Base 2.4.5 can be downloaded from the product page or from the Mac App Store.

As always, the full list of changes can be found in the release notes and if you’ve found a bug or have a question, please do get in touch.

Base 2.4.4 Released

Fri, 17 May 2013 08:09:30 +0000

Base 2.4.4 is now available to download for both web and App Store users. The changes in this version are small, but significant:

Sandboxing is now re-enabled for App Store customers. See this blog post for more details
A crash-on-launch bug has been fixed
An interface glitch where the SQL error notice could not be dismissed has been fixed.
Base now requires Mac OS 10.8 or newer to run

Base 2.4.4 can be downloaded from the product page or from the Mac App Store.

As always, the full list of changes can be found in the release notes and if you’ve found a bug or have a question, please do get in touch.

Menial

Base 3.3.0 Released

Base 3.2.0 Released

SQLite Dates

The formats

Dates as TEXT

Dates as REAL

Dates as INTEGER

Other formats

Which to choose?

Rowids and Primary Keys

Make your own keys

Which is the “real” primary key?

What about AUTOINCREMENT?

Other special or unusual things

Rowid aliases

WITHOUT ROWID tables

References

Base 3.1.0 Released

Retrospective on making Base 3

Getting Started

Mistakes I made

1. Rewriting functioning code

2. Adopting SwiftUI too quickly

3. Aiming for perfection

4. Taking the difficult path

Stuff outside my control

Trying again

What actually worked

Translating without actively rewriting

Using plenty of packages

Third-party libraries

Scheming

Some observations

What I learned

Suggestions for others

Base 3.0.2 Released

Base 3.0 Released

Pricing and requirements

Base 2.5 Released

Base 2.4.11 Released

Base on Setapp

InkStamp - A rubber stamp sticker pack for iMessage

Base 2.4.10 Released

Base 2.4.9 Released

Base Turns 5 Years Old

Base 2.4.8 Released

Base 2.4.7 Released

Base 2.4.6 Released

Base 2.4.5 Released

Base 2.4.4 Released

Dates as `TEXT`

Dates as `REAL`

Dates as `INTEGER`

What about `AUTOINCREMENT`?

`WITHOUT ROWID` tables