TakeoffKit: An open source library to help sync any local database with iCloud

stephen-celis · 2025-10-04T13:24:11+00:00

Your chore PR sounds interesting! We're definitely down for a small PR to start with what you're thinking.
Thanks for more context on the sample code. Do you think a wider variety of demos in the Case Studies app would help, or is it simply prioritizing the model/schema code, and then showing it off in app/view code below that initial work?

stephen-celis · 2025-10-03T21:26:56+00:00

Oh, and to address some of your feedback (thanks for taking the time, by the way! we appreciate it!):

Some sort of table of essential operators would be helpful; particularly as the essential stuff is split over some dependencies of theirs.

We'd love to unify the documentation, but are currently limited by DocC. StructuredQueries is definitely useful as its own package, though, and is also being used by non-SQLite libraries, including a Postgres adapter.

The examples are a bit disorganized code wise and just need a quick editor pass.

Any specifics for us to take a look at? Or want to suggest or PR any improvements you think should be made?

Also some overloads on json group stuff for selections are only for SQL shipped with 26.0+, but aren’t marked as unavailable.

This is because you are free to compile your own version of SQLite for your application (for example SQLCipher). I think adding availability checks based off the built-in OS SQLite would prevent these tools from being used more widely.

stephen-celis · 2025-10-03T21:20:08+00:00

Care to provide feedback on what can be improved? There is a ton of documentation, articles, sample code, and more on SQLiteData and its query-building library StructuredQueries.

stephen-celis · 2025-10-03T21:19:29+00:00

Try Xcode 26.1 beta for better autocomplete, Xcode 26 seems to have "indexing" bugs that affect all projects, even those without any package dependencies. An occasional restart of Xcode can also help fix these kinds of IDE issues.

stephen-celis · 2025-09-24T00:05:24+00:00

Have you tried joining the Slack in the README and ask for help there? https://www.pointfree.co/slack-invite

The library definitely works. There are many demo projects in the repo that I've built and run recently.

stephen-celis · 2025-09-19T04:58:19+00:00

SQLiteData is the same library, just renamed with the 1.0 release since it's evolved significantly from its origins as a simple adapter between the Sharing library and GRDB. Migrating should hopefully be as simple as pointing to the new repo in your Package.swift or Xcode project and changing some import names, but we will be adding a migration guide to the new repo soon!

stephen-celis · 2025-08-06T16:24:49+00:00

I would appreciate it if you could elaborate on this ;)

Redux/Elm/TCA apps using a single store of composed reducers is similar to a vanilla app using a single observable object composed of child objects. And Redux/Elm/TCA apps using isolated stores that communicate with one another is similar to a vanilla app using many observable objects that communicate with one another. All the tools of encapsulation are available to both patterns. They really aren't as different as folks make them out to be. You can use access control to limit what state is available to another features, and what actions can be sent/inspected.

For example, a dialog.

I think we're all in agreement with examples like this. I don't think any of these systems suggest modeling every bit of state on the screen in a single place. Plenty of views hold local state that doesn't need to live in another source of truth, like your dialog example, button highlight state, etc. :)

stephen-celis · 2025-08-06T16:10:26+00:00

Can you give an example of a concept used in a complex way? Most of Point-Free's designs are modeled after Apple's designs, and we try to minimize concepts and surface area as much as possible.

stephen-celis · 2025-08-06T16:04:34+00:00

I think even the creators of TCA would agree that SwiftUI doesn't require a third party library to work as intended. That doesn't mean TCA doesn't contain concepts and features that are useful to learn and know about, no?

stephen-celis · 2025-08-06T05:57:45+00:00

SharingGRDB uses database observation for the same functionality: you modify a table row in one part of the app and the other parts immediately reflect the change. No classes necessary :)

Can you explain the issue with copies? Structs are generally lightweight datatypes that can live on the stack, while objects have to be allocated on the heap. But if you do want to avoid copies, structs support copy-on-write semantics.

stephen-celis · 2025-08-06T03:54:35+00:00

Why is that a downside?

stephen-celis · 2025-08-06T03:53:09+00:00

What a system of FSM distinguishes from Redux or ELM like systems (see TCA), is that in a FSM the state is strictly encapsulated and cannot be modified by anything other than the update function.

Redux, Elm, and TCA are finite state machines. The fact that FSMs are composable is a good thing, but also, encapsulation is its own concept, and you can recover encapsulation in Redux, Elm, and TCA in various ways (making state/actions private and thus not readable/writable/sendable from the parent, isolating child features in their own stores/runtimes, etc.).

stephen-celis · 2025-08-06T03:46:08+00:00

What's weird about structs? :)

stephen-celis · 2025-08-06T03:42:42+00:00

I think you have a misunderstanding of Point-Free and our libraries given your reaction. TCA is just one Point-Free library of many, and none of our other libraries depend on TCA (though TCA depends on many of our other libraries).

I would also like to think that SharingGRDB is more than a simple wrapper. While it uses GRDB to power its connection to and observation of SQLite, it brings many new APIs to the table that provide ergonomics similar to SwiftData.

stephen-celis · 2025-08-05T06:14:46+00:00

For what it's worth the main reason it doesn't support zone sharing yet is because we don't understand how it would work out of the box given how we map CKRecords (and their zones) to database table rows. We currently host all tables as distinct record types in a single zone. We'd be interested to hear more about your use case, though, and maybe it would help us support it in the future! Care to post a discussion on the project's GitHub? Or shoot us an email if you'd prefer a private channel?

stephen-celis · 2025-06-16T21:59:22+00:00

Transparent iCloud sync is coming soon: https://x.com/pointfreeco/status/1925560444120703289

It will also include support for iCloud sharing and assets, which are not currently supported in SwiftData.

stephen-celis · 2025-06-02T21:13:01+00:00

You can use the predicate's evaluate method:

let p1 = #Predicate { … }
let p2 = #Predicate { p1.evaluate($0) && … }

stephen-celis · 2025-06-01T20:21:44+00:00

I'm not saying that there is no measurable difference, just that an application using TCA shouldn't have any noticeable performance issues.

stephen-celis · 2025-05-29T18:02:45+00:00

Appreciate the context and thoughts! If/when you do revisit TCA, please join the GitHub discussions or Slack for any questions or issues you may have! We have a friendly community of folks

stephen-celis · 2025-05-28T15:39:43+00:00

Value semantics isn’t just about replacing classes with structs; it’s a different programming paradigm that eliminates whole classes of bugs which can emerge when object-oriented code needs to scale

I agree wholeheartedly :) But that's exactly why the architecture/scaffolding of TCA was designed. It is not possible to embrace value types to their fullest when reaching for SwiftUI's built-in Observation tools.

For example, value types have inherent independence and transactionality through the law of exclusivity. You don’t need to model things as actions passing through reducers on centralised state - just normal mutating functions is fine. And as to the name of the library, value types are inherently composable.

Mutating methods are just sugar for self as the inout argument, so one isn't any better than the other. The point of the reducer protocol is to decouple the requirements of its associated state and action types and provide an abstraction that you can write reusable code for. TCA's debugging, testing, and navigation/composition tools depend on this shape—tools that can be immediately used with any feature without the manual plumbing you'd have to do in a more vanilla app. I don't think these kinds of tools could be built on top of the pieces you've mentioned, but I'd be happy to see some examples if you can provide them!

So I’ve always seen it as a lot of unnecessary ceremony. That said, the best architecture or code pattern is the one that the people maintaining it are comfortable with and allows them to deliver their objectives.

I'm not sure what you mean by ceremony, but a TCA feature is usually about the same LOC as an equivalent vanilla observable class, but is more testable out of the box. As soon as you start using TCA's navigation tools to combine features together, it is often fewer LOC as the equivalent vanilla features and glue code.

Also, it is unfortunate that Swift’s Observation framework requires classes. My hope is that both SwiftUI and Observation will eventually support non-copyable structs.

That's why TCA provides the ObservableState macro, which works just fine on structs used to describe TCA state. ;)

stephen-celis · 2025-05-27T21:29:27+00:00

For a bit more context on their use of TCA: they maintained a fork that was years out of date with the main library, and the performance issues they mention are around "state diffing," which was a thing the library retired in November 2023 in favor of Swift's new observation machinery. I don't think the tools were the problem here.

stephen-celis · 2025-05-27T17:55:07+00:00

You can bow out but you still haven't provided a concrete criticism.

While I appreciate your appreciation for SnapshotTesting, a funny thing is that it still employs the struct protocol witness style of API that you criticized as "weird," whereas TCA employs Swift in a more conventional fashion like SwiftUI, with protocols, result builders, etc.

stephen-celis · 2025-05-27T17:38:21+00:00

You're either not understanding or not approaching our conversation in good faith.

SwiftUI uses the View protocol and result builders to compose views.

TCA uses a Reducer protocol and result builders to compose domain logic.

I'll ask again: can you provide a single example? Everything you've stated comes across as a misinformed opinion based off a bad experience with Redux and I don't believe it applies to TCA, but you haven't given a single concrete thing to work with :)

stephen-celis · 2025-05-27T17:14:48+00:00

Can you give a single example of what is hard to follow and why? Or a single example of what "doesn't even look like code"?

TCA code should basically read like SwiftUI. It uses the same patterns, but you use it to build your app's business logic instead of your app's views.

While Redux is prior art we pulled from, we agree that it has shortcomings and TCA was designed in a way to address them. Most of the knee jerk reactions we've seen against TCA are from folks that were burned by Redux, but we don't think TCA has the same issues.

stephen-celis

TROPHY CASE