Fiexed on 11.3 beta 4, just verified. Great! :)

By the way, of course disabling SIP all works just fine..

Just Filed an issue with FB9029443

Same here, 2018 13'' MBP.., this is sad :(

Same here on my 2018 MBP 13''

Great, thanks! will play with that for sure!

Thanks! Just done it 🙂

Yes.., still waiting since August 2019 for the approval/denial of kext signing request 😟 😟

Yes, it was before :S.., missed that! In any case, I'm developing a new version of the app.., I guess I must distribute unsigned content outside the .app starting from now if I want to keep signing using my Dev ID. Any other way?Thanks!

Thanks!!That's what I though, but it's great you can confirm that, since some days ago read also some posts from people commenting the opposite and I was sure I heard what you mention at WWDC sessions.

Hi!"Thanks for the answer..., padhikari reported "As kexts will no longer be supported starting macOS 10.16..." how is that? For what I understood at WWDC 2019, only the type of kexts with corresponding support using System Extensions will be deprecated/unsupported, but those without it don't. There are al lot of kexts performing other tasks different than drivers and Network extensions that hasn't been supported yet.In example, those with low level access to commonly used features like MSR registers, used by Intel Power Gadget to read CPU stats, or even write configuration values to MSR registers..., so these type of kexts will be still supported as long as they don't still have support using System Extensions, isn't it?How to use in the future the kernel functions, like the included in proc_reg (rdmsr64) and so on? They can't be used right now using System Extensions... 😟 and there are a lot of software out there that need them in order to properly work.https://developer.apple.com/documentation/kernel/kernel_functions?language=objcThanks!

Hi! already did (first post), but wanted to share with all out there to be aware in case other apps are affected and a possible workaround/fix..., using the now recommended .menu property if able to make a new release.., or other one workaround (if any) without the need to release a new version.

Sorry, but wrong again! and 32 bits vs 64 it's a totally different thing!.., but in any case, as you said, they announced they'd unsupport that in the future.., and that hasn't happened yet with the method I'm talking about here.., so, it must/should be supported, since it's still included in the SDK and end of support for it hasn't been announced yet. Imagine a world where all deprecations meant incompatibilities.., you wouldn't be able to use many software if not constantly updated! that's why it's called "backward compatibility"..., and that's what I meant with "APIs are forever".Of course, they can do what the want with macOS, but they're serious about these kind of things and most (if not all) APIs/languages follow the same principle: 1st, deprecate it -> 2nd unsupport it -> 3rd remove it, and Apple hasn't been an exception for years. If you read their release notes, you know what I'm talking about..., an example hereCarbon component-based Audio Units are deprecated and support will be removed in a future release.https://developer.apple.com/documentation/macos_release_notes/macos_catalina_10_15_release_notes?language=objcThat method is still on phase one, since It hasn't been unsupported yet.. (or at least it's not docummented), and they always announce that..., so this is a bug, period. If they want to fix it or not is only up to them.