eskimo

Can you try this on macOS 26.1? Or the latest 26.3 beta seed? I’m not sure I’m reading FB18543729 correctly but I have a suspicion that the fix might be in those releases but not 26.2 )-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

For those following along at how, emilsp and I have been continuing this discussion over in VPN profile corruption. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

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. On what product shall I add the feedback. In Feedback Assistant, first choose Developer Tools & Resources and then choose XCTest from the “What area” popup. Please post your bug number, just for the record. Finally, I have a lot of hints and tips on how to file bugs effectively in Bug Reporting: How and Why? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='873227022, Claude31, /thread/813376?answerId=873227022#873227022, /profile/Claude31'] That's no more the case, so data is empty, hence the problems. [/quote] Indeed. The solution is to get the encodedData property: let archiver = NSKeyedArchiver(requiringSecureCoding: true) archiver.encode(Hello Cruel World! as String, forKey: greeting) archiver.finishEncoding() let data = archiver.encodedData print(data.count) // 162 [quote='873227022, Claude31, /thread/813376?answerId=873227022#873227022, /profile/Claude31'] I do not use decodeObject(of:) … Is it OK ? [/quote] No. A key goal of secure coding is that you should tell the decoder what type you’re expecting. That allows the decoder to apply its own type checking. This is critical in Objective-C, where it’s easy to confuse types. It’s less critical in Swift, where the compiler is much stricter about type checking, but it’s still the right thing to do. So, whenever you decode, aim to use a decodeXyz(…) method that takes type information. Share and Enjoy —

I’m not sure what sort of help you’re expecting me to provide here. As I mentioned above, this looks like a bug to me. If I had a bug report with a sysdiagnose log, I might — and I want to stress the might here — be able to offer more insight. But without that, I’m flying completely blind. In terms of a workaround, I see two potential options: You could explore user-level workarounds with your user. For example: You might have them reset Face ID (Settings > Face ID & Passcode > Reset Face ID) and re-enroll. Or have them disable the device passcode and then re-enable it. Or have them back up their device and restore from that backup. All of these things are common patterns for clearing out mysterious problems. You could explore code-level workarounds. For example: You might change your system to record multiple biometric domain states. Or have an option to disable biometric domain state checking for specific users. It’s hard to offer specific advice on either of these fronts because I don’t have a re

I recommend that you start a new thread about this, making sure to include the details of this crash. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Again, I’m struggling to read your post. Chunks of text are being munged because you’ve not put them inside a code block, which makes it hard for me to offer advice because I can’t tell whether the info I’m looking at is accurate. Please repost it with better formatting. Earlier I mentioned Quinn’s Top Ten DevForums Tips. Please read it through, especially tip 5. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='873232022, naftaly, /thread/812973?answerId=873232022#873232022, /profile/naftaly'] First step is to figure a way to get the underlying xpc_connection_t from an NSXPCConnection. [/quote] There isn’t a supported way to do that. I presume that you want to do that so that you can transfer Mach ports over the connection. If so, there’s an alternative path: Create an XPC dictionary. Add a send right to the dictionary using xpc_dictionary_set_mach_send. That dictionary is an xpc_object_t, so you can send it over the NSXPCConnection using NSXPCCoder. On the receiving side, get the send right from the XPC dictionary using xpc_dictionary_copy_mach_send. Or at least that should work. I’ve never actually tried it (although I have exercised step 3 with other types of xpc_object_t). I recommend that you prototype this on your Mac using a loopback connection, as explained in TN3113 Testing and debugging XPC code with an anonymous listener. And you can use lsmp (see the lsmp man page) to make sure that you got all t

The older NWConnectionGroup API doesn’t really model datagrams correctly. In the latest API, NetworkConnection, the modelling makes more sense, where there’s a single subconnection for datagrams. Are you able to use the new API? If so, I encourage you to try that. But if you have to stick with the old API, most commonly this is because you want to support systems prior to xyzOS 26, lemme know and I’ll dig into that. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Tag names are not available on iOS. Xcode does a pretty good job of explaining that. Consider this snippet: let values = try url.resourceValues(forKeys: [.tagNamesKey]) // ^ 'tagNamesKey' is unavailable in iOS let tags = values.tagNames ?? [] That fact is also reflected in the documentation for the tagNamesKey property. I’m not sure why the documentation for the tagNames property gets this wrong, but it’s definitely a bug in the docs and I encourage you to file it as such. Please post your bug number, just for the record Taking a step back, I can see why you might want to work with tags on iOS, so I encourage you to file a separate enhancement request asking for this property to be made available there. Again, please post your bug number. 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. [quote='813441021, Eligian, /thread/813441, /profile/Eligian'] Usually this process is fairly quick for this app [/quote] Interesting. Based on what I see here in the forums, most folks in this situation don’t have an app with a long notarisation history. [quote='813441021, Eligian, /thread/813441, /profile/Eligian'] These have been stuck in progress for a long time. [/quote] Can you elaborate on what “long time” means here? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Quoting Developer > Swift Student Challenge > Eligibility: Your creation should not rely on a network connection Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

There’s nothing Apple-specific about this. My understanding is that the Wi-Fi Aware standard has mechanisms whereby a peer advertises the channel bandwidth to other peers [1]. [quote='813077021, Bojie_Lv, /thread/813077, /profile/Bojie_Lv'] what is the channel bandwidth used by AirDrop? [/quote] We don’t document AirDrop for third-party use. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] I’m not an expert in the standard, but I asked about this internally and folks who are tell me that you should look at Operation Mode field format info in Table 81.

What Kevin said plus… It’s reasonable to use different approaches for different subsystems in your app. For example: If you’re fetching an audio file to play immediately, a standard session is probably best. Critically, it results in the least latency, which is important because you’re actively playing that audio. And while this requires your app to not suspend, that’s OK because you’re playing audio. If you’re downloading a large file that the user isn’t actively playing, a background session makes sense. If you’re scanning for updates, you could use a background processing task. This typically runs overnight, which is fine because the user isn’t expecting the results immediately. Unless they bring your app to the foreground and tap the refresh button, in which case you might run the same code immediately. And you can then use a continued processing task to complete the refresh. But that’s just one way to slice this. You have lots of options and it’s kinda up to you to decide which one makes sense based on t

It has nothing to do with Sign in with Apple. OK. Thanks for confirming that. I'm working on a roaming project for VoIP app development OK. Unfortunately, I don’t have a solution for you. As I mentioned previously, these values were historically available via various properties on the xxx class but that’s no longer the case. Access to this information was deliberately removed for privacy reasons. You’ll need to find another way to way to approach your overall problem. 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