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

[core-code]

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

• Log file
• Project file

Additional information & file uploads

see above

[MariMakes]

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]

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]

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

[core-code]

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

nl.ultimaker.cura_UltiMaker_Cura_5.3.0

[martinvandiemen]

Please change this back to nl.ultimaker.cura.

[martinvandiemen]

When can we expect a fix for this?

[MariMakes]

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]

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]

We detect the application based on Bundle ID

same here

[MrCoBalt]

Giving this a bump as a renewed plea to the development team, please revert this specific decision: 7e88e3a

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]

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]

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]

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