Account Locked

Hello - I was able to see the 110 Consumable in-app purchase products in your account. I can see that all are Cleared for Sale in the 42 countries specified. When I downloaded your app as a user in the Germany App Store, I was able to successfully load the product shown in my attached screenshots (Product ID=com.audiolasitava.book.price63) and get to the final step before completing the 9,99€ purchase. When I did the same test signed in to the US App Store, then I receive the same Invalid Product ID error you did (which I would expect, since your configuration does not include the US for this consumable product.) Please ensure the user account (i.e. the App Store user signed in to the Apple Account under Settings on the device) trying to make the purchase is in a territory where your in-app products are available and cleared for sale. If you are still having problems, we will need more details (including the country your user account is in, the specific API call(s) being ma

It was generated by XCode with the settings turned to YES in the Build Settings no third party tool or otherwise. Thanks for your clarification. I don't have an Apple Connect account to really go through the whole process of uploading an app to App Store, but I did try the following: Creating an iOS app using Xcode template. Adding a watchOS app target by following the steps. Archiving the app, and distributing it for releasing testing. The whole process went through pretty well. I also tried validating the app. The process also went well, until it hit the App Record Creation Error, which was expected because I didn't have an app record. To move forward in this situation, I suggest that you start an Xcode template project, as described above, and share the details of your steps with screenshots, and also the project that reproduces the issue. That way, folks may be able to figure out the issue more easily. Alternatively, you can consider contacting Apple's DTS, if you can't share on the forums due to

36 minutes, base on our log, the call at 16:58 have no problem. and the app went into background from 17:00 - 17:36(screen lock), until an incoming call push woke up the app. OK. That time scale does fit my other theory, which makes my optimistic about the workaround I’m suggesting. So, you recommended we set the configuration before CallKit is first used after the app starts? At this point, my best advice would be to set the configuration before every call. There are probably cases where it would be reasonable to skip that, however: Will this overwrite the configuration of CallKit? Keep in mind that the configuration here is primarily just a set of settings that control a few key details of how CallKit handles your call. Many apps already set the configuration immediately before reporting calls—for example, to customize the ringtone based on the incoming caller or to prevent that particular call from listing in recents. That leads to here: We may give this a try, but it's difficult to determine if i

Sorry guys, it didn't work. I followed all the recommendations from the Development and Technical Support team. I created new provisioning profiles and imported/downloaded them into Xcode using manual signing, but there are no Critical Alerts in Capabilities list yet. So they gave up and asked me to reply in this thread, saying they can't help me with Xcode. When the entitlement was approved, I received this instructions: https://developer.apple.com/help/account/reference/provisioning-with-managed-capabilities . There it says to enable the Automatic signing in Xcode target and all would be solved, but it's not working. I suspect there is something wrong with my entitlement, or there is a bug in Xcode or in Certificates, Identifiers & Profiles web page. What can I do next? Thanks, The VIAWEB Developer Team.

for the same code (didn't change anything - just keep toggling same app code 1 minute apart): If I set alarm 1 minute later and lock the phone -> I see alarm go off and UI shows in Lock Screen with the alarm sound If I set alarm 1 minute later and do NOT lock the screen (looking at Home Screen while I wait) -> I get nothing (likely my app code is executing something though) without fail it does that behavior atm

Hi there, thank you for the response. At the moment, I am not 100% clear on what's going on so don't want to go through the process of filing Feedback. My updated understanding is that the alarm maybe does go off, but there's some special behavior if the phone is not locked (ex. its in foreground) or app is in foreground while the alarm goes off. If I lock my phone, even with 1 minute differential I see the alarm go off. If I don't lock my phone, what maybe happens (at least I sometimes see it in debugger) is that the app runs to receive the alerting update (even if its technically in background?), but there's no UI anywhere showing that the alert is going off. Sometimes I do hear the sound (there's sound of alarm going off with no UI anywhere). I utilized open source sample code around AlarmKit and for that I do see the UI appear, where maybe it does because they implemented the custom widget? (but even their UI still shows inconsistencies depending on state of device/app) Of cours

Are you absolutely certain of this? If so, then do you have any idea/guess as to how much time was between the last working call and the first failed call? 36 minutes, base on our log, the call at 16:58 have no problem. and the app went into background from 17:00 - 17:36(screen lock), until an incoming call push woke up the app. The issue began to occur on this call and subsequent calls. My intuition is that #2 will probably solve the issue, but if I'm wrong, then #3 should ensure that the issue is corrected, and the next call will work. So, you recommended we set the configuration before CallKit is first used after the app starts? Will this overwrite the configuration of CallKit? We may give this a try, but it's difficult to determine if it will work or not since it's hard to reproduce. We might need to implement this in our production environment and check the metrics to assess its effectiveness. I will discuss with team.

I am not certain there is a conflict: First document says : (A) LA stays on Lock Screen for 4 hours after it ends Second document says (B) A Live Activity can be active for up to eight hours (B) is not related to (A) which specifies the time for visibility AFTER the Live Activity ends. Total time of visibility is (A) + (B) (A) is 4 hours for Lock Screen and 0 hours for Dynamic Island. So, a Live Activity can stay on the Lock Screen for 12 hours, even though after 8, it is not showing anything new. The Dynamic Island is cleared as soon as the activity ends after a maximum of 8 hours. Argun Tekant /  DTS Engineer / Core Technologies

Check and see if you may have inadvertently registered the identifier to your personal account by accident while working in your Xcode project. If you did, delete it from there so you can use it in your development account.

Yowsers! That’s so not valid code. createTCPConnectionThroughTunnel(…) is meant to be used asynchronously. Polling for completion like this a really bad idea. It’s possible that this polling is cause the problem you’re seeing. One way that iOS reduces power in Low Power Mode is to reduce the resources it uses to run Dispatch queues [1]. Polling locks up resources, so it’s easy to imagine how you could get into trouble in this way. However, I don’t think that’s the full story here. Your Task.sleep(…) should be sufficient to avoid such problems. OTOH, polling is a really bad idea in general, so I’m gonna advise you to stop doing that first. That might fix the problem but, even if it doesn’t, it’s a step in the right direction. There are two ways to avoid polling here. The first is to use a checked continuation, driving the continuation from a KVO observed on the state property of the NWTCPConnection. The second is to drop NWTCPConnection completely. It’s part of a suite of APIs we call in-provider netw