Post not yet marked as solved
@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.
Post not yet marked as solved
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. :-)
Post not yet marked as solved
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.
Post not yet marked as solved
@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.
Post not yet marked as solved
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.
Post not yet marked as solved
Sorry I should have mentioned those conditions. None of the components are sandboxed, but I did turn on the Hardened Runtime for the Privileged Helper and turned Library Validation off because the helper tool wouldn't load my framework in /Library/Frameworks. Wasn't sure why not as they are both signed with the same cert, and I've followed the sample code w/r embedding cert data in the mach file.
I've got a Workspace with multiple projects, app targets and frameworks, all side-by-side and working correctly, except for this target. My workspace builds a bunch of products that work together with XPC, so one of those build targets isn't a traditional bundle, it's just a binary, that's deployed to /Library/PrivilegedHelperTools so embedding isn't an option for this target. Thanks, I'll have a look at installer pacakges, that might answer the questions I have. For now I think I'll just sudo copy it. I was just hoping Xcode was privileged enough to install into a location that's recommended for framework deployment, but I guess not.
Post not yet marked as solved
I understand. I had pretty much given up hope of having it on the store and sandboxing it. Where I was getting my hopes up was with wrapping priviledge escalation with Authorization to prevent non-Admin users from running code. That's still a non-started for the App Store I guess.Regardless of how it's distributed, I still need to ensure that only Admin users are pre-authorised to run functionality that requires Admin priviledges. If my app ends up on university computers and it's used by students as well as Admins, I just want to make sure no one can gain access to priviledged code they don't actually have.Thanks for your advice. I've got my helper service installed and almost finished implementing basic authorization. If/when I get to the command line tool implementation, I'll take your advice I found in the Swift forum and generate a symlink to an executable I ship with my app bundle.
Thanks very much for explaining that to me. Now I know why it's like that, and thanks for the example code.
Post not yet marked as solved
I think the issue is that if you are developing an app to help macOS Administrators then your app stands no chance of ending up on the App Store. My intentions aren't malicious. I've been a mac user for over 20 years, I just want to develop a tool that makes automation on macOS easier for myself and others who are administrators.
Post not yet marked as solved
Thanks for the info. I did eventually find a blog post that referred to xpcservice.plist after posting this. So your XPC service would call out to the blessed helper process, so long as they were both signed with the same certificate.Having a closer look at the Sandboxed App in EBAS (as previously I'd assumed I'd have to forgo App Store distribution because I'm using Apple Events to Finder etc — I know there is a Sandbox switch to enable Apple Events, but that still won't allow me to communicate with the Finder via Apple Events. I have no idea why not), can I assume this means that I could get my app on the App Store if all my Apple Event code was placed in a helper tool?Having a sneak peek at "Professional Cocoa Application Security" By Graham J. Lee i see the tool would be installed to /Library/PriviledgedHelperTools. And Finder describes them as documents and not executable code. If I wanted a command line tool to access the helper tool, I'd have to embed an info.plist in the CLI tool's mach-o executable with an entry for SMPrivilegedExecutables?It's quite interesting when you think about getting priveledged code to execute from a suite of app targets (GUI, MenuBar, CLI).
Post not yet marked as solved
Thanks Ken, I'll give that a look.
Post not yet marked as solved
> Once you figure out how to get your Blob on the pasteboard when your app is not running, it should be downhill thereafter.My app will always be running, as they'll be dragging a UI element to the Finder.
> I’m sure you can figure how to combine the aforementioned methods with AEM’s AEFlattenDesc/AEUnflattenDesc procedures yourself.Thanks for the tip!> Oh, and as far as launching apps goes, you need to use LaunchServices for that (either what’s left of the old C LaunchServices API, or AppKit’s NSWorkspace).Did eventually find the NSWorkspace API call. Managed to have some success creating AE's with NSAppleEventDescriptor today, including building object specifiers, so it should be all hunky dory from now one. :-/
Thank you! That works. It's amazing how much simpler your code is than mine, and how much more familiar I need to be with the APIs to do things correctly. It's interesting how, in some situations, you don't really need to create Swift Pointer instances to work with C APIs.After posting this discussion I got to thinking about using the AE C APIs. I want to store these event descriptions to disk, and thought it would be better to serialize the AEDesc data structure than the NSAppleEventDescriptors, then I discovered that you can get and set the AEDesc on a NSAppleEventDescriptor.Working with pointers, even from Swift is going to increase the potential for bugs and intruduce needless complexity so I will take your advice and work with NSAppleDescriptor from now on.Thanks Eskimo!
