Typically when I create relevance for macOS app bundles, I’m looking at the Info.plist for the version I want to pull back.
Safari.app provides the two key/value pairs:
<key>CFBundleShortVersionString</key>
<string>10.0.1</string>
<key>CFBundleVersion</key>
<string>12602.2.14.0.7</string>
When I find that version is in the CFBundleShortVersionString, for example, I use:
version of folder "/Applications/Safari.app"
Which returns 10.0.1
.
Running the bundle version:
bundle version of folder "/Applications/Safari.app"
Returns 12602.2.14.0.7
.
So far this makes sense. However, when I introduce a new .app bundle, like TeamViewer.app for example, the relevance fails…
The TeamViewer.app Info.plist contains:
<key>CFBundleShortVersionString</key>
<string>11.0.66595</string>
<key>CFBundleVersion</key>
<string>1</string>
When I check the version of it:
version of folder "/Applications/TeamViewer.app"
I get 1.0
When I try to get the bundle version:
bundle version of folder "/Applications/TeamViewer.app"
I get 1.0
If I manually edit the value in CFBundleVersion
it will return my edited version for both version
and bundle version
.
My question is why? Why does Safari.app return the expected values, but TeamViewer (and quite a few other apps) don’t? I’m interested in the best path going forward. I don’t want to create a lot of content with the impression it’s going to work.
P.S. I can work around it using :
not exists file "/Applications/TeamViewer.app/Contents/Info.plist" whose (string "CFBundleShortVersionString" of dictionary of it >= "11.0.66595")