Open core-code opened 1 year ago
Hey @core-code,
Thanks for the report 👍 This is outside my field of expertise but it seems to be related to building the .dmgs. I'll bring it up to the team to see what they can do to improve it. Fingers crossed 🤞
Can you help me understand how this damaged bundle-identifier is affecting your use of Cura?
Hey @core-code,
I discussed your issue with the team. We've added a ticket to the backlog with the intent of improving this.
After digging into this it seems to effect permissions, and window locations and might require you to enter your password more often. They seem to be minor conveniences. Do you have other examples?
For internal reference CURA-10269
Thanks for the report! đź‘Ť
yeah i'd file it as a "minor convenience"
still damaged in 5.3.0 - bundle identifier is ( but should not be ):
nl.ultimaker.cura_UltiMaker_Cura_5.3.0
Please change this back to nl.ultimaker.cura
.
When can we expect a fix for this?
Hey @martinvandiemen,
We have a ticket on our backlog with the intent to find a new workaround for installing multiple versions using pkg, that should resolve this. It doesn't have a high priority so I don't expect it to be resolved very soon.
Can you share how this is an inconvenience for you? That will help us to reprioritize it if needed.
We detect the application based on Bundle ID. Now each version reports its own Bundle ID and version which makes it difficult to get a good picture of versions installed (and impossible to update the app).
We detect the application based on Bundle ID
same here
Giving this a bump as a renewed plea to the development team, please revert this specific decision: https://github.com/Ultimaker/Cura/commit/7e88e3a0192199fee90ec377dd6caf4773983b82
If this was done to differentiate the Enterprise version from consumer, as suggested by the commit message, then the fix is to give each version of the app its own unique Bundle ID, not just append the app name and version onto the end of the bundle ID for every release. Specifically, removing the + "_" {{ short_version }}
from the above code would be enough to avoid this issue as long as the app's display_name
isn't expected to change often/if at all.
It's been said before, but having the app's Bundle ID change every time the app is updated is most certainly not best practice, and consequently breaks a lot of automated patch management workflows, along with the issues mentioned above where the changing bundle invalidates Apple's internal Privacy and Security database entries for things like Full Disk Access, Accessibility permissions, etc. —every time you change the Bundle ID the system will consider it to be a brand new application.
The app should have kept the same bundle ID over its entire lifetime (for example Photoshop's ID is com.adobe.photoshop
since it was first released on macOS!) in order to avoid the privacy permissions issues mentioned above, as well as to ensure automated deployment and patching methods know that when they find an app with a specific unique-and-unchanging ID they are dealing with solely the expected application; if there is a need to compare the version(s) installed then those details can be provided by the app name and version info already included in the CFBundleDisplayName
/ CFBundleVersionString
/ CFBundleShortVersionString
fields, which all Mac MDM/patch management systems already rely on.
Thanks!
It's been said before, but having the app's Bundle ID change every time the app is updated is most certainly not best practice
thats a huge understatement.
If the version would be important it would be the major version in the Bundle ID. This is more common with other apps. For example: nl.ultimaker.cura.5, nl.ultimaker.cura.6, etc.
there is no justifiable reason to have the major-version in the bundle-id either, the only semi-valid reason this has ever been done was to circumvent Apple's rules about disallowing paid upgrades for Mac App Store apps. new BID = new App, so you can charge again...
still broken in 5.9!
I can confirm this: the BundleIdentifier contains: nl.ultimaker.cura_UltiMaker_Cura_5.9.0 and the CFBundleVersion is empty
When you can point to the exact decision that causes this BundleIdentifier issue and give Mac-specific best practices but still garner no response… it would appear that Ultimaker’s preference is to remain broken & incorrect for the time being 🤷
Internally we’ve decided to look elsewhere in the marketplace for 3D printing hardware & software; even though it is often the case, it (ideally) shouldn’t be incumbent on IT depts. to fight uphill battles with software where the manufacturer can’t be bothered to implement modern management and deployment methods.
Application Version
5.2.2
Platform
macOS
Printer
None
Reproduction steps
all previous versions of UltiMaker had a proper CFBundleIdentifier (
nl.ultimaker.cura
) but the newest download has a broken one (nl.ultimaker.cura_UltiMaker_Cura_5.2.2
).the version number is definitely not supposed to be inside your bundle identifier as per Apple's documentation.
also, due to the change from previous versions you'll loose all native macOS preferences and caches.
Actual results
broken bundle identifier
nl.ultimaker.cura_UltiMaker_Cura_5.2.2
Expected results
bundle identifer should stay at
nl.ultimaker.cura
Checklist of files to include
Additional information & file uploads
see above