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
Post not yet marked as solved
Same here, 2018 13'' MBP.., this is sad :(
Post not yet marked as solved
Same here on my 2018 MBP 13''
Post not yet marked as solved
Great, thanks! will play with that for sure!
Post not yet marked as solved
Yes.., still waiting since August 2019 for the approval/denial of kext signing request 😟 😟
Post not yet marked as solved
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!
Post not yet marked as solved
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.
Post not yet marked as solved
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!
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
Sorry, but I’m afraid you’re getting confused here, no offence. It’s just two different concepts. No asking obviously for “undeprecation,” just for support, as most of languages/APIs, if not all, does.In fact, there are A LOT of deprecated method/apis that keep working just fine, since it must! due to obvious compatibility reason, some even since 10.6. APIs are “forever”, or at least the serious ones (and Apple is) and unless you release a breaking change and/or end of support is announced, they must just work and be supported even when deprecated…. and this is not a breaking change since the method still exists/nor end of support has been announced. In fact, as I said above, the method was deprecated on Mojave and works perfectly fine with that version, and “almost” fine too in Catalina so.., yes, this is a bug to be fixed.
Post not yet marked as solved
Hi,Thanks, but sorry.., the method is “.menu”.., documentation is wrong (another thing to fix), but .h files are ok. Copying below:- (void)popUpStatusItemMenu:(NSMenu *)menu NS_DEPRECATED_MAC(10_0, 10_14, "Use the menu property instead");https://developer.apple.com/documentation/appkit/nsstatusitem/1535918-menu?language=objc…and I can confirm that using it the issue is not present, but that’s not the point here. In order to maintain compatibility (this has been just deprecated, we’re not talking here about a method that has been deprecated for years/removed support) so I think it should be fixed.
