The distribution certificate is only used in the act of uploading the app to the App Store. Apple discard the signature which was used in the upload process and, when distributing to user devices, sign the app themselves with their own App Store certificate. Thus user devices only need to understand one, Apple certificate. That is the technical side. However, on the commercial side it is conceivable that “did not renew a certificate” could induce Apple to think “inactive developer”. I think this is unlikely, given the sophistication of internal communication between departments that would be required. But only Apple can really answer this. If somebody from Apple doesn’t respond to this thread, you might try the Contact Us link in the App Store Connect page.

The latest version of Xcode is 13.4.1.

Unfortunately the entire write-only access feature is the right answer to the wrong question. No person and no app ever wants to add an event to a calendar. We may talk about "adding an event" colloquially, but what we mean is: Add the event if it is not already there. If the event is already there, modify it if necessary. For a human example: when you confirm a meeting and say "I will put it in the diary", that does not mean that you open your diary, see the meeting is already in the diary, and then add it a second time. But that is what the assumptions behind the new API imply. In my case the app is maintaining a one-a-day list of future "events" for the next 365 days (it does this in a separate calendar with a separate name, not in "Home" or "Work"). Each time the app is run it needs to add whatever future dates have not yet been added. The new API does not allow this because there is no way of knowing what has already been added. In addition (in parallel to your case): the exact content of the events may depend on app settings. When the user changes a setting the app needs to update the previously added events but again the new API does not allow this. Both you and I would benefit from a concept of ownership, either on the calendar level or on the event level. "Tell me what events I have created and let me edit them", or "Tell me what events are in the calendar I own and let me edit them". The new API does not provide this and we will both have to stick with full access for now. Adding a concept of ownership sounds easy but requires more resources and a certain amount of political will: for instance, how does "ownership" work when an event is shared with Google or Outlook? It is more work for Apple than just adding a "write permission" flag to EventKit as a whole. I would love to give feedback on this and I am sure you would too – but it is not clear to me to whom, at the beta stage, such feedback should be directed. Probably I have missed something obvious here!

You are not alone. I used the "Contact Us" button at the bottom right of the App Store Connect screen to get an Apple representative to call me. He then sent me a standard email asking for full details and a video. I have provided all the requested information and therefore Apple have at least one report. I suggest that anyone who has this problem submits a proper report to Apple. Apple do not really read these discussion forums on a regular basis so they are not the right way to report problems to them. Though it IS reassuring to know it is not just me. Thank you, everyone!

The same bug here. Reported by a user using iOS 18, reproduced locally with Xcode 16 and an iOS 18 device. iOS 17 and earlier work correctly. Bug report ID is FB15343941 (As always, it is difficult to establish whether I have assigned this bug report to exactly the right category in Feedback Assistant!)

Thank you! I should have noticed that. For the benefit of anyone else reading this, I have just experimented as follows. Create a file called lldbinit containing the single line settings set target.process.thread.step-avoid-regexp ^std::|^string:: Place it in the same directory as my .xcodeproj file In the field you mentioned in Product > Scheme > Info, I set the "LLDB Init File" field to $(SRCROOT)/lldbinit And indeed, when single-stepping, it now steps over functions in the string namespace instead of stepping into them.