Posts

Post not yet marked as solved
5 Replies
Thanks for your reply.That makes a lot of sense and is how I think of it too. I am a great believer in Apple's guidelines. Where many complain, I generally see them as protective because I have worked a lot in security over the years and I know how many bad guys and exploits are out there!I would definitely never be adding helper apps as automatic downloads. Someone would need to quite clearly (with probably a help page to guide them), go to our website and download a .dmg for the developer ID signed helper app. They would then be strongly encouraged to keep it somewhere safe/sensible. And it would not run automatically, it would have to be run manually by them. They can start it at login if they wish.As for privilege escalation, it would be another UI app in the same login context and would require no elevated privileges I don't think? Unless privilege escalation means something different from what I think.I'm partly thinking of having the app separate, not just for process isolation (bonus) but because it's actually a more advanced feature, for when users/developers have learned the basics, like the application, are using it and are ready to progress to the next level. It will definitely not be something people do "by accident" and it won't be used as a backdoor way to make money or other nefarious things. 🙂Carl
Post not yet marked as solved
5 Replies
Can I chip in on this? I've spoken to you before about my situation, (in a DTS ticket). I've got an IDE that has well known third party command line tools bundled in it (gcc, gmake, swiftc, etc.) It's currently code signed, uses hardened runtime and is DeveloperID signed but I'm not deploying or selling it via the App Store because the code signing for the App Store is much more fiddly (inside out signing). I had the brainwave to separate the editor, serial console, etc. into one standard mac app ("the IDE") that can be signed and deployed via the app store and leave just the build tools part ("the build engine") as a smaller, separately deployed standalone mac app still signed via DeveloperID, as it is now. This should not violate any terms or conditions and will allow many people to try the IDE who otherwise wouldn't (although without the build the app is much less useful).To make it easier for people to use, I also want to get the IDE to "drive" the "build engine" using an XPC socket to send a simple command (basically "build target 1 in folder X").Reading your reply above and the app store review guidelines, it looks like this might not be acceptable to the review team? Specifically, clauses 2.4.5.v (using a mach XPC socket from within a sandboxed app) and maybe 2.4.5.iv (do not download/use a standalone app that might change the behaviour of the reviewed app).I wondered what you think? I won't take it as a binding answer! I'm just trying to figure out if there's a way to avoid doing all the work then finding I should have done it a different way.