“sandbox”

Can you please confirm if my findings are accurate and sandboxed apps fail to read the com.apple.system.Security EA by design? No, I don't think that's correct. You can see the code here but I believe that xattr was set up as the fallback storage mechanism which the VFS system uses if the can't retrieve the data through ATTR_CMN_EXTENDED_SECURITY. As far as directly reading the xattr, the vfs layer is what blocks that, not the sandbox, through this check. However, my bigger question here is what you mean by read. ACL enforcement and validation happens in the kernel, not user space, so a process doesn't really read its ACL, whether or not it's stored in an xattr. I don't know what's going on here, but the general theory you're describing doesn't really make sense to me. Have you tried starting with a minimal test app that's sandboxed and directly access the file? I'd start with our basic app template with the sandbox enabled, then use the File Access Entitlement to hard code

I am also experiencing this (though I'm using Unity IAP, not StoreKit directly). Clearing purchases locally and in cloud, then signing out of Sandbox account and restarting/reinstalling the app: my fulfillment logic still being triggered for previous purchases. :( @newwbee That link is showing Feedback Not Found FYI

Finally someone asking; 1st Submission on June 8th Rejection 1: June 11th - A subtle yet valid UX issue, fixed that day itself and resubmitted. Rejection 2: June 12th - 1st Guidelines 4.3(b) rejection. The app is nuanced, so there were 2 accounts attached in the reviewer note with concisely explained details so they understand the nuance while reviewing the app as a whole. The reviewer only logged into one account and rejected. I resubmitted the same day clarifying this and that they needed to login to the other account to fully understand. Rejection 3: June 24th - Guidelines 4.3(b) rejection again. The reviewer only logged into one account again and rejected it. At this point I heard about App Review Board and I thought that might be the way to do this because I clearly explained why previously but the reviewer still rejected. So I made a App Review Board appeal. 3 weeks passes by no response, that's when I made my initial forum post asking how long does this process take. At the same time, I booked a 1 on 1

Don't use the comments feature. They hide your replies. For better or worse the App Sandbox is not a good option for our software. That's not what I'm saying. App Sandbox opts you into a lot of modern behaviour and expectations. It's literally the default. But all you need to do is add an unsandboxed XPC service. The whole OS, and random, unsuspecting APIs, run via XPC. You can't avoid it. the moment your app starts using the newer APIs, a few behaviors are clearly different. Certainly. But the old behaviours are deprecated. They may break at any time, especially if root is involved. The nice part is that launch daemons are the intended application for much of these technologies. The official documentation assumes a launch daemon. But if you're trying to do a launch agent, then you have to cobble together information from various places and try to make it work. I did finally get it to work, but it took me a year. But you could just run through the standard examples and see if that exhibits t

I don't know much about root issues with apps. But this question seems like it might be useful: https://developer.apple.com/forums/thread/792826 I think that the term privileged helper historically referred to an older way for apps to temporarily gain root privileges. Apple didn't like that and pushed people towards launch daemons. Lots more information here: https://developer.apple.com/forums/thread/708765 if one needs these LaunchDaemons to perform some actions with root privileges, what exactly would enabling the App Sandbox (com.apple.security.app-sandbox = true) on the privileged helper tool accomplish? Is there any point in confining a process with root privileges inside a container? Again, I'm not sure about anything involving root. But I have discovered certain benefits to sandboxing everything. If you have any part that requires (or typically uses) sandboxing, then all parts should be sandboxed. It greatly helps with interoperability between different apps

As it happens, shortly after posting I had a hunch that the com.apple.developer.service-management.managed-by-main-app entitlement may not be needed at all. That entitlement features on the GitHub repo LLMs are likely training on: https://github.com/malpern/privileged_helper_help/tree/main The .developer suffix hints that this would only be needed during development, but my best guess is that the fact that my main app uses a provisioning profile in both Debug and Release configuration somehow plays a role. Either way, removing that entitlement from the Helper tool suddenly allowed the connection to be started automatically. It would be great to know the answers to the other questions, since trial-and-error sometimes leads to half-truths: In addition to having the launchd plist that describes the helper tool copied to /Contents/Library/LaunchDaemons, should the same plist also be embedded by the helper tool binary via -sectcreate __TEXT __launchd_plist? Would this requirement, if it exists, be true for all ver

Follow-up: three possible causes of such purchase failures. I have continued investigating and now have three possible explanations for the STORE_PROBLEM result. None is confirmed, so I would appreciate tips on whether any could produce the complete sequence reported above. 1. Invalid or stale Apple sandbox session I performed a controlled test on my own iPad: I signed in with a valid developer-created Sandbox Apple Account. I confirmed that purchases worked. I deleted that account from App Store Connect while it remained selected on the iPad. I attempted another purchase. Apple displayed: You are not authorized to make purchases of this InApp in Sandbox at this time. This Apple Account doesn’t have permission to make In-App Purchases. After dismissing it, my app displayed the same high-level failure message seen during App Review. RevenueCat returned STORE_PROBLEM. I understand that App Review uses an Apple-managed sandbox identity that does not need to appear in my develo