[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.

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.

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

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.

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.

notarization will fail In what way?

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.

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.

Is it possible? Sure. It's always possible for Apple to approve an app as long as it complies with all Developer and App Review requirements. If you add new features, then you'll need to release an update. If you're concerned that your app might not have enough real functionality, then your judgement might be sound.

What are you in such a hurry for? App Store Connect always lags behind releases.

I just checked it and it seems like Numbers implemented in HTML or something. I get the same long delay with a bunch of messages about networking, non-existent processes, WebProcessProxy, and WebPageProxy. Then I finally get a failure message "DID FAIL LOADING QLWeb2DisplayBundle" and the preview appears. But my app doesn't have networking. If I enable outgoing client, then the preview appears more or less instantly. The preview still isn't correct. Instead of being a large icon, it's the upper left portion of the content. QLThumbnailGenerator sounds like an interesting idea.

Hi, this is a series of questions for the Apple developers, and also for anyone that would like to speculate. How are they able to get trees marked on the in-app map? There are many GIS datasets that include trees. And how come they are fairly but not completely accurately marked? That one's more difficult. Everyone loves a great dataset. You can even download open source one for free. But nobody likes to maintain any of these datasets. So they get stale really fast. Pretty much every company, government agency, and institution vastly underestimates the costs of maintenance.

It looks fine here. I've seen several people make similar statements about colours. One user sent me a picture of their screen (not a screenshot) where one relatively light icon was completely gone. It looked like they had turned on some accessibility contrast option. However, I did recently find a bug/change in NSBox on Tahoe. It won't print (or export to PDF). I had to override wantsUpdateLayer and return false to fix it. But, for me, that's strictly when printing. It looks fine on the screen. I have an M1 MacBook Pro and an M2 MacBook Air. If you have a significantly different computer, perhaps without a built-in display, it's possible your display could be being processed as if it were a printout, and not showing.

Just because the error messages reference Metal, doesn't mean it's a bug in Metal itself. It's most likely a bug in Qt and/or the Esri SDK. Maybe just add a check and if you're running on iOS 26.1 or later, with your current version of Qt/Esri, and OpenGL is available, then use OpenGL. Then, if any of that changes, you'll fall back to Metal.

You only have 129.7 GB of System Data?