I don't know what you are reading, but crash reports are never symbolicated. They might be if it crashes while you are running in debug mode. But crashes from ad-hoc customer delivery, like this is, are not symbolicated. I recommend the MacSymbolicator app: github.com/inket/MacSymbolicatorIt will automatically search Xcode for the matting debug files.Your app isn't going to crash because you "violate MVC". I think all apps do that. It is only a theoretical architecture. The App Store is not a testing service. You need to test your app before sending it to them. Ideally, test it in a pristing virtual machine. Don't bother testing on your development machine. Always archive the apps and do a "development" distribution. That will give you a release build just like what the App Reviewer sees. When that crashes, you will get a crash report that you can symbolicate and find the bug.

What is the usual bundling for the app store? I know lots of iOS developers do funky thing with something called "Application Loader". What is a "setup app"? I just do Organizer > select archive > Distribute App > App Store Connect.

OK. I get it. Maybe you can just call the R executable instead.

Sorry. That was either autocorrect or a typo. I meant "VM". Do not attempt to install any system modification, of any kind, on your development machine. That will scramble the system really nicely. And if you've got SIP disabled, then you can do an even more thorough job of scrambling.Wherever you test in the future, you can only use systemextensionctl on a live, running system with SIP disabled.

If you debug your code and break on one of those lines you will be able to see what class those pointers really are. I'm sure it is not an Xcode bug.

Shouldn't you be accessing the property via "self."? There must be something else going on in the code you haven't shown.

Those cross-platform build tools are a nightmare to use. This is not the project you want to start learning Xcode with. You will need to be a real expert with Xcode to use this.PS: I went to look up QML to see what that was and it is Qt. Qt is just a train wreck of a project. Avoid it at all costs.

You may be able to rebuild the R dylib from scratch, and then manually construct a proper framework. This is very easy to do. Sometimes these open source packages have their Mac versions build by that one guy who had a Mac in 2003. Ever since then they rebuild using either a Linux cross-compiler or an VM running on Linux.R is a GPL project, in case you didn't already know.

You have to use Recovery Mode to turn off SIP. Then, after rebooting normally, you can use systemextenionsctl to remove the system extension. Don't forget to go back into Recovery Mode and re-enable SIP.A Time Machine backup should only take a couple of minutes. You may have more serious problems. In the future, you should test things like system extensions in a VPN that can easily be reset to a factory-fresh configuration. You will still need another machine for doing live testing. If you can't afford multiple machines, find some other kind of software to develop.

Ideally, you would just embed such frameworks inside your app. If you are developing a framework along with an app, you can configure an Xcode workspace that contains both the app and the framework. Xcode will know how to properly sync them together. The framework project and the app project need to by side-by-side. If you are just trying to deploy a project, you would create an installer package. When you install it, as root, it will be able to write to /Library/Frameworks.

But what if the user wants to use one of those popular "app zapper" or "clean up" tools? I realize there are two classes of users. Many users are unaware of the existence of kernel extensions, system extensions, launch daemons, etc. When they want to uninstall software, they drag an app to the trash. This API serves that class of users. But there are many other users who have a bit more knowledge. They know about some of these "detrius" files, but they don't know what they do or how to properly shut them down and remove them. They use a number of popular utilities that search the system for any files whose name or metadata matches a bundle ID. Some of these files are actually created and manged by the operating system, but they don't know or care about that. They then delete all those files using whatever means the tool uses. That is probably not going to be the Finder. This API harms those users.In a few cases, developers themselves don't know about any of this. One popular app that was one of the first to use system extensions also uses a custom uninstaller that does not properly delete its system extension. Another popular app doesn't include an uninstaller at all. Its web site tells user to drag the app to the trash, ignoring the launchd tasks. I met a developer from this company at a conference once and specifically asked him about this problem. He was aware of the problem, but simply didn't care. These are popular apps that are more likely to be used by that first class of users. This API harms those users.I recognize that the first group of users are much more pleasant to deal with than the second. But all customers are vulnerable to developers of tools that either delete wide swaths of files from other developers or don't even delete their own files. Many users simply don't have the knowledge necessary to exercise this control. This is a problem that I see every day.

The only libpd I can find is the Pure Data embedable audio synthesis library. But that is BSD, not GPL. See: github.com/libpd/libpd/blob/master/LICENSE.txt

The only libpd I can find is the Pure Data embedable audio synthesis library. But that is BSD, not GPL. See: github.com/libpd/libpd/blob/master/LICENSE.txt

What is the IOService utility app? I generally use "ioreg -l" and save the output to a file. Then I look for the devices I want. When I find the right one, I locate the most convenient ancestor or descendent to search for via IOServiceGetMatchingServices. When I find the object I want, I use IORegistryEntryCreateCFProperties to get its properties. I have a wrapper class that automatically walks up the device tree searching for a requested key.In the ioreg output, I see keys like "USB Product Name" and "USB Vendor Name". Is that what you are looking for?

You must use the Finder to delete the container app. Supposedly, systemextensionsctl will be updated one day so that it doesn't require SIP disabled. It is possible there is some system task scheduled inside launchd that could do it. I haven't bothered to go looking for such a thing. That would be a fragile solution anyway. As far as I can tell, Apple has designated the Finder as the "API" for this task.