Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement @Observable on iOS 17/macOS 14 #54

Open
mergesort opened this issue Jul 18, 2023 · 5 comments · May be fixed by #69
Open

Implement @Observable on iOS 17/macOS 14 #54

mergesort opened this issue Jul 18, 2023 · 5 comments · May be fixed by #69

Comments

@mergesort
Copy link
Owner

The Store is currently powered by the ObservableObject protocol. The latest operating systems add the new @Observable macro and Observation framework, which will make observing Store changes automatic.

This migration can provide significant performance benefits and simplification, but will add some complexity because Boutique backwards compatible to iOS 13.

This task may seem small but it will be a decent-size undertaking so there will be more considerations expanded upon as the process goes on.

@iamgp
Copy link

iamgp commented Sep 27, 2023

Hey, do you have any idea of when/if this will happen? What do you recommend in the meantime?

@mergesort
Copy link
Owner Author

mergesort commented Sep 28, 2023

That's honestly a great question @iamgp, but there are a couple of things standing in my way right now.

  1. Simple and straightforward, I need to do the work to convert Boutique to use Observable. I have a proof of concept locally, and it does seem to work fine. There are some changes I'm going to need to make to the library to ensure that there is as little impact on end users as possible. I want to make sure those changes are done right, tested, and of course documented since the shift from ObservableObject to Observable will require work for lots of people.

    There are new mental models and APIs for me to explain and for users to learn. The transition to the Observable APIs over the iOS 17 beta period wasn't completely smooth, and as importantly, I will have to change how I explain some of Boutique's APIs. (Or why there are now changes to how you use Boutique's APIs based on whether you use Observable or ObservableObject, for example prepending @ObservationIgnored to @Stored since you can't compose macros and property wrappers.)

  2. I need to ship my next app. This is the most practical reason I haven't shipped an Observable update to Boutique, I've been working hard every day to make my goal of shipping the app in November. Besides the time required to do this right I will be supporting iOS 16 in Plinky, so I'm still using ObservableObject.

  3. Since Observable is only supported on iOS 17+ and Boutique supports iOS 13-16 (and equivalent macOS versions) I need to figure out the best way to version Boutique. Complicating things is that an Observable Boutique would have to be tied to the Swift 5.9 compiler, and consulting with other open source maintainers they are struggling with similar questions about the best way to version their Observable and Macro related libraries to these constraints.

    I'm leaning towards maintaining two major versions, Boutique 2.x would be for iOS 13-16 and Boutique 3.x would be for iOS 17+. There are a few complexities related to this problem, including the fact I will likely have to do make changes in two versions any time I ship a change. I am incredibly open to suggestions and help with this point, since I'm yet to figure out the best approach.


I am very, very, welcome to accepting contributions, especially ones that meet the expectations I outlined above. (Working, tested, documented.) I wish I could provide a more concrete timetable but I'm a person with competing priorities. I can push up the Observable proof of concept on another branch to see if that spurs some external contributions, but if I'm being realistic about when to expect something I feel confident in on the main branch I would say without help late 2023 is a realistic estimate.

@iamgp
Copy link

iamgp commented Oct 8, 2023

That makes sense. Apologies if my initial question implied that you needed to do anything to a specific timeline.

I'd be happy to have a go at finishing your initial implementation if you could push up that branch. I'm coding Swift as a side-hobby so not fully confident that I am the best person but definitely want to help where I can.

FWIW, I think the new major version for iOS17 compatibility makes sense and is clear from a user perspective.

@mergesort
Copy link
Owner Author

Don’t worry about it @iamgp, I didn't take your comment at all that way. I'm just trying to do my best to develop a project that many people are using as transparently as I can.

I'll push up a different branch next week — I'm still on vacation and want to clean up the proof of concept since I took a few shortcuts before sharing it more widely.

With regards to versioning a friend gave me a good idea I hadn't thought of that may help me avoid versioning, vending two targets. This would let people selectively opt into Observable support by calling import ObservableBoutique (or some other name), without having to jump through hoops every time I want to push up a change that affects both libraries. 😄

@grdsdev
Copy link

grdsdev commented Jun 7, 2024

Hi, I suggest the usage of https://github.com/pointfreeco/swift-perception from Point-Free for supporting older OS versions, it is Observable backport down to iOS 13.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants