Program crash caused by [initWithUUIDBytes] on macOS intel chip

[GenkiChiang]

I used the data_store_identifier function of wry on the macOS intel chip notebook to pass in the UUID error, and the error message showed that the error was thrown by objc2-foundation. I looked at this lib, and it was probably thrown by this line of code.

Since I use it on macOS with M chip, the program is running normally. intel and M chip macos version, installation dependence, software are the same.
Os：macOS 15.1 (24B83) 2.2 GHz 6core Intel Core i7

throw file:
https://github.com/madsmtm/objc2/blob/master/framework-crates/objc2-foundation/src/uuid.rs

throw message：
thread 'main' panicked at /Users/genki/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc2-foundation-0.2.2/src/uuid.rs:31:1: invalid message send to -[__NSConcreteUUID initWithUUIDBytes:]: expected argument at index 0 to have type code '*', but found '[16C]'

I don't think you should switch UUID by chip architecture
macos 10.8+This interface has not been changed
https://developer.apple.com/documentation/foundation/nsuuid/1417039-initwithuuidbytes

• (instancetype)initWithUUIDBytes:(const unsigned char *)bytes;
  `
  #[repr(transparent)]
  struct UuidBytes([u8; 16]);

unsafe impl RefEncode for UuidBytes {
// Encoding depends on Foundation version, we hack it for now.
const ENCODING_REF: Encoding = if cfg!(target_arch = "aarch64") {
Encoding::String
} else {
Encoding::Array(16, &u8::ENCODING)
};
}

`

some img

[madsmtm]

The issue is that while the signature of the function didn't ever change, the internal encoding did, and that's what I've been working around here :/. But you're completely right that the fix is bad, I'll make sure to fix it properly in the next release.

In the meantime, you can do:

[profile.dev.package.objc2]
debug-assertions = false

[GenkiChiang]

Thank you very much for your help and reply. Since I have only been in touch with rust for more than a week, I can only find where and why the error was reported. To run forked obj2 locally on macos, GNUstep cannot be installed and it is impossible to verify whether the code can be repaired. I'm sorry I'm not able to provide more repair help.

[madsmtm]

Don't worry, I know what the issue is. The fix I provided was for you to put in your top-level Cargo.toml. Does that make sense? ;)

Also, you shouldn't need GNUStep on macOS?