Hi @eskimo "we recently added an API, SMAppService, that makes installing this stuff much easier." I was experimenting with that API yesterday. It's definitely very easy to use, thanks. "At a minimum, the Mac App Store has always supported helper tools." Recently I came across the macOS Planning Your App page, and was really impressed that it exists. I know there are a wealth of different Apple technologies and different styles of apps you can build with them, so it might be difficult to justify addressing this in a general way, but I can't help but think that it might be useful to others in the planning stage if Apple were to mention in the Planning your macOS app page what kind of helper tools are allowed on the Mac App Store, because it can have a huge effect on how you plan and what you design for, which can even make or break the user experience for certain types of apps, where background processing is a valuable feature. I did see the documentation on the embedded CLI tool thanks. I just assumed it was new. :-) Thanks for the detailed feedback Eskimo, it's absolutely critical information for me. Choosing between a launch agent and a login item, the thing that appeals to me about login items, is that the user can very easily confirm whether it is installed via System Settings, and they can easily remove it without me having to add some extra management code to my app for a launch agent. A few questions from your feedback: Let's assume I choose what I feel is the path of least resistance, and embed a sandboxed login item in my app bundle. If the user chooses to give my app full disk access, would that access extend to the login item? If not, how would I go about ensuring that the login item full disk access status matches that of the main app? Would the same apply to a bundled launch agent? Thanks.

@endecotp Why do you say that? Do you think it will take too long to learn the required technologies? Or maybe you think the cost of server infrastructure will be unaffordable? Why specifically does it matter that you are an “indy developer”? If you want to do business in Europe and the UK, and you want a backend service that stores information about your customers, then you are legally obligated to comply with the GDPR, unless you are comfortable with getting sued into your next lifetime. That's not a one man job, hence why I'm asking as an indy developer. If someone pays for your app and then for some reason your code decides they’re a pirate, they will write a 0-star review and your sales will fall. How many blocked pirates are worth one bad review? You're making disparaging assumptions about my abilities in a way that almost seems like borderline gas-lighting. The idea that I should simply tolerate pirates to ensure the app's reputation on the store is just bizarre to me. It is worthwhile blocking every single pirate in my view. If the software is good quality and people who value it and have paid for it, review it positively then I don't see how that will get drowned out by hypothetical bugs you feel I'll introduce. and generally pirates would not have paid for your app anyway. Tired of hearing this fallacy. That's like saying the only people who will buy your app are the ones who paid for it. If a pirate is not interested in my app, then why would they download it off a pirate site? Because it's available for free. The idea that people who are willing to pay for your software, won't download it for free, given half the chance, is naive.

Not quite; it’s only an issue if it’s personal information that you store. Not quite; it's personally identifiable information that you request from the user, and they provide to you in response. It doesn't include unsolicited data such as if someone emails you their personal details without you asking for that information. I've read the +30k word document on the UK Governments guidance on GDPR. It's not a small task, but we're getting off topic, I suppose. App receipts do not include personally-identifying information. True, however, if you've ever read the tech news in the last decade you'll know that companies that used to publish anonymised data for research purposes have stopped doing it, because it was quite quickly discovered that even anonymised data can be cross-referenced with other data (anonymised, or otherwise) to eventually render that data no longer anonymous. Suggesting getting lawyer involved is missing the context of my original post. But still, you need to be extremely careful with how you handle other people's financial data. I've worked as a backend engineer for over a decade in commercial banking, investment banking, publishing, startups etc. I'm well aware of the team of people required to engineer and maintain a backend solution. If you think it's a one-person job, you are already way out of your depth. The whole point of my post is to get feedback from Apple regarding a simpler mechanism of receipt validation for those who can't afford to setup and maintain a backend receipt validation service, in the hopes of reducing app piracy and given indy developers more of chance of financial success. Bug accusations aside, I'd be happy to hear your thoughts and criticisms on this mechanism, and why, perhaps it hasn't been implemented up until now. Also, I couldn't get AutoPairs to work on Sonoma. No matter how many times I granted it permission in Accessibility Settings, the user interface never reflected that permission, even after restarting the app. And it never did auto-complete my text.

Hi @eskimo ! file a bug against that page. Will do thanks! "keep clause 2.4.5(iii) in mind." ... "Mac App Store apps generally do include this UI as part of their user consent story." ✓ Login items are not automatically relaunched if they crash or quit. You can configure your launchd agent to do that. Righty-ho, a launch agent it shall be. Thank you for your help. :-)

@endecotp Feedback from Apple is quite rare on this forum. More likely, you’ll just have to listen to other developers sharing their experience. *giggle snorts* @ Eskimo I think Eskimo's work rate speaks for itself.

Quinn... IPC always has some per-message overhead, so you get more throughput if you batch your messages. However, batching introduces latency. Whether that latency matters depends on how “real” your real-time goal is. The aim it to try to get the user to believe the processing is happening in the app, instead of the background service, so any user-perceived lag would be missing the goal. It’s not uncommon for subsystems like this one to set up a shared memory region between the server and the client and then either use some fancy lock-free data structure or use IPC to coordinate access to that memory. This is something that I'll have to learn about. I've had a brief search online a month or two ago for negative sentiment around shared memory acceess and to trying and identify how promising this approach is, for someone with no experience in it, to base an entire app's functionality on. But if that's the correct approach here, then I'm willing to get it done. With shared memory, should I be looking for Apple API's or will it be POISX APIs that I might be able to learn from the Linux world? I'm still in the design phase, so details aren't really necessary right now, just trying to gauge how rocky the learning path will be.

Kevin... ... what are you expecting your GUI to do with 1000s of updates per second? Good question. 1000's is a bit of an exaggeration, but I thought it might tease out some information from Apple Engineers about other people's experiences with XPC performance. As you mentioned, the single biggest performance drag was messaging. I understand what you're saying about displaying useful information to the user. I ran the Red Canary Endpoint Security client a while back to see how they handled the performance issues around the Endpoint Security framework, and noticed that their GUI interface isn't dealing particularily well with the high volume. A feature to filter the live view in the GUI would be how I'd solve the overload. Or the data may simply be sent over XPC to then be processed further as per the user's commands. But as you say, it's better to move this all to the backend. Yourself and Quinn mentioning shared memory is very much more like my use-case. While it might be uncommon (one reason why I wasn't too keen on it), "spying" on the backend is a very accurate way of describing what I plan to do. In fact you mention ring buffers, which is one of the data structures I'll need to spy on, but I'm not working with audio. Thanks for your input, both of you, it's very helpful.

Hi Kevin, Thank you very much for your insightful perspective on this. [quote='792745022, DTS Engineer, /thread/757744?answerId=792745022#792745022'] -XPC/IPC latency is FAR smaller than screen latency [/quote] I hadn't given much thought to screen latency in relation to XPC, so thank you for highlighting this. [quote='792745022, DTS Engineer, /thread/757744?answerId=792745022#792745022'] I was curious enough that I actually ended up mocking this up myself [/quote] [quote='792745022, DTS Engineer, /thread/757744?answerId=792745022#792745022'] ~30/s was very fast/blurry, [/quote] I will definitely take your advice regarding a mock up and timers. But even your results have put my mind at easy regarding XPC performance and what I'm hoping to achieve. [quote='792745022, DTS Engineer, /thread/757744?answerId=792745022#792745022'] My actual suggestion here is that you START by figuring out what you want this to look like. [/quote] I'm always thinking about, not so much worst-case scenarios, but extreme-case scenarios. If my backend is capable of running any number of concurrent background tasks for a user, and they want to try and keep an eye on them, whether using a summary overview, or multiple task detail views, I wonder how well that would handle performance wise, but as you say, it's down to how much information the user can interpret in their perceived "real-time". [quote='792745022, DTS Engineer, /thread/757744?answerId=792745022#792745022'] Note that, in my experience, many of these issues are caused by the GUI being drowned in noise, NOT because the GUI didn't have enough data to look at. [/quote] I was thinking I might run into trouble when users attempt to interact with a table view containing historical activity. Something like Instruments detail views. If a user wants to scroll down through a fine-grained list of activity, and that's being pulled from a DB that the backend controls, the experience is probably going to be quite smooth, given the numbers you're seeing. Assuming the disk reads are sequential, which they will be. I haven't worked in web development for over a decade, but having spent so much time in that field, developing a macOS app with a backend architecture really does appeal to me. I know a lot of apps simply don't require an architecture like this (Pages, Keynote, etc), but any unattended background processing, and you really have to start looking at things differently. Thanks for the time you've spent on answering my questions, and taking the time to mock up something out of curiosity.

Thank you for answering my questions Quinn, I really appreciate it . With regard to the use of user space I/O Kit API (I suppose you could include API like libproc to the this list) and the App Store/Sandbox, if developed a self-distributed (Developer ID signed) non-sandboxed agent that contained the IOKit/system calls, and had that communicate with the sandboxed App Store app, I guess that would keep my app on the store? Without the agent though, the app would be useless. Perhaps that would be grounds for failing the review process?