Thank you: this isn't a complete solution yet – mostly because Apple insist repeatedly that one should submit a minimum example of the problem, and that is exactly what I did, removing all features that weren't relevant to the specific problem! Since the "minimum" example didn't include them, your solution ignores those features and there seems to be no way of putting them back in. There are three that are relevant: You ignore and obliterate the font specified in the original NSAttributedString. In practice a full text would include (for example) headings which use a bold font, as well as lines and paragraphs using a normal font. Is there a way of adapting the solution to do this? Following on from this, it is also necessary to have individual words have a font of their own (suppose, for instance, that in the NSAttributedString in the example, the words forty-two were bold). Is this doable? I appreciate how you have taken the indentation properties from the individual parts of the string and applied them when constructing the Text items. Is it similarly possible to make paragraphSpacing and paragraphSpacingBefore work? We use them both, and need them.

Thank you! I will look into this. I am not using Auto Layout, so it is good to know the alternative approach. I can imagine that in the course of handling some kinds of scroll gestures, UITableView needs to know the size of cells that don't yet exist. Otherwise one couldn't scroll a tenth of the way down a 10,000-row list without explicitly creating 1,000 cells. Is this the sort of area where estimatedRowHeight comes in?

Got it. In this case the iOS app happens to carry its settings within itself. I will keep it that way and use UserDefaults to carry relevant settings from the app to the watch: better than sending the user off to the Settings app, which is not otherwise used by the iOS app. Or are there problems with this proposed approach?

Thank you. This kind of suggestion of reasons for choosing one approach over another is exactly why these forums are so helpful.

"In the iOS settings bundle" meaning that they will appear in the iOS Settings app in the section devoted to the app in question?

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.

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!)

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!

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.