iOS 18 support for the Observations struct is being dropped before release?

Using Swift
1

When I started looking into this new addition I was sure as hell it was back ported to iOS 18. Now the documentation claims it’s v26 only. For me that’s a pretty big blow as this is kind of the missing piece of the puzzle before going full in to Swift Concurrency.

2 Likes
2

This wasn't really able to be back ported since it is a type - there are fundamentals that are kinda missing that would allow it to be available to before the '26 releases.

2 Likes
3

swift-perception is a full backport of the Observable machinery, including Observations, as various Perception types. This includes OSes that predate Observable altogether, as well as SwiftUI and UIKit integration.

5 Likes
4

@Philippe_Hausler is back porting this something that could be reconsidered? It’s a pretty huge unblock for a lot of teams switching to concurrency and replacing older streaming libraries in their code - would be a big win for a lot of teams (ours included :smiley: ) if we could adopt a year earlier!

2 Likes
5

From just a quick experiment on my local machine… if I copy Observations.swift and Locking.swift from the Observation directory in swift I can import that code in a new package that deploys back to macOS 15. I can then build and run the Person example from SE-0475 and I don't see any crashes so far… but maybe there is something else lurking there that makes this unstable on macOS 15?

1 Like
6

The problem is not about the implementation but instead about the back porting of types themselves w.r.t. to ABI stability. Normally back deployed things are available to just be functions. Since this is a full type layout that metadata does not currently have any direct affordances in the language to make it available to anything beyond the newest release.

Personally I agree that the utility for folks to be able to use this before `26 aligned releases of swift is pretty impactful, however there are a lot of moving parts logistically that would need to be solved to back deploy the type itself.

Since it is open source you can copy the implementations as listed; so at least there is a caveat emptor version of a work-around... That is likely workable till I have done some feasibility research on how we could even approach this.

3 Likes
7

You can also give a try for OpenObservation in general usage of Observable feature if you are not care about SwiftUI.

Both OpenObservation and swift-perception provide full backport of the Observable machinery and the macros.

The key differentiator is OpenObservation's SPI access is to OpenSwiftUI. And when building with toolchain path set, OpenObservation will share the same thread local storage with Observation providing mix use or debugging Observation possibility. (See OpenObservation/Sources/OpenObservationCxx/ThreadLocal.cpp at 1dd8b16a539e3563e05b77749acf334a4857a6a7 · OpenSwiftUIProject/OpenObservation · GitHub)

While IMO swift-perception is more focus on developer ergonomics and provide more SwiftUI integrations. (eg. Perception.Bindable and WithPerceptionTracking in SwiftUI's body.)

OpenObservation does not provide such ability since those part is already included in OpenSwiftUI.

2 Likes
8

Thank you for all of your answers. I was planning for getting serious about migrating to Swift Concurrency after September because of a few reasons:

  • All devices that support iOS 17 also support iOS 18, so you can update your minimum version straight to 18 if your current minimum version is 16. (iPadOS support for 18 is dropped for two models)
  • viewWillLayoutSubviews() is now tracking@Observable in iOS 18, if you enable it
  • @Observable can now emit an AsyncSequence, turning it into a drop-in replacement for @Published

It’s really the last bit of the puzzle. swift-async-algorithms and all of the other concurrency related stuff goes back to iOS 15 if I remember correctly.

I can of course analyze how well swift-perceptionplugs this hole, but having two Packages as standard dependencies for anything I build, to fix things that in my opinion should be core functionality, reminds me of the JavaScript world.

I did use an external Package called Observations to test Swift Concurrency in an earlier beta of Xcode 26 that didn’t ship with Observations at all, and that just worked under iOS 18. AFAIK that was just a copy of the Swift source as well.

@Philippe_Hausler : any chance it could be rolled into an official Apple Package instead, like Async Algorithms? Or that would then conflict with the shipped implementation of Observations starting xOS 26?

I was really happy for a moment to see that things were getting back ported and I could actually use new API’s in production within months of seeing them in WWDC. I was also pushing hard internally for starting to migrate, so it’s a bit disappointing to say the least.

2 Likes
10

Sadly that would conflict, if I understand correctly, as you guessed. This is definitely a topic I'd be interested in how much it really impacts folks and gathering that feedback is quite important, because there is some level of precedent to back porting things... but that has a very high bar to meet since it involves a lot of bespoke work.

11

Are there any clues lurking in the support that was added to backport Span types? Or was that a lot of custom code that wouldn't help us much here to backport Observations?

2 Likes