Post

Replies

Boosts

Views

Activity

Shared defaults between macOS App and Extension
Hi all, TL;DR; All of a sudden we can no longer use shared defaults between a macOS app and an extension. We've got a CTK extension that we are working on for macOS, and we have hit a bit of a stumbling block right in the middle of development. We are a bit atypical as the extension is sandboxed like normal, but the container app isn't. We have a common defaults suite name that we use to hold a few bits of data that both the .app and .appex need. All of a sudden, this data sharing has stopped working. The docs for UserDefaults say that extensions on macOS are exempt from requiring an app group for shared preferences and this has been our experience so far. Now though it doesn't seem to be the case. The extension is refusing to read the shared domain and making its own copy of the settings inside of its sandbox. If I jump into the debugger in the extension I can see that it can't read the shared domain. This is currently baffling us as it has been working just fine throughout development and beta testing. I had the thought that it could be that some change now requires an app group, but the previous builds continue to work fine. I've requested an app group from our dev ops team so that I can try that and see if things improve. Has anyone else run into something like this? Most of the search results on the web are about iOS appex sharing of defaults. Since that is significantly different than macOS I thought I would ask here. Thanks, Josh
2
0
1.6k
Mar ’21
Are Xcode Extensions busted in macOS BS?
Is anyone else unable to use Xcode editor extensions with Xcode 12 and macOS BS? I'm assuming that there is something going on with Xcode here that is blocking the use of them. I can see Xcode advertise its public extension point in the logs. [d <private>] <PKHost:0x157b13060> Query: {     NSExtensionPointName =     (         "com.apple.dt.Xcode.extension.source-editor"     ); } I can see the plugins are loaded by plugin kit.  % pluginkit -v -m -p "com.apple.dt.Xcode.extension.source-editor"      name.lazarenko.daniel.xcsort.xcsortext(1.1) BF40D8E4-3611-46B6-B320-1E167B793A49 2020-12-15 15:42:34 +0000 /Applications/xcsort.app/Contents/PlugIns/xcsortext.appex      io.quicktype.quicktype-xcode(8.2.22) F673691C-1C2A-48D7-8587-85FECBD0CB05 2020-12-15 15:42:34 +0000 /Applications/Paste JSON as Code • quicktype.app/Contents/PlugIns/quicktype-xcode.appex      de.pmw.ProtocolExtension.ProtocolXcodeExtension(0.1.0) 827CBD12-8E79-4819-A8DB-5C97A3A3F85F 2020-12-15 15:42:34 +0000 /Applications/Protocol.app/Contents/PlugIns/Protocol Extension.appex  (3 plug-ins) The plugins never show up in Xcode to be used. 😢 I'll file a radar soon, but was also wondering if anyone else was seeing this.
2
0
1.5k
Dec ’20
Remote Debugging for Authorization Plugins
Hi all,We are developing a variety of login window plugins for macOS and are looking for greater control of the debugging process. I've followed the steps in Technical Note TN2108: Debugging An Authorization Plug-In With Xcode, but they don't seem to work on modern macOS, even with SIP disabled. It would seem that SecurityAgent has some anti-debug protection in it now as I can't connect to the running instance with lldb.As a work around we've resorted to caveman debugging with lots of log statements, but that's more than a bit of a pain to do as our products become more complex. Having debugging in Xcode would be best, but at this rate I'll even settle for lldb.Any ideas?Thanks,Josh
4
0
3.3k
Dec ’17