eskimo

[quote='870261022, MaheshGubbi, /thread/808088?answerId=870261022#870261022, /profile/MaheshGubbi'] will there be any problem in apple review ? [/quote] DTS and App Review are separate organisations and we can’t give you definitive answers about their policy. My general advice is: Check App Review’s published guidelines. If that doesn’t answer your question, you should feel free to engage with App Review directly. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='870122022, Hylus-Arbor, /thread/806187?answerId=870122022#870122022, /profile/Hylus-Arbor'] We had a similar issue with Accessibility permissions in 26.1 and 26.2 Beta. However it has now been fixed in 26.3 Beta. [/quote] [quote='870110022, dseijffers, /thread/806187?answerId=870110022#870110022, /profile/dseijffers'] Seems that this is resolved in 26.3 beta 1 [/quote] That gels with my expectations. Thanks for taking the time to test this on the beta seed. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

First up, you’re correct that there’s a contradiction here: Apple has effectively deprecated the file-base keychain in favour of the data protection keychain. But the Personal Team limits, which come from iOS, run counter to the expectations of macOS developers. I don’t have any answers for you on that front, but if you file a bug describing this contradiction and post the bug number here, I’ll make sure that the relevant folks see it. Coming back to your real issue, there’s a lot to unpack there and I don’t have time to dig into it all. However, you seem to have bumped into a pretty fundamental limitation: You want the system to protect your item such that only your program can access it. But you’re not giving it any code-signing credentials to do that. Something has to give. The file-based keychain has a bunch of legacy access control centred around code-signing requirements — see TN3127 Inside Code Signing: Requirements — so that’s one thing you might explore. But that still requires you to have a stable c

[quote='869055022, Yvan.d, /thread/809534?answerId=869055022#869055022, /profile/Yvan.d'] could this type of Keychain item design … lead to the kind of attribute inconsistency [/quote] It’s certainly possible. My experience is that there’s a lot of really bad keychain code out there )-: That’s partly because the SecItem API is way more subtle than people think, and partly because Apple’s initial documentation and sample code for it was… well… less than ideal. Moreover, the keychain is a persistent database where it’s important to not lose user state. So if your app has been around for a while, debugging a keychain problem means that you have to understand your current code and all the previous iterations of that code. There’s a few ways to tackle a problem like this: You could use source control to resurrect old versions of your keychain code, put all that code in a test app, and then try it out. You could use telemetry to understand the state of your users’ keychain items in practice. You could do what you’r

[quote='869124022, shi11, /thread/661320?answerId=869124022#869124022, /profile/shi11'] Would it be possible to get a status update? [/quote] No. Our focus here on the forums is APIs. We can’t help you with account issues because the forums are public and the details of your account are not. The standard escalation path for entitlement requests is Apple > Developer > Contact Us > Development and Technical > Entitlements. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Well, that’s weird. And it doesn’t gel with my experience. Admittedly, that was all prior to iOS 26, so it’s possible we broke something. I’m gonna try to reproduce this here in my office, but I won’t have time to do that until after the winter break. [quote='869103022, captadoh, /thread/808917?answerId=869103022#869103022, /profile/captadoh'] Are you open to me inviting you to a private Github repo? [/quote] It’s much more convenient to do this with public source code. Keep in mind that you don’t need a full app to test this. Just getting TCP to connect (or the QUIC tunnel) is sufficient to confirm that peer-to-peer Wi-Fi is working. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

No, alas. As I mentioned at the start, App Clips isn’t really my area of expertise. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='869090022, Mathias_, /thread/808401?answerId=869090022#869090022, /profile/Mathias_'] most applications should just perform the request regardless … ? [/quote] Yes. When using URLSession, our general advice is to: Set up your constraints in advance, that is, things like allowsConstrainedNetworkAccess. Set waitsForConnectivity. Issue the request. Implement urlSession(_:taskIsWaitingForConnectivity:) if you need to know that the request is waiting. This is useful, for example, if you want to update your UI. Apply your own timeout if you feel that’s absolutely necessary, or use timeoutIntervalForResource [1]. Note In cases like yours, where it’s a now-or-never kinda thing, it’s fine to skip steps 2 and 4. We specifically recommend against preflighting your network requests because: TOC/TOU makes it impossible to do correctly. Which means you’re required to handle errors anyway. So you might as well not implement the preflight. An incorrect preflight can prevent you from making a network request that migh

[quote='869104022, scottbonar, /thread/809596?answerId=869104022#869104022, /profile/scottbonar'] We are grabbing the dict from State:/Network/Interface//AirPort [/quote] From System Configuration framework’s dynamic store? How are you accessing that on iOS? This is iOS, right? I mean, you’re talking about CarPlay and cellular, which AFAIK are iOS-only features, but I wanna be 100% sure. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='809913021, ArcticSentinel, /thread/809913, /profile/ArcticSentinel'] Does NEURLFilterManager require the user's device to be at a minimun of ios 26? [/quote] Yes. [quote='809913021, ArcticSentinel, /thread/809913, /profile/ArcticSentinel'] Does any of these APIs/Extensions require the device to be managed/supervised or can it be released to all consumers? [/quote] This varies based on a bunch of factors. TN3134 Network Extension provider deployment has all the details. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

My response on that other thread still applies here. Can you reproduce this on a clean machine? Or are you only seeing this on specific Macs? Specifically, I recommend that you run this test: Install your target OS in a VM. Take a snapshot of the clean VM for the benefit of future tests. Install your product as a user would. Update your product as a user would. Does that reproduce the problem? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='869201022, Gong, /thread/765648?answerId=869201022#869201022, /profile/Gong'] Same issue here. [/quote] Are you specifically referring to the com.apple.CommCenter.fine-grained? If so, are you seeing this problem only with Xcode Cloud builds? Or are you seeing it when you build with Xcode locally? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Let’s start with terminology. When talking about phones, clone doesn’t mean what you think it means (-: [1] The correct name for the mechanism that allows a user to easily migrate to a new iPhone is Quick Start. Apple Support has an article that explains the user side of this: Use Quick Start to transfer data to a new iPhone or iPad. If you store information in the keychain then, yes, it’ll be migrated during the Quick Start process. There’s no specific API to prevent that [2]. One thing you can do is sign some data with a key that’s protected by the SE. Such a key will only work with that specific SE. However, there’s a caveat here. When you protect a key with the SE it’s bound not just to that SE but to that instance of the SE. Imagine the user does something like this: Sets up your app. Backs up their device. Erases it. Restores from the backup. Step 3 generates a new instance of the SE and it won’t be able to use the key you created in step 1. You’ll need some strategy to recover from that case. Finally,

You tagged your thread with “Swift Playground”. Does that mean you’re using the Swift Playground app? Or using Xcode with a playground project? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='809934021, DenisPoliarush, /thread/809934, /profile/DenisPoliarush'] Is it possible that the required agreement is available only to the Account Holder … ? [/quote] I’m not sure about visibility, but only the Account Holder is allowed to accept legal agreements. See the “Accept legal agreements” row in the chart on Developer > Support > Articles > Program Roles. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com