Thank you for clarification. As I anticipated the complexity of back-deplying is quite high. I want to narrow down the conversation to what seems critical to me: back-deploying fixes.
My goal is to push for an adoption of structured concurrency for at my company. I clearly see an overwhelming set of reasons for the adoption even without any features introduced since Swift 5.5. However because we have millions of daily users we just cannot make such an important technological decision lighly.
To assess risks we've made a production test (ran some structured concurrency code on background for 1% of users) and found a blocker (ticket and related post) for the adoption. I had hope that in Swift 5.6 the issue will be fixed and we would be able to resume adoption considerations. There are evidence that the issue was fixed in libswift_Concurrency.dylib 5.6. The bug is not reproducible on iOS 15.4 but still reproducible on prior iOS versions due to libswift_Concurrency.dylib 5.5.2 being embedded.
I assume many Swift engineers are in a similar situation on the adoption of structured concurrency. We cannot adopt structured concurrency for now because our crash rate is going to go over the crash rate budget. So the choice is to either:
-
keep asking for back-deployment of fixes
-
shelf the adoption of structured concurrency until the deployment target is raised to 15.4. Which could take many years.
I want to know if there is a hope to unlock the adoption or will we be limited to GCD+Combine for a while.