Apple only provides the data documented by MapKit. And that data is subject to extremely restrictive licensing. It's better suited for a secondary data source, where you display your own data against an Apple Maps basemap. Apple's map data isn't unique in these respects. Any map data is subject to similarly restrictive licensing. I'm unaware of any data source for this kind of street-level data. That doesn't mean it doesn't exist, just that I don't know about it. Any company that has gone to the trouble of collecting this kind of detailed data is not going to provide it for free. And any company that's ever tried has quickly found out that the data is way more complicated than they anticipated. Google is able to leverage a large user base for Free Labour. Apple's trying a hybrid approach that clearly isn't working. When someone finds some data in your app that's wrong, it's your app that gets the 1-star review, not your data source. It's a real mine field. It's simply not something that any "indie" developer could ever manage.

Git repos can be big source of this problem. But there's one more to check. Xcode projects actually consist of two parts - the project and the workspace. The source code integrations are based on the workspace. Xcode uses a shared workspace by default. But you can create a dedicated workspace file for your project and then just open that file instead of the project file.

You are only required to create an account once you reach $30k in revenue. You can always voluntarily register, which you would need to do in this case. The problem here is that Apple is the retailer and Apple handles all of the tax collection and remission to CRA. Apple wants to have its CRA account tied to your CRA account because of the commissions that Apple charges you. If you have further questions, I recommend contacting CRA directly. They're usually very helpful. Unfortunately, this kind of business arrangement is actually very unusual as businesses go. But Apple is large enough so that CRA will understand the business from your perspective and should be able to provide assistance. Unfortunately, the entire process of connecting your CRA account with Apple can take a long time. And since Apple is a US company, there are also IRS forms you'll have to fill out. All of these forms can take some time to fill out - think months, not days.

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.