Hey all. We just released version 0.2.0 of the Composable Architecture, which comes with a new micro library that introduces the Composable Architecture to Core Location. We've included a demo that powers iOS and macOS applications if you'd like to get a feel for things.

Please let us know if you have any questions or feedback!


Hi, @stephencelis

First of all, you guys are doing an outstanding job for the community. And this mini library will greatly benefit everyone. Thank you :pray:

I do have a question. I’m sure you guys have considered this, but did you feel at any time that this library could be released outside of TCA?

Take for instance, swift-case-paths. I was really happy to see it being moved out of TCA and added as a dependency. Now, for swift-case-paths it makes sense to live as a dependency, you need it to complement Swift and enhance TCA.

Contrasting with CoreLocation, only a small subset of users would use it in comparison to the thousand of developers that are already full on developing with it (myself included).

Let’s say someone would like to implement support for some FileProvider, an Image Picker or a Document Picker for the iCloud drive, Siri support, or some other framework/api, would these fit in TCA?

One thing that comes to mind is RxSwift, where there is a community driven account for projects that enhance RxSwift’s experience. The ComposableCoreLocaliton could serve as a great jump start for something like this I believe.

Unless CoreLocation is a really specific use case that really needs to be in TCA, and I’m just not seeing it. I may be way of here.

Anyways, what are your thoughts on this?

Thank you again for the all great contributions you guys are making, enabling everyone to write better apps!

TCA in the hands of a junior developer would make an experienced developer from a couple years back really sweat to keep up ahah :rofl::face_with_hand_over_mouth::face_with_hand_over_mouth::face_with_hand_over_mouth:

1 Like

This is actually a great example of where an overlay framework would make sense.

1 Like

Hi Tarja, it's a good question and something we've talked about.

We are open to someday splitting these supporting libraries out into their own repos, but for now we are not for a few reasons:

  • It can be a real pain to put support libraries in a separate repo. It means every time we bump a version of TCA (which we have already done 7 times) we would have to go bump the versions for all the support libraries.
  • Although the code is in the TCA repo it isn't compiled unless it is depended upon. The only cost is downloading the code, which is just a few kilobytes.
  • These support libraries will only be for Apple specific frameworks that come for free on Apple platforms, and therefore won't have any additional dependencies themselves. If someone wanted to make a TCA-friendly version of a 3rd party library, then we'd suggest a composable-ABC repo be made for that.
  • We'd like the experience of using TCA to be comparable to the experience of building for Apple's platforms. At anytime you can just do import CoreLocation, or import CoreMotion, etc. and you get all that functionality. We'd like to have the equivalent of import ComposableCoreMotion available to you immediately if you decide you need it.

We think that for any framework ABC that Apple has we may potentially want the corresponding ComposableABC version of it that implements all/most/some of its functionality in a TCA-friendly style (most people ask us for import ComposableCoreData :joy:). Most of the time it's just simple wrapper types exposing the API endpoints in Effects, and so the code is super simple. For example, ComposableArchitecture is really just one big struct, a value of the struct .live, and a function on the struct .mock.

Often times these little wrapper structs are so easy to make that maybe it doesn't even needed to be vended by us. For example, the location manager demo has a LocalSearchClient struct for wrapping the functionality of the MKLocalSearch API. It's so simple that anyone could implement this themselves. The CLLocationManager API is quite a different beast, and so we would like to provide a correct version of it a single time for people to use.

Does that answer your questions?


Yeah, that would be awesome!

It certainly does, thank you for sharing your reasoning :slightly_smiling_face: