search

madsmtm / objc2

Bindings to Apple's frameworks in Rust
https://docs.rs/objc2/
MIT License
290 stars 35 forks source link

List of frameworks to translate #393

Open silvanshade opened 1 year ago

silvanshade commented 1 year ago

This is a list of frameworks I've been working through in the translation PRs.

This is basically just what shows up on the Apple website under system frameworks, technologies page, the SDK directories, etc.

Some of these are obsolete and probably not worth bothering with. Several have issues that will prevent translation until more work is done on the translator (e.g., the core foundation stuff). Some give errors related to seemingly not finding the header files (not sure why, but I've added notes about those below).

Some are only available in Swift and I guess this will only increase in the future. It would be nice if we could figure out a way to still include bindings for those but I suppose it might require building out some new tooling?

madsmtm commented 1 year ago

Some are only available in Swift and I guess this will only increase in the future. It would be nice if we could figure out a way to still include bindings for those but I suppose it might require building out some new tooling?

Indeed, that's basically doing the entirety of objc2, just in a new language (people have already begun in swift-rs, swift-bridge and swift-bindgen), and that will, well, take a lot of work.

In any case, I suspect it will be years before Apple releases a Swift-only frameworks that an application developer actually needs to use (SwiftUI is still very much in its early stages). So let's tackle that when the need arises!

silvanshade commented 1 year ago

In any case, I suspect it will be years before Apple releases a Swift-only frameworks that an application developer actually needs to use (SwiftUI is still very much in its early stages). So let's tackle that when the need arises!

I agree that it probably won't become mandatory for quite some time. Still, it's a little disappointing that some of the newer technologies will be unavailable.

I wonder how feasible it would be to write some sort of objective-c bridging modules for those few cases and then run the translator against that. It wouldn't be a fully automatic process but maybe worth experimenting with?

Another possibility would be to more seriously consider the approach you described in #345. I only looked at it briefly so far, but it seems that if we were to build against that implementation, we could take advantage of the clang module importer (for objective-C frameworks), on the one hand, but also be able to re-use most of the same infrastructure for importing swift modules, right? As I understand it, most of the work we would need to do would be to implement a new code generator that maps the swift module AST (whether it is synthesized from objective-C or directly from native swift) to our rust equivalent.

madsmtm commented 1 year ago

I wonder how feasible it would be to write some sort of objective-c bridging modules for those few cases and then run the translator against that. It wouldn't be a fully automatic process but maybe worth experimenting with?

You mean modules that use Swift's @objc attributes? + some generated headers? Or is there some mechanism for using Swift from inside Objective-C that I'm not aware of?

Another possibility would be to more seriously consider the approach you described in #345. I only looked at it briefly so far, but it seems that if we were to build against that implementation, we could take advantage of the clang module importer (for objective-C frameworks), on the one hand

I am seriously considering that approach, it's honestly the only sustainable option, header-translator is a hack that has to go one day.

be able to re-use most of the same infrastructure for importing swift modules, right?

Probably, and you do make a good point about it being a good starting point for it!

As I understand it, most of the work we would need to do would be to implement a new code generator that maps the swift module AST (whether it is synthesized from objective-C or directly from native swift) to our rust equivalent.

I honestly don't think that part will be too difficult, if we get the above-mentioned setup for it.

Rather, I worry that getting the ABI and calling convention right (which is still not done for objc2) will take a lot of time, or perhaps more aptly, mental bandwidth (there's a lot to learn!), especially if we need to handle generics.

Anyhow, sorry for my dismissiveness, I think I'm just focused on getting objc2 v0.3 done (I have been working on it for more than 18 months now, would be nice to actually finally release something useful into the hands of users) - this is also why I'm punting on #345, since it will take time that I would rather be focusing elsewhere.

So it's not that I don't want to work on/support Swift, it's just that I can neither allocate the time nor energy for it, nor promise that I will be able to, sorry about that :/

silvanshade commented 1 year ago

You mean modules that use Swift's @objc attributes? + some generated headers? Or is there some mechanism for using Swift from inside Objective-C that I'm not aware of?

Yeah, probably something like that. I'm not entirely certain how it would work out since I've barely used Swift, but it at least seems plausible that something like that could be done, at least on a smaller scale, and with enough effort. But that's something to worry about later I guess.

Anyhow, sorry for my dismissiveness, I think I'm just focused on getting objc2 v0.3 done (I have been working on it for more than 18 months now, would be nice to actually finally release something useful into the hands of users) - this is also why I'm punting on #345, since it will take time that I would rather be focusing elsewhere.

So it's not that I don't want to work on/support Swift, it's just that I can neither allocate the time nor energy for it, nor promise that I will be able to, sorry about that :/

Yeah, that's perfectly reasonable. I'm mostly just thinking out loud here as far as what it would take to get closer to a complete translation of these frameworks.

I agree that in the near term it's more important to focus on ironing out some of the current issues and working toward getting the next release out.

silvanshade commented 1 year ago

@madsmtm is it currently possible to run the translator for different platforms (e.g., iOS, tvOS, watchOS)? Some of these frameworks are only available on certain platforms and it would be nice to include them.

Also, what about Catalyst frameworks? It seems the header translator doesn't find these which I suspect is probably because they are in a different location. Looks like they are inSystem/iOSSupport/System/Library/Frameworks versus System/Library/Frameworks.

Maybe some command line options could be added to control this?

silvanshade commented 1 year ago

I also wonder if we may need to think of how to structure the modules differently to account for platform differences. For example, some of these frameworks are available for standard macOS development but also Catalyst. I'm not sure to what extent the header definitions are different but they are separate frameworks so that might be an issue.

madsmtm commented 1 year ago

This is the real reason why header-translator is not just a fork of bindgen: It is because I was hoping we'd be able to take the list of Stmt's generated by the different platforms, and then combine them with cfg statements, such that we could expose a really nice docs.rs output with working "only available on target_os = macos" notes.

Not sure about catalyst yet.

lachlansneff commented 1 year ago

Hi, I'm interested in using the Vision api here. Could y'all point me to some resources on how I could get that ball rolling?

madsmtm commented 1 year ago

The documentation for doing so is quite lacking, but the first steps for you would probably be taking a look at header-translator's readme, and then add the library to translation-config.toml and framework-includes.h.

Maybe you can also take some inspiration from the framework addition PRs that @silvanshade has contributed in the past.

Feel free to ask further questions, I'm also available on Matrix/Element as @madsmtm:matrix.org btw.

bes commented 6 months ago

UiKit support would be a dream come true ❤️

marcpabst commented 3 months ago

Hey, I'm interested in adding support for ARKit. Are there any problems I'd need to anticipate, given it's iOS-only?

madsmtm commented 3 months ago

Definitely problems, you can't do iOS-only frameworks yet, though I'm inching closer to it. Tentative timeline would be UIKit / support for other iOS frameworks around the start of March.

marcpabst commented 3 months ago

Oh, that would be nice! I'm currently using a wacky apple-sys/objc implementation which feels a bit brittle and takes ages to compile.

roniemartinez commented 1 month ago

I hope there is some progress with CoreServices (Launch Services), too.

At the moment, I am using icrate's NSWorkspace to check and set the default browser, however this API is not available in older versions of MacOS. For now, my alternative is to add and use the core_foundation crate for any version less than 12.

A large chunk of MacOS users are still on <12 (if the statistics are correct) so hopefully this can be added up in the queue.

madsmtm commented 1 month ago

Update on UIKit: I've put up https://github.com/madsmtm/objc2/pull/600, which I expect will be a bunch of trouble to get fully compiling, but mostly a bunch of tedious trouble, not a bunch of impossible-this-is-not-how-the-world-works trouble ;)

CC @simlay @jpedrick