eskimo

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. The screenshot above is the iOS system's crash log Just clarify what we’re talking about here, this is an Apple crash report from iOS 26.1: Exception Type: EXC_BAD_ACCESS (SIGKILL) Exception Subtype: KERN_PROTECTION_FAILURE at 0x0000000000000000 … Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 ??? 0x0 ??? 1 Test808813 0x10058c128 -[MainViewController tableView:didSelectRowAtIndexPath:] + 100 2 UIKitCore 0x1a563bc98 -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:isCellMult… 3 UIKitCore 0x1a563bfbc -[UITableView _userSelectRowAtPendingSelectionIndexPath:animatedSelection:] + 255 4 UIKitCore 0x1a563c0c8 -[UITableView _userSelectRowAtPendingSelectionIndexPath:] + 215 5 UIKitCore 0x1a407d878 -[_UIAfterCACommitBlock run] + 71 … You’re concern is with that SIGKILL, where prior to iOS 18 this was a SIGSEGV. That doesn’t strike me as a proble

Thanks for your explanation of how you got to where you are. My natural inclination here is to use a UIApplication background task with an expiration handler. It sounds like you’re already doing most of that. If you simply delete the preflight code and rely on your expiration handler, does that work in practice? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’ve attached my test project to FB21240977. Thanks for that. I did some poking around and I believe this error is being triggered by the echoed pong frame containing no data. If I change this line: try await connection.ping(Data()) { to this: try await connection.ping(Data(hello.utf8)) { I don’t see the error. ps It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hmmm, that wasn’t the answer I was expecting. Something is clearly borked on your machine. You wrote: [quote='868691022, swdev-sos, /thread/809359?answerId=868691022#868691022, /profile/swdev-sos'] Does the pkgbuild command have a cache that can be deleted? [/quote] AFAIK that’s not the case. [quote='868691022, swdev-sos, /thread/809359?answerId=868691022#868691022, /profile/swdev-sos'] We are both using [Xcode] 16.2. [/quote] The Xcode version doesn’t matter here, but rather the OS version. Are you both on the same version of macOS? If you create a new user account on your Mac, does the problem reproduce there? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='868752022, DMSAS, /thread/794045?answerId=868752022#868752022, /profile/DMSAS'] However, some Macs still have issues with malicious software [/quote] My advice is that you test your notarised software on a ‘clean’ machine. I generally use a VM for this. See Testing a Notarised Product. If that test fails, there’s definitely something wrong with your product and you should investigate that. I have lots of advice on that topic in Resolving Trusted Execution Problems. If that test succeeds but you receive sporadic reports of Gatekeeper problems from your users, that’s a trickier issue. It’s possible that you have a Gatekeeper problem with a specific OS release. You can investigate that by re-running the above-mentioned test process with that release. However, it’s more likely that there’s something borked on that user’s machine. That puts you in a bit of a bind: You want to help the user with their problem. But debugging their machine configuration problems isn’t really your core business. This is a bala

Sorry I didn’t reply sooner; older versions of DevForums had a bug that meant that I didn’t see updates on this thread (that’s fixed now, so yay!). [quote='785947022, Najjii, /thread/675290?answerId=785947022#785947022, /profile/Najjii'] edit the trust settings to be able to use it normally. [/quote] Monkeying with trust settings on a code-signing certificate is a bad idea. It can trigger the dreaded errSecInternalComponent. I talk more about this in Fixing an untrusted code signing certificate. [quote='794668022, olvrwn, /thread/675290?answerId=794668022#794668022, /profile/olvrwn'] Is there any information why this does not work with iCloud Keychain? [/quote] Not really. Keychain Access is very much on the way out as a user-level feature. Witness, for example, its recent move from Applications > Utilities to /System/Library/CoreServices/Applications. Given that, it’s easy to see why big picture issues like this aren’t being addressed. Having said that, the file-based keychain is also on its way out, as e

[quote='809534021, Yvan.d, /thread/809534, /profile/Yvan.d'] kSecAttrAccessibleAfterFirstUnlock should allow [access] as long as the device has been unlocked at least once after reboot. [/quote] Correct. I’m aware of two common causes of this problem: There are very limited circumstances under which iOS will run third-party code before first unlock. The canonical example of this is VoIP push notifications. Sometimes these problems are caused by the keychain item not having the correct kSecAttrAccessible value. For example, where the developer shipped a version of their app that set the attribute incorrectly and fixed that in the next version, which left any user who first ran the broken version of their app with the wrong value. Beyond that, it’s hard to say what’s going on here. It’s certainly possible to imagine an OS-level bug causing a problem like this, but I’m not aware of any such bug in play right now. I have general advice about how to approach issues like this in Investigating hard-to-reproduce keyc

[quote='809588021, sts, /thread/809588, /profile/sts'] Is there … no way for a paying developer to downgrade her test devices? [/quote] That’s correct. The only exception to this rule is if the new iOS version is a beta seed, in which case you can roll back to the previous public release. For advice on how to do that, see Apple Beta > FAQ > Support > How do I leave the Apple Beta Software Programme? [quote='809588021, sts, /thread/809588, /profile/sts'] Please don't tell me to use the support forums, this is a concerning a developer test device [/quote] This answer is the same for both developers and users. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Let’s focus this discussion on your other thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

We can’t really help you with Wi-Fi level issues here on the forums. My advice here is that you file a bug so that our Wi-Fi engineering team can investigate. Make sure to include: Wi-Fi debugging information Your analysis so far Regarding the former, see the Wi-Fi for iOS/iPadOS instructions on our Bug Reporting > Profiles and Logs page. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='809584021, st-gab, /thread/809584, /profile/st-gab'] is it possible to rename a notarized ZIP package and not to loose the notarized status? [/quote] Absolutely. I think you might benefit from reading Notarisation Fundamentals, which explains what the notary service actually does. Once you understand that, you should be able to work out for yourself what post-notarisations operations are OK. Specifically, you have watch out for any operation that breaks the seal on a code signature, such as: Modifying a Mach-O image Modifying the contents of a bundle Beyond that, everything else is pretty much fair game. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

To what end? If you have access to that information, what would you do with it? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I don’t see any value in starting yet another forums thread about this. I recommend that we focus this discussion on the existing thread you found. I’ve just posted an update there. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Earlier I wrote: [quote='867857022, DTS Engineer, /thread/806187?answerId=867857022#867857022'] And, no, I don’t have any info to share as to when that fix will actually land. [/quote] As others have noted, this is still present in the macOS 26.2 Release Candidate. Given that, it’s very likely to remain unfixed in the final release of macOS 26.2 )-: and I recommend that you plan accordingly. Beyond that, I still have no specific info to share. But, as always, it’s a good idea to test with new betas of macOS as and when we seed them. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Multipeer Connectivity hasn’t worked over Bluetooth for 10-ish years. On modern systems its peer-to-peer support is based entirely on peer-to-peer Wi-Fi. Historically, Multipeer Connectivity wasn’t the only option for accessing peer-to-peer Bluetooth. Even after peer-to-peer Bluetooth was no longer enabled by default, you could still access it via lower-level APIs or an explicit opt in [1]. However, that’s not been the case for a long while also. At some point we disabled the opt in [2] and eventually we removed the implementation entirely. My general advice is that you: Not use Multipeer Connectivity at all. See Moving from Multipeer Connectivity to Network Framework Forget about peer-to-peer Bluetooth, and rely on either peer-to-peer Wi-Fi or Wi-Fi Aware. However, I wanted to address your case specifically: [quote='809565021, AppDevVa , /thread/809565, /profile/AppDevVa+'] We have a requirement for device-to-device communication … without requiring Wi-Fi connectivity. [/quote] What’s the rationale for the p