How are you opening these files? Do they have attributes that are different than other files?

You probably started both apps from the templates. Interface Builder is just XML, so classes are just class names. It doesn't know the difference between two different classes that are both named "ViewController". I had this problem in a project I'm currently developing. My main app showed objects from my UI tester app. I closed the main app and opened just the subproject with the UI tester app. From there, I could safely refactor "ViewController" to "TestViewController" to fix the problem.

My first thought was some kind of cross-platform PDF code that wasn't doing file coordination properly. But what you're showing is basic NSDocument file reading. However, NSDocument can get very complicated when writing. You said you're writing a viewer app. Are you sure you've specified the role for PDF as "Viewer"? There would have to be some other kind of change, possibly to attributes or permissions, in order for Time Machine to balk. Reading a file should be a no-op in that respect.

Closing the app and running TM fixes the error. So you're saying there is no error? Because that's how Time Machine works. It doesn't back up open files. There is some uncertainty as to what constitutes an "open file" on macOS. Obviously an open SQLite file or a package being actively modified will qualify. But an NSDocument file, even though it opens a file only briefly, could replace the original at some later date. I'm happy to let the Apple folks debate those finer points. If the problem goes away when your app quits, then there is no problem. You still haven't answered my question about your NSDocument Viewer/Editor role. Perhaps that is an improvement you can make.

I set the PDFDocument to nil when I close it. Maybe review how you're doing that. The NSDocument teardown process is not straightforward. As the documentation says, the "close()" method doesn't always get called. This is a general problem throughout the UI APIs. The init, setup, layout, display, hide, teardown, dealloc process can be quite delicate. This is most apparent with NSDocument, where everything either happens at an inconvenient time, or simply not at all. It's better to rely on major events like NSWindowDelegate "windowWillClose" to perform your teardown. Make sure your teardown logic can be safely called repeatedly, and then call it again in places like close() and dealloc. The "Debug Memory Graph" tool is very useful. Just run your app normally. Open a couple of documents and close them. Then hit Debug Memory Graph. You may be surprised at what objects still exist at that point.

This all makes me think that "sleep" on macOS in the past few years is now defined differently -- perhaps an Apple Silicon change? But I can't find documentation that covers this. Buried in a WWDC video, maybe? I think it was before that. It sounds like you're encountering "Dark Wake". It's only hinted at in a couple of places in the documentation. The "Power Nap" feature is closely related and seems to be more openly acknowledged. But I don't know of any way (for an app) to detect or control when they get triggered. Apple engineers say there's no way to detect it.

That's the great thing about standards, there are so many to choose from.

The only thing better than multiple standards to choose from, is multiple questions on the same topic. Rather than ask what "standard zip format" (probably the only time those 3 words have ever been used in sequence) that iOS 26 is using, maybe explain why you're asking. Most likely, it's some custom version that suits Apple's needs. It can, and almost certainly will, change without notice, frustrating your efforts to support the One True Zip.

Just change the label in your customized version and then change the configuration to use a different value for QueueDirectories. Then, when your directory gets modified, it will launch your custom process, not the system one.

This is a well-known problem. It actually doesn't (directly) involve your app at all. The operating system will do this with any document when you've configured the document to be opened with an app that doesn't explicitly declare support for it. Since you have declared support for this file type, the most likely explanation is that you haven't declared that support correctly. Document types are specifically for the NSDocument architecture. I don't know anything about your app so I don't know if that usage is appropriate or not. But it sounds like you just need to add some imported type identifiers for those types.

That is the intended behaviour. But it wouldn't be the recommended API for every kind of "temporary directory". It seems designed for implementing a manual atomic write. The NSDocument architecture would do that for you. But if you had a reason to avoid using the NSDocument architecture, you could use this API, and it might be a good idea for the end user to see the directory in case the save is going to take a long time. You wouldn't want the user interfering with your save. However, if you're looking for a more traditional type of temporary directory, then this API wouldn't be appropriate.

Yeah. Pretty obvious. There's been a dramatic drop off in a number of social media sites. I've noticed a similar trend on the Apple Support Communities. Stack Overflow has a Data Explorer that you can use to chart its own demise. At least these forums are still getting some engagement, even if it's pointless.

Does app review depend on app reviewers availability? And holidays etc? Yes, of course. If there are no reviewers available, then there is no one to review your app. And yes, Apple does regularly shut down app reviews for significant holidays. IS there a maximum number of days that an app has to be reviewed before end of that period? In other words: if an app is posted, a review HAS TO HAPPEN before x days, is a rule (hopefully) or no? Nobody outside of Apple knows Apple's internal app review procedures. However, we can make logical inferences. Let's suppose there is a rule that a review HAS TO HAPPEN before 10 days. OK, then. Now let's suppose that doesn't happen. We can suppose that because obvious you wouldn't be asking otherwise. 😄 Does your app get automatic approval? Obviously not. Is the app reviewer who didn't make quota subject to some kind of internal discipline, and possible reassignment, or even termination? Sure. That's possible. Then your app would be reassigned to a new reviewer, who hopefully gets the review done within 10 days. But there is no guarantee of that. Apple could burn through slow reviewers forever and your app would never get reviewed. Therefore, if there is such a rule, it applies only to the performance evaluations of the app review team and is irrelevant to when, or if, your app ever gets reviewed. Once an an app has been reviewed once, and you send a new build (that addresses the fixes) for example you add the "sign in with Apple" if you forgot to add it next to "sign in with another method", does the second round of review have to be done by the SAME REVIEWER first time or can it be done by a second reviewer? Again, let's use logic. Suppose there is a rule that the SAME REVIEWER must review all subsequent submissions. Furthermore, let's suppose this reviewer gets hit by a bus. Too bad for you, I guess. Or what about scenarios that aren't as sad. How about a wedding, or a honeymoon, or a vacation? Do you really want your app to be sitting in a reviewer's inbox while the reviewer is downing margaritas on the beach for two weeks? Therefore, we can logically assume that there is no such rule. I have posted and have been waiting since 5 days now (since 5 march) Over a weekend? I should point out the existence of a concept called "business days". One of the reasons someone might want to work for Apple is so they don't have to work weekends. Are we allowed to post many apps at once? Sure. Why not? I mean as a developer I can take time working in multiple apps, then suddenly deciding to publish them all, that is okay right? Sure. Go for it! Are their limitation or expected "published flow" to have? Well if you were the world #1 target for scams, would you implement some kind of system to detect suspicious activity? Isn't it reasonable to expect some a rate of new app releases and/or updates that are proportional to the number of developers on a given team? Once an app has been approved and published, will the waiting times for updates (new versions of the app) reviews smaller hopefully? Hopefully. 😄 or how was your experience? Is there a general rule you have seen? One developer's experience is not applicable to any other developer's experience. Maybe I develop some dictionary app for medieval French literature. My experiences may not be applicable to your innovative new social networking-crypto-dating app for kids.

I don't know anything about your app or what you've submitted. All I can tell you is that there are some items that are required by the automated flow. The system will prevent you from submitting without them. But then there are still other items that are also required and app review will check for those and reject your app if they're missing. I would assume that screenshots are required for submission and that the system would display an error on a submission without them. But I'm not going to try that to test. And maybe you're talking about an update given the context of your first question? But generally speaking, once you submit, all you have to do is wait. But if you're concerned that your review might take a long time and ultimately end in rejection, then perhaps you have valid reasons for those concerns. Maybe be proactive. Reject the build yourself and resolve any lingering concerns. When you're 100% confident that your submission will be approved, then resubmit. It's always possible that your confidence was too high and the app gets rejected anyway. But I don't see the point in starting the process when you're already worried about rejection.

I don't know. Sorry.