“eskimo”

[quote='878914022, captadoh, /thread/808917?answerId=878914022#878914022, /profile/captadoh'] Could me passing a closure that throws to NetworkListener.run(_:) be the cause of my issues? [/quote] That’s unlikely. I mentioned it purely because it’s one of the various random issues I’ve bumped into during this process. But if you’re worried about this, I recommend that you make your closure non-throwing like so: listener.run { do { … your code here … } catch { … log the error … } } Sadly, I’ve still not made relevant progress on your main issue. I think I need to just bite the bullet and create a minimal test project, rather than try to build something ‘correct’. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='878887022, Nickkk, /thread/817724?answerId=878887022#878887022, /profile/Nickkk'] But the crash report mentions the architexture x86_64, which I don't own myself anymore. [/quote] If you run your app under Rosetta it can still run vmmap against, and I think the reported __TEXT segment size will match what you get on a real Intel Mac. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Cool. I consider this to be a problem with Xcode’s build system, but it’s an understandable one. Xcode knows that your tool depends on this library — because it adds an import of it — but, being a command-line tool, it doesn’t have anywhere to embed the library. It should embed it in the container app, but it’s clearly not doing that. I think it’s worth filing a bug against Xcode about that. And if you do, please post your bug number, just for the record. As to a workaround, there’s a couple of ways to approach that. The first is the obvious one we’ve been discussing here: Add a dummy use of Subprocess within your app. Xcode will embed libswiftCompatibilitySpan.dylib, because it knows that your app needs it, and your tool can pick it up from there The other option is to embed the library explicitly. This is complicated by the fact that the library exists within a toolchain, so it’s not clear how to reference it [1]. For the moment I recommend that you go with the first option. I’m going to talk to some collea

OK. Lemme explain how I’d tackle this and then you can either try it yourself or, if you’ve tried it already, share your experience. I typically test this stuff with a small test project. I set it up to run a request via URLSession and also load a page via a web view. I then run my debugging infrastructure against that test app. If things work there, I can run the same setup against my real app with some confidence that my debugging setup is working. OTOH, if I can’t get the results I expect with my test app, I know that there’s something wrong with my debugging setup. I haven’t tried mitmproxy recently, but the last time I did it worked a treat. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='818269021, anonymousdev332299, /thread/818269, /profile/anonymousdev332299'] is both a Developer ID certificate and Apple notarization required on current macOS versions? [/quote] Yes. Developer ID signing has been required for a long time (10.8?). Notarisation for apps has been required since 10.14. [quote='818269021, anonymousdev332299, /thread/818269, /profile/anonymousdev332299'] Is [ditto] necessary to properly preserve the app bundle structure and extended attributes? [/quote] Yes and no. If you compress with the Finder then extended attributes get sequestered, which is not good. See Extended Attributes and Zip Archives. The ditto tool doesn’t do that by default. However, in an ideal world this wouldn’t matter because your code signature should not depend on extended attributes. If you find that it does, that suggests your have a bundle structure problem. We talk about this more in TN3126 Inside Code Signing: Hashes and Placing content in a bundle. As to what’s actually happening here, it’s hard

I’m not entirely sure what’s going on here, and it’s hard to talk about the specifics without… well… you sharing info about the specifics, like what MyApp is. However, if this is a new App ID then I’ve found that it’s quicker to not try to resolve the underlying issue but instead pick a different App ID. For example, com.automaticduck.My-App. 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

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

What _lilpit said, plus… For more on this, see here. 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

[quote='878847022, jzilske, /thread/817599?answerId=878847022#878847022, /profile/jzilske'] the HTTP Traffic Instrument does not seem to record anything [/quote] Indeed. I had just assumed that it’d work for requests generated by a web view, but I tried that here today and it doesn’t seem to be the case )-: Still, that’s more evidence that this QUIC traffic is coming from a web view, which is very likely to be HTTP/3. And you should be able to intercept that with a debugging HTTP proxy. Have you tried that already? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Honestly, I’m not sure what’s going on here. None of this sounds at all familiar. I’d like to get a copy of your installer package so that I can poke at it myself. Can you share a link to a download site here? [1] If not, you can file a bug and attach it to your bug report, and then post the bug number here. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Posty your link in the clear; see tip 14 in Quinn’s Top Ten DevForums Tips.

Thanks for filing FB22152886. Zenning on this over the weekend I realised that there’s a much easier solution here. This is based on two key factoids: The app under test must have the Local Network privilege. Local network privacy doesn’t apply to loopback connections. So, you can set up a network listener in your app that listens for incoming connections and, for each one, opens a connection to your accessory and proxies traffic between the two. Your UI test can then connect to 127.0.0.1 and talk to the accessory indirectly through the app. I prototyped this in my office and it seems to work. I recommend that you try it out and see how far you get. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='878607022, Nickkk, /thread/817724?answerId=878607022#878607022, /profile/Nickkk'] I'm assuming that's what you mean by Mach-O image. [/quote] A Mach-O image is code that can be mapped into memory by the dynamic linker and then run directly, as opposed to something like a .o file that contains code that must be linked before it can be run. I talk more about this in An Apple Library Primer. A Mach-O image is often stored within a universal binary, one image per architecture. So when looking at stuff like this you have to consider the image of the architecture that was running. The other thing to considered is that the dynamic linker may only map in parts of your image. A good way to see what actually gets mapped is to run the app and then run vmmap against it. Consider this: % ls -lh Pages Creator Studio.app/Contents/MacOS/Pages -rwxr-xr-x 1 root wheel 45M 16 Jan 02:44 Pages Creator Studio.app/Contents/MacOS/Pages The Pages executable is 45 MiB. And this: % file Pages Creator Studio.app/Contents/MacOS/P

Thanks for posting that log entry. Using that I was able to quickly locate the code that enforces this restriction. It turns out that your analysis is spot on. The content filter machinery is generally limited to 8 filters [1] and on macOS this is divided evenly between the two filter grades [quote='878777022, faisalIkwal, /thread/793289?answerId=878777022#878777022, /profile/faisalIkwal'] Is this documented somewhere? [/quote] Oh, hey, wouldya look at that, it’s actually documented on this page within the Apple Platform Deployment guide. (I really need to spend an afternoon reading that doc thoroughly.) Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] This is visible as CFIL_MAX_FILTER_COUNT in the Darwin open source. WARNING As always, stuff you find in Darwin is considered an implementation detail rather than an API.