Saw this info: https://developer.apple.com/documentation/contacts/cncontactstore But have no idea what I'm doing. This is a pressing matter and I need to determine the date/time contacts were originally created on my icloud account. I have tried the shortcuts method and it merely shows the date they were loaded into whichever device i'm logged in on if they were created a while ago

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.

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

I'm a newbie to on-demand resources and I feel like I'm missing something very obvious. I've successfully tagged and set up ODR in my Xcode project, but now I want to upload the assets to my own server so I can retrieve them from within the app, and I can't figure out how to export the files I need. I'm following the ODR Guide and I'm stuck at Step #4, after I've selected my archive in the Archives window it says to "Click the Export button", but this is what I see: As shown in the screenshot, there is no export button visible. I have tried different approaches, including distributing to appstore connect, and doing a local development release. The best I've been able to do is find a .assetpack folder inside the archive package through the finder, but uploading that, or the asset.car inside it, just gives me a "cannot parse response" error from the ODR loading code. I've verified I uploaded those to the correct URL. Can anyone walk me through how to save out the file(s) I need, in a form I can just upload to my server? Thanks, Pete

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.

For the Linux version of my application which is written in C++ using Qt, I display the CHM format help files with this code: QString helpFile{ QCoreApplication::applicationDirPath() + "/Help/" + tr("DeepSkyStacker Help.chm","IDS_HELPFILE") }; QString program{ "kchmviewer" }; QStringList arguments{ "-token", "com.github.deepskystacker", helpFile }; helpProcess->startDetached(program, arguments); (helpProcess is a pointer to a QProcess object) The -token com.github.deepskystackerpart of that ensures that only a single instance of the viewer is used for any code that uses that invocation. Are there any chm file viewers for macOS that are capable of that sort of trick? The ones I've found on the App Store give minimal information and appear to be very simple minded tools that are not not intended for integration into an application as above. I know that MacPorts offers ports of kchmviewer but I'd prefer not to use either that or HomeBrew ... David

The target was chosen as IPhone and IPad. I can also run this build on my IPad. The info.plist content of all our other applications is the same and there were no problems until today. I don't understand why it is being rejected now.

Hi everyone, I’m hoping someone here can shed some light on what’s going on with Apple’s one-hour security delay when trying to register an iPhone for development use. I’m currently setting up an app build using Expo / EAS and a paid Apple Developer account. Every time I scan the device registration QR code or try to authorise my iPhone as a development device, I get hit with a “security delay — try again in one hour” message. This happens every single time, even if I wait the full hour. The device is the same iPhone I always use, signed in to the same Apple ID, and verified with 2FA. The only thing unusual about my setup is that I’m using Starlink for internet access. Because Starlink uses dynamic IP routing and your exit node changes frequently (depending on which satellite or ground station you’re on), it looks like I’m signing in from a new location each time — sometimes even hundreds of miles apart. It seems that Apple’s security system flags each of these as a “new login” or “new device registration,” then enforces a one-hour safety lockout. That makes it basically impossible to register my device and proceed with iOS builds or testing. Has anyone else run into this problem while using Starlink (or other dynamic-routing connections like VPNs or cellular hotspots)? And if so — is there any known workaround or setting to whitelist a device, stabilise verification, or bypass the repeated one-hour wait? This feels like an over-protective security feature that doesn’t play well with modern satellite internet setups. Any insights from the Apple engineers or other developers would be hugely appreciated. Thanks, Tim Lazenby

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!

Hi, is there a compiled version of MailCore.swift? I want to build an easy-to-use mail app for my mother, who is 97, has a MacBook Air, but Apple Mail is too complicated for her. chatGPT said I am too stupid to compile it by myself. Regards Stephan

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

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.

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!

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

Hi everyone, I'm working on an NFC-related app using CoreNFC with APDU commands to read and write tags. I’ve encountered an issue when trying to handle the scenario where the user cancels the NFC session. Here’s what’s happening: When a user cancels the NFC session manually (e.g., by tapping "Cancel"), I see an error log indicating tagReaderSession|userCancelled. However, when I explicitly call session.invalidate(errorMessage: "No NFC tag found") in my code to handle a scenario where no tag is detected, the session still shows the error as userCancelled instead of my custom error message. This behavior is confusing both in terms of debugging and for providing feedback to users, as I expect my custom message to appear instead of the generic "user cancelled" message. func tagReaderSessionDidBecomeActive(_ session: NFCTagReaderSession) { // Session becomes active } func tagReaderSession(_ session: NFCTagReaderSession, didDetect tags: [NFCTag]) { // Handle tag detection logic } func tagReaderSession(_ session: NFCTagReaderSession, didInvalidateWithError error: Error) { print("Session invalidated with error: \(error.localizedDescription)") } func handleNoTagDetected(session: NFCTagReaderSession) { session.invalidate(errorMessage: "No NFC tag found") } I call handleNoTagDetected(session:) explicitly when no tag is detected, expecting the custom error message to show. However, the system still shows the cancellation error. Has anyone else experienced this behavior? Is this the intended behavior for CoreNFC, or am I missing something in my implementation? Any guidance would be appreciated. Thanks in advance!

Hi developers, I'm searching for a kind of way of working to develop my apps on a different machine than testing and final building. For development I have a MacBook Pro m4 and for testing I want to outsource this to a Mac mini m1. I was searching for a solution and also contacted the support, but the answer wasn't really helpful. Any ideas how to setup this configuration to automate this kind of tests? Thanks a lot!

There is a bug in Unity Plugins: Corehaptics.AssetPickerDrawer throws exceptions and draws incorrectly when fieldInfo or assetType is null (FB17305973). I fixed it and created a pull request: https://github.com/apple/unityplugins/pull/47 It has been months and this bug is really annoying.

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

Hi, Help!! So I was in Thailand for a number of years and developed an app over there and signed up as a developer over there. But now I'm in the USA indefinitely and I'm unable to change my payment method. How can I change it? I called the USA support line twice and no one was able to help me. I tried the Thailand phone number and I'm unable to call from the USA. Any suggestions? Thanks!!

I already asked this, although I want to ask again so it boots and gets more people; When I try to run my project on the simulator, it tells me there is a bug. It is not in the code I wrote, but I believe in the compiler. It would work perfectly, say the build succeeded, but the phone turns white and stops there. I don't know how to debunk it, what to do! Picture of what happens with the phone: Picture of the debugging area: Picture of my code: If I need to add more things, please let me know. Have a great day!