Can you provide more specifics on what the conflict is? Apple tools aren't very friendly to any cross-platform work. The idea is to build everything in Xcode. And in Apple's defence, I've seen a number of cases where the easiest path to get something to compile on a Mac is to just compile the thing in whatever crazy cmake/ninja tools they use on Linux, with verbose mode turned on, and manually construct an Xcode project. It might take a full day to get it right, but then its done for good. There is a good chance that this approach will give you an easy(er) universal build and iOS version too. Another option is to just turn off that warning. Many open source frameworks are never going to satisfy it. Depending on what the conflicts are, another option might be to specify a custom framework header.

ODBC hasn't been used, or noticed, on macOS in at least a decade. You can still build and install the open-source ODBC libraries. But I don't know if there is any Mac software that would know about it.

It may not like those accents in the path. Try copying the app to /tmp and see if it works there.

That include path will be incorrect when building the project--there is no real 'mylib' directory. Maybe Xcode hacks the include paths to magically work, but other toolchains have no way of doing that. You can always build a demo framework in Xcode and see how Xcode does it. For example, it might be the "-fmodule-name" parameter. I think that may be the "magic", but it won't help you if you didn't write the code anyway. Also, if there's an installed version of the headers in '/usr/local/include/mylib', a normal C toolchain will try to include 'header1.h' from there instead of from the project directory. It is a really bad idea to have anything installed in /usr/local when you are building something for distribution. That local version is often a custom build, specific to your machine. You could be building for another architecture or platform and it could use that include. Apple platforms now support 2 different processors across 6 different platforms. It seems to me that Apple (or the clang devs) have redefined what angle bracket includes mean within the context of a framework, and the new definition is not compatible with non-Xcode toolchains. I currently have the warning disabled, but if at all possible I'd like to be creating properly structured frameworks. That sounds like a catch-22. If this is some open-source project, you aren't going to be able to change all the #includes to be framework-style. The Linux folks probably wouldn't appreciate that. What's the problem with turning it off? To be honest, I think this is just a side effect of modern developers. There are few developers would could take an open-source project, turn it into a framework, and link it to an iOS or Mac app. They generally need Homebrew, CocoaPods, or something similar. So, for most developers, not using the proper framework include, naming, and usage convention probably means they did something wrong. Additionally, such a framework probably wouldn't work in Swift, which is all that most developer care about anymore. Aside from Swift complications, I don't know if there is going to be any problem later on down the line. I have a similar framework that I've manually cobbled together. There is no way I'm going to change all the #includes in that framework. If it breaks in the future, then I'll fork the project and fix them in a script. I've already forked the project anyway. It is not like I can keep up with upstream updates. You're not wrong. Apple is diverging away from other, non-Apple platforms. If you want to use code from other platforms, it is going to get more and more difficult. You might have to do as I suggested and start picking your battles.

To be clear, this is my own library so reworking how it builds (even abandoning frameworks) is no huge issue. Frameworks for iOS and MacOS are simply convenient packaging for the resources (and Metal shaders) that go with it. If this has Metal components, then it is a native project and should be a framework built in Xcode. There is no law against having other build systems for other code. If the biggest stumbling block is the module directory, you can easily create a symbolic link for that. The angle brackets vs quotes should be no big deal since other platforms just pick one version or the other at random. I actually tried a custom framework header, but the warning is triggered not only from the umbrella header, but from any of the headers included by umbrella header. An umbrella header is something entirely different. You don't want that. A custom framework header is only useful if you are trying to build a framework called "MyLib" and there already exists a "MyLib.h" header. In your framework, you can set the framework header to be "MyLibHeader.h" or something similar to avoid a file name conflict. It seems that all public includes are expected to only reference the system search paths. How would it work otherwise? If there are any non-public headers, then any builds using your framework would fail. Regarding /usr/local, since that's kinda the typical place to install stuff on any Unix platform, so when installing as a static/shared library--even on Apple platforms--that's where it goes by default. The fact that an older version is installed somewhere on the system shouldn't break the build. That is strictly for software being built on your machine. If you are building software for other people, don't ever use /usr/local for anything. It is not a question of older versions. One day you are trying to build something for M1 and you #include some header that was generated via some configure script that was run on Intel. And that configure script has processor-specific definitions. The code builds fine but crashes at runtime due to page sizes or something. If frameworks are no longer viable for cross-platform code it's seriously annoying and unfortunate, but not catastrophic. It sounds like you have it backwards. There is nothing wrong with frameworks or using Xcode to make them. If this were someone else's code that you are trying to shove into a framework, then do it as best you can and don't worry about it. But if it is your code, then you have to decide who you are building this for. Build it for the convenience of your primary target platform. Hack up the other ones.

I am unaware of any change in this area or any way that this is different behaviour than on other operating systems. Using tilda for your home directory is not very reliable due to the problems you have encountered. It would be better to use the HOME environment variable. You will still need to use double quotes as single quotes typically implies that no variable substitution should be applied.

The new small business program only involves lowering Apple's commission from 30% to 15%. You don't need an M1 to build universal binary apps. Any Mac with a copy of Xcode 12.3 can do that. For testing, you can rent an M1 via AWS or similar services. AWS is very expensive for long-term usage. I use and recommend macweb.com instead.

There are some low-level subtleties involved when opening documents via the sandbox. I don't know the exact details to tell you why this is happening, but I can give you some suggestions on how to solve and/or work around it. First of all, if you are doing this, never ever specify nil as the application. There is no way for you to know what the user has done on their computer. Always specify the exact, Apple-supplied system app that you want to use when opening the document. Next, don't do this at all. You can't really guarantee the existence of any specific Apple app. As Apple would say, the existence of Apple apps should not be considered "API". And on a general user-experience level, this is bad. It dumps the user out of your app. You don't ever want to do that. What you want to do instead is have your own document viewer. All you need is a window with a rich text editing view. You can read the RTF, convert it to attributed string, and stuff it into the view. Takes 5 minutes. If you want to get extra fancy, there are lots of opportunities for that too. I have lots of RTF files in my app and this is how I display them. For the license agreement, I even have logic to make sure they scroll all the way to the bottom before they can agree. In some cases, I adjust the background colours so it doesn't look like a text view. I always turn editing off. For short snippets of text, I use the width of the window and get the ideal height. Then I set an auto layout fixed height. This makes sure that the window automatically sizes to adjust for the content. This is helpful for localization. Don't forget to check in dark mode. You might have to do a little extra work there.

In theory, you could fully notarize the app and staple it, then add it to the dmg, notarize that and staple it. But you don't need to do that. I think either the DTS engineer was wrong or misunderstood what you were doing. Everything I have seen in this forum from Apple engineers says to only notarize and staple the outermost container, which would be your DMG.

Why isn't Helper.app implemented as a normal XPC? And for that matter, why is it a separate helper?

thank's to it's multi-platform nature that would take forever You will need to expand on that aspect. Many of these cross platform packages, and the people who use them, do absolutely crazy things that no one has ever seen before. Otherwise, I'm not sure what kind of built-in security you are looking for. App groups don't provide any security, they provide a hole punched through the built-in sandbox security. That being said, the punched hole is restricted to apps in the app group. Because the app is still sandboxed, I think the sandbox will not allow public access to your message port. See the documentation here. - https://developer.apple.com/library/archive/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW24

The UI of the Main app is Electron That complicates things. I strongly suggest building a non-Electron proof-of-concept for any solution just so you know how it should work and where any complications might come from. only sandboxed apps outside of app group are restricted from accessing it :)  Important plot point. Sandbox security is different depending on your perspective. It provides security to the user against your app, not against other apps. At minimum level we need to be able to verify the sender identity (i.e. if the sender is app signed by us). Ideal situation would be to have fully private communication channel secured by app signature on the OS level.  I don't know of any built-in API that is going to give you that guarantee. This would be easy enough to solve by just getting rid of the multiple executables. So which is more important? The security or the electron?

There is something wrong with your computer. It is possible to get some characters to echo before the password prompt appears. But it is really humanly impossible to actually type your password in that length of time. It should only take a fraction of a second. If yours is slow enough to type "asdasdasdasdasdsadadasdsa" then something is seriously wrong. I did manage to get "sdfa" to show up, but that is only by quickly slamming my hand on the keyboard. There is no way I could type anything and have it show up.

Just because you were doing something a certain way in the past doesn't mean it was ever correct. As the error message says, you are using a reference to a non-const temporary object, which is not allowed. You could change it from a static_cast to a constructor and C++11 would be happy. But that would break it for older versions. Ideally, just do the output operator normally in the first place. std::cout << "matrix (of size N=" << n << ")" << std::endl; and that works with any version.

If you have questions about or problems with Qt, then you will have to ask Qt support for assistance. I can tell you that very few people use Qt on a Mac, but those that do have an inordinately large number of problems. When I see someone posting about how they are struggling for weeks to perform some simple task that takes 2 minutes, it turns out they are always using Qt. Well, that's not true. Sometimes they use Electron. If you want to write a game for Linux, then use whatever it is that will work best for your Linux users. If you want to write a game for the Mac, then use whatever is going to work best for your Mac users. Keep in mind how many potential Linux users you might have vs how many potential Mac users you might have. Also consider how easy it would be to port a Mac game to iOS, which gives you 1 billion potential users. Choose wisely.