Hello, First, a quick reply to the question from Apple Staff above. I tried downloading the files from the Terminal as suggested: xcodebuild -downloadPlatform iOS It worked only for the first time. The other files remained stuck at “Preparing” after the first download was completed. My older 2023 MacBook Pro M2 Pro worked flawlessly with all the files, downloading and installing them normally. The computer is no longer with me, so unfortunately I cannot run sudo sysdiagnose, xcrun simctl diagnose, or collect any additional logs at this point. Now, a full update about the MBP M5 Max. The computer has issues with both Find My localization and networking. The issues are: Find My localization has never worked correctly, essentially since day one. The Wi-Fi connection in my place in Rome was extremely unreliable and, in practice, unusable for large downloads such as Xcode and other large software packages. My older 2023 MBP M2 Pro and ny other Apple devices work flawlessly under exactly the same conditions and at the same time. I also observed some Bluetooth-related issues. Find My problem Find My localization has never worked correctly, essentially since I first started using the computer. The Mac frequently remained at an old location for many hours, or did not update its location at all when the lid is closed. This was not an occasional delay that I could simply ignore: the problem has been persistent. I have screenshots (attached below) showing the M5 Max and my older 2023 M2 Pro in the same physical situation. The M2 Pro correctly reported its current location while the M5 Max reported an old/incorrect location. My (many) other Apple devices also work as expected. This makes the problem particularly significant because Find My is a security and recovery feature. A Mac that cannot reliably report its location cannot be relied upon for recovery if it is lost or stolen. Network problem The Wi-Fi connection in my place in Rome was unreliable and, in practice, unusable for large downloads from Xcode and Terminal. My older 2023 MBP M2 Pro works flawlessly under exactly the same conditions and at the same time. I also observed some Bluetooth-related issues like weird disconnections of wearables. Again, the older Mac and my other iOS devices worked flawlessly. What happened Everything is documented, at least by case ID, in my Apple Support history. I first went to the Genius Bar at the main Apple Store in Rome. After more than an hour of troubleshooting and the usual system/configuration tests, the only recommendation was to perform a complete system reinstall. I went home and spent a considerable amount of time installing macOS Golden Gate from scratch and then reinstalling Tahoe. Nothing changed: neither the new installation nor the reinstalled original system resolved the problems. I contacted Apple Support again and booked an appointment at an Authorized Apple Repair Center where I personally know the staff and technicians, in order to avoid spending more time repeating the same basic troubleshooting. They were able to see the Find My problem (is always present). The networking problem did not reproduce with their access point. They told me that they will first follow the Apple troubleshooting procedure, including a complete system reinstall. If that does not resolve the problem, they will send the computer to Apple, since the issue appears to be well beyond what they can diagnose or repair locally. Before leaving the computer with them, I was asked to erase it for data-privacy reasons. As a software engineer interested in low-level systems, I subsequently did some research into similar issues reported with the N1 wireless chip used in the new M5 Macs. I found a surprisingly large number of reports involving N1 systems, including Wi-Fi connectivity/performance problems, AppleCentauriAlpha driver errors, Network Extension compatibility problems (I spent years develping them for a well-known software security company), and other wireless-related issues. I am not claiming that the N1 is necessarily the cause of the problems on my particular machine, however, the number of reports was significant enough that I think it is worth mentioning here. I will not add all of my findings to this thread, since they are publicly searchable for anyone interested. Needless to say, I am not going to accept a repair or replacement unless the computer is fully functional and works as advertised by Apple, including reliable Find My localization and network connectivity. A note about Apple Support case reporting I think the case-reporting functionality on the Apple Support website could be substantially improved. The support history currently provides very limited information about previous cases, often essentially just a case ID, without a useful summary of the problem, the troubleshooting already performed, the diagnosis, or the actions taken. This makes it unnecessarily difficult for a customer to provide an accurate history when a problem is escalated from Apple Support to a Genius Bar and then to an Authorized Service Provider or Apple Engineering. For a complex hardware/software problem such as this one, having a complete and accessible case history would be extremely useful and would also help avoid repeating the same troubleshooting steps multiple times. Luca Severini

Does it mean that this (below) is not true or somehow incorrect? Apple does include LC3 framework references internally, and iOS leverages aspects of LE Audio exclusively for its Made for iPhone (MFi) hearing aid program and specific accessibility protocols. For mainstream consumer audio, however, iOS remains firmly locked to AAC (Apple's preferred high-quality codec) and SBC (the classic Bluetooth baseline).

Today is August 22 2024. Same problem (aside that those web pages are terrible).

Hello, Same issue here. We are in the same situation (an iOS app connecting to bluetooth devices using Core Bluetooth framework) and when we submitted the app for TestFlight Beta we got exactly the same response, up to the commas. Is there anybody here with experience on this matter who could kindly give some quick and effective advice? What is the string for the bluetooth protocol that we must add to the key UISupportedExternalAccessoryProtocols in plist file? Thank you! Luca Severini

Hi Quinn and Uoptaget We have exactly the same issue and the official answer provider by Apple (Feedback ID FB11963304) is to prevent the use of DoH by replying to _dns.resolver.arpa queries with NXDOMAIN in the DNS proxy provider. As Uoptaget said above this is clearly an overlook by Apple that makes the DNS Proxy Extension practically useless and the workaround actually disable an important security feature. Where is that attention to security that Apple is so proud of? It seem it doesn't count every time... :-( Also this is a not so new issue, still present in Ventura 13.2 after four months that have been reported, on a beta version... Despite your very valuable help, to develop a DNS proxy network extension is being a nightmare... Frankly I'm quite disappointed of the lack of complete documentation and the other issues that are present (even after years) in the NE framework, some really blocking but pretty easy to spot with real QA. Well it looks like the maxim "the customer is the QA" is valid also for Apple... If it may help to have it fixed for good, should I file the same bug again or is there a wait to add +1 to it? Best regards, Luca Severini

Long story short, Swift is mostly about politics.