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.

I have no sound on any app after beta 18.3 no keyboard click nothing

Hi, I have a library for my iOS Apps. It uses among other things the Combine framework, Core Location and OSLog. I manage the library using the Swift Package Manager (SPM) and usually build via XCode, which works fine. However for CI I would like to build everything from the terminal. So I do call 'swift build' on the terminal. This produces errors such as: 'PassthroughSubject' is only available in macOS 10.15 or newer 'os_log(:dso:log::_:)' is only available in macOS 10.14 or newer 'eraseToAnyPublisher()' is only available in macOS 10.15 or newer 'authorizedWhenInUse' is unavailable in macOS 'AnyPublisher' is only available in macOS 10.15 or newer 'showsBackgroundLocationIndicator' is unavailable in macOS ... These are all from the used frameworks. However, I do not care on which version of macOS, for example, PassthroughSubject is only available at, since the library is iOS only. Too make sure of that I added "platforms: [.iOS(.v14)]" to my Package.swift and thought this would be sufficient, so the project does not get build for macOS. Can anyone please tell me or give me a hint on what I am getting wrong here?

Hi everyone, I’m encountering a crash in my app and need help understanding what’s causing it and how to resolve it. As stated in the crash report, the issue is caused by exceeding the system-wide per-process port limit. Can you tell me how to locate and identify why this is happening? Below are the full report of the crash log: crash.log Summary of Crash: ------------------------------------- Translated Report (Full Report Below) ------------------------------------- Incident Identifier: B509FF2B-C8D8-4E9F-B664-E24464CFD5F8 CrashReporter Key: b390cfe931a83efde49bd8b523023a275b55ef64 Hardware Model: iPhone14,2 Process: MyApp [22515] Path: /private/var/containers/Bundle/Application/F73212A7-4CB9-485A-A8B7-8114F4E9A9AB/MyApp.app/MyApp Identifier: com.beeasy.app.id.enterprise Version: 3.41.38-ID-MySDKMemory-12261114 (3.41.38-ID-MySDKMemory-12261114) Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: com.beeasy.app.id.enterprise [515] Date/Time: 2024-12-29 01:29:48.3023 +0800 Launch Time: 2024-12-26 16:38:36.7895 +0800 OS Version: iPhone OS 16.6.1 (20G81) Release Type: User Baseband Version: 2.80.01 Report Version: 104 Exception Type: EXC_RESOURCE (SIGKILL) Exception Codes: 0x000000000001c1d6, 0x0000000000000000 Termination Reason: PORT_SPACE 14123288431433990614 (Limit 115158 ports) Exceeded system-wide per-process Port Limit Triggered by Thread: 64 Thread 64 name: AURemoteIO::IOThread Thread 64 Crashed: 0 libsystem_kernel.dylib 0x20ce5eca4 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x20ce71b74 mach_msg2_internal + 80 2 libsystem_kernel.dylib 0x20ce71e4c mach_msg_overwrite + 540 3 libsystem_kernel.dylib 0x20ce5f1e8 mach_msg + 24 4 libEmbeddedSystemAUs.dylib 0x238bb2148 void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, AURemoteIO::IOThread::IOThread(AURemoteIO&, caulk::thread::attributes const&, caulk::mach::os_workgroup_managed const&)::'lambda'(), std::__1::tuple<>>>(void*) + 556 5 libsystem_pthread.dylib 0x22dcda6b8 _pthread_start + 148 6 libsystem_pthread.dylib 0x22dcd9b88 thread_start + 8

Hi! I'm new at developing apps. I built my app with Expo and it's working fine in simulator and my iPhone 14 as well. But when I try to run the build in my iPhone with TestFlight it crashes instantly :/ This is part of the log: Incident Identifier: B0ED8DEF-A0F0-4D0C-B3BB-3BB9CAB3242A Distributor ID: com.apple.TestFlight Hardware Model: iPhone14,7 Process: colbakapp [83024] Path: /private/var/containers/Bundle/Application/44211687-140E-4DF3-A577-CB68CE6414B0/colbakapp.app/colbakapp Identifier: com.colbak.colbakapp Version: 1.0.0 (3) AppStoreTools: 16F3 AppVariant: 1:iPhone14,7:18 Beta: YES Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: com.colbak.colbakapp [18141] Date/Time: 2025-06-22 13:26:29.0142 -0400 Launch Time: 2025-06-22 13:26:28.6532 -0400 OS Version: iPhone OS 18.5 (22F76) Release Type: User Baseband Version: 3.60.02 Report Version: 104 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: SIGNAL 6 Abort trap: 6 Terminating Process: colbakapp [83024] Triggered by Thread: 2 Thread 0: 0 libsystem_kernel.dylib 0x00000001f2e4fce4 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x00000001f2e5339c mach_msg2_internal + 76 (mach_msg.c:201) 2 libsystem_kernel.dylib 0x00000001f2e532b8 mach_msg_overwrite + 428 (mach_msg.c:0) 3 libsystem_kernel.dylib 0x00000001f2e53100 mach_msg + 24 (mach_msg.c:323) 4 CoreFoundation 0x00000001a1c42900 __CFRunLoopServiceMachPort + 160 (CFRunLoop.c:2637) 5 CoreFoundation 0x00000001a1c411f0 __CFRunLoopRun + 1208 (CFRunLoop.c:3021) 6 CoreFoundation 0x00000001a1c42c3c CFRunLoopRunSpecific + 572 (CFRunLoop.c:3434) 7 GraphicsServices 0x00000001eee21454 GSEventRunModal + 168 (GSEvent.c:2196) 8 UIKitCore 0x00000001a4655274 -[UIApplication _run] + 816 (UIApplication.m:3845) 9 UIKitCore 0x00000001a4620a28 UIApplicationMain + 336 (UIApplication.m:5540) 10 colbakapp 0x00000001046296b0 main + 64 (AppDelegate.swift:6) 11 dyld 0x00000001c8b17f08 start + 6040 (dyldMain.cpp:1450) Thread 1: 0 libsystem_pthread.dylib 0x000000022c350aa4 start_wqthread + 0 Thread 2 Crashed: 0 libsystem_kernel.dylib 0x00000001f2e5a1dc __pthread_kill + 8 1 libsystem_pthread.dylib 0x000000022c357c60 pthread_kill + 268 (pthread.c:1721) 2 libsystem_c.dylib 0x00000001a9c782d0 abort + 124 (abort.c:122) 3 libc++abi.dylib 0x000000022c2815a0 abort_message + 132 (abort_message.cpp:78) 4 libc++abi.dylib 0x000000022c26fef4 demangling_terminate_handler() + 316 (cxa_default_handlers.cpp:72) 5 libobjc.A.dylib 0x000000019f1e7c08 _objc_terminate() + 172 (objc-exception.mm:499) 6 libc++abi.dylib 0x000000022c2808b4 std::__terminate(void ()()) + 16 (cxa_handlers.cpp:59) 7 libc++abi.dylib 0x000000022c2840d0 __cxa_rethrow + 188 (cxa_exception.cpp:658) 8 libobjc.A.dylib 0x000000019f1e5568 objc_exception_rethrow + 44 (objc-exception.mm:399) 9 colbakapp 0x00000001049f7b68 invocation function for block in facebook::react::ObjCTurboModule::performVoidMethodInvocation(facebook::jsi::Runtime&, char const, NSInvocation*, NSMutableArray*) + 200 (RCTTurboModule.mm:444) 10 colbakapp 0x00000001049fc538 facebook::react::ObjCTurboModule::performVoidMethodInvocation(facebook::jsi::Runtime&, char const*, NSInvocation*, NSMutableArray*)::$_1::operator()() const + 36 (RCTTurboModule.mm:463) 11 colbakapp 0x00000001049fc538 decltype(std::declval<facebook::react::ObjCTurboModule::performVoidMethodInvocation(facebook::jsi::Runtime&, char const*, NSInvocation*, NSMutableArray*)::$_1&>()()) std::__1::__invoke[abi:ne190102... + 36 (invoke.h:149) 12 colbakapp 0x00000001049fc538 void std::__1::__invoke_void_return_wrapper<void, true>::__call[abi:ne190102]<facebook::react::ObjCTurboModule::performVoidMethodInvocation(facebook::jsi::Runtime&, char const*, NSInvocation*, NSMu... + 36 (invoke.h:224) 13 colbakapp 0x00000001049fc538 std::__1::__function::__alloc_func<facebook::react::ObjCTurboModule::performVoidMethodInvocation(facebook::jsi::Runtime&, char const*, NSInvocation*, NSMutableArray*)::$_1, std::__1::allocator<face... + 36 (function.h:171) 14 colbakapp 0x00000001049fc538 std::__1::__function::__func<facebook::react::ObjCTurboModule::performVoidMethodInvocation(facebook::jsi::Runtime&, char const*, NSInvocation*, NSMutableArray*)::$_1, std::__1::allocator<facebook::... + 104 (function.h:313) 15 libdispatch.dylib 0x00000001a9bbcaac _dispatch_call_block_and_release + 32 (init.c:1575) 16 libdispatch.dylib 0x00000001a9bd6584 _dispatch_client_callout + 16 (client_callout.mm:85) 17 libdispatch.dylib 0x00000001a9bc52d0 _dispatch_lane_serial_drain + 740 (queue.c:3939) 18 libdispatch.dylib 0x00000001a9bc5dac _dispatch_lane_invoke + 388 (queue.c:4030) 19 libdispatch.dylib 0x00000001a9bd01dc _dispatch_root_queue_drain_deferred_wlh + 292 (queue.c:7198) 20 libdispatch.dylib 0x00000001a9bcfa60 _dispatch_workloop_worker_thread + 540 (queue.c:6792) 21 libsystem_pthread.dylib 0x000000022c350a0c _pthread_wqthread + 292 (pthread.c:2696) 22 libsystem_pthread.dylib 0x000000022c350aac start_wqthread + 8 Thread 3: 0 libsystem_pthread.dylib 0x000000022c350aa4 start_wqthread + 0 ... EOF

Hello everyone, I've recently added a push notification extension to my React Native app to track specific notification events. The extension itself is quite lightweight, with minimal code – just enough to handle and log some event data. However, I've noticed that the overall app size has increased by around 30MB since adding this extension, which seems unusually high given the simplicity of the code. I inspected the extension's executable file, and it's showing up as 29MB, which doesn’t align with the amount of code I added. I’m wondering if this is expected behavior or if there’s something I can do to reduce the extension's size. Has anyone else encountered a similar issue or found ways to optimize extension sizes? Any guidance on reducing the size of my app post-extension would be greatly appreciated! Thank you in advance for your help!

Hi, I'm generating MusicKit JWT tokens on my backend side and using it on the client side to query the Apple Music API. One concern I have is accidentally over issuing the scope of this JWT, resulting in accidental access more services than intended like DeviceCheck or APNS. Other than using separate keys for MusicKit and other services, is there a way to limit the generated JWT to only the Apple Music API (https://api.music.apple.com/v1/*) using the JWT payload scope?

@MainActor class AddCarViewModel: ObservableObject { @Published var photoUrls : [String] = [] func uploadImages(images: [Image], customerId: String) async throws { let subFolderId = UUID().uuidString let pictureFolderRef = Storage.storage().reference().child("CarPhotos").child(customerId).child("\(subFolderId)") images.enumerated().forEach { index, image in guard let imageData = image.asUIImage().jpegData(compressionQuality: 0.5) else { return } let pictureReference = pictureFolderRef.child("image_\(index).jpeg") pictureReference.putData(imageData, metadata: nil) { metadata, error in if let error = error { print("failed to put data") } pictureReference.downloadURL { url, error in if let error = error { print("error while downloading url ") } guard let urlString = url?.absoluteString else { return } self.photoUrls.append(urlString) } } } } func addCar(carInfo: Car) async throws { try await Firestore.firestore().collection("cars").document().setData(from: carInfo) } } VStack { Button { Task { do { try await viewModel.uploadImages(images: selectedImages, customerId: viewModel.user!.uid) try await viewModel.addCar(carInfo: Car(photoUrls: viewModel.photoUrls)) } catch { print(error) } } dismiss() } label: { Text("Post") } }

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

Hello, I'm developing a macOS application that uses the Virtualization framework to run Linux virtual machines (specifically Ubuntu and Fedora) on Apple Silicon Macs. I've noticed that while the macOS host properly supports all trackpad gestures, the two-finger tap gesture for right-click does not work within the Linux guest. Only the primary click is recognized. This behavior is consistent across different Linux distributions and desktop environments (GNOME, KDE, etc.). I would like to confirm: Is the macOS Virtualization framework expected to support trackpad gestures such as two-finger tap for right-click within Linux guest VMs? If not currently supported, is there a known workaround to enable right-click functionality for the trackpad in Linux guests? (e.g., configuration changes in the VM, Linux kernel input modules, or framework-level adjustments.) Any insights or suggestions would be greatly appreciated. Thank you!

如何在没有电脑的情况下启用开发者模式 please reply me in Chinese

Hello everyone, my iPhone keep on showing multiple "Trust this Computer" alert simultaneously which I cannot tap on it to Trust. As a result, I cannot run my XCode project on my device. Does anyone has any ideas or solutions to fix this ? Solution I have tried: Reset Location & Privacy Reset Network Settings Enable Developer Mode Restart Device My devices specs: iPhone 15 Pro: iOS 18.2.1 Macbook Pro M3 Max: Sequoia 15.1.1

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.

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.

It was required to compile older WebKit versions for other operating systems and was made available up until ~2020 by Apple under the url http://developer.apple.com/opensource/internet/webkit_sptlib_agree.html However this site and file does not seem to be available anymore. Looking for someone who can provide this file. I'd like to put this on archive.org for historic purposes.

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

I am running Appium tests on an iOS 18 simulator, and I am encountering an intermittent issue where the device screen gets locked unexpectedly during the tests. The Appium logs show no errors or unusual activity, and all commands appear to be executed successfully. However, upon reviewing the device logs, I see entries related to the lock event, but the exact cause remains unclear. SpringBoard: (SpringBoard) [com.apple.SpringBoard:Common] lockUIFromSource:Boot options:{ SBUILockOptionsLockAutomaticallyKey: 1, SBUILockOptionsForceLockKey: 1, SBUILockOptionsUseScreenOffModeKey: 0 } SpringBoard: (SpringBoard) [com.apple.SpringBoard:Common] -[SBTelephonyManager inCall] 0 SpringBoard: (SpringBoard) [com.apple.SpringBoard:Common] LockUI from source: Now locking Has anyone experienced similar behavior with Appium on iOS 18, or could there be a setting or configuration in the simulator that is causing this issue?

Apologies if this isn't tagged right but dev tools and services seemed the most appropriate since this is related to the workbench Ad Tester tool. I'm seeing a behavior where the preview link is not being generated. Specifically, I am seeing a POST request to the following URL consistently fail: https://iadworkbench.apple.com/adtester/api/v1/ads/previewLink?orgId=1127861 Variations/scenarios I have tried so far: All possible ad format choices on all possible devices All options for the placement type Both third party and uploaded creative sources Uploaded creative sources appear to be failing to upload as well A simple div with a "hello world" content fails as a third party creative source Multiple apple accounts I created a new account specifically to test if my primary apple ID was experiencing issues with this Multiple browsers I have tried multiple versions of Chrome/Firefox/Safari I tested with and without browser extensions to determine whether an extension was interfering or not Clearing session/local storage along with cookies I also created new profiles in browsers to verify that I was getting a fresh browser environment In all of these cases, the API request to generate a preview link is consistently failing with a 500 error code. It's worth noting that the web preview option works, but this isn't a truly accurate test environment and can't be solely relied on when testing ad content. I don't know exactly when this started happening as I have not used it in the last couple of weeks but I have used the workbench ad tester extensively in the past the same way I have been trying with my current test without issue. That coupled with the fact that the request for the preview link consistently fails in all of the test scenarios I've outlined above leads me to believe there is a problem with the API that is responsible for generating the preview links.

I'm on Mac Studio with Apple M1 Max and I recently upgrated to Sequoia 15.4. After that, Docker won't run anymore. I tried almost all proposed solutions on the web to make Docker to work with Sequoia 15.4 (e.g. workaround at GitHub), without success. Because of this, now I'm stuck in all of my development activities. For example, I cannot develop and deploy anymore my projects and applications. What can I make to solve that?

Is there a way I can use the lldb user defined commands, which I can load from a KDK, to determine how much memory my kext has consumed? Is there a way to figure out what size blocks they are? I have already run the showallclasses command and the output has assured me that I am not leaking any objects which are defined by my driver's classes. Thanks, Tim