User Profile

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!

The latest version of Xcode is 13.4.1.

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.

For many people Xcode 12 beta 4 crashes whenever they try to open an existing project. There do not appear to be any other problems.

None. Individual transactions are never reported.It might help if you could say what exactly you are trying to achieve. The in-app purchase receipt says that a purchase has been made, so it is made, so the app should behave as if it had been made (and so should your server, if you have a server).Are you trying to check whether Apple are paying you for the in-app purchases they sell? Or what else are you trying to do?

I have now distributed two apps with this warning, and they are working well with no evil consequences.

What status is App Store Connect reporting for these apps? Is it "In Review", "Waiting for Review", "Ready for Developer Release", "Ready for Sale"?

I had this confirmed by Apple DTS for an exactly similar crash problem: the App Store uses the buggy compiler, mangles the app so that 32-bit devices can't run it, and then goes ahead and installs it anyway.Our crash also involved OpenSSL, and the recommended cure is indeed to turn off "Include bitcode" because then the mangling doesn't happen. In fact you can reproduce the problem for yourself locally by taking a suitable build, archiving it, pressing "Distribute", taking the "Development" route, and turning ON the "Rebuild from Bitcode" option.Xcode 11.5 cures this problem locally, so the problem will be cured when the App Store publication process starts using tools from that version. When I asked, the App Store people said that the version of the tools they use was not something they are prepared to reveal, so we will never know when it is safe to turn on "Include bitcode" again.

No. I have just tried (in a project with no third-party code). FB7668750

This is probably the same bug, still present in iOS 13, which has been reported to Apple as FB7538414.