Comment by mrsteveman1 | Hacker News Reader

Comment by mrsteveman1 | Hacker News Reader

Parent Full thread

> The last time I checked Rust didn't support .frameworks creation

From a purely "how do I get something I can link to" perspective, you can still build a cdylib and a header for it, Xcode will let you include the header in your Objective-C code or in the Swift bridging header, and then you can link to the cdylib and copy it into the "Frameworks" subdirectory in the bundle at build time. I've been doing that in an OS X app for several months and it works out very well.

> calling the main thread from Rust wasn't easy.

If you want to schedule code to run in the main queue/thread/runloop, that's an Apple-specific thing Rust wouldn't be aware of by default, but I did find a wrapper for libdispatch/GCD, and it seems to support calling things on the main queue which should do what you want.

https://crates.io/crates/dispatch

You can also have your app provide a C callback to the Rust code (even a Swift closure with captured variables, with some clever workarounds since you can't do that by default), and then in the callback you can schedule code to run on the main queue/thread if you want.

You can't use dynamic libraries on iOS because they fail iTunes Connect validation. The only dylibs it allows are the Swift standard library. You can, however, use clang to take a static library and throw it into anything you want (framework, dylib, executable).

It looks like you're right, Apple says you can't bundle dylibs outside of a Framework on iOS :\

What would be the difference though, why make the distinction?

> Dynamic libraries outside of a framework bundle, which typically have the file extension .dylib, are not supported on iOS, watchOS, or tvOS, except for the system Swift libraries provided by Xcode.

https://developer.apple.com/library/content/technotes/tn2435...

From my understanding, the limitation is purely because of how Apple designed iTunes Connect validation, and not for technical reasons.

That's not true at all. You can use dynamic libraries; Swift modules produce .framework packages, which are dynamically linked.

I meant dylib files. You can't ship those, but you can ship dynamically linked frameworks.

AFAIK the only difference between a dylib and a framework is the folder structure (and I guess the install path of the library). So in theory you could produce a cdylib, create a framework folder structure for it, and then use install_name_tool to update the install name appropriately.

That's what I thought, too, but I was reminded of the filetype field in the mach_header which has distinct MH_DYLIB and MH_BUNDLE values. fwiw, I don't think that difference means much for the loading process, but they are different.

Hmm. I just ran `otool -hv /System/Library/Frameworks/Foundation.framework/Foundation` and it says the "filetype" header has the value "DYLIB". It looks like MH_BUNDLE is actually for plugin bundles, not for frameworks.

Oh, I see! That makes sense. Preference bundles are type "BUNDLE" but frameworks are not. TIL.

Ah, I see. Thanks for the clarification.

If you can avoid using a dylib on iOS, I would do it. It effects startup performance time. Just make a static version and compile it into the binary?

I'm aware of long polling of file/socket and libdispatch.dispatch_source to update main threads from BG on iOS/Android. I'll have to try that out and find if it works.

>You can also have your app provide a C callback to the Rust code

That's exactly what I'm doing, however callbacks become cumbersome after a while, and I don't like that pattern. I need to do MVVM where the View is a thin iOS/Android layer, and the VM is in Rust. Right now there are significant hurdles to keep references from Swift to Rust and vice versa.

Reply on news.ycombinator.com