“eskimo”

You can expect that most uploads will be notarised quickly. Occasionally, some uploads are held for in-depth analysis and may take longer to complete. As you notarise your apps, the system will learn how to recognise them, and you should see fewer delays. For lots of additional info about notarisation, see Notarisation Resources. Specifically, it links to a Q&A with the notary service team that’s quite instructive. [quote='878814022, James21180, /thread/818070?answerId=878814022#878814022, /profile/James21180'] It’s frustrating when there is no feedback to understand what’s going on. [/quote] Indeed. I’ve recently filed my own bug requesting better feedback in this case (r. 170230393). Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='818029021, Kuroglo, /thread/818029, /profile/Kuroglo'] Could DTS help enable notarization for my team? [/quote] No, sorry. I suspect you might’ve found this post already but, if not, have a read. As I mention there, I’m not able to escalate this. While I’m usually quite happy to wade into other team’s ponds, this specific issue has to be handled through official channels. 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

Thanks for all that extra info. So, it’s definitely correlated with iOS 26.3. Which is strange, because I can’t think of any iOS 26.3 aligned change to local network privacy that would affect this. You could file a bug about this issue, but I’m not sure it’d get traction. As you noted in your first post, this whole process is a bit of a kludge, and it’s hard to argue that we should fix this (in contrast to FB12846267, which we definitely should fix, but haven’t yet). But if you do file a bug, please post your bug number, just for the record. At this point I think it might be worth considering different approaches. I zenned on that a bit today and I wasn’t able to come up with anything I’m truly happy with. One approach that I like is to have your UI test use some sort of IPC mechanism to the app, have the app connect to the accessory under test, and then proxy the UI test’s requests to that accessory. Unfortunately I couldn’t think of a good way to do that. It is possible to set up an IPC channel between apps

Your setup, prohibiting Wi-Fi and enabling peer-to-peer, is contradictory — peer-to-peer Wi-Fi is a ‘subclass’ of Wi-Fi — so I’m not surprised you’re seeing weird results. [quote='878519022, nikhil2701, /thread/817831?answerId=878519022#878519022, /profile/nikhil2701'] But there are some cases where I want to allow only peer to peer. [/quote] I don’t think that’s feasible without how the networking stack currently works. Well, assuming you’re talking about Apple peer-to-peer Wi-Fi, which is what includePeerToPeer controls. You could change tack and set up your connection with Wi-Fi Aware. IIUC such a connection will never run over infrastructure Wi-Fi. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='878529022, ski4funSonoma, /thread/817488?answerId=878529022#878529022, /profile/ski4funSonoma'] Including the sample code in the helper [/quote] Ah, I think you misunderstood that test. I was suggesting that you temporarily add that code to the app, with some sort of debug UI wired up to call it. That has two benefits: If it fails in the app context then there’s something weird going on. If it works in the app context, it should cause Xcode to embed libswiftCompatibilitySpan.dylib which might then ‘fix’ your helper tool. And if that second point is true, it confirms the nature of the problem and suggests a path to a workaround. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

If it’s a QUIC connection and the logs has a com.apple.WebKit.Networking subsystem, it’s almost certainly HTTP/3. Have you tried the HTTP Traffic instrument? See Analyzing HTTP traffic with Instruments. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

That looks like a very straightforward sandbox violation. I think this is NFS specific, because my understanding is that other network file systems can be mounted within your app’s container. I’m going to consult with a colleague about this, but I suspect that this is ultimately going to end up being a bug report. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='878469022, Nickkk, /thread/817724?answerId=878469022#878469022, /profile/Nickkk'] Is the unmapped memory exception also the reason why the binary image address for my app is 0x0 - 0xffffffffffffffff? [/quote] Sadly, it’s not that simple. I created a small test app with this code: - (IBAction)testAction:(id)sender { #pragma unused(sender) NSLog(@-[AppDelegate testAction:]); void * p = (void *) 0x123456789ab; typedef void (*FunctionPtr)(void); FunctionPtr f = (FunctionPtr) p; f(); } and it produces a crash report like this: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x00000123456789ab Exception Codes: 0x0000000000000001, 0x00000123456789ab … Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 ??? 0x123456789ab ??? 1 xxom 0x10e301bf3 -[AppDelegate testAction:] + 83 2 AppKit 0x7ff81fa612ea -[NSApplication(NSResponder) sendAction:to:from:] + 444 … Thread 0 crashed with X86 Thread State (64-bit): … rip: 0x00000123456789ab rfl: 0x0000000000010202 cr2: 0x0000012

[quote='878552022, HiddenJester, /thread/748447?answerId=878552022#878552022, /profile/HiddenJester'] The bug number is FB22140603. [/quote] Thanks! Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='878482022, Pavel, /thread/817602?answerId=878482022#878482022, /profile/Pavel'] Our IPC implementation is based on [/quote] I find it strange that this is limited to sockaddr_un. macOS is not unusual in longer paths; I don’t know about Linux, but pretty much all the BSDs work this way. [quote='878482022, Pavel, /thread/817602?answerId=878482022#878482022, /profile/Pavel'] Are there any guarantees the path returned by this function will always fit within the buffer sockaddr_un? [/quote] I’ve never seen such a guarantee. [quote='878482022, Pavel, /thread/817602?answerId=878482022#878482022, /profile/Pavel'] are there any other locations for IPC sockets that avoid this path length restriction? [/quote] The traditional location for this stuff is /var/run. See the hier man page. But if you do use that, choose an appropriately unique file name to avoid collisions with the system and other third-party products. Typically that means using reverse DNS or embedding your company or product name in the file name.

[quote='878490022, N. Holzschuch, /thread/817449?answerId=878490022#878490022, /profile/N.+Holzschuch'] I have filed a report: FB22138371 [/quote] Thanks. decomposedStringWithCanonicalMapping should work here, but Kevin would probably advise that you go via URL and then use the withUnsafeFileSystemRepresentation(_:) method instead. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='817887021, kappie, /thread/817887, /profile/kappie'] Both produce: Warning: unable to build chain to self-signed root [/quote] Hmmm, that doesn’t sound good. Have you tried testing the cross-over cases? That is: Building on macOS 26.3 and trying to install on macOS 26.2 Building on macOS 26.2 and trying to install on macOS 26.3 Those will let you determine whether this is a build problem or an install problem. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You can expect that most uploads will be notarised quickly. Occasionally, some uploads are held for in-depth analysis and may take longer to complete. As you notarise your apps, the system will learn how to recognise them, and you should see fewer delays. For lots of additional info about notarisation, see Notarisation Resources. Specifically, it links to a Q&A with the notary service team that’s quite instructive. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

OK. When you run this command, what do you see: % find YourApp.app -name libswiftCompatibilitySpan.dylib YourApp.app/Contents/Frameworks/libswiftCompatibilitySpan.dylib libswiftCompatibilitySpan.dylib exists to provide Span support on older systems. AFAICT it’s expected to work on Intel Macs running 13.1 or later: % vtool -show-build Test817488.app/Contents/Frameworks/libswiftCompatibilitySpan.dylib Test817488.app/Contents/Frameworks/libswiftCompatibilitySpan.dylib (architecture x86_64): Load command 10 cmd LC_BUILD_VERSION cmdsize 32 platform MACOS minos 13.1 sdk 26.2 ntools 1 tool LD version 1230.1 … And I tested it here in my office, on both 26.2 (Rosetta) and 13.6.1 (real hardware), and I didn’t have a problem. However, that was from my main app, not from a privileged helper tool, so it’s possible that there’s something specific to privileged helper tools in play here. My test code is pasted in at the end of this email. If you temporarily add this to your app, does it work on the same Intel Mac? And with