“eskimo”

I presume we’re talking about Team ID Y________J. If so, my view of your team indicates that you have the Default Mail App capability for a specific App ID (Y________J.e____.d___) and for Development and App Store distribution. That’s a pretty common setup [1]. You should be able to confirm that on the Developer website. See Finding a Capability’s Distribution Restrictions for instructions on how to do that. IMPORTANT Make sure you select the above-mentioned App ID. The Default Mail App capability will only show up there. Please do this and let me know what you see. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Don’t ask me why there’s no Ad Hoc or I’ll start to whimper )-:

[quote='848896021, mike87, /thread/848896, /profile/mike87'] 1- Is the Declared Age Range API itself available only on iOS 26+ devices … ? [/quote] Yes. The base Declared Age Range API is available on iOS 26.0 and later. As you noticed, there were additions in iOS 26.2 and iOS 26.4. Remember that, if you use an API that’s lower than your deployment target, Swift will complain. For example, if you write this code: let isRequired = try await AgeRangeService.shared.requiredRegulatoryFeatures.contains(.declaredAgeRangeRequired) and your deployment target is iOS 26.0, you’ll get an 'requiredRegulatoryFeatures' is only available in iOS 26.4 or newer error, with various fix-its explaining your options. If your deployment target is below 26.0 then you’ll get a related but different error: 'AgeRangeService' is only available in iOS 26.0 or newer. And, again, it will present you with various fix-its. [quote='848896021, mike87, /thread/848896, /profile/mike87'] 2- For users running iOS versions below 26, will the Declar

It looks like we already responded to you over on your other thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='907479022, OC_s, /thread/848903?answerId=907479022#907479022, /profile/OC_s'] the profile linked to my personal team BHHT72562H is available on the machine where the app has been developed [/quote] Kinda. The profile is actually embedded within your app, but a development profile contains a list of machines that it applies to and I suspect that your profile lists your development machine but not the other machine. You can confirm this using the instructions in TN3125 Inside Code Signing: Provisioning Profiles. The easiest way out of this is to not use a provisioning profile. However, your app’s entitlements include com.apple.developer.homekit, and I presume that’s required. In that case you need a profile because that entitlement is restricted, that is, its use must be authorised by a profile. If you were a member of a paid team there’s a standard way to fix this: Use the Developer website to add the other Mac’s provisioning UDID to your team. In Xcode, choose Product > Archive. Then in the Xcode o

[quote='907537022, DTS Engineer, /thread/848882?answerId=907537022#907537022'] I think this is a very reasonable use of libproc [/quote] Agreed. The situation with libproc is much like the situation with Mach. We strive to maintain binary compatibility but that’s tricky because it’s very tightly bound to the kernel’s implementation. Oh, one last thing: proc_signal_with_audittoken was added in some time during the macOS 14 release cycle, so you can’t use it before then. But I think you’ll be OK in this case because es_new_descendants_client requires macOS 27 anyway. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='907521022, mronian, /thread/848726?answerId=907521022#907521022, /profile/mronian'] Is this static plist plus kickstart arrangement within the intended … model … ? [/quote] Your overall goal isn’t well supported by macOS as things currently stand, and this approach is my best response to that. Specifically, you have the bits in place such that, if the background task management subsystem starts to notice your agent, it should understand that the agent is associated with your app. However, you’re gonna need to do some testing, both to ensure compatibility with any older releases you support and to confirm that things still work as new OS releases are seeded. Then again, you should be doing that anyway (-: [quote='907521022, mronian, /thread/848726?answerId=907521022#907521022, /profile/mronian'] On disable or unregister, should our daemon leave the agent job loaded and let the helper exit on socket EOF … ? [/quote] That’s what I’d recommend. It keeps the system configuration static, which is kind of th

I’ve been talking to folks in the same boat on this thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hmmm, you’ve tried a lot of things but AFAICT you didn’t try the first thing that I would’ve tried, namely copying the app to a different Mac to see if it verifies there. Did you try that? If so, what were the results? If you didn’t try it, please do that now and let me know what you get back. I recommend that you use a newly installed virtual machine for this test, because that way you can repeat the test by restoring the VM to a ‘clean’ snapshot, one that’s never seen your app previously, between each test. Note that you don’t have worry about Gatekeeper here, your key test — running codesign --verify — doesn’t care about the Gatekeeper state of the code. So, you can just zip up the failing up, copy it across to the VM, unzip, and try to verify its code signature. [quote='849002021, marucello, /thread/849002, /profile/marucello'] I have also observed the following message in the Security log during signing: CSSMERR_CSP_INVALID_KEYATTR_MASK [/quote] What was the full text of that log message? I’m curious bec

On modern systems SessionGetInfo is basically a wrapper around auditon with the A_GETSINFO_ADDR selector. See the auditon man page for more on that. Both of these APIs are fundamentally racy. There’s a source of truth (currently held in the kernel) and the API returns a copy of the information from that source of truth. The API has no locking, so the source of truth can change between when the system makes the copy to return to you and when you look at it. There’s simply no way to avoid that. Audit sessions IDs are relatively large (32 bits) and the system tries to avoid reusing them, so if the session has gone away then you’re likely to get an error rather than the data for an unrelated session. However, I use the word likely deliberately. I don’t think there’s anything that’ll explicitly prevent that. A process references its audit session and, in general, that doesn’t change for the lifetime of the process [1]. So, if you know that the process is still alive you can reasonably assume that the audit session

What version of the Swift Playground app are you running? And on what version of iPadOS? ps For hints and tips on how to use the forums effectively, see Quinn’s Top Ten DevForums Tips. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

The best way to deal with this problem is to avoid creating it in the first place. That is, when you start developing an app, do so as a member of the team that intends to publish the app. Ideally that’d be on Organization team, so the Account Holder can add you as an App Manager or Developer [1]. However, if you didn’t do that there there are two standard ways of tackling this problem: Convert your Individual team into the Organization team. For info on how to do that, see Developer Account Help > Membership > Program enrollment. Transfer the app from your Individual team to the Organization team. For info on how to do that, see App Store Connect Help > Transfer an app The first option is the most seemless seamless, but it only makes sense if the Organization doesn’t currently have a team. The second option comes with some caveats; see the docs for the details. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] S

[quote='848966021, opalc, /thread/848966, /profile/opalc'] If there is any official Apple documentation [/quote] Yes there is. Quoting TN3155 Debugging universal links: Confirm your website’s configuration allows direct access to the AASA file in the .well-known directory, in all geographical locations, from any IP address. Specific IP addresses and ranges are not published as they cannot be guaranteed. ps The search function on the Developer website was recently revamped, and it’s pretty good at finding stuff these days, especially when the focus is on “official Apple documentation”. For example, my search for “what ip addresses can access my aasa file” found TN3155 and highlighted the relevant paragraph. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I don’t think there’s anything I can do to help out here: Regarding bug priority, the network engineer team sets its own priorities based on a lot of competing demands on its time from a lot of different folks. Regarding Darwin source drops, historically Apple has released Darwin source shortly after the corresponding macOS release, but there’s no concrete timeline for this. So, while I’m happy to look at specific API-level problems, there are limits to what I can do about the big picture. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’m gonna recommend that you start out by reading this thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

So the Swift Student Challenge is not currently running, and AFAIK there’s been no announcement about a future challenge, and that includes what its rules might look like. Given that, I can’t give you an answer here. However, you raise a good point and I’ve brought it to the attention of the folks who run the challenge. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com