Apple Silicon computers support running iOS apps. The property iOSAppOnMac of ProcessInfo is true for these apps. Checks like #available(iOS 15, *) are used to only access new APIs on operating systems that support them. For iOSAppOnMac apps on Big Sur #available(iOS 15, *) evaluates to true despite ProcessInfo().isOperatingSystemAtLeast(.init(majorVersion: 15, minorVersion: 0, patchVersion: 0) evaluating to false. So without an additional check code like the example below crashes with an unrecognized selector exception. Steps to reproduce: Use an API only available for iOS 15 e.g. UITabBar.scrollEdgeAppearance Use #available(iOS 15, *) as condition Code compiles, but crashes at runtime due to unrecognized selector on an iOSAppOnMac Big Sur device Workaround: Add ProcessInfo().isOperatingSystemAtLeast(.init(majorVersion: 15, minorVersion: 0, patchVersion: 0)) as condition. Code sample from our app: if #available(iOS 15, *), ProcessInfo().isOperatingSystemAtLeast(.init(majorVersion: 15, minorVersion: 0, patchVersion: 0)) { let tabBarScrollEdgeAppearance = tabBar.standardAppearance // ... tabBar.scrollEdgeAppearance = tabBarScrollEdgeAppearance } Expectation: I expect #available(iOS 15, *) to evaluate to false on iOSAppOnMac processes running Big Sur. Or in general, if the operating system major version returned by ProcessInfo is x then #available(iOS x+1, *) should be false. Actual behavior: #available(iOS x, *) always evaluates to true on iOSAppOnMac processes potentially causing crashing by using unavailable APIs.

Hi, I'm trying to load libgcrypt library (brew install libgcrypt) with dlopen/dlsym but getting a crash when I use RTLD_LAZY | RTLD_LOCAL mode with dlopen. Any other combination works, for example: RTLD_LAZY | RTLD_GLOBAL RTLD_NOW | RTLD_GLOBAL RTLD_NOW | RTLD_LOCAL I have attached a tiny sample program to reproduce the issue: $ gcc -o dyld_test dyld_test.c $ ./dyld_test gcry_check_version dyld: lazy symbol binding failed: Symbol not found: __gcry_check_version Referenced from: /usr/local/lib/libgcrypt.dylib Expected in: flat namespace dyld: Symbol not found: __gcry_check_version Referenced from: /usr/local/lib/libgcrypt.dylib Expected in: flat namespace I have tried to build dyld myself but failed to succeed. https://opensource.apple.com/source/dyld/dyld-852.2/ Any help would be really appreciated. Thank you, Aleix dyld_test.c

I am using spm in my project. When I build via Xcode 13, I get error "Argument list too long". After some research I found multiple repeat of flags -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks. Have you any idea how to fix this? full log: CompileSwiftSources normal x86_64 com.apple.xcode.tools.swift.compiler (in target 'TryToReproduce' from project 'MyProject') cd /Users/renat/Sources/MyProject export DEVELOPER_DIR\=/Applications/Xcode-13.0.0.app/Contents/Developer export SDKROOT\=/Applications/Xcode-13.0.0.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator15.0.sdk /Applications/Xcode-13.0.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc ... -I /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator -I /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/RxCocoa -I /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/RxRelay -I /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/RxSwift -I /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/TensorFlowLiteSwift -I /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/RxCocoa -I /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/RxRelay -I /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/RxSwift -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator/PackageFrameworks -F /Users/renat/DerrivedData/Build/Products/Debug-iphonesimulator -F /Users/renat/Sources/release-ios/ios/Pods/TensorFlowLiteC/Frameworks -F /Users/renat/Sources/release-ios/ios/Pods/YandexMapKit -F /Users/renat/Sources/release-ios/ios/Pods/YandexRuntime -F /Users/renat/Sources/release-ios/ios/lib -F /Users/renat/Sources/release-ios/iOS ... I already created an empty project and checked adding packages to an empty project, the problem is reproducible

Hello, I finished my SwiftUI application. I uploaded the images and the promotional text. I have to generate and upload the release file. I never did it before. This is my first iOS app. I cannot add my developer account to XCode, because it does not recognize the password maybe, an error is issued from the server. This is a common issue. It happens to me and other developers with apparently no solution(?). I tried with Catilina XCode 12.4 and BigSur XCode 13. I need to release my app for the review process as soon as possible. I think it is possible also with command line but I do not know. I found this page: How do I archive and export my app for distribution I wonder whether the account/password issue would be fixed or not, even with the command line instructions. My app is ready but I am stuck with this strange issue. How to solve this problem with XCode or command line? Thanks

https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/working_with_core_foundation_types If we define a C function that returns a CFType, Swift can (sometimes) bridge the memory management semantics. If Swift cannot bridge the memory management semantics, we can end up with an Unmanaged type: CFStringRef StringByAddingTwoStrings(CFStringRef s1, CFStringRef s2); bridges to: public func StringByAddingTwoStrings(_ s1: CFString!, _ s2: CFString!) -> Unmanaged<CFString>! We can improve the bridging with the CF_RETURNS_RETAINED annotation: CFStringRef StringByAddingTwoStrings(CFStringRef s1, CFStringRef s2) CF_RETURNS_RETAINED; now bridges to: public func StringByAddingTwoStrings(_ s1: CFString!, _ s2: CFString!) -> CFString! What does not seem to be documented is how to improve bridging when function pointer return values should be annotated. For example: typedef CFStringRef (*StringByAddingTwoStrings)(CFStringRef, CFStringRef); bridges to: public typealias StringByAddingTwoStrings = @convention(c) (CFString?, CFString?) -> Unmanaged<CFString>? Is there any way to annotate the function pointer to properly communicate the memory management semantics? Adding the CF_RETURNS_RETAINED to the function pointer does not seem to help.

Hi, We have a large workspace with multiple targets with a mix of Objective C and Swift code. We have been doing our best to update the frameworks used and use module maps where possible. However with Xcode 13 our build times for one target have ****-out to a very large time. I was able to trace it to one file in a framework: However in another target it is significantly less: These two targets are not that different in terms of frameworks linked and files etc. Have not been able to identify exactly what might be causing the differences here. Note also if we compile the framework on it's own then the compile time is at the lower value. This file is large ~ 8MB and contains some large switch statements. it is not including any objective c or swift just c headers with an enum. Any ideas on what to look for here would be most welcome. Thants

Hello, I've noticed, that since Xcode 13 my framework classes references are not working. Even though the project compiles and works, the imported framework and it's classes references could not be found, also autocomplete for the methods is not working. The same behavior is for XCFramework and for the "Fat" framework. Any ideas on how to fix it, should the framework be built differently?

I've updated my M1 mac to Monterey and installed Xcode 13.1. I have a shared lib project I compile with -nostdlib. It's a CPU emulator that doesn't use any external code, no system calls, no std c lib functions... nothing. The library doesn't require initialization either. Now I get this error when building the library ld: dynamic main executables must link with libSystem.dylib for architecture arm64 which can be solved by passing -lSystem to the linker. The question is: is this a bug? I've not changed anything in my project. Is this a new Apple policy? to force everything to be linked against libSystem even when it's not necessary?

Need some help debugging an issue that only started after upgrading to Monterey. Our application is failing to start resulting in a segmentation fault. I am new to debugging such things on MacOS. Using lldb I get the following back trace. Tells me a little but I am unsure how to approach the issue. Looks like it may be related to loading symbols from a dynamic library? Oh, and yes, everything was rebuilt and all dependent libraries installed / upgraded with brew, etc. Thanks, Bob (lldb) bt * thread #1, stop reason = signal SIGSTOP   * frame #0: 0x0000000000000000     frame #1: 0x00007ff807e34bb2 libobjc.A.dylib`load_images + 1358     frame #2: 0x0000000115a0a41c dyld`dyld4::RuntimeState::notifyObjCInit(dyld4::Loader const*) + 170     frame #3: 0x0000000115a0fbfd dyld`dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&amp;, dyld3::Array&lt;dyld4::Loader const*&gt;&amp;) const + 167     frame #4: 0x0000000115a0fbeb dyld`dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&amp;, dyld3::Array&lt;dyld4::Loader const*&gt;&amp;) const + 149     frame #5: 0x0000000115a0fbeb dyld`dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&amp;, dyld3::Array&lt;dyld4::Loader const*&gt;&amp;) const + 149     frame #6: 0x0000000115a0fcac dyld`dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&amp;) const + 108     frame #7: 0x0000000115a2332e dyld`dyld4::APIs::runAllInitializersForMain() + 222     frame #8: 0x0000000115a01358 dyld`dyld4::prepare(dyld4::APIs&amp;, dyld3::MachOAnalyzer const*) + 3438     frame #9: 0x0000000115a004b4 dyld`start + 388

Are there any Fortran compilers that can be used on the 2021 MacBook Pros with Apple Silicon?

How do you set the deployment target when compiling code for Apple TV? If I use -mios-min-version or -mmacosx-min-version I get: % xcrun --sdk appletvos clang -isysroot $(xcrun --sdk appletvos --show-sdk-path) -mios-version-min=13.0 test.c clang: warning: using sysroot for 'AppleTVOS' but targeting 'iPhone' [-Wincompatible-sysroot] ld: warning: building for iOS, but linking in .tbd file (/Applications/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/SDKs/AppleTVOS15.0.sdk/usr/lib/libSystem.tbd) built for tvOS ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libcache.dylib) built for tvOS ld: warning: building for iOS, but linking in .tbd file (/usr/lib/system/libcommonCrypto.dylib) built for tvOS ... If I leave off the -mios-min-version then the code is compiled for the latest appletvos SDK however I want to target an earlier version: xcrun --sdk appletvos clang -isysroot $(xcrun --sdk appletvos --show-sdk-path) test.c otool -l a.out ... Load command 9      cmd LC_UUID  cmdsize 24     uuid A9538E37-7DB1-3EEE-AD77-FAE9DBA8562D Load command 10       cmd LC_BUILD_VERSION   cmdsize 32  platform 3     minos 15.0       sdk 15.0    ntools 1      tool 3   version 711.0 ... There doesn't appear to be a -mtvos-min-version?

As you may know libc++ on MacOS is using weird implementation of RTTI: it compares typeinfo objects by pointers instead of comparing name-strings (like it happens in standard runtimes on Windows and Linux). Since each module has its own typeinfo instance - dynamic_cast for polymorphic types and exception handling may not work across module boundaries if you use -fvisibility=hidden and/or two-level namespace (At the runtime you will either get error from dynamic_cast, or fail to catch exception that was thrown from another module). The problem is that sometimes we have ODR violations because of legacy code, and sometimes there are reasons to legally violate ODR and define same typeinfo in multiple modules - templated polymorphic type. To make polymorphic types work across modules we must make sure that our typeinfo symbols are coalesced (merged) across these modules. This is why I started investigating the way symbols are coalesced on MacOS, my observations so far: For dylib compiled with -flat_namespace everything seems to work as in linux - strong definition in our dylib is overridden by strong definition from another dylib only if another dylib is loaded before ours and both definitions are visible, another library might be compiled with two-level namespace. Weak definitions can be overridden by other weak definitions or strong definition. For dylib compiled with two-level namespace (default and recommended mode) strong symbol definitions cannot be overridden, so there is no way to merge strong typeinfos (these are normally defined for non-templated polymorphic classes). At the same time typeinfo of templated is represented as weak definition, which gets overridden by any previous definition of typeinfo in process, if another dylib with strong/weak visible definition is loaded before our dylib. Questions (sorry for 3 questions at once, but I am really confused): Is there any way to override/coalesce strong symbol definition when this definition is in dylib built with two-level namespace? In the example below this would mean calling sharedlib::Print of main.cpp from libsharedlib.dylib. This works in flat_namespace mode, but not in two-level namespace. Maybe I am missing something. What is the point of two level namespace if weak definitions of my dylib can be overridden by any bad implementation from customer's process? I thought two-level namespace was supposed to protect my dylib from picking up unexpected symbol definitions (for example from another boost version used in process of my customer), but it seems this expectation is not holding up for templated polymorphic classes, and for all weak symbols in general. Is there any common way to handle issue with multiple typeinfos on MacOS? I think one of solutions would be to use -fvisibility-ms-compat and -flat_namespace, which is basically -fvisibility=hidden + it makes all vtables and typeinfos visible, -flat_namespace makes sure all typeinfos for the same types are merged into one by dynamic linker. The problem with this approach is that it seems hacky, and it also makes typeinfo and vtable of some boost header-only classes to be visible in our dylib. I am afraid we can break customer's process if at some point these boost classes change order of methods, or change set of methods (therefore vtable will become incompatible). If you want to play with example, here it is: templates.hpp: #pragma once namespace Foo { template<typename T> class Bar { public: Bar(){}; virtual ~Bar(){}; virtual void SetValue(const T& v) { m_value = v; } T m_value; }; } main.cpp: #include <typeinfo> #include <cstdio> #include "templates.hpp" namespace sharedlib { void CheckTemplate(const Foo::Bar<double>& b); void __attribute__ ((visibility ("default"))) Print() { printf("Print from main executable\n"); } } int main(void) { Foo::Bar<double> b; sharedlib::CheckTemplate(b); return 0; } sharedlib.cpp: #include "templates.hpp" #include <typeinfo> #include <cstdio> namespace sharedlib { void __attribute__ ((visibility ("default"))) Print() { printf("Print from sharedlib\n"); } void __attribute__ ((visibility ("default"))) CheckTemplate(const Foo::Bar<double>& b) { printf("&typeinfo=%p\n", static_cast<const void*>(&typeid(b))); Foo::Bar<double> localB; printf("&typeinfo=%p\n", static_cast<const void*>(&typeid(localB))); Print(); } } Makefile: check: ./main all: main sharedlib main.o: main.cpp clang++ -fvisibility-ms-compat -c main.cpp sharedlib.o: sharedlib.cpp clang++ -fvisibility-ms-compat -c sharedlib.cpp sharedlib.dylib: sharedlib.o clang++ sharedlib.o -dynamiclib -o libsharedlib.dylib # If you use flat_namespace, sharedlib::Print will be replaced by sharedlib::Print defined in main.cpp #clang++ sharedlib.o -dynamiclib -Wl,-flat_namespace -o libsharedlib.dylib main: main.o sharedlib.dylib clang++ main.o -L. -lsharedlib -o main clean: rm -rf *.o *.dylib main Some commands to check results: # check if TWO_LEVEL namespace is used by the dylib otool -Vh ./sharedlib.dylib # check all symbols nm -om ./libsharedlib.dylib | c++filt # output: ... ./libsharedlib.dylib: (undefined) external std::terminate() (from libc++) ./libsharedlib.dylib: 0000000000004040 (__DATA_CONST,__const) weak external typeinfo for Foo::Bar<double> ./libsharedlib.dylib: 0000000000003f70 (__TEXT,__const) weak external typeinfo name for Foo::Bar<double> ... # ld verbose mode, to see how coalescing happens: DYLD_PRINT_BINDINGS=1 ./main

What are the C++ Compilers suitable for Macbook Pro M1 Max? Is there a FORTRAN Compiler available for Macbook Pro M1 Max? If the above compilers are available, will those work with XCode and/or VSCode? Do RStudio and R work on Macbook Pro M1 Max? If so, which version?

I have just updated my MacBook big Sur to Monterey. But after updating, whenever I tried to run GCC in the terminal it shows an invalid active developer path error. I am an absolute beginner, and can't resolve this error. Please help me to resolve this error. Log: gcc --version xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun

We have a Filters framework that contains many image processing filters (written in Swift and Metal) and the resources they require (like ML models and static images). But not every app we have uses all the filters in Filters. Rather we want to only build and bundle the required filters and resources that are needed by the app. The only way we can think of to achieve that is to create different framework targets in Xcode, one for each app. But that would require that the Filters framework project “knows” all of its consumers (apps) and we would rather like to avoid that. Especially since the filters are in a separate repository. Is there a way to, for instance, pass some kind of configuration file to the framework that is used at build time to decide which files to build and bundle?