Posts

Post not yet marked as solved
6 Replies
2.2k Views
Apple developer documentation - https://developer.apple.com/documentation/apple_silicon/implementing_drivers_system_extensions_and_kexts#3616855 says: If your hardware communicates entirely using standards-based protocols, you can ship a driver that matches your hardware to one of the built-in system drivers. Is this possible to do if macOS itself has the driver implemented as a DEXT? Particularly, I'm interested in providing support for an FTDI device with a custom product ID in my application. I've understood that macOS implements the FTDI driver as a DEXT (/System/Library/DriverExtensions/com.apple.DriverKit-AppleUSBFTDI.dext). In Catalina, it's possible to work around this problem by instructing the users to install FTDI's custom KEXT driver, but that doesn't work anymore in Big Sur because the KEXT is blocked there.
Posted
by spartan1.
Last updated
.
Post marked as solved
1 Replies
4.5k Views
Could someone with an M1 Mac test what output does uname -a give there? This information would be useful for SW trying to detect what kind of Mac it's being run on, and could be updated to the table here: https://en.wikipedia.org/wiki/Uname
Posted
by spartan1.
Last updated
.
Post marked as solved
4 Replies
2.8k Views
Hi, I'm trying to get our Electron app running on Apple Silicon Mac. Running a beta release of macOS Big Sur on our DTK machine, I reached the conclusion that just upgrading the Electron version our app is using to 11.0.0 would be sufficient to get the app running under Rosetta2. Today I updated the DTK to official Big Sur 11.0.1, and now the same (Intel) application built using Electron 11.0.0 refuses to start. The app icon has a "prohibition sign" on top of it, and when trying to launch it from command line, I get % open MyApp.app The application cannot be opened for an unexpected reason, error=Error Domain=NSOSStatusErrorDomain Code=-10661 "(null)" UserInfo={_LSLine=3665, _LSFunction=_LSOpenStuffCallLocal} Rebuilding the app changing only Electron version to 10.1.5 makes the "prohibition sign" go away and the app can be launched (although it doesn't work properly as Electron 10 has other Rosetta2 interoperability issues). Does anyone have any clue what's the issue here?
Posted
by spartan1.
Last updated
.
Post marked as solved
13 Replies
3.7k Views
We are seeing some failures every now and then in our notarization TeamCity job where the "altool --notarization-info" command is failing with exit code 239. I didn't find anything about this by googling, except that the Mozilla guys are seeing the same issue (https://bugzilla.mozilla.org/show_bug.cgi?id=1562412).What does exit code 239 mean and can we prevent it somehow?
Posted
by spartan1.
Last updated
.