You can code sign and notarize with an individual Apple Developer account. Whether that is appropriate for what you are planning to do, I cannot even begin to guess. I strongly urge you to do more research. There are some things than an individual account cannot do. Depending on what you are doing, it may not be possible to move to an organization account later.

I've done some more digging. I think the biggest one that I haven't found an answer to is (a) can I automatically create folders within the security-accessed folder and (b) can I launch a background process that could access my project folder (and its internals) Is there a good recent swift code or article - I can't seem to find something my newbie mind can handle. I'm afraid I can't answer those questions. It is possible to do those things. But writing a Mac app - just a Mac app - no sandbox, no Mac App Store, no security scoped bookmarks, no background processes - is exceptionally difficult. It is good to inquire about the technical and procedural limitations of the sandbox and Mac App Store before starting a project. But it is better to start with a smaller, more manageable idea. It is easier to make an iOS app and get that running on the Mac via SwiftUI or Catalyst.

10.7 was released by Apple over a decade ago. gfortran is not an Apple product. Your chances of finding anyone to support gfortran on 10.7 is 0.0.

You are on the right track with bookmarks. What you want is a Security Scoped Bookmark.

From what I'm reading into this I think avoiding the app store and just continuing to offer a download on our university web site may be the best/most practical option, but I'll admit I might simply not be fully understanding the app store rules. I think that would be the best course of action. Don't forget that the Mac App Store is going to add another layer of licensing onto the app. Free or not, it will be linked to the original downloader's Apple ID and subject to various other Apple licensing issues. Apple has some other programs for enterprise and business customers. I know nothing about them and I don't know if they would help. Also, you have to remember that 3rd party developers think in terms of sandbox == Mac App Store. From Apple's perspective, the app sandbox and the Mac App Store are two completely different things. The Mac App Store does require sandboxing, along with a long list of other requirements. Apple's intention is that ALL apps should be sandboxed, whether or not they are in the Mac App Store. Therefore, along with a number of technical issues getting AppleScript to work from the sandbox, there is another set of procedural requirements for the Mac App Store that go above and beyond those technical requirements. And don't think you can use other apps as a reference for what is technically and procedurally possible. Just because a handful of very popular apps can do exceptional things in the Mac App Store doesn't mean that Apple will extend those privileges to your app.

If your tools are simple enough, you can just do: clang -o a.out -arch x64_64 -arch arm64 hello.c But be careful. There are few projects that are that simple. Sometimes there are very subtle differences between include files and compile-time settings between architectures. In these cases, you may have to compile separately and use lipo to join them together. And if you are building frameworks instead of stand-alone executables, you have to check your own header files for architecture-specific differences.

It's C 101....I know I'm getting old, but hopefully they still teach this in school. We're talking about using ld at its most fundamental level. ld is used to link things together, including the system library. What you are technically saying is Apple is dropping support for using ld to link production executables. I hope you don't work for Apple. Rest assured, I do not work for Apple. For what it's worth, ld has virtually nothing to do with the C language. I don't know if you are trying to insinuate that I'm too young to know about these things or what. I can also assure you that I pre-date both ld and C. What I'm really curious is how the XCode IDE is linking production executables. They must not be using ld. If you are ever curious about how Xcode does things, you can always compile your little example code in Xcode and look at Xcode's link phase. It will look very similar to this: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -target x86_64-apple-macos11.1 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk -L/Users/jdaniel/Library/Developer/Xcode/DerivedData/ldtest-bvqaqdgevmzgmaedsishnfqvgzdl/Build/Products/Debug -F/Users/jdaniel/Library/Developer/Xcode/DerivedData/ldtest-bvqaqdgevmzgmaedsishnfqvgzdl/Build/Products/Debug -filelist /Users/jdaniel/Library/Developer/Xcode/DerivedData/ldtest-bvqaqdgevmzgmaedsishnfqvgzdl/Build/Intermediates.noindex/ldtest.build/Debug/ldtest.build/Objects-normal/x86_64/ldtest.LinkFileList -Xlinker -object_path_lto -Xlinker /Users/jdaniel/Library/Developer/Xcode/DerivedData/ldtest-bvqaqdgevmzgmaedsishnfqvgzdl/Build/Intermediates.noindex/ldtest.build/Debug/ldtest.build/Objects-normal/x86_64/ldtest_lto.o -Xlinker -export_dynamic -Xlinker -no_deduplicate -Xlinker -no_adhoc_codesign -Xlinker -dependency_info -Xlinker /Users/jdaniel/Library/Developer/Xcode/DerivedData/ldtest-bvqaqdgevmzgmaedsishnfqvgzdl/Build/Intermediates.noindex/ldtest.build/Debug/ldtest.build/Objects-normal/x86_64/ldtest_dependency_info.dat -o /Users/jdaniel/Library/Developer/Xcode/DerivedData/ldtest-bvqaqdgevmzgmaedsishnfqvgzdl/Build/Products/Debug/ldtest You don't have to type all of that yourself. You can just do: clang -o testcprogram testcprogram.c There are always other ways to do it. But once you start doing funky stuff, you risk getting stuck when something changes and you are the only one in the world doing it that way. In that case, if Apple breaks something, it's your problem. If you do things in a more traditional way and Apple breaks something, it's Apple's problem.

My subscription is individual, and I don't want to show my name under the app as developer or seller, how can change the developer & seller name ? I assume you want some kind of "doing business as" name? Apple doesn't allow individuals to have fictitious names. You would have to start a company. And not all companies qualify. Full-fledged corporations are usually fine. Sole proprietorships are not. For something in between, you will need to contact Apple directly and ask.

I am pretty sure it's possible. I have some apps downloaded from the App Store that do some things that are available only with that command. It is virtually always a bad idea to make plans based on what you see some other apps are doing, or appear to do. Maybe they are doing something else. Maybe they were grandfathered in. Maybe they know people at Apple and got one of those golden temporary entitlements. I have a tool that runs other tools within the App Sandbox. When I run "xcrun simctl --help", I get the following: xcrun: error: cannot be used within an App Sandbox. That sounds pretty definitive to me.

We have just come across the same issue and this is the only real reference I can find to it that matches anywhere. Obviously those entitlements are valid. Something else about the app is corrupted.

I'm suspicious of your variable named "fileLocation" that you are shoving directly into the URL. Is your URL being created correctly? The function "CFURLCreateWithFileSystemPath" would be more appropriate.

ld -execute -macosxversionmin 10.11 -lSystem -o testcprogram testcprogram.o Does not work. You get the error that the system library can not be found.  You are using ld directly to link an executable? Why? I've never seen anyone do that. Instead you have to use this linker command: ld -execute -macosxversionmin 10.11 -lSystem -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -o testcprogram testcprogram.o OK. So? You are doing something totally unique and you found a workaround - for today at least. It is a known issue in Big Sur and is in the release notes. I haven't see anything in the release notes about using ld. Maybe you are referring to the dynamic library cache issue. That is only incidentally related to ld. I only found out about the work around because a lot of others on the internet already figured it out and posted about it.  Don't take advice from the internet. They don't know what they are talking about. Just use Xcode. If you absolutely must develop your apps just one level above using a hex editor, what's the difference if you have to specify the path? If that's true, then you can't use ld to link .o files that have calls to the system library for production software anymore because the libraries will not be able to be found when xcode and the command line tools are not installed. The ld tool is only installed as part of either Xcode or the command line tools. Ergo, Xcode or the command line tools would have to be already installed if you are using ld. But that's not the point. At best, you are talking about a small implementation detail on a low-level tool that virtually no one uses, and obviously few of those should be using it. As you can see, I'm not using a crazy cross-platform development tool to compile this code. I'm only using the XCode command line tools cc and ld. And yes, there is a problem. I was hoping to hear Apple has say. Like if this will be fixed in the next release, or if support for ld is dropped, or if somehow using -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib with ld will work for production software. But from what you are saying, it looks like -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib is not a good solution. I'll accept that you aren't doing anything cross-platform, but I won't go any further than that. I'm not sure what you are doing here, in more ways than one. Generally speaking, the command line tools are for building and running software on your own machine. They shouldn't be used for distributing software. That's what Xcode is for. I don't know if the command line tools would create universal binaries, for example. But regardless, there isn't anything wrong with using "-L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib", just as there isn't anything wrong with using "-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib". Neither path is going to show up in the executable. That's why I suggested using "otool -L" to see how it works. It is going to say "/usr/lib/libSystem.B.dylib" using "otool -L". And you can even change that if you want, but that wouldn't be appropriate in this case.

There is a tiny typo: "--root ./tmp/usr/local" should read "--root usr/local". Sorry about that. I think that is an artifact from my difficulty with productbuild vs. pkgbuild. The productbuild tool kept generating an installer that wouldn't work, so I tried various different root paths before I figured out that pkgbuild could just set the correct value. I still think Apple could help out the community a lot by providing a graphical tool to help the many cross platform projects that do not use Xcode. There are a lot of moving parts, and the feedback is opaque. It seems like details change between OS releases, so search the web for answers causes issues with solutions that used to work.  You can always use Feedback Assistant to submit an enhancement request. Generally I would not recommend searching the web for answers. They are usually wrong. My example is a good case in point. It was always wrong. I just didn't notice it. This problem is worse where Macs are involved. There are far fewer people using Macs for open source projects. The few people that do often don't understand the fundamental differences between Macs, other Unixes, and Linux. The vast majority of Mac support in open source projects are little more than crude hacks done years ago and never touched since.

Hello, I am trying to run "xcrun simctl ..." commands in a App Sandboxed app but I am getting errors like: I let the user select the Xcode.app path but I really don't know what to do after that. You can't run that tool in the sandbox. Sorry.

I was also looking for answers for some of these questions. Specifically, I was trying to compile and use Infer analyzer tool (https://github.com/facebook/infer) - Infer uses some custom clang compiler for C++ analysis. Compiling custom clang plugin on M1 wasn't successful - there was some linking issue with LLVM. What does Facebook support say when you submitted the issue for this problem? An important thing to mention is that Infer requires some dependencies from Xcode 11.5 (there are issues with more recent versions). What does Facebook support say when you submitted the issue for these issues? I am not sure how to debug this kind of issue. Do you work for Facebook? The project is open source, so you are free to say "yes" whether or not you are a Facebook employee. Debugging these issues is straightforward. Install the latest versions of LLVM and other dependencies with Apple Silicon support. Correct any errors. Build infer and correct any errors that you encounter. Test using the (hopefully) supplied testing suite. Note that you may need to use unstable branches for any or all of the above. Is there anyone who has similar issue?  All the time. This is how open source works. Most tools are developed for Linux and Windows first. Mac support is hacked in as an afterthought and never touched again until is breaks. Always been this way.