Hello Apple community ! Not here to report an issue but I just wanted to make a suggestion ^^ I feel like a common frustration amongst developers is the lack of transparency over bugs filed on developer tools, SDKs, iOS versions, the whole Apple ecosystem really. This leads to the creation of parallel bug tracking tools (https://github.com/feedback-assistant/reports?tab=readme-ov-file / https://openradar.appspot.com/page/1) or filing of duplicates for reports that may already exist and are being worked on. I feel like this would save time for both external developers that encounter bugs & Apple engineers that have to look for possible duplicates to share a common public database of issues. Other companies have this kind of system in place (Google for example : https://issuetracker.google.com/) so why not Apple ? Thank you

We're facing critical stability issues with a Xamarin-based iOS warehouse management app and need expert validation of our crash log analysis. We’re seeing recurring issues related to: Auto Layout Threading Violations Memory Pressure Terminations CPU Resource Usage Violations These are causing app crashes and performance degradation in production. We've attached representative crash logs to this post. Technical Validation Questions: Do the crash logs point to app-level defects (e.g., threading/memory management), or could user behavior be a contributing factor? Is ~1.8GB memory usage acceptable for enterprise apps on iOS, or does it breach platform best practices? Do the threading violations suggest a fundamental architectural or concurrency design flaw in the codebase? Would you classify these as enterprise-grade stability concerns requiring immediate architectural refactoring? Do the memory logs indicate potential leaks, or are the spikes consistent with expected usage patterns under load? Could resolving the threading violation eliminate or reduce the memory and CPU issues (i.e., a cascading failure)? Are these issues rooted in Xamarin framework limitations, or do they point more toward app-specific implementation problems? Documentation & UX Questions: What Apple-recommended solutions exist for these specific issues? (e.g., memory management, thread safety, layout handling) From your experience, how would these issues manifest for users? (e.g., crashes, slow performance, logout events, unresponsive UI, etc. JetsamEvent-2025-05-27-123434_REDACTED.ips ) WarehouseApp.iOS.cpu_resource-2025-05-30-142737_REDACTED.ips WarehouseApp.iOS-2025-05-27-105134_REDACTED.ips Any insights, analysis, or references would be incredibly helpful. Thanks in advance!

Why as an IDE, many developers want to use the functions are not available, such as code formatting, if the function is not available, why not even a plug-in center, I have been using IDEA for code development, with Xcode development, feel very inconvenient to use

在将游戏从 Nintendo Switch 移植到 Mac 的过程中使用 .NET （NativeAOT） 有哪些限制和注意事项（尽管两者都是 ARM）？

Hello! I am trying to automate iOS builds for my Unreal Engine game using Unreal Automation Tool, but I cannot produce a functionnal build with it, while packaging from XCode works perfectly. I have tracked down the issue to a missing file. I'm using the Firebase SDK that requires a GoogleService-Info.plist file. I have copied this file at the root of my project, as the Firebase documentation suggests. I have not taken any manual action to specify that this file needs to be included in the packaged app. The Firebase code checks the existence of this file using NSString* Path = [[NSBundle mainBundle] pathForResource: @“GoogleService-Info” ofType: @“plist”]; return Path != nil; If I package my app from XCode using Product -> Archive, this test returns true and the SDK is properly initialized. If I package my app using Unreal Engine's RunUAT.sh BuildCookRun, this test returns false and the SDK fails to initialize (and actually crashes upon trying). I have tried several Unreal Engine tricks to include my file, like setting it as a RuntimeDependecies in my projects Build.cs file. Which enables Unreal Engine code to find it, but not this direct call to NSBundle. I would like to know either how to tell Unreal Engine to include files at the root of the app bundle, or what XCode does to automatically include this file and is there a way to script it? I can provide both versions .xcarchive if needed. Thanks!

Hi, I’m having trouble installing GPT 1.1 on macOS Sequoia 15.3.1 using Xcode Command Line Tools 16.0. I downloaded Evaluation Environment for Windows Games 2.1, mounted the image, and opened the README file. Then, I followed Option 2 to build the environment from scratch: Set up your development and Homebrew environment Ensure you are using Command Line Tools for Xcode 15.1. You can download this older version from: https://developer.apple.com/downloads Note: There is a header file layout change that prevents using newer versions of the macOS SDK. softwareupdate --install-rosetta arch -x86_64 zsh /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" which brew brew tap apple/apple http://github.com/apple/homebrew-apple brew -v install apple/apple/game-porting-toolkit At first, I noticed that I needed to use CLT 15.1, which is not supported on later macOS versions (including mine). Even when I tried using 15.3 (which is somehow supported), I received a message stating that I needed CLT v16.0 or higher to install GPT. After following all the steps and waiting for the installation to complete, I got the following error: ==> Installing apple/apple/game-porting-toolkit ==> Staging /Users/tycjanfalana/Library/Caches/Homebrew/downloads/7baed2a6fd34b4a641db7d1ea1e380ccb2f457bb24cd8043c428b6c10ea22932--crossover-sources-22.1.1.tar.gz in /private/tmp/game-porting-toolkit-20250316-15122-yxo3un ==> Patching ==> /private/tmp/game-porting-toolkit-20250316-15122-yxo3un/wine/configure --prefix=/usr/local/Cellar/game-porting-toolkit/1.1 --disable-win16 --disable-tests --without-x --without-pulse --without-dbus --without-inotify --without-alsa --without-capi --without-oss --without-udev --without-krb5 --enable-win64 --with-gnutls --with-freetype --with-gstreamer CC=/usr/local/opt/game-porting-toolkit-compiler/bin/clang CXX=/usr/local/opt/game-porting-toolkit-compiler/bin/clang++ checking build system type... x86_64-apple-darwin24.3.0 checking host system type... x86_64-apple-darwin24.3.0 checking whether make sets $(MAKE)... yes checking for gcc... /usr/local/opt/game-porting-toolkit-compiler/bin/clang checking whether the C compiler works... no configure: error: in `/private/tmp/game-porting-toolkit-20250316-15122-yxo3un/wine64-build': configure: error: C compiler cannot create executables See `config.log' for more details ==> Formula Tap: apple/apple Path: /usr/local/Homebrew/Library/Taps/apple/homebrew-apple/Formula/game-porting-toolkit.rb ==> Configuration HOMEBREW_VERSION: 4.4.24 ORIGIN: https://github.com/Homebrew/brew HOMEBREW_PREFIX: /usr/local Homebrew Ruby: 3.3.7 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/3.3.7/bin/ruby CPU: 14-core 64-bit westmere Clang: 16.0.0 build 1600 Git: 2.39.5 => /Library/Developer/CommandLineTools/usr/bin/git Curl: 8.7.1 => /usr/bin/curl macOS: 15.3.1-x86_64 CLT: 16.0.0.0.1.1724870825 Xcode: N/A Rosetta 2: true ==> ENV HOMEBREW_CC: clang HOMEBREW_CXX: clang++ CFLAGS: [..] Error: apple/apple/game-porting-toolkit 1.1 did not build Logs: /Users/xyz/Library/Logs/Homebrew/game-porting-toolkit/00.options.out /Users/xyz/Library/Logs/Homebrew/game-porting-toolkit/01.configure /Users/xyz/Library/Logs/Homebrew/game-porting-toolkit/01.configure.cc /Users/xyz/Library/Logs/Homebrew/game-porting-toolkit/wine64-build If reporting this issue, please do so to (not Homebrew/brew or Homebrew/homebrew-core): apple/apple In config.log, I found this: configure:4672: checking for gcc configure:4704: result: /usr/local/opt/game-porting-toolkit-compiler/bin/clang configure:5057: checking for C compiler version configure:5066: /usr/local/opt/game-porting-toolkit-compiler/bin/clang --version >&5 clang version 8.0.0 Target: x86_64-apple-darwin24.3.0 Thread model: posix InstalledDir: /usr/local/opt/game-porting-toolkit-compiler/bin configure:5077: $? = 0 configure:5066: /usr/local/opt/game-porting-toolkit-compiler/bin/clang -v >&5 clang version 8.0.0 Target: x86_64-apple-darwin24.3.0 Thread model: posix InstalledDir: /usr/local/opt/game-porting-toolkit-compiler/bin configure:5077: $? = 0 configure:5066: /usr/local/opt/game-porting-toolkit-compiler/bin/clang -V >&5 clang-8: error: argument to '-V' is missing (expected 1 value) clang-8: error: no input files configure:5077: $? = 1 configure:5066: /usr/local/opt/game-porting-toolkit-compiler/bin/clang -qversion >&5 clang-8: error: unknown argument '-qversion', did you mean '--version'? clang-8: error: no input files configure:5077: $? = 1 configure:5066: /usr/local/opt/game-porting-toolkit-compiler/bin/clang -version >&5 clang-8: error: unknown argument '-version', did you mean '--version'? clang-8: error: no input files configure:5077: $? = 1 configure:5097: checking whether the C compiler works configure:5119: /usr/local/opt/game-porting-toolkit-compiler/bin/clang [...] dyld[15547]: Symbol not found: _lto_codegen_debug_options_array Referenced from: <E33DCAC4-3116-3019-8003-432FB3E66FB4> /Library/Developer/CommandLineTools/usr/bin/ld Expected in: <43F5C676-DE37-3F0E-93E1-BF793091141E> /usr/local/Cellar/game-porting-toolkit-compiler/0.1/lib/libLTO.dylib clang-8: error: unable to execute command: Abort trap: 6 clang-8: error: linker command failed due to signal (use -v to see invocation) configure:5123: $? = 254 configure:5163: result: no configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "Wine" | #define PACKAGE_TARNAME "wine" | #define PACKAGE_VERSION "7.7" | #define PACKAGE_STRING "Wine 7.7" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "" | /* end confdefs.h. */ | | int | main (void) | { | | ; | return 0; | } configure:5168: error: in `/private/tmp/game-porting-toolkit-20250316-15122-yxo3un/wine64-build': configure:5170: error: C compiler cannot create executables See `config.log` for more details Does anyone have any ideas on how to fix this?

Production build on eas failing for a couple of days. Submitted a request for information day before yesterday, but I was wondering if anyone else has been having this problem. I will post any update from Apple if/when I get it.

Hello, I'm building this mobile app using Quasar - Capacitor on iOS. The app is working perfectly, but I'm encountering an issue whenever I push the rep I get this error: "Error Unable to open base configuration reference file '/Volumes/workspace/repository/ios/App/Pods/Target Support Files/Pods-App/Pods-App.release.xcconfig'. App.xcodeproj:1" I've tried every possible solution and made sure that everything is set perfectly. Can anyone please help me with that? Thanks in advance, appreciate you 🫶🏻

Windows 10 使用 VirtualBox 创建的 Monterey 12.6.7 macOS 虚拟机不能识别到 iPhone 7 手机。 iPhone 7 已经连接到电脑主机 (win 10) 的 USB 3.0 口子，手机已经信任电脑。 在 win 10，我看到了 “此电脑\Apple iPhone”，就是说，宿主机识别到了 手机。 现在，开启macOS 虚拟机，虚拟机右下角的 usb 图标，显示并且勾选到了 "Apple Inc. iPhone [0901]"，但虚拟机还是没看到手机设备，导致 Xcode 也看不到手机设备。 虚拟机运行后，插拔 iPhone 7 手机，通过 sudo log show --predicate 'eventMessage contains "usbmuxd"' --info 看到了报错信息： 2025-02-13 10:31:06.541201+0800 0xa3c Error 0x0 0 0 kernel: (Sandbox) 1 duplicate report for System Policy: usbmuxd(22583) deny(1) file-write-mode /private/var/db/lockdown 2025-02-13 10:31:07.090321+0800 0xf807 Error 0x0 140 0 sandboxd: [com.apple.sandbox.reporting:violation] System Policy: usbmuxd(22583) deny(1) file-write-mode /private/var/db/lockdown Violation: deny(1) file-write-mode /private/var/db/lockdown Process: usbmuxd [22583] Path: /usr/local/sbin/usbmuxd Load Address: 0x10564b000 Identifier: usbmuxd Version: ??? (???) Code Type: x86_64 (Native) Parent Process: sudo [22582] Responsible: /System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal User ID: 0 Date/Time: 2025-02-13 10:31:06.793 GMT+8 OS Version: macOS 12.6.7 (21G651) Release Type: User Report Version: 8 MetaData: {"vnode-type":"DIRECTORY","hardlinked":false,"pid":22583,"process":"usbmuxd","primary-filter-value":"/private/var/db/lockdown","platform-policy":true,"binary-in-trust-cache":false,"path":"/private/var/db/lockdown","primary-filter":"path","action":"deny","matched-extension":false,"process-path":"/usr/local/sbin/usbmuxd","file-flags":0,"responsible-process-path":"/System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal","flags":21,"platform-binary":false,"rdev":0,"summary":"deny(1) file-write-mode /private/var/db/lockdown","target":"/private/var/db/lockdown","mount-flags":76582912,"profile":"platform","matched-user-intent-extension":false,"apple-internal":false,"storage-class":"Lockdown","platform_binary":"no","operation":"file-write-mode","profile-flags":0,"normalized_target":["private","var","db","lockdown"],"file-mode":448,"errno":1,"build":"macOS 12.6.7 (21G651)","policy-description":"System Policy","responsible-process-signing-id":"com.apple.Terminal","hardware":"Mac","uid":0,"release-type":"User"} Thread 0 (id: 63477): 0 libsystem_kernel.dylib 0x00007ff80d8368ae __chmod + 10 1 usbmuxd 0x000000010565584e main + 3582 (main.c:816) 2 dyld 0x0000000114e3f52e start + 462 Binary Images: 0x10564b000 - 0x10565afff usbmuxd (0) <0fc9b657-d311-38b5-bf02-e294b175a615> /usr/local/sbin/usbmuxd 0x114e3a000 - 0x114ea3567 dyld (960) <2517e9fe-884a-3855-8532-92bffba3f81c> /usr/lib/dyld 0x7ff80d832000 - 0x7ff80d869fff libsystem_kernel.dylib (8020.240.18.701.6) /usr/lib/system/libsystem_kernel.dylib 2025-02-13 10:35:39.751714+0800 0x27f Default 0x0 0 0 kernel: (Sandbox) Sandbox: usbmuxd(119) allow iokit-get-properties kCDCDoNotMatchThisDevice 2025-02-13 10:35:45.025063+0800 0x27f Default 0x0 0 0 kernel: (Sandbox) Sandbox: usbmuxd(119) allow iokit-get-properties kCDCDoNotMatchThisDevice

My project requires the on-device apple intelligence models (FoundationModels) which are only available for iPad on iPad Pro M1 and later, iPad Air M1 and later, iPad mini A17 Pro. If they don't judge on one of these devices, my project might not work properly as FoundationModels is a pretty big part of my project. For this reason I really need to know what devices the Swift Student Challenge will be judged on.

I have opened a case with the apple developer support a month ago and they have not replied, since then I sent multiple other emails and opened more cases requesting them to get a status update about my case. So far I am being ignored, no reply or anything it is very frustrating, what can I do to get someone to help me with the apple developer team?

I have an xCode project called Vision + CoreML I wanted add some charts into it so I started installing cocoapad for the first time I followed all the steps from installing the latest ruby version to running pod install The critical .xcworkspace had been never created no matter how many times pod install was run. It is nowhere to be found. Could anyone advise me on what went wrong here? Here are some files used to generate Podfile platform :ios, '15.0' target 'Vision + CoreML' do use_frameworks! # Comment the next line if you don't want to use dynamic frameworks pod 'Alamofire', '~> 5.6' # Pods for Vision + CoreML pod 'Charts' end and here is the command prompt output ls MacBook-Pro-3:NotAbgabe myusername$ ls App Main View Configuration Models Documentation Podfile Extensions README.md Image Predictor Vision+Core-ML.xcodeproj LICENSE I ran all the commands under the NotAbgabe folder. Not sure if xcworkspace is hidden somewhere between the files

Hi Support Team, I am new here. I am unable to add my fonts to the asset catalog there is no option to add new font set when I click the plus sign. When I drag my files in they show up as data. I have a Contents.json in the font folder called BeVietnamProFont.font. Is there something I am doing wrong? Thanks SO much! { "info": { "version": 1, "author": "xcode" }, "properties": {}, "fonts": [ { "filename": "BeVietnamPro-Black.ttf", "weight": "black", "style": "normal" }, { "filename": "BeVietnamPro-BlackItalic.ttf", "weight": "black", "style": "italic" }, { "filename": "BeVietnamPro-Bold.ttf", "weight": "bold", "style": "normal" }, { "filename": "BeVietnamPro-BoldItalic.ttf", "weight": "bold", "style": "italic" }, { "filename": "BeVietnamPro-ExtraBold.ttf", "weight": "heavy", "style": "normal" }, { "filename": "BeVietnamPro-ExtraBoldItalic.ttf", "weight": "heavy", "style": "italic" }, { "filename": "BeVietnamPro-ExtraLight.ttf", "weight": "ultralight", "style": "normal" }, { "filename": "BeVietnamPro-ExtraLightItalic.ttf", "weight": "ultralight", "style": "italic" }, { "filename": "BeVietnamPro-Light.ttf", "weight": "light", "style": "normal" }, { "filename": "BeVietnamPro-LightItalic.ttf", "weight": "light", "style": "italic" }, { "filename": "BeVietnamPro-Regular.ttf", "weight": "regular", "style": "normal" }, { "filename": "BeVietnamPro-Italic.ttf", "weight": "regular", "style": "italic" }, { "filename": "BeVietnamPro-Medium.ttf", "weight": "medium", "style": "normal" }, { "filename": "BeVietnamPro-MediumItalic.ttf", "weight": "medium", "style": "italic" }, { "filename": "BeVietnamPro-SemiBold.ttf", "weight": "semibold", "style": "normal" }, { "filename": "BeVietnamPro-SemiBoldItalic.ttf", "weight": "semibold", "style": "italic" }, { "filename": "BeVietnamPro-Thin.ttf", "weight": "thin", "style": "normal" }, { "filename": "BeVietnamPro-ThinItalic.ttf", "weight": "thin", "style": "italic" } ] } ![]("https://developer.apple.com/forums/content/attachment/56835f04-d1c1-468f-808b-9a786562d367" "title=Screenshot 2025-07-13 at 1.05.05 PM.png ;width=539;height=630")

I'm adding state restoration to an old iOS app that does not use scenes or storyboards. Creating of view controllers is entirely programmatic. I found the restorationArchiveTool for iOS which is very helpful. However it also refers to a StateRestorationDebugLogging mobileconfig profile that is supposed to turn on additional debug logging when restoring state. https://download.developer.apple.com/ios/restorationarchivetool_for_ios_7/StateRestorationDebugLogging.mobileconfig However I do not seem to be able to install it to either a simulator or my device. Does anyone know if this profile is still valid? If so, how do I install it? Tom Aylesworth

I am new to Find My network development and i am going to use Nordic solution for my FMN application. I have asked the MFi representative to enable the "Find My network" in our MFi portal. But there are just a sets of PDF in the "Find My network" under "Technology" in MFi Portal. Is there any Find My network Supplementary Agreement in MFi portal? Is it a PDF or where can i find it? Because I need to sign this document back to Nordic solution representative. But it seems there are no such FMN Supplementary Agreement.

Apple’s library technology has a long and glorious history, dating all the way back to the origins of Unix. This does, however, mean that it can be a bit confusing to newcomers. This is my attempt to clarify some terminology. If you have any questions or comments about this, start a new thread and tag it with Linker so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" An Apple Library Primer Apple’s tools support two related concepts: Platform — This is the platform itself; macOS, iOS, iOS Simulator, and Mac Catalyst are all platforms. Architecture — This is a specific CPU architecture used by a platform. arm64 and x86_64 are both architectures. A given architecture might be used by multiple platforms. The most obvious example of this arm64, which is used by all of the platforms listed above. Code built for one platform will not work on another platform, even if both platforms use the same architecture. Code is usually packaged in either a Mach-O file or a static library. Mach-O is used for executables (MH_EXECUTE), dynamic libraries (MH_DYLIB), bundles (MH_BUNDLE), and object files (MH_OBJECT). These can have a variety of different extensions; the only constant is that .o is always used for a Mach-O containing an object file. Use otool and nm to examine a Mach-O file. Use vtool to quickly determine the platform for which it was built. Use size to get a summary of its size. Use dyld_info to get more details about a dynamic library. IMPORTANT All the tools mentioned here are documented in man pages. For information on how to access that documentation, see Reading UNIX Manual Pages. There’s also a Mach-O man page, with basic information about the file format. Many of these tools have old and new variants, using the -classic suffix or llvm- prefix, respectively. For example, there’s nm-classic and llvm-nm. If you run the original name for the tool, you’ll get either the old or new variant depending on the version of the currently selected tools. To explicitly request the old or new variants, use xcrun. The term Mach-O image refers to a Mach-O that can be loaded and executed without further processing. That includes executables, dynamic libraries, and bundles, but not object files. A dynamic library has the extension .dylib. You may also see this called a shared library. A framework is a bundle structure with the .framework extension that has both compile-time and run-time roles: At compile time, the framework combines the library’s headers and its stub library (stub libraries are explained below). At run time, the framework combines the library’s code, as a Mach-O dynamic library, and its associated resources. The exact structure of a framework varies by platform. For the details, see Placing Content in a Bundle. macOS supports both frameworks and standalone dynamic libraries. Other Apple platforms support frameworks but not standalone dynamic libraries. Historically these two roles were combined, that is, the framework included the headers, the dynamic library, and its resources. These days Apple ships different frameworks for each role. That is, the macOS SDK includes the compile-time framework and macOS itself includes the run-time one. Most third-party frameworks continue to combine these roles. A static library is an archive of one or more object files. It has the extension .a. Use ar, libtool, and ranlib to inspect and manipulate these archives. The static linker, or just the linker, runs at build time. It combines various inputs into a single output. Typically these inputs are object files, static libraries, dynamic libraries, and various configuration items. The output is most commonly a Mach-O image, although it’s also possible to output an object file. The linker may also output metadata, such as a link map (see Using a Link Map to Track Down a Symbol’s Origin). The linker has seen three major implementations: ld — This dates from the dawn of Mac OS X. ld64 — This was a rewrite started in the 2005 timeframe. Eventually it replaced ld completely. If you type ld, you get ld64. ld_prime — This was introduced with Xcode 15. This isn’t a separate tool. Rather, ld now supports the -ld_classic and -ld_new options to select a specific implementation. Note During the Xcode 15 beta cycle these options were -ld64 and -ld_prime. I continue to use those names because the definition of new changes over time (some of us still think of ld64 as the new linker ;–). The dynamic linker loads Mach-O images at runtime. Its path is /usr/lib/dyld, so it’s often referred to as dyld, dyld, or DYLD. Personally I pronounced that dee-lid, but some folks say di-lid and others say dee-why-el-dee. IMPORTANT Third-party executables must use the standard dynamic linker. Other Unix-y platforms support the notion of a statically linked executable, one that makes system calls directly. This is not supported on Apple platforms. Apple platforms provide binary compatibility via system dynamic libraries and frameworks, not at the system call level. Note Apple platforms have vestigial support for custom dynamic linkers (your executable tells the system which dynamic linker to use via the LC_LOAD_DYLINKER load command). This facility originated on macOS’s ancestor platform and has never been a supported option on any Apple platform. The dynamic linker has seen 4 major revisions. See WWDC 2017 Session 413 (referenced below) for a discussion of versions 1 through 3. Version 4 is basically a merging of versions 2 and 3. The dyld man page is chock-full of useful info, including a discussion of how it finds images at runtime. Every dynamic library has an install name, which is how the dynamic linker identifies the library. Historically that was the path where you installed the library. That’s still true for most system libraries, but nowadays a third-party library should use an rpath-relative install name. For more about this, see Dynamic Library Identification. Mach-O images are position independent, that is, they can be loaded at any location within the process’s address space. Historically, Mach-O supported the concept of position-dependent images, ones that could only be loaded at a specific address. While it may still be possible to create such an image, it’s no longer a good life choice. Mach-O images have a default load address, also known as the base address. For modern position-independent images this is 0 for library images and 4 GiB for executables (leaving the bottom 32 bits of the process’s address space unmapped). When the dynamic linker loads an image, it chooses an address for the image and then rebases the image to that address. If you take that address and subtract the image’s load address, you get a value known as the slide. Xcode 15 introduced the concept of a mergeable library. This a dynamic library with extra metadata that allows the linker to embed it into the output Mach-O image, much like a static library. Mergeable libraries have many benefits. For all the backstory, see WWDC 2023 Session 10268 Meet mergeable libraries. For instructions on how to set this up, see Configuring your project to use mergeable libraries. If you put a mergeable library into a framework structure you get a mergeable framework. Xcode 15 also introduced the concept of a static framework. This is a framework structure where the framework’s dynamic library is replaced by a static library. Note It’s not clear to me whether this offers any benefit over creating a mergeable framework. Earlier versions of Xcode did not have proper static framework support. That didn’t stop folks trying to use them, which caused all sorts of weird build problems. A universal binary is a file that contains multiple architectures for the same platform. Universal binaries always use the universal binary format. Use the file command to learn what architectures are within a universal binary. Use the lipo command to manipulate universal binaries. A universal binary’s architectures are either all in Mach-O format or all in the static library archive format. The latter is called a universal static library. A universal binary has the same extension as its non-universal equivalent. That means a .a file might be a static library or a universal static library. Most tools work on a single architecture within a universal binary. They default to the architecture of the current machine. To override this, pass the architecture in using a command-line option, typically -arch or --arch. An XCFramework is a single document package that includes libraries for any combination of platforms and architectures. It has the extension .xcframework. An XCFramework holds either a framework, a dynamic library, or a static library. All the elements must be the same type. Use xcodebuild to create an XCFramework. For specific instructions, see Xcode Help > Distribute binary frameworks > Create an XCFramework. Historically there was no need to code sign libraries in SDKs. If you shipped an SDK to another developer, they were responsible for re-signing all the code as part of their distribution process. Xcode 15 changes this. You should sign your SDK so that a developer using it can verify this dependency. For more details, see WWDC 2023 Session 10061 Verify app dependencies with digital signatures and Verifying the origin of your XCFrameworks. A stub library is a compact description of the contents of a dynamic library. It has the extension .tbd, which stands for text-based description (TBD). Apple’s SDKs include stub libraries to minimise their size; for the backstory, read this post. Use the tapi tool to create and manipulate stub libraries. In this context TAPI stands for a text-based API, an alternative name for TBD. Oh, and on the subject of tapi, I’d be remiss if I didn’t mention tapi-analyze! Stub libraries currently use YAML format, a fact that’s relevant when you try to interpret linker errors. If you’re curious about the format, read the tapi-tbdv4 man page. There’s also a JSON variant documented in the tapi-tbdv5 man page. Note Back in the day stub libraries used to be Mach-O files with all the code removed (MH_DYLIB_STUB). This format has long been deprecated in favour of TBD. Historically, the system maintained a dynamic linker shared cache, built at runtime from its working set of dynamic libraries. In macOS 11 and later this cache is included in the OS itself. Libraries in the cache are no longer present in their original locations on disk: % ls -lh /usr/lib/libSystem.B.dylib ls: /usr/lib/libSystem.B.dylib: No such file or directory Apple APIs, most notably dlopen, understand this and do the right thing if you supply the path of a library that moved into the cache. That’s true for some, but not all, command-line tools, for example: % dyld_info -exports /usr/lib/libSystem.B.dylib /usr/lib/libSystem.B.dylib [arm64e]: -exports: offset symbol … 0x5B827FE8 _mach_init_routine % nm /usr/lib/libSystem.B.dylib …/nm: error: /usr/lib/libSystem.B.dylib: No such file or directory When the linker creates a Mach-O image, it adds a bunch of helpful information to that image, including: The target platform The deployment target, that is, the minimum supported version of that platform Information about the tools used to build the image, most notably, the SDK version A build UUID For more information about the build UUID, see TN3178 Checking for and resolving build UUID problems. To dump the other information, run vtool. In some cases the OS uses the SDK version of the main executable to determine whether to enable new behaviour or retain old behaviour for compatibility purposes. You might see this referred to as compiled against SDK X. I typically refer to this as a linked-on-or-later check. Apple tools support the concept of autolinking. When your code uses a symbol from a module, the compiler inserts a reference (using the LC_LINKER_OPTION load command) to that module into the resulting object file (.o). When you link with that object file, the linker adds the referenced module to the list of modules that it searches when resolving symbols. Autolinking is obviously helpful but it can also cause problems, especially with cross-platform code. For information on how to enable and disable it, see the Build settings reference. Mach-O uses a two-level namespace. When a Mach-O image imports a symbol, it references the symbol name and the library where it expects to find that symbol. This improves both performance and reliability but it precludes certain techniques that might work on other platforms. For example, you can’t define a function called printf and expect it to ‘see’ calls from other dynamic libraries because those libraries import the version of printf from libSystem. To help folks who rely on techniques like this, macOS supports a flat namespace compatibility mode. This has numerous sharp edges — for an example, see the posts on this thread — and it’s best to avoid it where you can. If you’re enabling the flat namespace as part of a developer tool, search the ’net for dyld interpose to learn about an alternative technique. WARNING Dynamic linker interposing is not documented as API. While it’s a useful technique for developer tools, do not use it in products you ship to end users. Apple platforms use DWARF. When you compile a file, the compiler puts the debug info into the resulting object file. When you link a set of object files into a executable, dynamic library, or bundle for distribution, the linker does not include this debug info. Rather, debug info is stored in a separate debug symbols document package. This has the extension .dSYM and is created using dsymutil. Use symbols to learn about the symbols in a file. Use dwarfdump to get detailed information about DWARF debug info. Use atos to map an address to its corresponding symbol name. Different languages use different name mangling schemes: C, and all later languages, add a leading underscore (_) to distinguish their symbols from assembly language symbols. C++ uses a complex name mangling scheme. Use the c++filt tool to undo this mangling. Likewise, for Swift. Use swift demangle to undo this mangling. For a bunch more info about symbols in Mach-O, see Understanding Mach-O Symbols. This includes a discussion of weak references and weak definition. If your code is referencing a symbol unexpectedly, see Determining Why a Symbol is Referenced. To remove symbols from a Mach-O file, run strip. To hide symbols, run nmedit. It’s common for linkers to divide an object file into sections. You might find data in the data section and code in the text section (text is an old Unix term for code). Mach-O uses segments and sections. For example, there is a text segment (__TEXT) and within that various sections for code (__TEXT > __text), constant C strings (__TEXT > __cstring), and so on. Over the years there have been some really good talks about linking and libraries at WWDC, including: WWDC 2023 Session 10268 Meet mergeable libraries WWDC 2022 Session 110362 Link fast: Improve build and launch times WWDC 2022 Session 110370 Debug Swift debugging with LLDB WWDC 2021 Session 10211 Symbolication: Beyond the basics WWDC 2019 Session 416 Binary Frameworks in Swift — Despite the name, this covers XCFrameworks in depth. WWDC 2018 Session 415 Behind the Scenes of the Xcode Build Process WWDC 2017 Session 413 App Startup Time: Past, Present, and Future WWDC 2016 Session 406 Optimizing App Startup Time Note The older talks are no longer available from Apple, but you may be able to find transcripts out there on the ’net. Historically Apple published a document, Mac OS X ABI Mach-O File Format Reference, or some variant thereof, that acted as the definitive reference to the Mach-O file format. This document is no longer available from Apple. If you’re doing serious work with Mach-O, I recommend that you find an old copy. It’s definitely out of date, but there’s no better place to get a high-level introduction to the concepts. The Mach-O Wikipedia page has a link to an archived version of the document. For the most up-to-date information about Mach-O, see the declarations and doc comments in <mach-o/loader.h>. Revision History 2025-08-04 Added a link to Determining Why a Symbol is Referenced. 2025-06-29 Added information about autolinking. 2025-05-21 Added a note about the legacy Mach-O stub library format (MH_DYLIB_STUB). 2025-04-30 Added a specific reference to the man pages for the TBD format. 2025-03-01 Added a link to Understanding Mach-O Symbols. Added a link to TN3178 Checking for and resolving build UUID problems. Added a summary of the information available via vtool. Discussed linked-on-or-later checks. Explained how Mach-O uses segments and sections. Explained the old (-classic) and new (llvm-) tool variants. Referenced the Mach-O man page. Added basic info about the strip and nmedit tools. 2025-02-17 Expanded the discussion of dynamic library identification. 2024-10-07 Added some basic information about the dynamic linker shared cache. 2024-07-26 Clarified the description of the expected load address for Mach-O images. 2024-07-23 Added a discussion of position-independent images and the image slide. 2024-05-08 Added links to the demangling tools. 2024-04-30 Clarified the requirement to use the standard dynamic linker. 2024-03-02 Updated the discussion of static frameworks to account for Xcode 15 changes. Removed the link to WWDC 2018 Session 415 because it no longer works )-: 2024-03-01 Added the WWDC 2023 session to the list of sessions to make it easier to find. Added a reference to Using a Link Map to Track Down a Symbol’s Origin. Made other minor editorial changes. 2023-09-20 Added a link to Dynamic Library Identification. Updated the names for the static linker implementations (-ld_prime is no more!). Removed the beta epithet from Xcode 15. 2023-06-13 Defined the term Mach-O image. Added sections for both the static and dynamic linkers. Described the two big new features in Xcode 15: mergeable libraries and dependency verification. 2023-06-01 Add a reference to tapi-analyze. 2023-05-29 Added a discussion of the two-level namespace. 2023-04-27 Added a mention of the size tool. 2023-01-23 Explained the compile-time and run-time roles of a framework. Made other minor editorial changes. 2022-11-17 Added an explanation of TAPI. 2022-10-12 Added links to Mach-O documentation. 2022-09-29 Added info about .dSYM files. Added a few more links to WWDC sessions. 2022-09-21 First posted.

I cannot find this specific KDK for my build 22H417. I need help locating and downloading this Developer Kit. Error Domain=KMErrorDomain Code=34 "Missing Developer Kit: As of macOS 13.0, you will need to install a KDK matching your build 22H417 to rebuild kernel collections." UserInfo={NSLocalizedDescription=Missing Developer Kit: As of macOS 13.0, you will need to install a KDK matching your build 22H417 to rebuild kernel collections.} I

First time user here. Trying to build my React-Native app on xcode. I keep getting "Could not build Module" and "missing package product" and tried many combination for my Podfile. I am on macbook pro M2, XCode version 16.2, building on iphone 16 v18.3.1. Pod version 1.16.2, react-native-cli:2.0.1, Here is my Podfile. I tried to assign modular_headers to individual Firebase packages but then I cant pod install. require_relative '../node_modules/react-native/scripts/react_native_pods' require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules' use_modular_headers! platform :ios, '18.0' prepare_react_native_project! target 'plana' do config = use_native_modules! use_react_native!( :path => config[:reactNativePath], :fabric_enabled => false, :app_path => "#{Pod::Config.instance.installation_root}/.." ) post_install do |installer| react_native_post_install( installer, config[:reactNativePath], :mac_catalyst_enabled => false, ) end end

Hi, I requested the https://itunes.apple.com/lookup?id=6482849843&country=us for getting the information of Goods puzzle sort challange , but the screenshotUrls in the response was empty. Is iTunes search API has issue with getting the screenshot urls ? Is there any plan to update it ?

I have developed an app that I had been testing on the hardware device with the developer profile signed builds, I had setup a CloudKit container in development mode and also had tested with Production mode and they are working as expected. I have also tested storekit auto renewal subscriptions using Storekit Config file and all of that is working on the hardware device with the developer profile signed builds. Now comes the Fun Part, I want to use the Distribution profile to test the app for production readiness, I had created a distribution profile and had set that up in the Release under target of the app in Xcode, I have also created sandbox tester account (which is showing inactive even after 7 days - though I am also logged in with this sandbox tester account on a hardware device and under developer setting it shows as a sandbox tester account) All the subscriptions are showing Ready to Submit in the App Store Connect. I need help understand this whole flow, how to ensure I can test CloudKit and storekit for production readiness and then publish my app for the review. Thank you.