macOS: Python Launcher app reported in system profiler as "iOS" app rather than "Apple Chips" app

[sierkb]

Bug report

Bug description:

Description

macOS Python Launcher app reported in system profiler as "iOS" app (resp. "arch_ios") rather than "Apple Chips" (resp. "arch_arm") app on an Apple Silicon System.

Steps to reproduce:

1. Open System Profiler app ('/System/Applications/Utilities/System Information.app')
2. Go to Section "Software" -> "Applications"
3. Select row of Python Launcher app in column "Application Name" and have a look look at column "Kind"

Alternatively, via Terminal:
% system_profiler SPApplicationsDataType -xml | grep 'Python Launcher' -A 8 -B 2
or resp.
% system_profiler SPApplicationsDataType -xml | grep 'Python Launcher' -A 8 -B 2 | head -n 5 | grep -A 1 arch_kind

Expected Behavior:
Python Launcher app is shown as "Apple Chips" resp. "arch_arm"
Actual Behavior:
Python Launcher app is shown as "iOS" resp. "arch_ios"

Proposed simple fix/solution:

Add a CFBundleSupportedPlatforms key with MacOSX as its only platform to the app's Info.plist file:

<key>CFBundleSupportedPlatforms</key>
<array>
    <string>MacOSX</string>
</array>

Additional context

See also discussions/fixes around this issue on:

LibreOffice Bug 144200: LibreOffice 7.2 for ARM on Apple Silicon claims its an iOS application
https://bugs.documentfoundation.org/show_bug.cgi?id=144200
LibreOffice Commit: Add CFBundleSupportedPlatforms key with MacOSX as its only platform
https://git.libreoffice.org/core/+/562a40f453caa003187ff28c7798647d9e0b4ded%5E%21

Microsoft issue #157551: VS Code Apple Silicon build is identified as an iOS app in macOS system info
microsoft/vscode#157551

Microsoft issue #121169, issuecomment 820653677: M1 VSCode binary can be run on iOS?
microsoft/vscode#121169 (comment)

BTW: Apple's own macOS apps and most third party apps contain that key in their Info.plist, so, it can't be wrong or invalid and is there for a reason, although not or poorly documented by Apple.

Software:

Python Launcher app (arm64):
3.13.6

System:
% uname -m
arm64

% machine
arm64e

% /usr/bin/sw_vers
ProductName: macOS
ProductVersion: 15.6
BuildVersion: 24G84

CPython versions tested on:

3.13

Operating systems tested on:

macOS

[ned-deily]

I am unable to reproduce the results shown when using an installation from the python.org macOS installer for Python 3.13.6. What I see is below and that's what I would expect. The results you report are very odd. From where did you obtain the Python 3.13 installed on your system? What is the file system location or path shown in the System Profiler output?

% uname -m
arm64
% machine
arm64e
% /usr/bin/sw_vers
ProductName:		macOS
ProductVersion:		15.6
BuildVersion:		24G84
% system_profiler SPApplicationsDataType -xml | grep 'Python Launcher' -A 8 -B 2
			<dict>
				<key>_name</key>
				<string>Python Launcher</string>
				<key>arch_kind</key>
				<string>arch_arm_i64</string>
				<key>info</key>
				<string>3.13.6, © 2001-2024 Python Software Foundation</string>
				<key>lastModified</key>
				<date>2025-08-12T19:15:44Z</date>
				<key>obtained_from</key>
				<string>identified_developer</string>
				<key>path</key>
				<string>/Applications/Python 3.13/Python Launcher.app</string>
				<key>signed_by</key>
				<array>
					<string>Developer ID Application: Python Software Foundation (BMM5U3QVKW)</string>
					<string>Developer ID Certification Authority</string>
					<string>Apple Root CA</string>
				</array>
				<key>version</key>
				<string>3.13.6</string>
% system_profiler SPApplicationsDataType -xml | grep 'Python Launcher' -A 8 -B 2 | head -n 5 | grep -A 1 arch_kind
				<key>arch_kind</key>
				<string>arch_arm_i64</string>

[sierkb]

It's installed it via MacPorts dependency, the glib2 port needs it:

% sudo port installed | grep python
  python3_select @0.1_0 (active)
  python3_select-313 @0.1_1 (active)
  python313 @3.13.6_0+lto+optimizations (active)
  python_select @0.3_10 (active)
  python_select-313 @0.3_1 (active)

% sudo port dependents python313
glib2 depends on python313

It places a Python 3.13 folder into /Applications/MacPorts

% ls -la /Applications/MacPorts | grep Python
drwxr-xr-x   4 root  admin   128 12 Aug 10:42 Python 3.13

with these two Python apps: Python Launcher.app and IDLE.app

% ls -la /Applications/MacPorts/Python\ 3.13
total 0
drwxr-xr-x  4 root  admin  128 12 Aug 10:42 .
drwxr-xr-x  4 root  admin  128 12 Aug 10:42 ..
drwxr-xr-x  3 root  admin   96 12 Aug 10:42 IDLE.app
drwxr-xr-x  3 root  admin   96 12 Aug 10:42 Python Launcher.app

Because it initially seemed logical to me to assume that the Info.plist file could be patched via MacPorts, I looked at it and compared it with the upstream version in the Python project's main trunk. Through visual comparison and diffing, I found that they are almost identical, with MacPorts essentially adopting the upstream version of the Info.plist file from the Python project's PythonLauncher app unchanged.

So I came up with the idea of submitting my request directly to the Python project instead of opening a corresponding ticket with MacPorts, so that the relevant Info.plist file could be fixed upstream right away – the relevant MacPorts port would then inherit it and automatically adopt it with the next upstream version update, or so I thought. I hope that was a good idea.

PythonLauncher.app Info.plist on Python's GitHub Repository
https://github.com/python/cpython/blob/main/Mac/PythonLauncher/Info.plist.in

IDLE.app Info.plist on Python's GitHub Repository
https://github.com/python/cpython/blob/main/Mac/IDLE/IDLE.app/Contents/Info.plist

See also separate Issue 137675 #137675 for IDLE.app's Info.plist
as a potentially 'nice to have, but maybe not need to have', if fixed – contrary to the one of PythonLauncher.app, which I think should get fixed preferably upstream – that's, why I've filed the issue here and not at macports.org.

[ned-deily]

I suspect that most of the difference in here are due to the fact that, AFAIK, MacPorts does not codesign the macOS bundles that they distribute (like IDLE.app and Python Launcher.app) and that can cause some differences in how macOS treats them. I suggest you take this up with them and, if it makes sense to change any upstream code in cpython, I'm sure they will suggest it. Again, as noted in the other issue, the option to launch using Rosetta is a feature that we have no plans to remove.

[ned-deily]

On thinking about it a bit further, this seems like a harmless enough of a change with some cosmetic benefit. We don't see it with the python.org installer versions because they supply Universal apps (i.e. both Intel and Apple Silicon) so it seems that there is no ambiguity to system_profiler in that case. Likewise, Intel-only apps aren't ambiguous. It's just in the case of ARM (Apple Silicon) only apps that potentially could be either macOS or iOS binaries and, for some reason, system_profiler (or Launch Services) assumes iOS in that case. (I have a MacPorts installation which installs python313 from source with their +universal variant and it doesn't have this problem.)

Thanks for reporting it.

[sierkb]

I suspect that most of the difference in here are due to the fact that, AFAIK, MacPorts does not codesign the macOS bundles that they distribute (like IDLE.app and Python Launcher.app) and that can cause some differences in how macOS treats them.

I disagree.
See also for GIMP.app (codesigned), with the same issue, from today:

https://gitlab.gnome.org/GNOME/gimp/-/issues/14665

Fixed, built a test build, tested, merged into the main trunk, closed within 3 hours.

Also, same issue, also codesigned: Inkscape.app, Signal.app, Zed.app, GitHub Desktop app, Google's Chromium app. All these apps are codesigned. All these apps have the same issue. On all these apps, I've filed the same bug today, the one relating PythonLauncher.app among them. The GIMP developers fortunately have reacted very quickly and have already fixed it nearly instantly:

https://gitlab.gnome.org/GNOME/gimp/-/issues/14665

Also a first reaction from the Signal developers with a first request to me:
signalapp/Signal-Desktop#7449

I suggest you take this up with them and, if it makes sense to change any upstream code in cpython, I'm sure they will suggest it.

I still think it's better to address this issue at the upstream source regarding PythonLauncher than to have MacPorts patch it afterwards. I've decided to try it here first, before I file an issue at MacPorts to have the Info.plist be patched via port file.

Again, as noted in the other issue, the option to launch using Rosetta is a feature that we have no plans to remove.

Having in mind, that Rosetta and Intel architecture will be removed from macOS by Apple in one of the next big OS updates and won't be available in future macOS versions. So I think, it would be wise, any situation, that Rosetta may be called unintentionally for example by a script, packaged sole in an app bundle without a binary, should be avoided in the first place, that has been my thought for issue 137675 #137675 for the IDLE.app's Info.plist. But anyway, if you think, a change is not needed, then it's OK, I've meant it as a proposal.

[sierkb]

On thinking about it a bit further, this seems like a harmless enough of a change with some cosmetic benefit. We don't see it with the python.org installer versions because they supply Universal apps (i.e. both Intel and Apple Silicon) so it seems that there is no ambiguity to system_profiler in that case. Likewise, Intel-only apps aren't ambiguous. It's just in the case of ARM (Apple Silicon) only apps that potentially could be either macOS or iOS binaries and, for some reason, system_profiler (or Launch Services) assumes iOS in that case.

Yes. That seems to be the case and the cause for not seeing the issue right away.
See also (firstly hinted to in my given links above in my Additional context section of this issue):
microsoft/vscode#121169 (comment)

Its just an issue with which attribute the storage info queries to decide the kind, the output of system_profiler SPApplicationsDataType -xml shows the arch_kind is arch_ios. I think these look for CFBundleSupportedPlatforms attribute and if not present default to the ios kind for arm64 executables.

Given the universal and intel labels show up correctly, and considering the output of other apple silicon apps in the image posted. I don't think this needs a fix, but leaving it open for anyone to address as a good first issue.

(I have a MacPorts installation which installs python313 from source with their +universal variant and it doesn't have this >problem.)

And my MacPorts installation is arm64-only, no Universal builds. So, consequently, also no Universal build variant of Python, PythonLauncher.app but arm64. And I prefer to install my MacPorts ports as pre-build arm64 binaries via the -b option of the port command, to keep the dependency and build dependency overhead and footprint as low and lean as possible, which would be much higher, if I let macports build my requested ports inclusive all their dependency and above all their build dependency ports from the sources.