I once had my bank close my account because of a mistake they made (I can provide the background but it’s just a facepalming story). That meant my Bank ID was closed down, too.
I asked for an appointment with the bank to resolve it but was told I can only get an appointment with Bank ID.
It was outrageous. Obviously none of the other services worked either. Luckily I still had a British and a German credit card that I used for payments (since I lived in both those countries before). In the end I opened an account with another bank and moved on. Although I did try, furiously, for two weeks to get my old bank to admit their mistake and rectify it. No chance. If they had admitted it it would’ve meant they would have broken financial regulation, and obviously you don’t admit to that if you don’t have to.
Bank ID is great when it works and brutal when it doesn’t.
I actually don’t have a better proposal for a system since it works quite well in most cases, but just wanted to share my bad experience on it too.
Unfortunately the solution presented in the article is locked to a closed cloud offering. I have nothing against those, Firebase for example is like that, but I dislike the fact that it’s hidden. “It’s just an sqlite extension”, oh and it syncs with our commercial cloud offering only.
Other vendors like Powersync and ElectricSQL have a similar offering but are upfront about it. And at least in Powersync’s case (don’t know about Electricsql) you can also run their offering yourself.
It's kind of hard for me to think of a devtool as local-first or not, since the actual definition of local-first [1] talks about end-user software, not devtools.
So the question is whether it's possible to build software that adheres to the local-first principles using sqlite-sync.
edit: I'm aware people are using the term "local-first" very loosely, so perhaps my reply here is a bit off-topic
p.s. yes you can self-host ElectricSQL
p.p.s. I really need to keep my list of "sqlite sync" things updated: I have SQLSync [2], SQLiteSync [3] and now SQLite-Sync [4]. Simple!
I remember seeing tons of mockups for how KDE 4 should look like. One was absolutely stunning but I can’t find it anymore. I remember a mostly flat theme with the idea that an app’s settings could be on the backside of a window. The dock was also brilliantly made.
Oh gosh I wish I could find those old designs again. Unfortunately they didn’t go for it and went with tons of silvery gradients instead.
I'm not a fan of Liquid Glass at all, but I just tried KDE again and it's certainly not there yet. Breeze has a ton of weird design decisions, rounded corners in things like list selections that don't work, and even basic understanding for padding and fonts still seems lacking in KDE.
That being said, KDE is very usable. I just wouldn't claim that it looks more professional than MacOS. I'd love for that to be the case but it just isn't.
> but I just tried KDE again and it's certainly not there yet.
I love KDE but t's getting close to being 30 years old.
"Not there yet" can probably be completed with "and will never be there unless a major revolution happens and even in that case, it's possible the outcome of that revolution will take them farther, not closer, to that goal".
You no longer need inner city parking, and people will be more willing to jump on public transport to skip traffic because you are not bound by the location of your own car anyway.
You think taxi companies are paying for enough parking spaces to store most of their fleet at once? A lot of those cars are stored on the street in front of the house of the driver.
Also, the problem of storing something like 10k taxis pales in comparison to storing 100k+ cars. Some large cities have millions of cars. When was the last time you drove to a stadium concert or ball game? It takes hours to get something like 30k cars in and out of those parking lots when everyone is trying to use the same roads at the same time. It's absolute gridlock.
So to implement anything like what you're talking about you'd need a network of garages and lots in the periphery of a large city, and the road infrastructure that can handle 100k cars driving from outside the city to your home all in time to whisk you away on your morning commute.
For that kind of civic planning & engineering complexity you could just build public transportation based on trains, light rail and busses.
For now, their Nashville test cars seem to be stored in a lot that's basically unused otherwise (I'm not even sure what building it belongs to). I drive by it occasionally. It's not the cheapest part of town, but it's probably pretty affordable.
Yeah, agree the UI is not great, but after using it for a week I feel it's actually... fine. Probably because I use a lot of third-party apps who don't use the new design.
Mojo is a terrible language and its main feature (GPU acceleration through Mojo max) is closed source and requires a commercial license to be purchased.
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).
I didnt know there are dozens of us! When I saw the lack of native support i decided to use binary blobs. I mean, why waste many bytes if few bytes do trick? In the SQLite studio app im using its garbled and annoying to browse.
Too bad this is mac only. I mean, im a mac user (among other things) but i don't want to depend on platform specific tooling.
See, I would be terrified of doing that because different RDBMSs and languages store and sort UUIDs differently. A UUID is not just a number. It's a structured data format.
Both MariaDB and SQL Server have dedicated data types for UUIDs, and they sort in an unexpected order if you're unfamiliar with the structure of a UUID or the endianness of certain portions of it. Oracle assumes it's going to be binary, but the generating function SYS_GUID() has some endianness issues you can run into. Meanwhile, PostgreSQL kist sorts them like a string!
Similarly, if you're using .Net to generate a native GUID type and passing that through your RDBMS provider, it may arrive and be stored differently due to that endianness problem.
Expecting that every SQLite database is going to be storing UUIDs in an identical manner seems insane to me.
It's the fact that, as the Base author, you don't really know how a given application might present a 16-byte binary version of a UUID to the database. If you don't know that, how can you reverse it to display the correct string representation? There are complications with byte groups potentially being in different places, and even the potential of mixed byte ordering.
How can Base make a 16-byte binary format that display both a GUID stored from a .Net application from person A, and also a UUID from a Python application from person B, and have the string representation be accurate in both cases? I don't think you can.
Off the top of my head, I can think of three different ways to store it in a single field: Big endian binary, little endian binary, or text. (Serious questions: Are there reasonable alternatives? Are people actually storing single UUID values across multiple DB columns?) That seems pretty simple for Base to add a display option... or add some "if-then" smell tests (shortly followed by an AI/ML cloud add-on subscription!).
I asked for an appointment with the bank to resolve it but was told I can only get an appointment with Bank ID.
It was outrageous. Obviously none of the other services worked either. Luckily I still had a British and a German credit card that I used for payments (since I lived in both those countries before). In the end I opened an account with another bank and moved on. Although I did try, furiously, for two weeks to get my old bank to admit their mistake and rectify it. No chance. If they had admitted it it would’ve meant they would have broken financial regulation, and obviously you don’t admit to that if you don’t have to.
Bank ID is great when it works and brutal when it doesn’t.
I actually don’t have a better proposal for a system since it works quite well in most cases, but just wanted to share my bad experience on it too.
reply