Don't use the comment feature here in the forums. It's hides your response. Unfortunately, a 256 GB with Xcode is going to be a significant challenge. I've had problems with my 1 TB drive. One of the more problematic issues with Xcode are all the iOS simulator runtimes. Perhaps you could try to delete all of those except one. Or perhaps you could look into a cloud server. Sometimes those have small drives too. If you only need it for a couple of days, AWS might be more cost effective than a monthly fee.

The only parts of Xcode that can't be moved to external storage are the parts that take up the bulk of your storage. You haven't said anything about your storage (internal or external) or your development needs, so I can't provide any more detailed information. In some cases, you can reduce Xcode's storage. You may be able to remove some or all of the simulator runtimes. Generally speaking, this is one of those cases where you have to weight the cost of your time and trouble against the cost of a computer with more internal storage.

Rotated by how much? 27.6238 degrees? Or flipped? If you just need them flipped, you could create images or perhaps custom SF symbols and display them inline in a rich text view.

Who told you that?

That feature can't be used by 3rd party apps on macOS.

happyfeet, Are you an Apple employee? Usually Apple people have a little Apple logo next to their name.

I don't know. Sorry.

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.

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.

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.

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.

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.

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.

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.

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