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.

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.

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.

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.

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

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.

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.

This is apparently a known problem: https://developer.apple.com/forums/thread/659864 The solution is to use some other port.

Sorry, I will try to clarify: I am able to notarize my installer package when the static library is a non-fat file (only one arch). But it still fails when I try to notarize it with the static library as fat file (universal). There is only one valid reason to be including a static library in an installer package. That would be if you are shipping a developer framework to other developers, who are your customers. Here, I am using the work "framework" as a generic package of files for a developer to use, not an official "framework bundle" in Apple's platforms. An official "framework" is a bundle and wrapper around a dynamic library that includes header files and, optionally, some resources. A static library is not part of a framework. Now you can distribute a static library along with your framework for those customers that want to link statically. I hadn't mentioned this possibility before because I didn't want to introduce additional confusion. I just accepted you at your word that you are doing exactly what you claim - trying to notarize a static library, which is not possible. A static library is not runtime code. It does not need to be notarized. It does not even need to be signed. It doesn't need anything. It is just an "archive" of object files that you shove into your executable. In theory, you could run with that "shove it in somewhere" static library approach and just shove your static library somewhere inside a real framework bundle. You haven't said anything about that, however. I would not suggest you do that for a number of reasons. If you are getting stuck by some obscure Apple bug, that should be easy enough to avoid. Just zip the static library, or maybe use a tarball. The static library doesn't need to be inside the framework, and shouldn't be there either. If you are just shipping files based off of your "/usr/local" directory (a very bad idea, by the way) then you might have to do something else. In this case, you would have to zip/tarball the static library before your build your package. Add a post-install step to the package to extract the static library back to its original state. If worse comes to worse, you can carefully corrupt the archive or encrypt it in such a way that the notarization servers don't recognize it. You want the notarization server to just treat it as random binary and ignore it, more or less. If none of this applies, or doesn't make sense, then please explain what you are attempting to do, at a high level.

I didn't say that I'm notarizing a single static library or a Framework by itself ^^ I notarize my Framework as package, the package contains a binary and multiple libraries including the static library. I must have misinterpreted all of the "codesign ... libtbarcode11.a" commands. So I'm indeed able to notarize this archive. Excellent! Problem solved.

I'm from an open-source company that made a simple tool to convert videos from one format to another using FFmpeg in a MacOS app built with python that has been distributed from our site for the past few years. In Big Sur 11.1, the app is unopenable and we are now looking to notarize the app bundle I can help you with the notarization. Ideally, it should have been notarized a couple of years ago. Then you would have had more time to work on it and more people to help. or get it on the MacOS app store.  The licensing of ffmpeg may forbid that. You will need to carefully review the FFmpeg license and your use of the project. Depending on which parts of ffmpeg you are using, it could fall it a more restrictive case that would forbid use in the Mac App Store. I attached the entire crash log at the bottom in case it helps. Your crash log is not useful. At the minimum, you should symbolicate it so it can be read. Since this is your code, you should also include the relevant source where the crash occurs. The app bundle is not openable in Xcode so I am struggling to look for a simple way to sign the app and submit it for notarization. I don't understand your question. Xcode doesn't open apps. Is there a way to do this without xcode? Again, I don't understand your question. Xcode is an IDE for developing apps. It includes facilities to easily sign and notarize apps. There are command-line tools that you can use to sign and notarize apps without running Xcode. I couldn't begin to tell you if those tools are functional if Xcode is not installed. I know they require a paid developer account. If you are looking for some solution that avoids even installing Xcode, I'm afraid you're on your own. Do I need to rebuild the app in xcode completely, or is there an alternative?  The first thing you would have to do is figure out why the app doesn't work with SIP enabled. Getting notarized seems like an ambitious goal at this point. I can tell you that people who use open-source tools and try to avoid Xcode have a particularly difficult time with notarization. Invariably, they do crazy things inside their code that either Apple has never heard of, or that Apple has specifically designed the operating system to block. Either way, the only way to truly say your app is notarized is to run through the process, post the app on the internet, and then download it. I suggest, in the strongest terms possible, that you do this using a pristine, factory-fresh virtual machine that you have never used for development. If your app downloads, has a friendly message about "no malware found" from Apple, and then works as designed, then you can consider the notarization to be successful. You may need to play around with some funky entitlements to get your open-source libraries to work. Those are explicitly supported by notarization and the hardened runtime. You will also have to make sure that the app overall is correctly linked. Just because it worked before, without notarization, or SIP, is no guarantee that is has ever been correctly linked so far.

I'm trying to implement an Go2Shell or cd to.. like App and upload it to AppStore. Bad idea. Generally speaking, you should consider how your app would work on the iPhone. If that doesn't even make any sense, then your app is probably not suited for the Mac App Store. It probably isn't even suited for the Mac anymore. Put icon on Finder. By pressing the Icon, the user can launch the terminal at the current Finder path Yes. I wrote one of the first implementations of such a tool, at least 12 years ago. The crude way to implement it is like the source code here. Get the current Finder path by AppleScript return value. And then use /usr/bin/open to launch the terminal with path parameter. Fixed your typo there. According to this post ("Executing AppleScript in a Mac app on macOS Mojave and dealing with AppleEvent sandboxing "), I can't just disable the sandbox or use "temporary exception". Correct. It is always a bad idea to write software that depends on some other developer's work. You are literally dependent on them. Do they approve of this derived work? Do they support it? Will they change their API one day and break your app? Apple is "some other developer" much like anyone else. They have a certain interest in supporting your work, but they have limits. And since Apple software runs as root, Apple has more limits than other developers. The only possible way is to find the scripting targets of the Finder. But I can't find the corresponding target name by sdefcommand. Anyone know how to fix this problem? The limitations you are trying to work around are there by design. This is a case where your success would be considered by Apple to be a critical security bug. Not only will Apple not allow your app in the Store, they will literally submit an update to the operating systems of 100 million devices just to block your app. The easy answer is to just find some other app to work on. Apple has a number of authorized Finder APIs you could use if you really wanted to. However, most of the limitations I mentioned above would still apply. It is better to go your own way, write an app that people want to use, and then add support for operating system integration as you have time, in a secondary capacity. There is literally no possible downside to this approach.

It contains UIWebview etc. where in order to submit a new review will make us change a lot of code. We don't want to touch it, just leave it alive as long as it will take by itself. This app will likely stop working entirely when Apple removes support for those deprecated APIs. Apple has gotten much more aggressive about this sort of thing recently. It would be better to just pull the app if you are not supporting it.

We have an app in the store Then none of that applies to you. We cannot upload a new app as it will take a tremendous amount of time to rewrite it, and if broken we will have a serious production issue as lots of customers are still using it. This doesn't make any sense. If you did need to resubmit for some reason, it should only take a couple of minutes. What do you mean by "rewrite"? You don't need to rewrite the app to submit a new version. This particular issue does not apply to you as Apple manages certificates in the store. However, it sounds like you could have some very serious problems with your app. You should investigate what is going on. Ensure that you can re-build the app and resubmit it in a couple of minutes should the need arise. If there is any reason why you can't do that, then you are in serious, serious trouble.

The error in the log is like this... Like what? In all honesty, it probably doesn't matter what the error in the log file is like. Have you confirmed that it is even possible to access shared memory in a sandboxed XPC service? Personally, I don't know. It sounds like you are trying to do something really tricky, over and above shared memory in a sandboxed XPC service. What does this app do anyway? Have you confirmed that it is something that will obviously pass app review even if you can get it working? And why are you asking about the hardened runtime? I'm sure Apple wants all developers to adopt the hardened runtime and I wouldn't dispute that it is a good idea. But it should be an afterthought that you wouldn't even see the point of mentioning. The fact that you did mention it suggests you are trying to do something clever to get around Mac App Store sandbox limitations. If that is true, it is dead in the water.