Ultimaker / Cura

3D printer / slicing GUI built on top of the Uranium framework
GNU Lesser General Public License v3.0
6.23k stars 2.08k forks source link

[macOS] UltiMaker Cura 5.2.2 has a damaged "bundle-identifier" (CFBundleIdentifier) #14375

Open core-code opened 1 year ago

core-code commented 1 year ago

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

MariMakes commented 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?

MariMakes commented 1 year ago

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! đź‘Ť

core-code commented 1 year ago

yeah i'd file it as a "minor convenience"

core-code commented 1 year ago

still damaged in 5.3.0 - bundle identifier is ( but should not be ):

nl.ultimaker.cura_UltiMaker_Cura_5.3.0

martinvandiemen commented 1 year ago

Please change this back to nl.ultimaker.cura.

martinvandiemen commented 1 year ago

When can we expect a fix for this?

MariMakes commented 1 year ago

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.

martinvandiemen commented 1 year ago

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).

core-code commented 1 year ago

We detect the application based on Bundle ID

same here

MrCoBalt commented 4 months ago

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!

core-code commented 4 months ago

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.

martinvandiemen commented 4 months ago

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.

core-code commented 4 months ago

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...

core-code commented 2 weeks ago

still broken in 5.9!

suschizu commented 2 weeks ago

I can confirm this: the BundleIdentifier contains: nl.ultimaker.cura_UltiMaker_Cura_5.9.0 and the CFBundleVersion is empty

MrCoBalt commented 2 weeks ago

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.