This is not possible by design.

Your app should have translate capabilities automatically if you use standard system views and controls. Otherwise, you have to be very careful with other companies' apps and services. You might not be legally allowed to use those services or data inside your own app.

I'm sure that industry already has sophisticated tools available. They are not using spreadsheets. I recommend a computer science program at your local college or university instead.

Does your app support account creation inside the app? If so, you probably shouldn't worry too much about App Review. Instead you should be worried about the SEC, IRS, and various other global agencies.

If you look in the platform SDK path, you'll see two "tbd" files for libarchive. However, there are no header files. This means that libarchive is something that Apple uses internally for some other, supported API. Obviously, Apple would prefer that you use the higher-level API instead. This is probably the Apple Archive Swift module. It is always tricky trying to link to your own version of a dynamic library when the system includes a different version. App Store submission makes that even more difficult because it is directly checking for usage of those internal symbols. What you'll have to do is build a static version of libarchive and link to that. Make sure that your binary doesn't link to libarchive. You can use the "otool -L" tool for this. Also do a grep for the symbols that the App Review bot is complaining about and make sure those don't exist in the binary either. This may require some rather obscure linking commands, but I'm not sure. And if you are using an XPC and/or other extensions, then you will probably have to link a separate static copy of libarchive into each executable artifact.

It is probably a security restriction. There are quite a lot of people who work full time looking for security exploits in Apple products. If the exploit involves a feature that isn't very common, removing said feature is a quick and easy fix.

No luck on both counts. All data in Apple Maps is owned or licensed by Apple under very strict terms. You can't do anything with it other than look at it or get directions. It also doesn't support incorporation of end user data.

Have you tried an external boot drive with all of those OS versions installed?

Could you be a little more specific about the error and the file you are using? You could be talking about virtually anything.

I'm not sure what you mean about "copying the output of xcodebuild". What I've done in the past is save one output to "x86_64/myproj.framework" and the other architecture to "arm64/myproj.framework". Save yet another version to just "myproj.framework". Take any "executables" (tools or dylibs) from the two architecture-specific versions, lipo together, and write into the appropriate place in the universal version. Then sign the universal version. However, I pay very close attention to all of my projects and check them carefully. Some open source projects will generate different build configurations on different platforms. If your projects are doing this, then you have no alternative. You must do two separate, architecture-specific builds. In theory, a project could also save the architecture-specific information in public header files. Luckily, I haven't had to deal with that or I was able to hack around it. But this is something that has always been in the back of my mind when dealing with these kinds of build problems and hack-arounds.

Maybe post the exact commands you are using to sign and notarize. Normally when someone has an app file, they just do everything in Xcode. So when people have problems, they are typically trying to notarize PKG or DMG files. Sometimes I've seen people do the zip/notarize sequence incorrectly. That's probably what I was thinking about originally, but that would have probably caused a different result. Are you using the commands as described on this page? https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/customizing_the_notarization_workflow

I'd never heard of vcpkg before you mentioned it. I don't think you need to sign before doing lipo. You can wrap the whole thing into a script and easily do the lipo first and then sign the universal app. I'm afraid the most likely explanation is that your build scripts need significant changes. I haven't encountered any cross platform incompatibilities on the several cmake-based projects I use. Getting cmake to generate iOS code is more difficult. There is a custom config script floating around that is designed specifically for iOS. (See https://fossies.org/linux/opencv/platforms/ios/cmake/Modules/Platform/iOS.cmake Here are the custom configuration options I specify in my code: CMAKE_INSTALL_PREFIX (You probably don't need this one) CMAKE_C_COMPILER (Set to /path/to/Xcode/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang) CMAKE_AR (Set to /path/to/Xcode/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar) CMAKE_LINKER (Set to /path/to/Xcode/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) CMAKE_TOOLCHAIN_FILE (Set to the iOS.cmake file mentioned above, but only for iphoneos builds). IOS_PLATFORM=OS (As opposed to SIMULATOR, again, only for iphoneos builds) Otherwise, aside from being 8 hours too slow, I don't necessarily think you are doing anything wrong. I don't even use the above build settings anymore. One of my most important projects recently switched to cmake and that was the impetus I needed to set VERBOSE=1 and convert everything from automake, cmake, jam, ninja, and gn to Xcode. Now it works great and builds on all platforms, even in Xcode Cloud.

It sounds like you got caught by Apple's temporary relaxation of notarization requirements. Review the items listed in this developer update and see which of these are breaking your notarization.

I have no idea what you are talking about.

Xcode only includes the latest version of any platform SDKs. The ideal solution is to always target the latest SDK and properly handle any API differences in older versions. If your 3rd party app-builder tool doesn't allow that, it may be possible to hack-in an old SDK, but that's not supported.