Cant install wakatime in Xcode 14 stable version

[AlfinIndrawan]

just installed new xcode but all messages show:

 cp: cannot overwrite directory//Applications/XcodeWithPlugins.app/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/SDKs/AppleTVOS16.0.sdk with non-directory /Applications/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/SDKs/AppleTVOS16.0.sdk
cp: cannot overwrite directory /Applications/XcodeWithPlugins.app/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/SDKs/AppleTVOS.sdk/usr/include/libxml2/libxml with non-directory /Applications/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/SDKs/AppleTVOS.sdk/usr/include/libxml2/libxml
cp: cannot overwrite directory /Applications/XcodeWithPlugins.app/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/Library/Xcode/PrivatePlugIns/IDEAppleTVSupportCore.framework/Resources with non-directory /Applications/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/Library/Xcode/PrivatePlugIns/IDEAppleTVSupportCore.framework/Resources
cp: cannot overwrite directory /Applications/XcodeWithPlugins.app/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/Library/Xcode/PrivatePlugIns/IDEAppleTVSupportCore.framework/Versions/Current with non-directory /Applications/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/Library/Xcode/PrivatePlugIns/IDEAppleTVSupportCore.framework/Versions/Current
cp: cannot overwrite directory /Applications/XcodeWithPlugins.app/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/Library/Xcode/PrivatePlugIns/IDEAppleTVSupportCore.framework/Headers with non-directory /Applications/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/Library/Xcode/PrivatePlugIns/IDEAppleTVSupportCore.framework/Headers
cp: cannot overwrite directory /Applications/XcodeWithPlugins.app/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/Library/Xcode/PrivatePlugIns/IDEAppleTVSupportCore.framework/Modules with non-directory /Applications/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/Library/Xcode/PrivatePlugIns/IDEAppleTVSupportCore.framework/Modules

and everything is full of that warning after that it failed. do new version is not updated yet?
im using curl -fsSL https://raw.githubusercontent.com/wakatime/xcode-wakatime/master/install.sh | sh -s copy
the first time is success but it wont show api key in file menu and dashboard still dont change so i uninstall the clone version and install again but it shows that which i dont know why?

[AlfinIndrawan]

well it turns out that there is still leftover in my xcodeplugins , after cleaning them i can clone the xcode without that warning but the api key still dont appear in file menu with xcode 14

[mobile-sergey]

Same issue. After install copy with resign to XCode 14 - not showed menu "File → WakaTime API Key"

[tw93]

+1

[alanhamlett]

Looks like Apple finally completely disabled plugins in Xcode ☹️

[AlfinIndrawan]

Looks like Apple finally completely disabled plugins in Xcode ☹️

Whatttt? Not anymore? Its a big upgrade. I thought you need time to update 🥲.

[AlfinIndrawan]

so do your team have solutions with this? maybe creating external apps or etc? i think lot of us want to hear about your updates with this plugin. :)

[alanhamlett]

No solutions as of yet. This is a very unfortunate move against devs by Apple.

[alokc83]

+1
Does anyone tried building on a local machine and try installing it?
Or converting the project as an Xcode extension?

I am still not able to place where I can put API.
Even though I can build and install successfully.

** BUILD SUCCEEDED **

Cleaning up after installing WakaTime...
Make sure all installed plugins have the latest Xcode compatibility UUID...
Finished installing WakaTime. Launching Xcode...

[alanhamlett]

Does anyone tried building on a local machine and try installing it?

Building locally won't help if Xcode 14 no longer loads plugins.

Or converting the project as an Xcode extension?

Xcode Source Editor extensions can only be run when you manually select them from a menu or manually run the extension's command, which means a WakaTime plugin wouldn't be able to automatically track your code time:
https://developer.apple.com/documentation/xcodekit

[bumothekid]

So there won't be any future for wakatime?

[AlfinIndrawan]

So there won't be any future for wakatime?

Well you have one year because apple will adopt xcode 14 as standard in app store and there are time tracking apps out there but not accurate as wakatime and community support is meh (github readme wakatime api is what makes me interested you can look at my readme)

[bumothekid]

So there won't be any future for wakatime?

Well you have one year because apple will adopt xcode 14 as standard in app store and there are time tracking apps out there but not accurate as wakatime and community support is meh (github readme wakatime api is what makes me interested you can look at my readme)

Well that will be sad tbh cause I'm also a github readme API user :/

[plskz]

Looks like Apple finally completely disabled plugins in Xcode ☹️

pain

[mendozahector]

This is really sad, I just became an active user of WakaTime, and now I can't even use it with Xcode, tried every tool out there, and it simply just won't work with Xcode 14. Why does Apple do these things every single time? 😢

[jtchen2k]

Sad to hear this, I'm wondering if there could be any approach that utilizes accessibility features to track code time for XCode? Like a standalone Wakatime Tracker app or so.

[capnslipp]

I guess my question is: Why was this implemented as an Xcode plugin in the first place, when the venerable macOS AppleScript API will give you all the current-app/current-document information needed for nearly any macOS app (including Xcode)?

For example, if I open up the built-in macOS Script Editor.app and write a rudimentary script:

tell application "Xcode"
	file of active workspace document
end tell

I'll get back file "Space Phoenix:Users:capnslipp:Development:Projects:Advent of Code 2022:Advent of Code 2022.xcworkspace:". A bit more work and you can introspect into the project's targets and schemes and source code documents, etc.

(Alternatively, on the command line run osascript -e 'tell app "Xcode" to file of active workspace document' .)

The AppleScript API (formerly known as the Open Scripting Architecture) can be used via AppleScript or JavaScript scripts, or (more importantly) via Obj-C or C APIs and has been around for about 30 years (predating OS X!)

So I never understood why WakaTime fussed with making a custom Xcode plugin specific to that API when they could've just solved the problem generally for nearly every macOS app all in one go (with minor tweaks for apps with unusual project/document setups). Is AppleScript and the Script Editor.app that has shipped with macOS for decades really not that well-known or understood? Or as an alternative to AppleScript, has no one right-clicked Xcode in the Dock and found the Accessibility Inspector which similarly is an AI to introspect into the current UI state of any running macOS app? Was my long-time wariness of WakaTime needing to modify Xcode via a plugin when it's supposed to just be logging basic usage data justified? Or am I missing something here?

[alanhamlett]

Anything goes to get WakaTime working again for Xcode. Can we run that AppleScript from Xcode user events, like cursor moved or file saved?

[capnslipp]

Anything goes to get WakaTime working again for Xcode. Can we run that AppleScript from Xcode user events, like cursor moved or file saved?

Maybe, but I wouldn't. AppleScript and the Open Scripting Architecture are fairly primitive (30 years old, predating Mac OS X), so even if you can get that data, it would be horribly inefficient. The point of using AppleScript/OSA is to get high-level definitive data on which documents are open and frontmost and the file paths of said documents.

From there, there's some efficient system-wide filesystem change notification API that one could use to see when a file is changed (saved). I don't know what the API is, but I do know its used by a bunch of open source CI tools out there— a quick google search pointed me to git-fsmonitor--daemon which says it “watches the working directory for file and directory changes using platform-specific filesystem notification facilities” as well as NPM packages fsmonitor and fs.watch. And I know over a decade ago I was using some Ruby gem that also touting using the native FS change notification events for each platform. So there should be plenty of sample code out there to work off of— use OSA to check what files are open, then the FS-Notification-Whatever API to watch those files.

Input events are another thing I'm 99.9% sure can be done at a system level without any app-specific plugins or code. I don't know the name of the API, but it's whatever prompts the use for “Input Monitoring” permission in System Preferences ▸ Security & Privacy ▸ Privacy tab (macOS ≤12; not sure if it's been moved/renamed in macOS 13's System Settings). On my machine currently Karabiner, Discord, Novabench, Unity, Steam, OpenEmu, & VirtualBox have all requested Input Monitoring permission, and half of those are open source, so again, looking at their source code to see how they subscribe to system-wise mouse/keyboard events would be a good place to start, and again, solve the problem for all apps across the OS instead of being specific to any one IDE.

[capnslipp]

It would be a fairly major refactoring (including lots of code deletion), but the approach I would take to get this working is rename this repo to macos-wakatime and make it work for any Mac app that provides AppleScript/OSA definitions (which is going to be nearly every native AppKit/Obj-C/Swift mac app). The specific wakatime plugins for cross-platform IDEs like Sublime or VSCode should still take preference, but macos-wakatime should be able to handle lesser-used older tools like Dash, TextMate, TextWrangler, BBEdit just as easily as Xcode because it's all just the OSA API + other system-wide FS & input APIs. This approach would also be a nice fallback for any new code mac-native editors that come on the scene without needing to specifically build & maintain additional wakatime plugins.