STM32CubeMX on macOS does not properly register .ioc files

[Meyerii]

I am having an issue with .ioc file association on macOS when using STM32CubeIDE 2.2 together with the standalone STM32CubeMX.

The .ioc file does not seem to be properly registered with macOS.

For example, in Finder, .ioc files are shown as unknown files rather than as STM32CubeMX project files.

More importantly, when I open an .ioc file from STM32CubeIDE, STM32CubeMX is launched, but it stays on the welcome screen instead of opening the selected .ioc project.

The behavior is roughly:

STM32CubeIDE
      ↓
STM32CubeMX launches
      ↓
CubeMX stays on the welcome screen
      ↓
project.ioc is not opened

 

I've made some checks. macOS does not appear to assign a normal, application-specific UTI to the .ioc file.

For example:

mdls -name kMDItemContentType -name kMDItemContentTypeTree project.ioc

returns:

kMDItemContentType     = "dyn.ah62d4rv4ge80w55d"

kMDItemContentTypeTree = (
    "public.item",
    "dyn.ah62d4rv4ge80w55d",
    "public.data"
)

I also checked the application bundle:

plutil -p /Applications/STM32CubeMX.app/Contents/Info.plist | grep -i ioc

This returns nothing.

As far as I can tell, the macOS version of STM32CubeMX does not currently declare a document type or UTI for .ioc files in its Info.plist.

Interestingly, CubeMX itself can open the file

The .ioc file is not corrupted.

If I run the CubeMX executable directly and pass the file as an argument:

/Applications/STM32CubeMX.app/Contents/MacOS/STM32CubeMX project.ioc

CubeMX opens the project correctly.

So the problem seems to be specifically related to how macOS launches CubeMX with the .ioc file, rather than a problem with the .ioc file itself or with CubeMX's ability to parse it.

 

This makes me suspect that the macOS application package may be missing the necessary LaunchServices document type registration for .ioc.

For example, I would expect the application bundle to contain something along the lines of a CFBundleDocumentTypes entry for the .ioc extension, possibly together with an exported UTI for STM32CubeMX projects.

I have not modified the application bundle myself, so I cannot say for certain that this is the only issue, but the behavior seems consistent with missing file type registration.

 

Ideally, macOS should recognize .ioc files as STM32CubeMX project files, and opening one from Finder or STM32CubeIDE should launch CubeMX and open that particular project.

This is particularly important with STM32CubeIDE 2.x, since CubeMX is now a separate application.

Could someone from ST confirm whether .ioc file association is currently supported on macOS?

If it is supposed to be supported, could you please check the macOS packaging of STM32CubeMX and the LaunchServices registration for .ioc files?

Thanks.

[Ghofrane GSOURI]

Hello ​@Meyerii 

Could you please provide a few additional details so this can be investigated more accurately?

• macOS version you are using
• STM32CubeMX version currently installed
• Whether the issue occurs with all .ioc files or only with a specific project

I will be waiting for your feedback.

THX

Ghofrane

[Meyerii]

Hello,

Thank you for the follow-up.

Here are the requested details:

• macOS: 26.6.1, running on Apple Silicon

• STM32CubeMX: 6.18.1

• STM32CubeIDE: 2.2.0

The issue occurs with all .ioc files I have tested, not just with a specific project.

I also tested the same .ioc file by launching CubeMX directly from the command line:

/Applications/STM32CubeMX.app/Contents/MacOS/STM32CubeMX project.ioc

In this case, CubeMX opens the project correctly.

The problem only occurs when the .ioc file is opened through the normal macOS file association / LaunchServices mechanism. In that case, CubeMX is launched but remains on the welcome screen instead of opening the selected project.

I also noticed that macOS assigns a dynamic UTI to the .ioc file, and the STM32CubeMX Info.plist does not appear to contain an .ioc document type declaration.

Please let me know if you need any additional logs or information. I can provide the relevant command output as well.

Thank you for your help.

[Pavel A.]

​@Meyerii This behavior actually can be desired. Several CubeMX versions can be installed side by side, and developers can work in parallel on several projects based on different CubeMX versions. The same applies,  of course, to Windows and Linux.

So it may be simpler to start the desired CubeMX instance first, and open the .ioc file via its file/open interface.

To deliberately update/migrate a specific project to newer HAL library version and newer Cube, user can start this newer Cube version, open the .ioc and accept prompt to migrate.  Otherwise, the migration prompt means you’re using the wrong Cube version for this .ioc. 

Mac OS supports per-file overrides that are stored in the file’s extended attributes (Finder → Get Info → Open With → Always Open With) - but this is too much hassle IMHO (and interferes with the upgrade scenario).

UTI (either plist based or dynamic) does not help, because the OS has no idea.