Supporting multiple versions of Mac OS

[programmingkidx]

MacDriver is very useful for making software on Mac OS. But I don't think we should limit ourselves to the latest versions of Mac OS. I ask that we provide support for multiple version of Mac OS.

How can we do this?
MacSchema already grabs the needed information:

"Platforms": [
      "iOS 2.0+",
      "macOS 10.0+",
      "Mac Catalyst 13.0+",
      "tvOS 9.0+",
      "watchOS 2.0+"
    ],

I suggest that a comment be added to each method that has a word like available, a colon, and the version number.
Example: // available: 10.0

A program can be made that reads the available field for all the functions in the source files and comment out those functions that exceed the supported Mac OS version.

Another possibility is to make a database of all methods in all Apple frameworks and have a program go thru all the .go files in the core, webkit, and appkit folders and comment out any functions that the database says came after the supported Mac OS version.

There is also the Go feature of using build tags. Code could be organized into file that represent Mac OS versions. All methods introduced in Mac OS 10.8 would go into a file called MacOS10_8.go. All methods introduced in Mac OS 10.14 would go in a file called MacOS10_14.go. We would then specify a version when building a program only files less than or equal to that version would be included in the build phase.

Please let me know if you have a better idea.

[progrium]

Assuming we can get to a point where all the bindings are generated, I was thinking we could just have separate packages.

[programmingkidx]

Do you mean like for Mac OS 10.8 compatibility I could import "MacOS10_8"?

[tmc]

We’re pretty close to full binding generation. I’d love to be able to import a/the macOS version. Happy to help plan out how we’d want to support that.

One factor at play is that there are some APIs that are marked beta so we may want to support some beta versioning scheme.

“macdriver/macos14/coreml”?
“macdriver/macos14beta/coreml”?

[progrium]

Yep, that sounds reasonable.

[progrium]

Just to document how I was planning to do this since I won't have time for it in the 0.5.0-preview, and is maybe not worth doing until 0.6.0:

Now that platforms have their own package directory (or at least, we're set up for that), I was thinking we could do versions with build tags. Of supported versions (currently defined by what we can test on GH Actions: 11, 12, 13), we'd chunk symbols into groups of either deprecated, common, 12, 13, or beta. Common would be symbols introduced before 12, 12 would be symbols before 13, beta would be everything else. Each group would get their own source files and build tags.

I think we'd want the default build to use the latest testable version (13). So you'd need to use build tags for 12, 11, beta, deprecated. I think it makes sense to not include deprecated in the default build. Although there are some APIs people still use (for example, our notifications example), some deprecated symbols are no longer defined so its safer to not include them. Especially since there's so many even without them. To validate this, currently and in the 0.5.0 preview I will leave out deprecated to see how things go.

[programmingkidx]

Before the switch to darwinkit, I was working on adding support for multiple version of Mac OS. It worked by having the user specify which version of Mac OS was wanted and not generating bindings for all methods and classes that came after this version. So basically this: go run ./gen/cmd --max_mac_os_version 10.8
This method would make source code far more portable because it wouldn't require changing any import statements.

If using build tags is still desired I ask that we also pay attention to the minor version. There are symbols that are new to say Mac OS 10.9 that are not in Mac OS 10.8.

[progrium]

The 10.x versions were more equivalent to todays major versions, they were on it for 20 years. 10.x is also no longer maintained. Otherwise, the latest minor version will be used for older major versions. At some point when the generation toolchain is developed enough, you'll be able to use it to generate for a more specific version yourself.