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.

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?

In our App we have a need to open Apple Developer App from our iOS App to guide user to Developer App. But looks like there is no confirmed URL Scheme provided. Can you help on this.

Hello all, I am building a simple Flutter app, and I want to support entering the app through an email. I have used flutter deep links on android and all works well, but for some reason on IOS it doesnt. What I have achieved: When clicking the link I do get navigated into the app, but I get navigated to whatever the last screen was, regardless of the path in the URL. Furthermore, the logical code inside the app doesnt seem to run either - no logs are printed etc. I have even tried following the flutter tutorial at https://docs.flutter.dev/cookbook/navigation/set-up-universal-links to the letter, and it doesnt work I am using: Flutter 3.22.3 Go Router 14.2.7 Thanks in advance

I am working on an iOS app and I want to achieve on demand module download inside the app when the user clicks on the module icon which he wants to use. The idea is that we have a super app consisting of multiple modules say four independent apps/features and I want to separate each one so that when the user selects a specific app/feature, it’s downloaded on demand and then opened directly within the same super app resulting in a lower app size initially I want to upload all the code of all modules to app store connect but when the user downloads the app, then only one module's code should be available to the user, the rest of the module's code should be downloaded when the user wants to use that module. I know apple restricts downloading new code but in my case I want to upload all the code to app store for review but just give option to the user to get rest of the code when needed. Any guidance, architectural advice, or example implementations would be highly appreciated.

I have been trying to subscribe a few times from Japan, being a foreigner and i amunable to get validated despite my residence card. it feels a bit difficult to navigate this walkthrough.

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.

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!

I have a project inside the project structure. I have around 300 unit tests in the project. I see that for some of the subprojects, the coverage numbers show up correctly, but for other subprojects and the main project, the coverage number shows zero, even though the tests are running successfully. The log I get is: Aggregation tool emitted warnings: warning: /Users/ABC/Library/Developer/Xcode/DerivedData/projectABC-hfzmkbdgpiswoxfvvnvhrafaiqyb/Build/ProfileData/A8EEC1FB-1699-4C29-A88C-D3DDA226DBC0/0A416494-A393-4319-AA47-502D72084C9C-43351.profraw: raw profile version mismatch: Profile uses raw profile format version = 8; expected version = 10 PLEASE update this tool to the version in the raw profile, or regenerate the raw profile with the expected version. I only have one Xcode (26.0.1) on my machine. I tried cleaning the derived data, the cleaning project, and rerunning the tests, but it hasn't helped. Please help me get the coverage number back. Thank you.

How do I download the iPad Air (5th generation) 18.3 simulator? I activated my Mac and only have version 18.2 available. I need to test the simulator that they are testing, but I can't because I don't have version 18.3 available. I only have the iPad version 18.2 available and the application works fine on that version. I have already added logs in different parts of the application, but in the files that you shared with me no log appears. The macOS operating system is macOS Drought.

We are developing a cross platform c++ application. We also use some objective-c (no swift) and specific Apple frameworks like AVFoundation, CoreML in the MacOs version of our software. We use Apple Clang as compiler when building for MacOs. As our code is primarily c++ we would like to use the latest and greatest c++ 20 features. So we are looking into using vanilla clang instead, the builds with vanilla clang seem to work fine, however our concern is that we might have overlooked possible issues that could arise. So our question is whether there are specific things we need to address when switching compilers, are there things that we need to be aware of? In the end we just want to know if switching compilers won't cause problems we can't oversee. So we would like to know if others took the same steps and what your thoughts/experiences are regarding this?

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

My app will not open to myself or to clients and has a pop up that claims "App Outdated" The app version you are using is no longer supported. Please install he latest Heartland update through the App Store. However, there have been no updates to the app.

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 everyone! I change my iPhone but I don't find the voice to activate "Developer Mode". I remember that I activated this feature with my old Xs in few minutes. I don't understand.... I must add the 16 Pro and the new Watch 10 for testing in Xcode. How? Thanks!

Crash dump: `Crashed Thread: 0 tid_103 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGILL) Exception Codes: KERN_PROTECTION_FAILURE at 0x000000016d3bfea0 Exception Codes: 0x0000000000000002, 0x000000016d3bfea0 Termination Reason: Namespace SIGNAL, Code 4 Illegal instruction: 4 Terminating Process: Unity [7873] VM Region Info: 0x16d3bfea0 is in 0x169bbc000-0x16d3c0000; bytes after start: 58736288 bytes before end: 351 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL mapped file 169b00000-169ba8000 [ 672K] rw-/rwx SM=PRV Object_id=4d22156e GAP OF 0x14000 BYTES ---&gt; STACK GUARD 169bbc000-16d3c0000 [ 56.0M] ---/rwx SM=NUL stack guard for thread 0 Stack 16d3c0000-16dbbc000 [ 8176K] rw-/rwx SM=SHM thread 0 Thread 0 Crashed:: tid_103 Dispatch queue: com.apple.main-thread 0 libsystem_platform.dylib 0x1932ee7ac _platform_memset + 108 1 libmonobdwgc-2.0.dylib 0x33977abdc GC_clear_stack_inner + 60 2 libmonobdwgc-2.0.dylib 0x33977abf8 GC_clear_stack_inner + 88 3 libmonobdwgc-2.0.dylib 0x33977abf8 GC_clear_stack_inner + 88 4 libmonobdwgc-2.0.dylib 0x33977abf8 GC_clear_stack_inner + 88 5 libmonobdwgc-2.0.dylib 0x33977abf8 GC_clear_stack_inner + 88 6 libmonobdwgc-2.0.dylib 0x33977abf8 GC_clear_stack_inner + 88 7 libmonobdwgc-2.0.dylib 0x33977abf8 GC_clear_stack_inner + 88 8 libmonobdwgc-2.0.dylib 0x33977abf8 GC_clear_stack_inner + 88 9 libmonobdwgc-2.0.dylib 0x33977abf8 GC_clear_stack_inner + 88 10 libmonobdwgc-2.0.dylib 0x33977abf8 GC_clear_stack_inner + 88 11 libmonobdwgc-2.0.dylib 0x33977abf8 GC_clear_stack_inner + 88 12 libmonobdwgc-2.0.dylib 0x33976b518 GC_clear_stack + 76 13 libmonobdwgc-2.0.dylib 0x33973c074 mono_gc_alloc_obj + 112 14 libmonobdwgc-2.0.dylib 0x3396e0db4 mono_object_new_specific_checked + 72 15 libmonobdwgc-2.0.dylib 0x3396e116c ves_icall_object_new_specific + 28`

Title basically explains what my issue is, from what I understand the only way to set an icon in an tauri app is using a icns file, I could be wrong but I don't know how to get macos theme changing stuff to work with it because of the icns file.

Hello, There seems to be a regression with macOS SDK 15 and dynamically loading libraries if Address Sanitizer is turned on. Seems to only affect Debug builds, and .frameworks. I've also reported this via the Feedback Assistant: FB16513866 Here's a minimal repro, if anyone is interested: https://gist.github.com/peter-esik/6b00432e411be85333e14ae7d953966e I thought I'd post this here, as according to my web searches, this isn't a very well-known bug at this point.

Inside our app, after login (user side), getting grey screen on homepage.

I work at a well-established university with a business journal that is over 25 years old. We have been waiting now for almost four months to have our Apple News account reviewed. In what world is this OK? No ability to communicate with anyone or have any updates except to log in once a month to see the 'under review' message still there. Seriously?