@Quinn - Sorry to dredge up an older thread. I've gone through many of your replies on this topic (which were much appreciated, btw) and I'm confused. The link you mentioned also states: "Before you can use this entitlement, the scriptable app must provide scripting access groups. If it does not, you can still control the app, but you use a temporary exception entitlement instead. In some cases, you may use both scripting-targets entitlement and a temporary entitlement together, to provide support across different versions of the OS. For more information, see Apple Event Temporary Exception." As I learn more about this I'm trying to reconcile: In the case of the scripting-targets entitlement, it reads like the target app must support scripting security groups If the target app does not use scripting security groups you need to use a temporary exception From what I've read on the discussion forums it sounds like using temporary exceptions = app store rejection Or that's how I've read things. Assuming my understanding is correct, is there a suggested process for communicating with external apps using AppleScript when they don't have security groups? We have an academic research app that can only use AppleScript to communicate with external 3rd party statistical tools and Microsoft Office. The other apps don't offer any other mechanism, but AppleScript. Not all of them (any of them?) offer security groups for the current version(s) of their apps and we need to be able to support historical versions up to 5 years prior. We currently distribute our app outside of the app store, but had discussed trying to fully sandbox it so it could be distributed via the app store as a convenience to users. From what I'm reading into this I think avoiding the app store and just continuing to offer a download on our university web site may be the best/most practical option, but I'll admit I might simply not be fully understanding the app store rules. Any insight much appreciated Thank you

I'm seeing the same thing with an app that previously worked. Radar FB9079256 1) AEDeterminePermissionToAutomateTarget no longer responds for StataSE 15. Restarting as was mentioned by @tualatrix.chou helped on the first run. Subsequent runs then failed to respond. Calling that method just goes off into the nether nether. I then tested with Microsoft Word instead of Stata. Everything worked well for Word. 2) We're also seeing some really strange behavior from the scripting bridge now - again, only with Stata in our case. When interacting with Stata if Stata is not running and must be launched then app launches and shuts down repeatedly (several times per second). Xcode is filled with the message: "Scripting Bridge could not launch application id com.stata.stata15". If Stata is already running then the AppleScript calls to it work fine. It seems to be exclusively a problem with launching applications. My co-worker sees identical issues with Stata 16 (com.stata.stata16). This feels really weirdly application-specific to us right now. All of this previously worked until just recently. I don't know specifically when these issues popped up, but certainly they're recent.

Quick edit: We're both using Xcode 11.0 on macOS 10.4.6. (we can't upgrade past that for a variety of reasons) I'm seeing other messages in the console: default 08:03:00.116960 -0500 StatTag UNIX error exception: 17 default 08:03:00.122118 -0500 trustd cert[0]: TemporalValidity =(leaf)[] 0 default 08:03:00.123491 -0500 trustd cert[2]: AnchorTrusted =(leaf)[force] 0 default 08:03:00.123558 -0500 trustd cert[0]: TemporalValidity =(leaf)[] 0 default 08:03:00.123584 -0500 trustd cert[0]: TemporalValidity =(path)[] 0 default 08:03:00.123992 -0500 StatTag Trust evaluate failure: [leaf TemporalValidity] I'm wondering if this might have anything to do with them email from Apple re: signing: If you’re running Xcode 11.4.1 or later, you’ll receive the updated certificate automatically when you sign an app after January 28, 2021. If you’re running an earlier release of Xcode and need to generate new certificates, download and install the new intermediate certificate and utilize the command line to sign your app. You can also archive your build with your existing Xcode version and sign it for distribution with Xcode 11.4.1 or later. 

Updated to macOS 11.2.3 and Xcode 12.4. Same behavior.

Hi, Quinn - First, thanks for the response. If R has both Apple silicon and Intel builds, the most obvious path forward is to link the Apple silicon ‘slice’ of your app to R’s Apple silicon build and the Intel slice of your app to R’s Intel build. I wasn't aware you could compile one universal app and link to two different libraries with different architectures like that. Is there any documentation on how to approach that? The only discussion I've found has been that WWDC session from last year. Right now when we build now we point to the /Library/Frameworks/R.Framework/Current symlink which resolves to whichever single version of R is listed as "Current" (EX: /3.1). When the user runs the app we then pull in "Current" and reference whichever version of R the user has installed - could be Intel and, as of last week, could be ARM. We don't know. We simply hit "Current" and pull in whichever version of R the user has designated as appropriate. If I understand this we'd have something like... R 3.1 (Intel) R 4.1 (ARM) both living in /Library/Frameworks/R.Framework. I'm struggling to grasp how we build against R as you describe. Right now we have a single reference to a single library in the build dependencies. BTW - not doubting you at all - I simply haven't heard of this approach before. I'd love to have more information on this. We're doing this for an open source app sponsored through an NIH research grant. There's an audience out there in our space who would benefit from having a way to interact with R like this from a Mac app and it's something we could at least share with other collaborators and colleagues. Thank you, Eric

@eskimo - You rule. Honestly, we're struggling with wrapping our heads around how to think about this, so I really sincerely appreciate you taking the time to respond to us and doubly appreciate you being willing to investigate. The R framework(s) are available via https://mac.r-project.org/ . There are separate Intel and ARM versions Intel 4.1 - https://mac.r-project.org/high-sierra/R-4.1-branch/R-4.1-branch.pkg ARM 4.1 - https://mac.r-project.org/big-sur/R-4.1-branch/R-4.1-branch.pkg Our audience (medical/biomedical informatics researchers, primarily) tend do want to use their own versions of R with their own packages, etc. installed, so as a result we do not distribute R directly with our app (https://sites.northwestern.edu/stattag/). Instead, we link on build to "Current" and our app links to the R distribution on the user's machine at runtime. Our focus is on reproducible research, so the rationale here is that we want to allow users to govern the specific application (R, Stata, etc.) versions for their project. There are some other challenges with that, but our big question right now is how to approach ARM vs. Intel. I think that means we have three scenarios: Universal app runs on Intel machine with Intel R Universal app runs on ARM machine with Intel R (I had previously tested this on the DTK before there was an ARM R and it worked fine) Universal app runs on ARM machine with ARM R Now that there's the possibility a user could have an ARM machine with either an Intel or an ARM build of R set as "Current," I'm not even sure how to think about this problem. We're in the process of getting an ARM Mac Mini (we two developers both have Intel machines right now) and we hope to be able to do more extensive testing soon. Any insights / ideas / critiques are very, very welcome. Again, thank you Eric (and Luke, Leah, and Abi)

@eskimo - I've opened up access to a demo app on GitHub that takes our R wrapper (RCocoa) and drops it into simple app that lets you enter basic R code to return a single R value. It defaults the R code for convenience https://github.com/StatTag/RCocoaExampleLinkAtRuntime (dummy app - exposes some of the R bits we use in our app) https://github.com/StatTag/RCocoa (R wrapper framework) RCocoa is the R wrapper framework that references R. The dummy app links to the RCocoa project. RCocoa was written by my collaborator Luke and presented at useR! in 2019 (https://www.r-project.org/conferences/useR-2019/posters). Exposing R for incorporation into statistical applications has been super super helpful to our users. Thank you, Eric

Hi, @eskimo - Thank you again for the fantastic response here. My apologies for just now responding (out last week). Luke, Leah I’m sure that generates some office teasing (-: LOL. I got that reference. (insert Steve Rogers meme) I'm also shocked none of us ever realized that... I can't thank you enough for you detailed and extraordinarily considerate response. This is some amazing guidance I'll bring to our team meeting this morning. If you’d like to dig into this in more detail, I’m going to recommend that you open a DTS tech support incident so that I can allocate more time to it. It might even involve gasp a phone call (-: Oh, I'm in! I'll submit it after our team meeting this morning. I'd love to see us do this in a way that benefits our users and also helps others understand how to approach similar needs. Thank you again, Eric (and Team Skywalker)

@eskimo - Finally got our M1 through academic purchasing! DTS request opened! Follow-up: 781056948