“eskimo”

[quote='845723021, anvar102b, /thread/845723, /profile/anvar102b'] a Feedback Assistant report will follow [/quote] Yeah, this all sounds very bugworthy. Please reply here with the bug number once you have it. 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 additional 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

That is the DeviceFS FSKit extension, which is what allows you to browse the contents of attached iOS devices directly from the Finder. You can see it System Setting > General > Login Items & Extensions > By Category > File System Extensions. That UI normally allows you to disable the extension, but in this case that doesn’t work, probably because it’s considered ‘built in’. If you’d like to see that change, I encourage you to file a bug about it (please post your bug number, just for the record). In the meantime, you can avoid this by telling df to only show you APFS volumes: % df -T apfs Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I have a couple of big picture points for you to consider. The first is about your reason for doing this. If your goal is primarily to have fun while you make something, let that guide your technology choice. For example, there might be good reasons to implement this as a website (see below) but if you’re not enamoured with web development and really want to make a native app then… yeah… that’s what you should do. OTOH, if you want to ship and maintain a product then it makes more sense to follow a technology path that’s appropriate for that product, even if it’s less to your taste. Second, the one up-front decision to make is whether this program needs to share data between multiple users. If it does then you’ll need some sort of server technology. It might be possible to use an existing service — in the Apple ecosystem that’d be CloudKit — but that comes with its own set of constraints. If those constraints don’t work for you then you’ll end up needing to build your own server. And if you have to do that an

You’re on macOS 15, right? I fired up a 15.6 VM (sorry, I don’t have 15.7 handy) and here’s what I see in Console: So crash reports show up under “Rapports de blocage”. Unfortunately I don’t have macOS 15 Intel machine lying around to try this on (and I don’t have time to set that up today). However, I can confirm that macOS 26 still runs unsigned Intel programs: % sw_vers ProductName: macOS ProductVersion: 26.6.2 BuildVersion: 25G83 % cat simplest_ever_c_program.c #include int main() { printf(Hello World ! Gratz : this progam could be run from the Terminal !n); return 0; } % clang simplest_ever_c_program.c % file a.out a.out: Mach-O 64-bit executable x86_64 % codesign -d -vvv a.out a.out: code object is not signed at all % ./a.out Hello World ! Gratz : this progam could be run from the Terminal ! I suspect there’s something in your environment that’s triggering this. Do you work for a large enterprise? I sometimes see folks encounter problems like this when their enterprise’s endpoint security product block

[quote='904897022, ChrisMofus, /thread/844715?answerId=904897022#904897022, /profile/ChrisMofus'] The current submission is still visible to notarytool [/quote] Cool. That, and your view of the verbose logging, suggests that the upload is complete, which brings us to second common issue that folks bump in to, namely, additional analysis. I have a standard spiel about that, which I’ve included below. 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 additional 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.

Hey hey, most people in your situation find that the problem reproduces with a profile, which gets me off the hook (-: The disparity between your profile and your code means I actually need to do some work! It’s unlikely that the connect-on-demand stuff is a factor here, so I’m gonna focus on the disconnect-on-idle. You wrote: [quote='904777022, NSerfontein, /thread/844686?answerId=904777022#904777022, /profile/NSerfontein'] We noticed that the runtime configuration dump lists disconnectOnIdle and disconnectOnIdleTimeout inside the protocol dictionary [/quote] Indeed. When you look in the system log you should see a log entry that includes these configuration properties. Do you see different values for the working (profile) case and the non-working (API) case? I have lots of hints and tips about working with the system log in Your Friend the System Log. I usually do an analysis like this by triggering a log snapshot and then looking at the snapshot offline. In this case, you’ll want to focus on the com.apple.

Thanks for that info. Here on the Apple Developer Forums we’re primarily focused on helping developers with code-level problems. Given that this affects the machine as a whole, my advice is that you seek help via an Apple Support channel, for example, Apple Support Community. Oh, wait, you’re talking about macOS 27 beta. ASC doesn’t really traffic in betas, so you might want to wait until macOS 27 is released before asking over there. Assuming that you’re unable to reproduce this with macOS 26. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='845491021, CTMacUser, /thread/845491, /profile/CTMacUser'] is the Instance object passed to each method of NWProtocolFramerImplementaion the same? [/quote] Yes. [quote='845491021, CTMacUser, /thread/845491, /profile/CTMacUser'] If that includes the initializer, why do the other methods still want it? [/quote] I suspect it’s simply fallout from the way that the Swift API is layered on top of the C API. There’s no C equivalent of NWProtocolFramerImplementation. Rather, in C you create the framer by passing in a closure to nw_framer_create_definition, which in turns is expected to set up the other closures. Having said that, I think it makes sense to use the instance that’s passed in to each method rather than caching that in a property. That’s how all the framers I’ve ever seen work, and there’s at least one potential pitfall for not following that pattern, namely, accidentally creating a retain loop [1]. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail =

We’re not really in a position to comment on third-party tooling. My advice is that you seek help via that tooling’s support channel. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='845512021, wizzznet, /thread/845512, /profile/wizzznet'] I've just shipped a signed NetworkingDriverKit driver [/quote] Congratulations! Did you mean to redact all your FB numbers? Because it’d be nice to have them included here, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

OK. Given that, my advice is: File a bug about this. Include that .ipa, your analysis of the code signature of the enclosed app, and the logs from Transporter. Seek help from the App Store Connect folks via Apple > Developer > Contact Us. 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

Are you working on the same product as the user hjvoryn in that older thread? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

TestFlight is also the tool I would reach for. The simplest case — installing the app from the App Store and then upgrading that from TestFlight — is something I’ve seen a bunch of developers do. Testing the upgrade from older versions of the app is gonna be trickier. There isn’t a good way to install an arbitrary version of the app from the App Store, so the standard process doesn’t work. And installing Development or Ad Hoc signed .ipa isn’t a great option because the old team’s signing assets will expire at some point. Given that, I think you need to look at the specifics. What aspect of the upgrade process are you trying to test? For example, if you’re trying to test whether the new app handles the content of the old app’s container, you have more options. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I can’t really speak to the Core NFC specifics here but… iOS doesn’t offer a general way for a standard app to disable networking for the device as a whole. Apps can affect system networking, but there’s nothing appropriate for your use case. For example, an app can include a Network Extension provider that blocks networking, but such a provider must either be authorised by the user or by device manager. There’s also no general way for an app to do this to itself. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com