Mac Catalyst Support

[johnzhou721]

Fixes #117.

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[johnzhou721]

We're still at the SDK level right now for getting logistics sorted out.

We've had enough white swans to convince us that all SDKs are distinct, but now we have a black swan of Mac Catalyst AND native macOS being macosx.

One could be lame I guess and just use macosx for Mac Catalyst, since the native macOS is already handled anyway; but we're using macabi for the base name of the targets for the dependencies, and also if at one point macOS embedded is going to be built by us and not CPython team like the earlier days of this project (shall we choose to apply some more complicated modifications that official CPython won't merge), it'll clash.

So I'm going to use the approach to try to sort out some of the SDK conflicts -- by abusing macabi as the SDK name UP UNTIL the Target level, where we do a distinction between the base part of the Target, and the actual SDK (since nothing "offical" is done until the Target level in terms of the compilers).

One might want to change the name of the $(sdk) to something like $(targetbase), but I'm choosing to ignore that for now and sort out all the stuff to have it build first; the rest will probably just be find and replace.

Hope this works for you.

[johnzhou721]

Ready for review.

As explained above, we might need to replace the wording for SDK since now it can have values like macabi which is not an SDK -- the actual SDK vs. basename of the target distinction is handled at the target level. So the semantics of the sdk variable at the SDK level has changed. We might need to take care of that.

Otherwise, I've gotten all the build issues sorted out; I'm asking for this review for only the Makefile aka. the logistics for building the whole thing; there's still a couple of test issues we need to dig into, but the idea is similar to how you approved the changes for the logistics in the visionOS patch.

Hope this is good for you. Signing off for the day.

[johnzhou721]

Also: The visionOS pyconfig.h is now copied correctly.

[johnzhou721]

fixed a couple of bugs but would be asleep before either ci or my computer finishes.

[johnzhou721]

OK so now this is actually green + ready for review...

[johnzhou721]

Note -- this got broken since placing the miscellanous PYTHONHOME stuff used to be in the framework Versions/3.14 folder by tradition of Python macOS but it is not an allowed location, so I moved it inside resources (modified everything in the cpython repo accordingly already), but this is not updated yet. Also -- we can now not copy the stdlib for python into the app but just load it from the framework resources for Mac Catalyst... and I did that in the testbed. Pushing a working premature commit right now, so mark as draft.

[johnzhou721]

Nevermind -- should be fixed for now, ready for review again

@freakboy3742 Are you against the general idea of putting PYTHONHOME stuff in the Resources?

[freakboy3742]

We're still at the SDK level right now for getting logistics sorted out.

We've had enough white swans to convince us that all SDKs are distinct, but now we have a black swan of Mac Catalyst AND native macOS being macosx.

... or we do what cpython-apple-source-deps does, and treat Catalyst as a platform.

As I've indicated elsewhere, I'm not yet convinced that a single "iOS XCframework that includes Catalyst" is actually what we need; and the cpython-apple-source-deps example demonstrates, you can keep the build fairly simple if you avoid that conceit.

That essentially becomes my high level review here; there's a lot of complexity that has been added, all in aid of a goal that doesn't seem beneficial. Adopting the cpython-apple-source-deps should end up with a much simpler implementation, with more direct substitutions rather than if clauses.

@freakboy3742 Are you against the general idea of putting PYTHONHOME stuff in the Resources?

I have no idea what you're referring to here.

[johnzhou721]

Yes but if we treat Catalyst as a platform... we'll still wound up using the macosx SDK. So everything will stay the same except that the macabi.x86_64 etc targets will be under a different platform. Also the structure of the framework is sort of different, so that's where a lot of the logic came from. I've made a lot of ifs in the SDK section just to accomodate for the different structure, so perhaps some simplification can be done on the cpython repository build stuff. Last point is sort of off-topic since it's for the cpython repo -- I've been putting the lib/ bin/ and include folders into the Resources directory of the framework because that's what proper framework structures requires for embedded macOS frameworks according to Quinn from Apple Dev Forums -- so is that okay? is what I mean. John

…

On Wed, May 7, 2025 at 10:48 PM Russell Keith-Magee < ***@***.***> wrote: ***@***.**** requested changes on this pull request. We're still at the SDK level right now for getting logistics sorted out. We've had enough white swans to convince us that all SDKs are distinct, but now we have a black swan of Mac Catalyst AND native macOS being macosx. ... or we do what cpython-apple-source-deps does, and treat Catalyst as a platform. As I've indicated elsewhere, I'm not yet convinced that a single "iOS XCframework that includes Catalyst" is actually what we need; and the cpython-apple-source-deps example demonstrates, you can keep the build fairly simple if you avoid that conceit. That essentially becomes my high level review here; there's a lot of complexity that has been added, all in aid of a goal that doesn't seem beneficial. Adopting the cpython-apple-source-deps should end up with a much simpler implementation, with more direct substitutions rather than if clauses. @freakboy3742 <https://github.com/freakboy3742> Are you against the general idea of putting PYTHONHOME stuff in the Resources? I have no idea what you're referring to here. — Reply to this email directly, view it on GitHub <#280 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BRODAI5SARG3SASXO2OIOL325LHZTAVCNFSM6AAAAAB4MHF7JGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDQMRTG4ZDGMRSGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[johnzhou721]

OK so I've just resolved that... I tried to follow the tradition on macOS for framework structure but then realized it has to be in Resources folder so that's where it wound up being -- happy to change if this is not okay with you.

[johnzhou721]

OK so nevermind... this patch broke iOS/watchOS/visionOS as reported in the test suite, unrelated to the other PR, which might be a false positive.

[freakboy3742]

Yes but if we treat Catalyst as a platform... we'll still wound up using the macosx SDK. So everything will stay the same except that the macabi.x86_64 etc targets will be under a different platform. Also the structure of the framework is sort of different, so that's where a lot of the logic came from.

Yes - but "path to resources folder" is then a path that can be configured on a "iOS/macabi/macOS" axis, which doesn't require an if statement - it's configured separately for iOS and macabi.

The complexity here is because you're trying to cram macabi into the iOS "shape". If you make it a separate target, it can have it's own shape.

Last point is sort of off-topic since it's for the cpython repo -- I've been putting the lib/ bin/ and include folders into the Resources directory of the framework because that's what proper framework structures requires for embedded macOS frameworks according to Quinn from Apple Dev Forums -- so is that okay? is what I mean.

This isn't something where I have "an opinion". It's entirely driven by what Apple will accept for App Store distribution.

The location for iOS is driven by the fact that the lib folder cannot be in the framework, or the app will be rejected at the pre-validation stage of submitting to the App Store.

I haven't done a lot of work with Mac App Store submissions, but I know they are a lot more liberal in what they accept (mostly reflecting the fact that Mac apps and frameworks predate the Mac App Store by some margin).

I don't know what (if any) of those restrictions change with a Catalyst app - if it's "just a macOS app" from the perspective of the App Store, or if it's identified as a different platform, and thus subject to different requirements. Asking my opinion on these points doesn't progress the discussion - we need to follow documented procedure; and when documentation doesn't exist, the approach needs to be empirically tested to see what works.

But - again, I need you to slow down. On that basis, I'm going to follow the example of freakboy3742/cpython#11, and not look at this PR any further until freakboy3742/cpython#8 is completed. The issues we're discussion here will be almost entirely resolved by getting that PR to a point of completion.

[johnzhou721]

Regarding breaking iOS CI:

I have PATH as

/Users/johnzhou/cpython-fb37/iOS/Resources/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin

and the command as

./configure \
      --enable-framework \
      --host=arm64-apple-ios-simulator \
      --build=arm64-apple-darwin \
      --with-build-python=/Library/Frameworks/Python.framework/Versions/3.14/bin/python3.14 && make -j && make install && make testios

on the cpython repo, and it starts successfully.

So... this is definitely this repo's patch's fault. I'll let it go for right now.