Here’s a handy little ditty I cooked up today after getting frustrated with Swift’s compiler warnings. Tested on Xcode 8.3.3.
I don’t like turning them off manually in the build settings, as it’s too easy to forget, but being able to quickly turn them off and on again via hotkey means I can get a bit of peace and quiet and stop the crashes that sometimes occur as the compiler chokes on incomplete code chunks.
tell application id "com.apple.dt.Xcode" -- Xcode.app
tell its front document
tell its front project
tell its front target
tell its build configuration "Debug"
set b to build setting "SWIFT_SUPPRESS_WARNINGS"
if b's value is "NO" then
set b's value to "YES"
else
set b's value to "NO"
end if
display notification "Suppress Warnings was set to " & b's value with title "Swift Compiler - Warnings Policies"
end tell
end tell
end tell
end tell
end tell
Can I ask you a related question?
Have you used Swift, instead of AppleScript, for app automation?
I have not done this, but I understand it can be done.
I have some technical questions about this simple script.
The display notification doesn’t have to be - and arguably shouldn’t be (see 2. below) - inside the Xcode tell block. I had put it there initially in the hope that the notification would appear to come from Xcode and would adopt Xcode’s Notification Center settings.
That proved a vain hope. Regardless of where it is, the notification appears to take on the identify and Notification Center settings of the script runner (FastScripts, in my case).
Having failed in that, I thought to move the display notification out of the tell block, but then realized that would only complicate what is otherwise a very straightforward script in that I’d have to pass b’s value out of the block. Of course, that’s not a big deal, but I wondered whether there was any point in jumping through that hoop.
So my questions are:
Is there any way to get the notification to take on the NC settings of Xcode?
I understand that leaving the display notification call within the Xcode tell block is not considered ‘best practice’, but in this case, does it really make any practical difference?
All it’s doing is generating a couple of errors and being redirected, so the only practical difference is a slight delay. It’s possible that one day security will be tightened and the redirection will turn into a hard error, I suppose.
Thanks, in which case I’ve updated the script to “best practices”.
use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
on sendNotification(aVal)
display notification "Suppress Warnings was set to " & aVal with title "Swift Compiler - Warnings Policies"
end sendNotification
tell application id "com.apple.dt.Xcode" -- Xcode.app
tell its front document
tell its front project
tell its front target
tell its build configuration "Debug"
set b to build setting "SWIFT_SUPPRESS_WARNINGS"
if b's value is "NO" then
set b's value to "YES"
else
set b's value to "NO"
end if
my sendNotification(b's value)
end tell
end tell
end tell
end tell
end tell
#EOF
As an aside, since Xcode now has pretty robust scripting support, I’m going to file an ER against Xcode 9 for its own scripts menu. I can see me writing quite a few more of these handy little ditties and it would be handy to have them all in a dedicated menu option.
As I don’t use the developer Bug Reporter or other public methods for filing, if any of you would also like to file that way it might be useful way to get a bit more attention.