“DTiPhoneSimulatorErrorDomain Code 2”

[quote='887853022, Madhuri_Ramapure, /thread/826318?answerId=887853022#887853022, /profile/Madhuri_Ramapure'] When an app is forcefully terminated, all background network tasks are cancelled [/quote] Correct. It’d be more accurate to say “tasks in a URLSession background session”, but the gist is right. I discuss this in some detail in Testing Background Session Code. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='888263022, DTS Engineer, /thread/824359?answerId=888263022#888263022'] And yet I’m telling you that I’ve personally seen them get resolved. Weird eh?[/quote] Hi Quinn, I posted (and you quoted) There’s never once been a post by anyone that their status code 7000 problem got resolved. Do you have a link to any post by anyone claiming that after they followed the official path that their status code problem was resolved? To be fair I didn't write There's never been second-hand anecdote by a forum mod with zero evidence provided that someone else's status code 7000 problem got resolved. You referenced Brad's thread and said you know it was fixed. Brad has been VERY vocal in his status code 7000 problem since February and even went so far as to blanket the internet last week (mid-May) with posts saying that he was still encountering the problem. Can you provide a hyperlink to this very vocal poster where he cites that Apple did fix the issue and he's now able to notariz

[quote='887858022, Spartan81, /thread/824359?answerId=887858022#887858022, /profile/Spartan81'] There’s never once been a post by anyone that their status code 7000 problem got resolved. [/quote] And yet I’m telling you that I’ve personally seen them get resolved. Weird eh? I believe there are a number of filters in play here, including: Some fraction of folks follow the standard DevPrograms path and the issue is resolved quickly. Some fraction of folks issue are unwilling to discuss the resolution in public. I’m not going to be drawn into speculation as to why that might be. Some fraction of folks simply forget to come back and close the loop [1]. I’m sorry I can’t help you with this but this isn’t an issue for DTS to resolve and, while I’m usually happy to wade into other team’s ponds, this specific issue has to be handled through official channels. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] For example, I happen to know

Are you sure there are two different Team IDs involved here? A lot of questions like this are, in my experience, caused by folks mixing up their Team ID with one of the other 10-character identifiers that Apple uses. I have a post that explains that source of confusion: Code Signing Identifiers Explained Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

RESOLVED — Posting what fixed it in case it helps others After a lot of debugging, the invalid_client error was caused by using Sign in with Apple (SIWA) endpoints instead of the Apple School Manager API endpoints. These are two completely separate OAuth systems that look very similar but are not interchangeable. Here is a direct comparison of what was wrong vs. what is correct: ❌ What I had (SIWA) ✅ What ASM API requires Token endpoint appleid.apple.com/auth/token account.apple.com/auth/oauth2/token JWT aud claim https://appleid.apple.com https://account.apple.com/auth/oauth2/v2/token JWT iss claim Organisation ID (55155430) API client ID (SCHOOLAPI.xxx) JWT sub claim Client ID (SCHOOLAPI.xxx) API client ID (SCHOOLAPI.xxx) — same as iss jti claim Not included Required — unique UUID per request client_id in request body Not included Required API base URL api.apple.com/v1 api-school.apple.com/v1 The working JWT payload looks like this: { iss: SCHOOLAPI.7c0c10a0-4d8a-4ef8-a2be-eda040b65c59, sub: SCHOOL

Hi MyMattes — sharing some experimental data in case it's useful for the discussion. While debugging icon jail behavior on Tahoe 26 for some other apps, I ran a controlled experiment that pinpointed an exact pixel-level trigger condition. Hadn't seen it documented anywhere, so it might add some context to your concerns about transition paths. The trigger is a single binary condition on edge pixel alpha: alpha ≥ 253 → filled rounded clip (no frame) alpha ≤ 252 → forced squircle frame + scaled-down inset The threshold sits exactly between 252 and 253. Verified with 12 controlled test apps using identical solid-color icons but varying alpha (255, 254, 253, 252, 250, 245, 240, 200, 128, 50, 10, 1). Values 255/254/253 render cleanly; everything ≤252 gets jailed with identical frame width regardless of how low alpha goes. Two findings worth highlighting: Frame width is constant. alpha=252 and alpha=50 produce frames of identical size. Lower alpha just makes the inner image more transparent (the desktop ble

This is much, much funnier than you'd realized. Up until COVID took... I can imagine! And don’t get me wrong, I really understand why you guys are suggesting the Network framework. IMO, it makes total sense for new applications to build directly on top of that. But I think there’s still a lot of value in fixing the MPC framework, because there are many apps and libraries out there relying on MPC. In our case, for example, we’re also quite restricted in terms of update policies due to our very regulated domain. We can’t simply push updated apps to customers, or at least not to customers running years-old versions who either don’t want to or can’t update to more recent releases. In those situations, we rely on Apple fixing these issues on the OS side. We also wouldn’t be raising awareness here if this had always been an issue. Our apps have relied on MPC for almost a decade now (the code goes back to 2018), and for our use cases it worked flawlessly (it really did :D). Customers used it extensively wit