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 have been working on a M1 Mac mini, using my iPad Air M2 running 26.3 iPadOS. Switched to a new M4 Mac mini, went to connect my iPad to run from Xcode and was presented this "The developer disk image could not be mounted on this device." So how can a get an updated DDI? I appreciate any ideas. /Users/robertlawson/Desktop/Screenshot 2026-02-15 at 8.21.50 PM.png

I regularly bump into folks confused by this issue, so I thought I’d collect my thoughts on the topic into a single (hopefully) coherent post. If you have questions or comments, put them in a new thread here on the forums. Feel free to use whatever subtopic and tags that apply to your situation, but make sure to add the Debugging tag so that I see your thread go by. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Testing and Debugging Code Running in the Background I regularly see questions like this: My background code works just fine in Xcode but fails when I download the app from the App Store. or this: … or fails when I run my app from the Home screen. or this: How do I step through my background code? These suggest a fundamental misunderstanding of how the debugger interacts with iOS’s background execution model. The goal of this post is to explain that misunderstanding so that you can effectively test and debug background code. Note The focus of this post is iOS. The advice here generally applies to any of iOS’s ‘child’ platforms, so iPadOS, tvOS, and so on. However, there will be some platform specific differences, especially on watchOS. This advice here doesn’t apply to macOS. It’s background execution model is completely different than the one used by iOS. Understand the Fundamentals The key point to note here is that the debugger prevents your app from suspending. This has important consequences for iOS’s background execution model. Normally: iOS suspends your app when it’s in the background. Once your app is suspended, it becomes eligible for termination. The most common reason for this is that the system wants to recover memory, but it can happen for various other reasons. For example, the system might terminate a suspended app in order to update it. Under various circumstances your app can continue running after moving to the background. A great example of this is the continued processed task feature, introduced in iOS 26 beta. Alternatively, your app can be resumed or relaunched in the background to perform some task. For example, the region monitor feature of Core Location can resume or relaunch your app in the background when the user enters or leaves a region. If no app needs to be executing, the system can sleep the CPU. None of this happens in the normal way if the debugger is attached to your app, and it’s vital that you take that into account when debugging code that runs in the background. An Example of the Problem For an example of how this can cause problems, imagine an app that uses an URLSession background session. A background session will resume or relaunch your app in the background when specific events happen. This involves two separate code paths: If your app is suspended, the session resumes it in the background. If your app is terminated, it relaunches it in the background. Neither code path behaves normally if the debugger is attached. In the first case, the app never suspends, so the resume case isn’t properly exercised. Rather, your background session acts like it would if your app were in the foreground. Normally this doesn’t cause too many problems, so this isn’t a huge concern. On the other hand, the second case is much more problematic. The debugger prevents your app from suspending, and hence from terminating, and thus you can’t exercise this code path at all. Seek Framework-Specific Advice The above is just an example, and there are likely other things to keep in mind when debugging background code for a specific framework. Consult the documentation for the framework you’re working with to see if it has specific advice. Note For URLSession background sessions, check out Testing Background Session Code. The rest of this post focuses on the general case, offering advice that applies to all frameworks that support background execution. Run Your App Outside of Xcode When debugging background execution, launch your app from the Home screen. For day-to-day development: Run the app from Xcode in the normal way (Product > Run). Stop it. Run it again from the Home screen. Alternatively, install a build from TestFlight. This accurately replicates the App Store install experience. Write Code with Debugging in Mind It’s obvious that, if you run the app without attaching the debugger, you won’t be able to use the debugger to debug it. Rather: Extract the core logic of your code into libraries, and then write extensive unit tests for those libraries. You’ll be able to debug these unit tests with the debugger. Add log points to help debug your integration with the system. Treat your logging as a feature of your product. Carefully consider where to add log points and at what level to log. Check this logging code into your source code repository and ship it — or at least the bulk of it — as part of your final product. This logging will be super helpful when it comes to debugging problems that only show up in the field. My general advice is that you use the system log for these log points. See Your Friend the System Log for lots of advice on that front. One of the great features of the system log is that disabled log points are very cheap. In most cases it’s fine to leave these in your final product. Attach and Detach In some cases it really is helpful to debug with the debugger. One option here is to attach to your running app, debug a specific thing, and then detach from it. Specifically: To attach to a running app, choose Debug > Attach to Process > YourAppName in Xcode. To detach, choose Debug > Detach. Understand Force Quit iOS allows users to remove an app from the multitasking UI. This is commonly known as force quit, but that’s not a particularly accurate term: The multitasking UI doesn’t show apps that are running, it shows apps that have been run by the user. The UI shows recently run apps regardless of whether they’re in the foreground, running in the background, suspended, or terminated. So, removing an app from the UI may not actually quit anything. Removing an app sets a flag that prevents the app from being launched in the background. That flag gets cleared when the user next launches the app manually. Note In some circumstances iOS will not honour this flag. The exact cases where this happens are not documented and have changed over time. Keep these behaviours in mind as you debug your background execution code. For example, imagine you’re trying to test the URLSession background relaunch code path discussed above. If you force quit your app, you’ll never hit this code path because iOS won’t relaunch your app in the background. Rather, add a debug-only button that causes your app to call exit. IMPORTANT This suggestion is for debugging only. Don’t include a Quit button in your final app! This is specifically proscribed by QA1561. Alternatively, if you’re attached to your app with Xcode, simply choose Product > Stop. This is like calling exit; it has no impact on your app’s ability to run in the background. Test With Various Background App Refresh Settings iOS puts users in control of background execution via the options in Settings > General > Background App Refresh. Test how your app performs with the following settings: Background app refresh turned off overall Background app refresh turned on in general but turned off for your app Background app refresh turned on in general and turned on for your app IMPORTANT While these settings are labelled Background App Refresh, they affect subsystems other than background app refresh. Test all of these cases regardless of what specific background execution feature you’re using. Test Realistic User Scenarios In many cases you won’t be able to fully test background execution code at your desk. Rather, install a TestFlight build of your app and then use the device as a normal user would. For example: To test Core Location background execution properly, actual leave your office and move around as a user might. To test background app refresh, use your app regularly during the day and then put your device on charge at night. Testing like this requires two things: Patience Good logging The system log may be sufficient here, but you might need to investigate other logging solutions that are more appropriate for your product. These testing challenges are why it’s critical that you have unit tests to exercise your core logic. It takes a lot of time to run integration tests like this, so you want to focus on integration issues. Before starting your integration tests, make sure that your unit tests have flushed out any bugs in your core logic. Revision History 2025-08-12 Made various editorial changes. 2025-08-11 First posted.

Hello, I am experiencing an authentication issue when submitting my Expo iOS app to App Store Connect using the Expo EAS CLI from the terminal. The exact flow is as follows: I run the submit command in the terminal. I am prompted to enter my Apple ID. After entering the Apple ID, I am prompted to enter my Apple ID password. After the password is accepted, I am prompted to enter a 6-digit verification code. I receive the 6-digit code immediately via SMS or phone call. I enter the code correctly and immediately, but the CLI always returns “Invalid code.” This happens every time. Important notes: The Apple ID and password are correct. The 6-digit code is entered immediately and exactly as received. Logging in to App Store Connect via a web browser with the same Apple ID, password, and SMS code works without any issue. The problem only occurs when authenticating through the terminal using Expo EAS CLI. Could you please advise why the verification code is being rejected in the CLI and how I can successfully authenticate and submit my app?

開発アプリで通知確認を行うため、UDIDをプロビジョニングプロファイルに追加する必要があります。 iPhoneのUDIDは取得することができたのですが、AppleWatchのUDIDを取得する方法が分かりません。 Xcodeと接続してUDIDを取得しようとしましたが、iPhoneのみ認識がされAppleWatchが認識されていません。 AppleWatchもデベロッパモードをONしなければならないとAppleから返答をもらったが、その方法がわからないのでどなたかご教授お願い致します。

Hi all, I'm trying to integrate Apple’s DeviceCheck API into my Flutter iOS app. I already have everything set up on the backend — the Apple private key, key ID, team ID, and DeviceCheck capability. The backend is generating and signing the JWT correctly and making requests to Apple. However, I’m currently stuck on the frontend (Flutter): 👉 How can I generate the device_token required by the DeviceCheck API (via DCDevice.generateToken) in a Flutter iOS app? I understand that DCDevice.generateToken() must be called from native Swift code. I previously attempted to use a MethodChannel to bridge this in Swift, but would prefer not to write or maintain native Swift code if possible. I've looked for a prebuilt Flutter package to handle this, but nothing exists or is up-to-date on pub.dev. Main Question: Is there any Apple-supported way to generate the device_token for DeviceCheck from a Flutter app without writing Swift code manually? If not, is DCDevice.generateToken() the only possible approach, and must I implement this via Swift and Flutter platform channels? Thanks!

Hi, I’m trying to free up space on my computer and have uninstalled Xcode. However, I noticed that many large files remain on the filesystem even after uninstalling it. The largest remaining files (~33 GB) are iOS Simulator images located at: /System/Volumes/Data/Library/Developer/CoreSimulator/Volumes I attempted to delete them using root privileges, but it seems that these system files are mounted as read-only. I’m reaching out to ask for guidance to ensure that these files do not contain anything important for macOS, and that it’s safe to remove them before getting in recovery mode. Thank you very much for your advice!

I am trying to integrate Apple Music API using MusicKit and need to generate a Developer Token. However, when I try to create a new key from the Certificates, Identifiers & Profiles section, the “Media Services (MusicKit, ShazamKit, Apple Music Feed)” option is grayed out. We are getting the error 'there are no identifiers available that can be associated with the key.' Although we did checkmark 'musickit' in app services. I have already: Enrolled in the paid Apple Developer Program Created a valid App ID under Identifiers Logged in as the Account Holder Tried multiple browsers and devices Despite this, the option remains disabled. Could you please enable this or let me know what further steps I need to take? Thank you!

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?

On macOS, I get a system popup when running UI tests in GitHub saying: “bash” is requesting to bypass the system private window picker and directly access your screen and audio. How can I prevent these login and screen access popups from appearing during automated UI tests? Is there an official setup or configuration for running IntelliJ UI tests in CI environments (macOS, Linux, Windows) to avoid such dialogs? My builds run in GitHub Actions VMs, so I can’t manually grant these permissions, and they block the tests.

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

Recently a bunch of folks have asked about why a specific symbol is being referenced by their app. This is my attempt to address that question. If you have questions or comments, please start a new thread. 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" Determining Why a Symbol is Referenced In some situations you might want to know why a symbol is referenced by your app. For example: You might be working with a security auditing tool that flags uses of malloc. You might be creating a privacy manifest and want to track down where your app is calling stat. This post is my attempt at explaining a general process for tracking down the origin of these symbol references. This process works from ‘below’. That is, it works ‘up’ from you app’s binary rather than ‘down’ from your app’s source code. That’s important because: It might be hard to track down all of your source code, especially if you’re using one or more package management systems. If your app has a binary dependency on a static library, dynamic library, or framework, you might not have access to that library’s source code. IMPORTANT This post assumes the terminology from An Apple Library Primer. Read that before continuing here. The general outline of this process is: Find all Mach-O images. Find the Mach-O image that references the symbol. Find the object files (.o) used to make that Mach-O. Find the object file that references the symbol. Find the code within that object file. Those last few steps require some gnarly low-level Mach-O knowledge. If you’re looking for an easier path, try using the approach described in the A higher-level alternative section as a replacement for steps 3 through 5. This post assumes that you’re using Xcode. If you’re using third-party tools that are based on Apple tools, and specifically Apple’s linker, you should be able to adapt this process to your tooling. If you’re using a third-party tool that has its own linker, you’ll need to ask for help via your tool’s support channel. Find all Mach-O images On Apple platforms an app consists of a number of Mach-O images. Every app has a main executable. The app may also embed dynamic libraries or frameworks. The app may also embed app extensions or system extensions, each of which have their own executable. And a Mac app might have embedded bundles, helper tools, XPC services, agents, daemons, and so on. To find all the Mach-O images in your app, combine the find and file tools. For example: % find "Apple Configurator.app" -print0 | xargs -0 file | grep Mach-O Apple Configurator.app/Contents/MacOS/Apple Configurator: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64] … Apple Configurator.app/Contents/MacOS/cfgutil: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] … Apple Configurator.app/Contents/Extensions/ConfiguratorIntents.appex/Contents/MacOS/ConfiguratorIntents: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] … Apple Configurator.app/Contents/Frameworks/ConfigurationUtilityKit.framework/Versions/A/ConfigurationUtilityKit: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64] … This shows that Apple Configurator has a main executable (Apple Configurator), a helper tool (cfgutil), an app extension (ConfiguratorIntents), a framework (ConfigurationUtilityKit), and many more. This output is quite unwieldy. For nicer output, create and use a shell script like this: % cat FindMachO.sh #! /bin/sh # Passing `-0` to `find` causes it to emit a NUL delimited after the # file name and the `:`. Sadly, macOS `cut` doesn’t support a nul # delimiter so we use `tr` to convert that to a DLE (0x01) and `cut` on # that. # # Weirdly, `find` only inserts the NUL on the primary line, not the # per-architecture Mach-O lines. We use that to our advantage, filtering # out the per-architecture noise by only passing through lines # containing a DLE. find "$@" -type f -print0 \ | xargs -0 file -0 \ | grep -a Mach-O \ | tr '\0' '\1' \ | grep -a $(printf '\1') \ | cut -d $(printf '\1') -f 1 Find the Mach-O image that references the symbol Once you have a list of Mach-O images, use nm to find the one that references the symbol. The rest of this post investigate a test app, WaffleVarnishORama, that’s written in Swift but uses waffle management functionality from the libWaffleCore.a static library. The goal is to find the code that calls calloc. This app has a single Mach-O image: % FindMachO.sh "WaffleVarnishORama.app" WaffleVarnishORama.app/WaffleVarnishORama Use nm to confirm that it references calloc: % nm "WaffleVarnishORama.app/WaffleVarnishORama" | grep "calloc" U _calloc The _calloc symbol has a leading underscore because it’s a C symbol. This convention dates from the dawn of Unix, where the underscore distinguish C symbols from assembly language symbols. The U prefix indicates that the symbol is undefined, that is, the Mach-O images is importing the symbol. If the symbol name is prefixed by a hex number and some other character, like T or t, that means that the library includes an implementation of calloc. That’s weird, but certainly possible. OTOH, if you see this then you know this Mach-O image isn’t importing calloc. IMPORTANT If this Mach-O isn’t something that you build — that is, you get this Mach-O image as a binary from another developer — you won’t be able to follow the rest of this process. Instead, ask for help via that library’s support channel. Find the object files used to make that Mach-O image The next step is to track down which .o file includes the reference to calloc. Do this by generating a link map. A link map is an old school linker feature that records the location, size, and origin of every symbol added to the linker’s output. To generate a link map, enable the Write Link Map File build setting. By default this puts the link map into a text (.txt) file within the derived data directory. To find the exact path, look at the Link step in the build log. If you want to customise this, use the Path to Link Map File build setting. A link map has three parts: A simple header A list of object files used to build the Mach-O image A list of sections and their symbols In our case the link map looks like this: # Path: …/WaffleVarnishORama.app/WaffleVarnishORama # Arch: arm64 # Object files: [ 0] linker synthesized [ 1] objc-file [ 2] …/AppDelegate.o [ 3] …/MainViewController.o [ 4] …/libWaffleCore.a[2](WaffleCore.o) [ 5] …/Foundation.framework/Foundation.tbd … # Sections: # Address Size Segment Section 0x100008000 0x00001AB8 __TEXT __text … The list of object files contains: An object file for each of our app’s source files — That’s AppDelegate.o and MainViewController.o in this example. A list of static libraries — Here that’s just libWaffleCore.a. A list of dynamic libraries — These might be stub libraries (.tbd), dynamic libraries (.dylib), or frameworks (.framework). Focus on the object files and static libraries. The list of dynamic libraries is irrelevant because each of those is its own Mach-O image. Find the object file that references the symbol Once you have list of object files and static libraries, use nm to each one for the calloc symbol: % nm "…/AppDelegate.o" | grep calloc % nm "…/MainViewController.o" | grep calloc % nm "…/libWaffleCore.a" | grep calloc U _calloc This indicates that only libWaffleCore.a references the calloc symbol, so let’s focus on that. Note As in the Mach-O case, the U prefix indicates that the symbol is undefined, that is, the object file is importing the symbol. Find the code within that object file To find the code within the object file that references the symbol, use the objdump tool. That tool takes an object file as input, but in this example we have a static library. That’s an archive containing one or more object files. So, the first step is to unpack that archive: % mkdir "libWaffleCore-objects" % cd "libWaffleCore-objects" % ar -x "…/libWaffleCore.a" % ls -lh total 24 -rw-r--r-- 1 quinn staff 4.1K 8 May 11:24 WaffleCore.o -rw-r--r-- 1 quinn staff 56B 8 May 11:24 __.SYMDEF SORTED There’s only a single object file in that library, which makes things easy. If there were a multiple, run the following process over each one independently. To find the code that references a symbol, run objdump with the -S and -r options: % xcrun objdump -S -r "WaffleCore.o" … ; extern WaffleRef newWaffle(void) { 0: d10083ff sub sp, sp, #32 4: a9017bfd stp x29, x30, [sp, #16] 8: 910043fd add x29, sp, #16 c: d2800020 mov x0, #1 10: d2800081 mov x1, #4 ; Waffle * result = calloc(1, sizeof(Waffle)); 14: 94000000 bl 0x14 <ltmp0+0x14> 0000000000000014: ARM64_RELOC_BRANCH26 _calloc … Note the ARM64_RELOC_BRANCH26 line. This tells you that the instruction before that — the bl at offset 0x14 — references the _calloc symbol. IMPORTANT The ARM64_RELOC_BRANCH26 relocation is specific to the bl instruction in 64-bit Arm code. You’ll see other relocations for other instructions. And the Intel architecture has a whole different set of relocations. So, when searching this output don’t look for ARM64_RELOC_BRANCH26 specifically, but rather any relocation that references _calloc. In this case we’ve built the object file from source code, so WaffleCore.o contains debug symbols. That allows objdump include information about the source code context. From that, we can easily see that calloc is referenced by our newWaffle function. To see what happens when you don’t have debug symbols, create an new object file with them stripped out: % cp "WaffleCore.o" "WaffleCore-stripped.o" % strip -x -S "WaffleCore-stripped.o" Then repeat the objdump command: % xcrun objdump -S -r "WaffleCore-stripped.o" … 0000000000000000 <_newWaffle>: 0: d10083ff sub sp, sp, #32 4: a9017bfd stp x29, x30, [sp, #16] 8: 910043fd add x29, sp, #16 c: d2800020 mov x0, #1 10: d2800081 mov x1, #4 14: 94000000 bl 0x14 <_newWaffle+0x14> 0000000000000014: ARM64_RELOC_BRANCH26 _calloc … While this isn’t as nice as the previous output, you can still see that newWaffle is calling calloc. A higher-level alternative Grovelling through Mach-O object files is quite tricky. Fortunately there’s an easier approach: Use the -why_live option to ask the linker why it included a reference to the symbol. To continue the above example, I set the Other Linker Flags build setting to -Xlinker / -why_live / -Xlinker / _calloc and this is what I saw in the build transcript: _calloc from /usr/lib/system/libsystem_malloc.dylib _newWaffle from …/libWaffleCore.a[2](WaffleCore.o) _$s18WaffleVarnishORama18MainViewControllerC05tableE0_14didSelectRowAtySo07UITableE0C_10Foundation9IndexPathVtFTf4dnn_n from …/MainViewController.o _$s18WaffleVarnishORama18MainViewControllerC05tableE0_14didSelectRowAtySo07UITableE0C_10Foundation9IndexPathVtF from …/MainViewController.o Demangling reveals a call chain like this: calloc newWaffle WaffleVarnishORama.MainViewController.tableView(_:didSelectRowAt:) WaffleVarnishORama.MainViewController.tableView(_:didSelectRowAt:) and that should be enough to kick start your investigation. IMPORTANT The -why_live option only works if you dead strip your Mach-O image. This is the default for the Release build configuration, so use that for this test. Revision History 2025-07-18 Added the A higher-level alternative section. 2024-05-08 First posted.

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!

I am developing an iOS in-app SDK for collecting code coverage data. The SDK writes coverage data to a specified file by calling __llvm_profile_set_filename and __llvm_profile_write_file. This implementation worked correctly until I switched to Xcode 26.0 to build my project. Now, when __llvm_profile_write_file() is executed, it crashes with the following error stack. Can anyone provide any assistance? Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000001 Exception Codes: 0x0000000000000001, 0x0000000000000001 Termination Reason: Namespace SIGNAL, Code 11, Segmentation fault: 11 Terminating Process: exc handler [454] Thread 96 name: Dispatch queue: com.test-coverage.processing Thread 96: Crashed: 0 Demo 0x122602ea8 initializeValueProfRuntimeRecord (in Demo) (InstrProfilingValue.c:351) 1 Demo 0x00000001226064c0 writeOneValueProfData (in Demo) (InstrProfilingWriter.c:153) 2 Demo 0x0000000122606308 writeValueProfData (in Demo) (InstrProfilingWriter.c:234) 3 Demo 0x00000001226060d0 lprofWriteDataImpl (in Demo) (InstrProfilingWriter.c:401) 4 Demo 0x0000000122605d98 lprofWriteData (in Demo) (InstrProfilingWriter.c:261) 5 Demo 0x0000000122604804 writeFile (in Demo) (InstrProfilingFile.c:536) 6 Demo 0x122604664 __llvm_profile_write_file_alias + 228 7 Demo 0x000000011c6dd108 -[BDTestCoverage p_dumpMainCoverageInfoWithCustomKey:] (in Demo) (TestCoverage.m:995) 8 Demo 0x000000011c6dcef8 -[BDTestCoverage p_dumpAllCoverageProfileWithCustomKey:] (in Demo) (TestCoverage.m:970)

I enrolled yesterday. Paid the money. It's already hit my credit card. Still shows that I'm not a member. You had zero problem taking my money, where is the service I paid for?

We're having issues getting Sign in with Google to function on TestFlight (not experiencing these issues on iOS Browser) with user unable to be authorised and proceed to logged in screens of our app. Below are the three sign-in methods tested and the exact results for each. Button 1: Default Standard Google Sign-In button (Google JavaScript SDK) embedded in the frontend. Uses the normal OAuth browser redirect flow. Auth URL: https://accounts.google.com/o/oauth2/v2/auth?... Sometimes disallowed_useragent error. Other times a 400 invalid_request error. In most cases the callback is never triggered inside the wrapper. Appears that the wrapper does not retain cookies/session data from the external Google window. Button 2: Custom Custom button calling Google OAuth through our own redirect handler. Explicitly set a custom user-agent to bypass disallowed user agent logic. Later removed user-agent override entirely for testing. Added multiple ATS (App Transport Security) exceptions for Google domains. Added custom URL scheme to Info.plist for OAuth redirect. Changing the user-agent had no effect. ATS exceptions + scheme support verified and working. Redirect still fails to propagate tokens back to the WebView. In tests a few weeks ago we got to Google’s login page, but it never returned to the app with a valid code. Now we are consistently getting disallowed_useragent error. Button 3: Default Same as Button 1 however tested outside of Vue.js with just plain JavaScript. Added new Google domain exceptions and updated redirect URIs. Behaviour matches Button 1 Google account selection sometimes worked, however now consitently disallowed_useragent error Additional Technical Attempts User-Agent Modifications Set UA to standard desktop Chrome → no effect. Removed UA override → no effect. ATS / Domain / Scheme Configuration Added: accounts.google.com .googleusercontent.com *.googleapis.com

Im getting this specific error 'Apple 403 detected - Access forbidden' when trying to build my app, my previous 10 builds all succesfully work but now it keeps on giving this error. I'm guessing its because of a new agreement email I recieved. But when i got to both developer website and app store connect there is no new agreements to accept. I'm quite stuck. Any help appreciated. Thanks

i have been added to an apple membership organization, and given App manager's rights b ut my build keeps failing and asking me to get more access

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 am a solo developer building a cross-platform voice assistant app using Capacitor (with HTML, JS) and Xcode for the iOS version. The app is called "Echo Eyes," and it already functions well as a Progressive Web App (PWA). However, the iOS build has been completely blocked due to persistent sandbox permission errors from macOS during the CocoaPods framework embedding phase. This issue has caused severe disruption to my project and personal well-being, and I am writing to formally request assistance in identifying a clear solution. I am not a beginner and have followed all known best practices, forums, and Apple guidance without success. What I’ve Built So Far: Fully working PWA version of the app (voice input, HTML/JS interface) Capacitor initialized with ID: com.echo.eyes.voice Capacitor iOS platform added with CocoaPods App runs fine until Xcode reaches: [CP] Embed Pods Frameworks The Exact Problem: Sandbox: bash(12319) deny(1) file-read-data /Users/Shared/projects/Echo_Mobile/ios/App/Pods/Target Support Files/Pods-App/Pods-App-frameworks.sh Command PhaseScriptExecution failed with a nonzero exit code Clarification: This is not an HTML/JS issue. The failure occurs in Xcode long before web assets are embedded into the bundle. The shell script /Pods-App-frameworks.sh cannot be read due to macOS sandbox restrictions. Everything I’ve Tried: Gave Xcode and Terminal Full Disk Access Ran: sudo xattr -rd com.apple.quarantine on the entire Pods directory Added /bin/bash and /bin/sh to Full Disk Access (after confirming the exact shell via $SHELL) Attempted to disable Gatekeeper via Terminal: sudo spctl --master-disable (confirmed not effective without GUI toggle) Tried relocating project to /Users/Shared/projects/ Cleaned build folder, removed derived data, reinstalled pods Debugged shell usage with: echo "▶️ Embedding under shell: $SHELL" in the [CP] Embed Pods Frameworks script Attempted to grant shell access to Documents Folder, Desktop, and more via Files &amp; Folders Current State: Despite following all known and recommended steps, Xcode continues to return the same sandbox error. The shell script that embeds the CocoaPod frameworks is denied permission to read its own contents by macOS. What I Am Asking For: Is this a known issue in current versions of macOS or Xcode regarding sandbox denial for shell execution inside Pods? Is there a recommended method to grant /bin/bash or /bin/sh permission to read and run these scripts under Xcode without compromising system security? Is moving the project outside /Users (e.g. to /Projects) the only real workaround? Are there official Apple workarounds or entitlements available for developers encountering this? Personal Note: This issue has caused significant emotional and physical distress. I’m building this app as a personal healing tool and companion. I’ve poured months of work into this and done everything I can to follow Apple’s development guidelines. I’m not asking for hand-holding — only a clear, respectful response confirming whether this is expected behavior and what can be done to resolve it. Thank you for your time and understanding.