“Account Locked”

Hello - Please review this documentation with details for Sandbox testing in a TestFlight build of your app: https://developer.apple.com/documentation/storekit/testing-in-app-purchases-with-sandbox#Sign-in-to-your-Sandbox-Apple-Account-for-a-TestFlight-app Related documentation to review: Overview of testing in Sandbox Enabling developer mode on a device Testing at all stages of development with Xcode and the sandbox Testing subscriptions and in-app purchases in TestFlight Please let us know if you have any additional questions or need further assistance. Thank you.

I also have same issue on the iphone 14, which I bought from my brother. Iphone 14 was reset and then i logged in with my apple account and when trying to do apple developer account enrolment, i get this error. I reached out to Apple support team and they simply say, that I cannot enrol using my apple account on this device. Is anyone aware of this issue and its resolution.

[quote='878184022, peterho, /thread/817501?answerId=878184022#878184022, /profile/peterho'] And a kernel extension certificate is used to sign the passthrough file system extension. [/quote] I’m not sure how you came to that conclusion. There is such a thing as a KEXT-enabled code-signing identity [1], but that’s irrelevant to this discussion. [quote='878184022, peterho, /thread/817501?answerId=878184022#878184022, /profile/peterho'] Does it need to be signed? [/quote] Yes. FSKit modules must be signed with the com.apple.developer.fskit.fsmodule entitlement. That’s a restricted entitlement, which means it must be authorised by a provisioning profile [2] [3]. To create that profile, you’ll need to be a member of a paid team. Based on our records it looks like you are a member of a paid team. Given that, you should be able to get this working as follows: Sign into with your Apple Account in Xcode > Apple Accounts. In the sample code project, for each target, go to the Signing & Capabili

Thanks again! I think very fast actually understates how significant the performance difference is. Ha, true. In practice it seems “instant”, to the extent that on APFS, updating huge zip files is not much slower than in-place saving into a package. I don't know if anyone has ever shipped a solution that worked like this, but... it might be worth thinking about using DiskImages as a file format. Interesting! Although cross-platform compatibility might be an issue here. The replaceItem(at:...) documentation actually answers this… Sorry, I should have been more clear, although thinking about it I have been tying myself up in knots and the solution was indeed here all along. I was referring to the circumstances we were discussing before, where we don’t want to do the temp work on the same volume as the destination because the destination volume is slow. In other words, we have deliberately created the temp folder for updating our file on another volume (e.g. one that supports APFS), because the one created using

Your questions are quite hard to read. See Quinn’s Top Ten DevForums Tips for advice on how to improve this going forward. Also, you asked questions about four very different technologies: User defaults, Core Data, the file system, and widgets. I have a good handle on the first and the third. I can offer some general advice about the second but, if you want more then you should start a follow-up thread in App & System Services > iCloud & Data with the Core Data tag. Similarly for the fourth, but with the App & System Services > Widgets & Live Activities subtopic. With that out of the way, let’s look at your questions. User defaults has a last-write-wins synchronisation policy, with the caveat that the definition of “last” is last change to hit the daemon that manages this stuff. The answers to your question fall out of that policy: [quote='817725021, gabrielsoria, /thread/817725, /profile/gabrielsoria'] If multiple processes (app + multiple widget instances) read and write the same share

Update: Two of my apps were approved today after remaining in “Waiting for Review” for several weeks. It looks like the review queue for my account is now moving again. Thank you to everyone who shared similar experiences.

Hi @pnelson, this is Argun, Quinn's Bluetooth colleague (while I don't have a transceiver in my head, it is not for lack of trying) I have been discussing your issue with the Bluetooth team, and while we are not dismissing the possibility of a bug, it is possible that the pairing process in different app contexts are behaving differently. Except we are not able to understand what exactly the conditions are when your app works, and when it doesn't, and when it gets the one error, and when it gets the other. There are also other conditions that might effect the issue, like whether both the Mac and the phone are logged in to the same iCloud account or not (changes pairing details) To that end, we would like some more info with a sample app, and exact repro steps, and some logs. So, first please go to https://developer.apple.com/bug-reporting/profiles-and-logs/ and follow the instructions for Bluetooth for macOS and iOS to install a logging profile on each of your devices. Then, once the logging profile