How to resolve bug for macOS app store approval?

I think it might be helpful if you explained "doesn't work". What actually happens and how does it differ from what you expect?

For instance, "doesn't work" could mean "the dialogue doesn't appear" or "the dialogue does appear but makes no difference".

If you do establish this as a bug then it would be reasonable to appeal against the rejection on the ground that it is only the bug in macOS which is forcing you to request the temporary exception. But it might be a case where you need to raise a DTS incident to get official confirmation that it is a bug – as well as raising a bug report, of course.

Our app was rejected because of an outdated entitlement key.

You are labouring under misconception here. The addition of user approval for automation in macOS 10.14 does not remove the requirement for Apple event sandbox entitlements. If you have a sandboxed app that controls other apps then:

• It must have the relevant entitlements.

• When running on 10.14 or later that control must be authorised by the user.

The fact that the first requirement is still in place is not a bug, but an expected behaviour.

With regards your App Review issue, I can’t give definitive answers on their behalf but my understanding is that they simply won’t approve apps that have the

com.apple.security.automation.apple-events

To offer further advice I need to know what your app does. What app are you controlling via ScriptingBridge? And what are you doing in that app?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

We have everything done. We entitlements, we have sandboxing, we have activated hardened runtime with the necessary settings, we use the mentioned entitlement for Apple events. We just need to add the temporary exception to make the system wok as intended: Working apple script and the promot of the system, that asks the user to allow apple script. It is obviously a bug, that the new Apple event entitlement doesn't work. Without the old temporary exception neither the system dialiog si shown nor apple script is working.

The reviewer suggest to unse com.apple.security.scripting-targets for com.apple.mail with com.apple.mail.compos. The fact is, that we don't use scripting bridge to compose an email. We further more use the scripting bridge of many further apps. So we have no other option to use temporary exception.

The documentation explicitly says: If your app scripts Mail to do more than compose messages, you can continue using the temporary entitlement.

It is obviously a bug, that the new Apple event entitlement doesn't work.

I disagree but, frankly, my opinions aren’t the ones that count. You should feel free to file a bug and make your case to the folks who have the power to fix this.

The documentation explicitly says: If your app scripts Mail to do more than compose messages, you can continue using the temporary entitlement.

Indeed. That’s true at a technical level, but the issue you’re hitting is one of App Review policy. As I mentioned before, I can’t make definitive statements on behalf of App Review, but my understanding is that they simply won’t approve apps that use

com.apple.security.automation.apple-events

ps I’d like to file a bug against that document to further clarify this situation. Can you post a link to it? I searched our site for that text and couldn’t find it )-:

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

The reviewer didn't say, that there is a problem with using the entitlement com.apple.security.automation.apple-events, but com.apple.security.temporary-exception.apple-events. We could remove com.apple.security.automation.apple-events, no problem.

My understanding ist, that the first entitlement has replaced the second one. So we have done this replacement and realised, that the scripting bridge is not working any more without the com.apple.security.temporary-exception.apple-events entitlement. With the last entitlement, the system prompts the expected dialog, that asks the user, whether the aspp can have access to a specific application. Everything works file as shown on slide 25 of the lecture about the new security of macOS at the WWDC:

https://developer.apple.com/videos/play/wwdc2018/702/

The reviewer linked the documentation about entitlements, where you can find the advice to use the com.apple.security.temporary-exception.apple-events, if the app uses the scripting bridge beyond email composing:

https://developer.apple.com/library/archive/qa/qa1802/_index.html.

We are using the official Scripting Bridge API (no hack), we are sandboxed our app, we have defined entitlements for sanboxing and the NSAppleEventsUsageDescription property in the info.plist file of the app. Furthermore we have defined the proprties for hardened runtime. Everything works fine to make the macOS intended security mechanism and user experience working.

If Apple decides to reject all apps, which are using the scripting bridge beyond composing emails, it should have been announced earlier, because our company has invested a significant budget in the macOS app development. The user experience for installing apps from outside the store has become worse and there is a risk, that macOS will become a closed system like iOS.

We would appreciate any solution to keep our app in the store with the core features, that have been accepted since years by Apple reviewers.

>where you can find the advice

Ouch... I'd suggest to avoid relying on something 5 yrs. old [2013-10-10] and no longer being updated.

Thanks for posting the link to QA1802. As I expected, that Q&A is technically correct but clearly misleading based on App Review’s policies. Alas, I’m not able to fix it because of systems changes at our end (hence the warning at the top of the doc indicating that it’s no longer being updated).

With regards your bigger issue:

• I’m not able to help you App Review approval issues.

• On the technical side of this, earlier I wrote:

To offer further advice I need to know what your app does. What app are you controlling via ScriptingBridge? And what are you doing in that app?

That offer still stands.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

@eskimo. Thanks for your reply.

Our app mainly provides contextual content to replace search by respecting privacy. The semantic analysis of the context is done locally without any cloud service.

Here is the snipped of the entitlements for the supported apps:

com.apple.security.temporary-exception.apple-events

  com.microsoft.powerpoint
  com.microsoft.excel
  com.microsoft.word
  com.microsoft.outlook
  com.evernote.evernote
  com.apple.iwork.keynote
  com.apple.iwork.numbers
  com.apple.iwork.pages
  com.apple.notes
  com.apple.preview
  com.apple.mail
  com.apple.addressbook
  com.apple.textedit
  com.apple.safari
  com.apple.itunes
  com.apple.iphoto
  com.foldingtext.foldingtext
  com.metaclassy.byword
  com.mindjet.mindmanager.10
  com.google.chrome
  jp.informationarchitects.writerformacosx
  com.apple.Photos

As required in the documentation, we don't use the scripting bridge for Finder. Instead we use another approach for this use case. Email is a good example: We use the scripting bridge to get the selected email, then the text and metadata for an input of a semantic analysis pipeline.

Our app mainly provides contextual content to replace search by respecting privacy. The semantic analysis of the context is done locally without any cloud service.

So how does that work? Is your app continuously scripting these target apps? Or does it run requests in response to user actions? For example, you wrote:

Email is a good example: We use the scripting bridge to get the selected email, then the text and metadata for an input of a semantic analysis pipeline.

How is that triggered? Automatically? Or via a user action?

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks for your question. If the user has one of the supported apps in the front, for example email, he or she can use a shortcut or the service menu to trigger the process for contextual content in our app.

It sounds like you are confused about new Mojave requirements and standard App Store requirements. The hardened runtime and the new entitlement are strictly for Developer ID apps. The rules for Mac App Store apps have not changed. The only thing surprising in your post is that you ever managed to get that app approved in the first place.

I have seen a number of your posts and have always reponded with the same reply. You continue to ignore it. You are certainly within your rights to keep fighting app review instead of selling software, but I’m getting tired if saying the same thing. Your app is not suitable for the Mac App Store. App Store apps should be self-contained. Anyone who manages to get something approved that isn’t (myself included) should realize they are livng on borrowed time.

Your app may not be suitable for the Mac at all. Apple Events are designed for end-user automation. By any reasonable evaluation, it is a walking-dead, zombie architcture with maybe another couple of years left before Apple kills it.

Sorry, I don't understand your message. We are considering many App store requirements. Just to list some of them:

1. Consequently sanbixed app with security scoped bookmarks
2. Complete Entitlements
3. Complete info.plist proprties for security dialogues
4. No external links
5. No scripting bridge to control Finder
6. No terminal commands like with NSPipe and NSTask
7. Only native code and official APIs
8. Only App Store purchase for payed features

With the help of this community, we could resolve the issues, that we have posted in other threads. In one case Apple confirmed a bug, that we found and helped us to find a workaround.

System integration is very important for modern apps. Therefore, macOS offers several official APIs for this purposse. The security mechanism ensures, that this system intergration is transparent for the user, to control his or her privacy. A store app has to take care, that these security mechanisms like sandboxing are properly used.

Mojave introduces new security features, which required to adapt our app. The store guidelines may not have changed. Thus the scripting bridge should be allowed. I have just have seen the restriction for Finder.

We appreciate any help to find a solution.

If the user has one of the supported apps in the front [they] can use a shortcut or the service menu to trigger the process …

OK. Given that, you should be able to create a solution that is both convenient for your users and passes App Review.

IMPORTANT I don’t work for App Review and thus cannot make definitive statements on their behalf. If you decide to go down this path, you will need to work with App Review on the details.

First things first, your app has to do something useful out of the box. Thus you have to make sure that your base UI is usable. For example, you could set things up so that the user can drag’n’drop content into your app, copy’n’paste content into your app, and so on. I’ve worked with some apps that include a floating palette to make this super convenient.

Given that base level of functionality, your next step is to find a way to create a smoother user experience that App Review will accept. I have a couple of suggestions on that front:

• You should make your app scriptable, so the user can write AppleScripts or Automator actions that take content from their app of choice and add it to your app. You can then put a variety of such sample scripts on your web site or, assuming App Review approves, include those samples in your app’s help, or documentation, or whatever.

• You could further enhance this by integrating

  NSUserScriptTask

  into your app. The user could then write an AppleScript to import content that can be triggered by your app’s logic.

  Keep in mind that this API was designed as a way for apps to implement AppleScript attachment user interfaces, not as a sneaky way around App Store policy, and thus you need to implement this in some general way.

I realise that these suggestions aren’t as seamless as your current solution, but I think that if you work with App Review you should be able to come up with a compromise that’s acceptable to both sides.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I'm sorry, but I don't know how to say it any other way. You are confused.

There are 3 ways to distribute your Mac software:

1) Mac App Store

2) Developer ID

3) Unsigned (but really not recommended)

This is entirely separate from any Mojave-specific issues. Mojave issues apply to any app.

Mojave adds some problems like Full Disk Access, AppleScript, and Notorized apps.

The Mac App Store has a number of well-known issues. I don't know of any that are specific to Mojave. In most cases, those issues that have new Mojave problems are completely forbidden in the Mac App Store. (There are many details that I'm omitting here for clarify).

According to everything I have seen about your posts, your app is not suitable for the Mac App Store. You can distribute your software using a Developer ID and 90% of your problems will go away in a single day, if not a couple of hours. You will still have to deal with new Mojave issues, but with a Developer ID, you are free to do whatever you want, tell the user whatever you want, and lead them to wherever you want. It's your party.

If you really want to go the extra mile, you can have a stripped down "Lite" Mac App Store version of your app. You can even charge people to move out of the Mac App Store for the "Pro" version. This will have little or no impact to your marketing. In my experience, the Mac App Store generates very little organic traffic.

I don't know what your list is about. I can assure you that external links, terminal commands, and pipes work just fine in the Mac App Store.

Sure, we can offer our app outside of the store, but the installation of apps outside of the store require a confirmation in the security settings. This is for mos consumer not obvious. However most import is the business value of the store for marketing, in-app purchases, update distribution and last but not least staitstics. It's expensive to create and maintain this infrastructure. 30 % provision is high, but it's valuable. Having the app in the app store is a very important strategic benefit.