That doesn't look like standard code for Apple platforms. Are you including any 3rd party frameworks or other code? That's most likely the source of these kinds of files. They could even come from 4th party code including in your 3rd party libraries. I'm sure it's device analytics/tracking code. You probably won't see it when run from Xcode or probably even from a developer machine. Such code is designed to detect this kind of usage and only execute on end user scenarios.

I'm currently working on an app that opens other apps and I can reproduce what you're seeing. I even tried it from AppleEvents. This is something being done at the Finder level. If the app is already running, then it works as expected when dropping onto the running app in the dock. I strongly suspect this is some kind of security fix. If so, don't expect it to get changed. I recommend just displaying an empty window with some kind of target image for users to drop things upon. Most users don't even know you can drag files to app icons in the first place. No great loss.

notarization will fail In what way?

Which report are you talking about? And which currency? Apple is very specific about currency. For example, "EUR" is unambiguous. But "$" could mean many different currencies. By random chance, I happen to be in Canada. And $12.45 CAD converts to € 7.69 EUR exactly. So it looks like you had a sale in Canada. I'm not sure what you mean by "Total sales". I don't see any value with that label on any of my Apple reports.

Those are probably clones that don't consume any additional storage space. You can verify this in Disk Utility. Finder isn't able to see low-level storage blocks.

That site has been having problems for the past month or so. Apple is aware of the problems.

I was wondering if there was an equivalent (or the same, I'm not fussy :) feature available to third parties, even if only during the app-store submission ? Somewhat. By default, your sandboxed app's Container folder is private. Other apps can request access and the user can permit it. And apps having Full Disk Access can read the data too. To avoid the X-Y problem, what I want to do is have a launch agent with access to a SQLite database, and I want only that launch agent to have access. You will need to be more precise here. By "access", do you mean both read and write access? You can prevent read access, but not write access. Any reads of the database will have to be done through an XPC call from the main user-facing application. Let me know if you ever get that working. I tried and failed to get XPC working with a sandboxed launch agent. So before you commit to that path, make sure you can make it work, or have a backup plan. I want to store private data into that database, and I don't want there to be any way for any other application to read it. If there's a way to do that without data-vaults I'm all ears :) You can always encrypt the data. That will block reading, but not writing. With checksums, you could detect tampering. But you probably couldn't detect outright erasure of the database. Perhaps this would be a good point to ask what your ultimate goal is with this? When you put your software out onto someone else's computer, you lose a lot of control. That's just the way it is. If you worry too much about security, and do something silly like take advice from the internet to encrypt your databases, then you're setting yourself up for a whole lot of headaches.

[quote='872548022, DTS Engineer, /thread/812688?answerId=872548022#872548022'] Interesting. That works for me. Historically, there were only two key issues [/quote] I don't want to hijack the OP's question. It's just not something that I would recommend here in the forums. I can only relate my own experiences. I spent quite a long time working on it. I read every scrap you've ever written on the topic, read all the related documentation, tried every combination of settings, and couldn't make it work.

Full Disk Access is a user privacy setting. App Review can't give that to your app. Only your users can give your app Full Disk Access. Furthermore, Mac App Store apps are sandboxed. That's a separate layer of privacy protection. You have to ask the user to give your app access to a given folder (or root) and then the user would also have to give your app Full Disk Access. Technically, it is possible. A few years ago, I had an app that did all that in the Mac App Store. I don't remember the relevant App Review communications at the time, but I remember thinking that I was not allowed to ask for Full Disk Access or direct users to it. I had an option in app settings to provide it, but users had to find that on their own. I could give them instructions on the web site, but not inside the app itself. I can't say what App Review's current policies are. All I can do is relate my own experience. I would also suggest that you're entering into a dangerous area. What kind of data from third party web browsers are you looking for? That's a suspicious Big Red Flag. Merely asking for such access can trigger a closer look at your app. You might ask, "What's the worst that App Review can do? Reject my request?" No. The worst that App Review can do is kick your app out of the store and you out of the developer program. Apple has over 51 million developers. They don't lose any sleep over terminating 100-400k developers per year. And the #1 category for app removals is "utility". You're talking about a Mac app. How much money are you really going to make from it? Even if you succeed, it's a horrible user experience.

So this is the actual purpose of my app. But the access you are attempting to obtain would also give you unrestricted ability to read and modify bookmarks, browsing history, image caches, cookies, extension data, etc. That's very valuable information. And having that access would, in turn, make your app valuable. Even if you only checked for invalid links, you could sell your app, and its Full Disk Access, to some other, less-scrupulous company. do you still think this would be considered too risky or difficult to get approved? I'm sorry, but wasn't clear enough before. I don't work for Apple or for App Review. My opinions have no part in their review. I've already described Full Disk Access as "a suspicious Big Red Flag" and "a horrible user experience". You asked for advice and experiences. I've provided both.

What is everyone using to create awesome "Previews and Screenshots" images for your app? The app itself? I tried Gemini AI and the art was great, but it's so stupid it just ignores the dimensions I tell it to use. That's the point of screenshots. In addition to being the exact dimensions required, they are also an accurate representation of the displays of your app. I don't see how AI would qualify for this.

My Mac app, an application launcher, has been rejected under Guideline 5.2.5 for being "too similar to LaunchPad, which creates a misleading association with Apple." After requesting specific feedback on what needs to change, I received only a generic response directing me to read the guidelines without any actionable details about which features or design elements are problematic. App Review has seen your screenshots and actually run your app. How would we be better able to judge it than those people who've actually run it? I've observed several other app launchers on the Mac App Store that appear to share more similarities with LaunchPad than mine does (e.g., identical pagination, similar grid layouts, similar visual design). I know! I just bought a new one recently published by the developers of one of my other favourite apps. Has anyone else faced this type of rejection for app launchers or similar utility apps? While I haven't personally experienced this, I've seen many, many posts virtually identical to yours from almost the first day these forums opened. What specific changes did you make that satisfied App Review? In the past, I've found App Review to be a good final check from a fresh set of eyes. People often complain that App Review doesn't understand how their app works. But I think that's what makes App Review valuable. They act much more like end users than the person who developed the app itself. If App Review is confused, then end users would likely be confused too. Are there particular visual elements or features that App Review considers "off limits" for this category? No one here in the forums knows the internal guidelines of App Review. Should I consider filing a formal appeal, or is there a better path forward? I think there's a better path forward. Since Tahoe, the market's flooded with LaunchPad clones. And that's the Mac market, which was minuscule and unprofitable in the first place. Just release your app for free on your own web site. Take what you learned from building it and make something new and unique. Are there any Apple engineers who might be able to provide insight into how to differentiate from built-in macOS apps while still solving the same user problem? Are there? Certainly such people exist. But they don't answer questions in these forums. The few Apple engineers who participate in these forums only answer technical questions. When the topic is App Review, they always qualify their answers that they don't work for App Review and restrict themselves to technical issues. I'm not trying to clone LaunchPad Oh, come on! Some people saw the writing on the wall and started developing their LaunchPad clones in June. Now you're finally ready to release but some manager in App Review has decided that they have enough LaunchPad clones now. It's a pretty brutal industry, eh? That's why I recommended you publish your app for free on your own website. If you attempt to charge money outside of the App Store, you'll get a really good lesson in how brutal the industry is. App Store developers are totally coddled by Apple. Don't throw good time and money after bad. Sometimes the best return on investment is a valuable lesson for next time.

Is it safe and supported to move Xcode to an external hard drive (SSD), use it from there, and simply connect the drive whenever I need to work with Xcode? Yes. Absolutely. Are there known issues with performance, stability, or updates? Nope. Apps can run from any visible location. Are there components that must remain on the internal disk to avoid unexpected behavior? Nope. Xcode is self-contained. Is this a reasonable long-term setup, or just a temporary workaround? Neither. It can't possibly work. The Xcode app itself is quite small. Moving it will do absolutely nothing to solve any storage problems. The problem with Xcode is the "Developer" folder. On my computer that's 34 GB for "Developer" in my home folder. There's another one in "Library" that's 80 GB. And in the System "Library" folder, there's an iOS Runtime folder for another 211 GB. And this isn't even my primary development machine. This is my backup and test rig. You need a minimum 1 TB boot drive for Xcode. Sorry.

What's the "Repository Up Arrow"? I don't see any arrows. The closest thing I can find suggests it may be part of GitHub Desktop, which I don't use. .gitignore is part of git. You'll have to take that up with Linus. However, this is a good use of AI. Forget "vibe coding", use AI to explain how to do things in Git. This is probably causing your issue #1. You probably have some IDE data files managed by Git. You don't want that. Try this for a .gitignore file: .DS_Store xcschememanagement.plist **/xcuserdata/ **/xcshareddata/ That's another Git issue. Use Fetch Changes to do things like detect new branched added elsewhere. I forget what Refresh is good for. I have used a couple of times, but only a couple of times. It sounds like most of your complaints are just about Git. Source control system were much easier and straightforward 20 years ago.

Alright, thanks! So I can’t move the Developer folder to an external SSD, right? To be honest, I've never tried doing anything like replacing the Developer folder with a symbolic link. In many cases, when there is something special about a folder, like special system protections, or it's being managed by a system daemon, you can't do that. But I don't know about the Developer folder. I had forgotten about the Locations setting. In my case, I could use that to move 17 GB on this machine. But the iOSRuntime is the big problem. At one point during the summer, this folder went crazy and completely filled my SSD with 300 GB of data. I had to hack it via SIP. A later build fixed that. This is just one of those problems that can be easily solved with money. A problem solvable with money isn't a real problem.