Create compatibility with legacy iOS verisions

[JWIMaster]

Now, I'm sure, reading this, you're thinking "not possible, can't happen". However, I am the creator of a Swift backport that allows Swift 5.10.1 to run on all versions from iOS 6+. This includes opaque types. Yes, this functions exactly as you would expect. Now, of course, the only substantial feature that I cannot get working is concurrency. However, I do not think that means all hope is lost. GCD still exists, and there are numerous other ways of getting it working. Now, understandably, this does not seem to be a focus of this project. However, I think there is incredibly large potential in getting this to function. I think that this product would be of great value to those targeting older iOS versions, and, in my experience, there is actually quite a high demand for it in those spaces. If you or your co-workers would not like to implement it, perhaps a seperate branch that is made for legacy iOS would work? If anyone is interested, please do reply on this thread.

[Kyle-Ye]

I am the creator of a Swift backport that allows Swift 5.10.1 to run on all versions from iOS 6+.

That’s impressive work! Could you share a short technical explanation of how you achieved it?

Did you replace the system Swift runtime on jailbroken devices, or is it more similar to the backported Concurrency feature (iOS 15 → iOS 13) where functionality is restored by patching certain dylibs?

[JWIMaster]

I'll make a proper write-up, but no. There is no dylib replacement. I basically rewrote the toolchain, or at least, the parts of it that weren't compatible with iOS 6. Swift 2.3 already natively works with no modifications, so I realised there shouldn't have to be all that much work involved in porting it. I had to remove 1 or two foundation types (URLComponents, ubiquitous URL keys), and the major rewrite was the removal of Data Destructor Munmap and using the older, selector-based method of calling objc's allocWithZone function. After that, basically everything works, bar concurrency and the odd bug when using weak self, which, for some reaso,n calls atomic_store. It's very stable, easy to set up and works well. I see a lot of potential in porting projects like this to older iOS versions, as there should no longer be a language barrier. To my knowledge, you don't extensively use concurrency in a way that is strictly required, nor do you heavily rely on modern UIKit API's, a lot of which I have already backported as well.

[JWIMaster]

TLDR is that until iOS 12, Apple shipped the ENTIRE Swift runtime with the application itself. The dylibs are included at buildtime, and run off the Objective C runtime. Because of this, they were able to backport Swift to iOS 7. I realised that because iOS 7 and iOS 6 are similar, that in theory, Swift should run on iOS 6. And after patching it does.

[Kyle-Ye]

So if I understand correctly your patch is for OS where Swift runtime does not ships with the system. (eg. support Swift 5.10 Runtime like Opaque type in iOS 6 ~ iOS 11).

[JWIMaster]

That's basically correct yes. Currently, everything you can do in Swift 5.10.1 other than concurrency works on iOS 6-11, and everything you can do including Concurrency works iOS 13+. iOS 12 is a weird one because it has no opaque type support, and a lot of runtime features are iOS 13+, but maybe one day I will have a fix for that. As it stands, though, my patch is for the open source Swift Toolchain that anyone can install from Swift.org, and is used to build for all iOS versions 6-26. Xcode 13.4.1 is the final version that supports 32 bit iOS, so all packages have to conform to Swift tools 5.6 at a minimum. Other than that, so long as your code doesn't rely on concurrency too much or UIKit apis that are too modern, the sky's the limit. Hence my interest in this project. And yes, opaque types work on iOS 6-11 with my patch.

[Kyle-Ye]

Got it. So your idea is running OpenSwiftUI on older iOS version?

so long as your code doesn't rely on concurrency too much or UIKit apis that are too modern, the sky's the limit.

1. This project heavily rely on some private framework API and modern UIKit/AppKit API which is only available on latest OS. (We can get ride of most private API call. But some underlying CoreText and CoreUI stuff is still a pain to fix.)

2. There is actually no strong dependency for opaque type. We can manually remove all some code to their underlying type or use AnyView to erase them.

Currently there is no plan to support older iOS version for this project yet. If the project grows, we can revisit this and reopen it later.