Out of curiosity, I went through posts the other day and counted the number of App Review complaints in a single day. I found 17, but it seemed like that was a slow day with numerous actual technical posts. I just repeated the exercise and found 32. I'm not sure about my methodology at the edge. The forum doesn't have real, absolute timestamps. A timestamp of "23h" is definitely in range, but I'm not sure about "1d". And the forum list is limited to 10 pages. So the actual 24-hour count number this morning could be more or less than 32. I'm probably not going to repeat the exercise. I'll just assume the average is 24 per day and leave it at that. I'm not claiming this is a good thing or a bad thing. I simply find it morbidly fascinating. Qualitatively, the results are equally creepy. The posts seem to follow a template. They virtually always feature: A call for input to ask if anyone else has ever experienced anything similar, as if the past 8 months haven't happened. But perhaps this is just the modern approach - speak your truth first, read or listen to others later, if at all. A request for guidance from other developers for escalation strategies. A plea to the Apple gods for intervention or confirmation of properly queued status. Engagement seems unproductive. More concerning for other developers is a common practice of automatically requesting an expedited review. Not every post includes this, but virtually every post that involves a rejection says that a subsequent submission was expedited. I don't think I've ever requested an expedited review. It doesn't sound like a good idea in this age of AI-supported App Review. If there's a rejection model in training, it seems like expedited review status would be a significant input. I noticed a recent attempt to bump some Apple posts pointing to App Review tips. I'm not sure such bumps are effective. For one thing, they're already on page 9. Who's looking at page 9 other than me? It would be better if they were truly pinned following common practice in other forums. And obviously none of these posters are reading any previous posts before making their own. They sometimes do some after-the-fact forum research and add a few "me too" replies. On a more humourous note, it's telling that there is an assumption in this community that people recognize rejection reasons by App Review Guideline paragraph number. I'm starting to learn those myself from reading these posts. That's a clear signal to change my own behaviour, which is ultimately all I can do. My plea to the Apple gods would involve some support for that endeavour in the form of forum updates to 1) better serve these hapless developers and 2) allow other developers to ignore them. For example, the Apple Support Community, apparently based on the same back-end discussion forum engine, has the ability to allow users to subscribe to specific communities. I don't see any way to do that here. I would sure like to be able to exclude both "App Store Distribution & Marketing" and "App Review" from any such subscription list. (And maybe SwiftUI too. 😄 ) I have other suggestions regarding comments, notifications, and update indications. But the current poor state of forums would overwhelm any such minor improvements.

I just saw another post regarding bookmarks on iOS where an Apple engineer made the following statement: [quote='855165022, DTS Engineer, /thread/797469?answerId=855165022#855165022'] macOS is better at enforcing the "right" behavior, so code that works there will generally work on iOS. [/quote] So I went back to my macOS code to double-check. Sure enough, the following statement: let bookmark = try url.bookmarkData(options: .withSecurityScope) fails 100% of the time. I had seen earlier statements from other DTS Engineers recommending that any use of a URL be bracketed by start/stopAccessingSecurityScopedResource. And that makes a lot of sense. If "start" returns true, then call stop. But if start returns false, then it isn't needed, so don't call stop. No harm, no foul. But what's confusing is this other, directly-related API where a security-scoped bookmark cannot be created under any circumstances because of the URL itself, some specific way the URL was initially created, and/or manipulated? So, what I'm asking is if someone could elaborate on what would cause a failure to create a security-scoped bookmark? What kinds of URLs are valid for creation of security-scoped bookmarks? Are there operations on a URL that will then cause a failure to create a security-scoped bookmark? Is it allowed to pass the URL and/or bookmark back and forth between Objective-C and Swift? I'm developing a new macOS app for release in the Mac App Store. I'm initially getting my URL from an NSOpenPanel. Then I store it in a SQLite database. I may access the URL again, after a restart, or after a year. I have a login item that also needs to read the database and access the URL. I have additional complications as well, but they don't really matter. Before I get to any of that, I get a whole volume URL from an NSOpen panel in Swift, then, almost immediately, attempt to create a security-scoped bookmark. I cannot. I've tried many different combinations of options and flows of operation, but obviously not all. I think this started happening with macOS 26, but that doesn't really matter. If this is new behaviour in macOS 26, then I must live with it. My particular use requires a URL to a whole volume. Because of this, I don't actually seem to need a security-scoped bookmark at all. So I think I might simply get lucky for now. But this still bothers me. I don't really like being lucky. I'd rather be right. I have other apps in development where this could be a bigger problem. It seems like I will need completely separate URL handling logic based on the type of URL the user selects. And what of document-scoped URLs? This experience seems to strongly indicate that security-scoped URLs should only ever be document-scoped. I think in some of my debugging efforts I tried document-scoped URLs. They didn't fix the problem, but they seemed to make the entire process more straightforward and transparent. Can a single metadata-hosting file host multiple security-scoped bookmarks? Or should I have a separate one for each bookmark? But the essence of my question is that this is supposed to be simple operation that, in certain cases, is a guaranteed failure. There are a mind-bogglingly large number of potential options and logic flows. Does there exist a set of options and logic flows for which the user can select a URL, any URL, with the explicit intent to persist it, and that my app can save, share with helper apps, and have it all work normally after restart?

There seems to be some kind of problem with the forum software incorrectly redacting certain words. It's even censoring Apple employees when they use the word "s i g n a l" in this post, which is now titled, "iOS Network ****** Strength" So, no, Apple employees are not complaining about iOS Network strength.

It looks like these new forums are based on the new Apple Support Communities code. I frequently post on ASC so I know what does and does not work there. I will focus on features that need to be imported from ASC and features that don't. Email notifications - Some people really like to work from e-mail notifications. ASC has notifications for participation, following, points, etc. Just make sure they always default to "OFF". Subscriptions - ASC already has this and is (in my opinion) the ideal way to find and respond to questions. Essentially, this is just searching on multiple tags. The subscriptions is an interface to let me define what tags I want to search for by default. Sorting - Primarily, we need to see messages sorted by descending timestamp. Sorting - I would like to be able to sort by both created or updated timestamps. Sometimes I want to see bona fide new messages. Searching - This is ASC's big weak spot. Search is virtually useless on ASC. You have to really tweak the "filters" to get anything useful out of it. Re-do this and then back-port it to ASC please. Threads - Thread view is all messed up. This thread (https://developer.apple.com/forums/thread/134075) is a good example. It seems to be organized hierarchically, with new replies to individual posts appearing immediately after the post being replied to. This is really confusing. Just order it by timestamp. ASC has a feature to automatically guess the target forum (tag in these forums) from the content of the question being asked. That would be useful here. Otherwise, you risk everything going into "iOS". Provide an easy way to see my own posts to see if anything has been updated. ASC doesn't really offer this. I have found a custom filter query that I use to simulate the "Inbox" of an old version of ASC. None of those custom filters seem to work over here. This is another opportunity to fix and then port back to ASC. Filtering - ASC has a complicated system of filtering. Please don't import that. 10. Subscriptions - If you do implement a subscriptions system like ASC, pay attention to unpopular forums. Otherwise, new question in popular forums will drown out questions in more specific forums. The "Top Tags" list has already started that. Of course "iOS" and "macOS" will be most popular. But if everybody uses only those tags, they become useless. Specialties - This is part of ASC gamification system. I don't necessarily mind them, but they aren't implemented very well on ASC. One has to perform specific actions, such as asking a question, to start earning a speciality. What about people who don't ask questions? How do you handle people with multiple specialties? ASC seems to pick one at random and display it, which is very annoying. Guidelines - I think the Terms of Use need to be expanded and be crystal clear about what is allowed and not. I've just seen my first help wanted ad here. Is that allowed? I don't know. Other comments: Very nice use of Markdown in the editor. This is probably not something that could be ported back to ASC. Developers should be able to handle it though. I like the documentation links at the top of tag results pages.