“DTiPhoneSimulatorErrorDomain Code 2”

[quote='888654022, rbmanian75, /thread/826990?answerId=888654022#888654022'] I have already set this to true. [/quote] OK. I’d like to clarify the actual goal here. On macOS function keys behave [1] in one of two different ways: Without the fn modifier, the function keys perform built-in actions. For example, pressing F10 on my MacBook Pro perform a mute action. With the fn modifier, the function keys generate traditional function key events. For example, pressing fn + F10 generates an F10 function key event. Which of these are you trying to route to the guest? Also, you specifically called out F10 and F11. Were those just examples? Or are you seeing different behaviours for different function keys? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] You can reverse these two options with System Settings > Keyboard > Keyboard Shortcuts > Function Keys > Use F1, F2, etc. keys as standard function keys. Wow, we re

You’re not the first person to notice this. I can’t provide any backstory, but I will say that an enhancement request to bring this back feature would be welcome [1]. Make sure to include an explanation of why you want this. Please post your bug number so I can add it to my own personal watchlist. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] I’m almost certain that someone has already filed a bug about this, but I spent a bunch of time looking for that today and I couldn’t find it. It may have got merged into a wider bug about our user name story in general (right now if two DTSers are helping you on a thread, it’s hard to tell them apart). Regardless, a new bug from a third-party developer explaining the value they see in the feature would be useful.

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='827096021, mazzystar, /thread/827096, /profile/mazzystar'] Is it expected for Developer ID notarization jobs to remain “In Progress” for more than a day with no log available? [/quote] Yes, if you hit the in-depth analysis path mentioned above. We don’t document a detailed list of criteria that cause a request to get on that path. However, one thing I’ve noticed here on the forums is that folks with new apps, or new teams, are commonly affected. Given that, I’m not super surprised that you’re seeing it after an app transfer. My advice here is that you simple wait. This state usually cle

I've just (2 weeks ago) released an iOS/watchOS app and have a TestFlight user experiencing this. The app listens for HealthKit updates and wakes/processes/records data to update its complication. The user in question is on an S10 26.4 (23T240). That I know of no other user is experiencing this. I've had no reports of this happening for production users.

Hi, Thank you for the clarification. We understand that APNs 410 timing is intentionally unpredictable, and that APNs may return HTTP/200 for tokens that are no longer in active use for an extended period. However, the current issue does not appear to be correcting itself within a short while on our side. We have continued to observe the same behavior since around May 12, and it is still ongoing as of May 22. Across multiple bundle IDs, the volume and rate of HTTP/410 “Unregistered” responses remain significantly lower than the pre-May-12 baseline, while our APNs request volume, request flow, credentials, push token collection, and App Store Connect deletion trends remain stable. Could you clarify the following? Is this temporary glitch still ongoing on the APNs side? Is there an estimated timeline for when APNs 410 “Unregistered” response behavior is expected to return to normal? Should we expect APNs to eventually return 410 for tokens that would have returned 410 during the affected period, or will those t

I don't see how you could ever do pixel-perfect layouts in storyboard in the first place. It's extremely buggy. I generally have a lot of constraints that I configure to be removed at build. I just need them in IB to keep the size greater than zero and less than 7000. Then I set accurate constraints in code. That's really the only option. What you see in IB is just a very rough facsimile of what it will look like when running. And many Mac controls don't support constraints at all.

Sorry for the delay. A bug on the forums prevented me from replying. That seems to be fixed now, so here are some examples: So, before I comment on your two examples, there are a few things I want to make clear: These issues cannot be properly investigated by simply looking at your app’s own logging or even the full system log. The actual behavior here is determined not just by the software environment, but the network the device is operating on and the physical environment the device is active in. Your app and server have no real role in any of this, and, ignoring obvious failures like app crashes or server failures, nothing you can do will have any effect on this. There is value in understanding how your pushes are generally behaving, but many developers come into these issues with the assumption that there is some kind of fix that they need to find and apply, after which their app will work great. Nothing like this actually exists. Looking at your two examples: APNs response time: 2026-05

@wodiuleliangpro Please file a code-level support ticket so we can assist you with this issue.