M1 project compatibility

defagos commented 3 years ago

We still use CocoaPods, not running natively on M1 yet. It is possible to use the arch command to run the command on Rosetta.

Proposal:

We are the only ones building the project on M1, so there is no hurry. We can wait until CocoaPods properly run on M1.
If support is not ready at the time we switch our development Macs to M1, we can update the Makefile so that the pod command is forced to run on Rosetta.

defagos commented 3 years ago

The application runs fine on M1, except when playing on-demand audio. This is an AVFoundation issue, see our corresponding SRG Media Player issue.

defagos commented 3 years ago

Still not working correctly on macOS 11.6 with our 3.3.0 version built using Xcode 13 and the iOS 15 SDK. Guess we should report this issue to Apple.

defagos commented 2 years ago

I confim that version 3.4.0 now crashes on M1, while 3.3.0 wasn't. The stack trace is not the same, but it is likely related to our new CarPlay support. We should check what happens on Monterey.

defagos commented 2 years ago

The CarPlay-related crash is fixed when running the application on macOS Monterey.

pyby commented 2 years ago

@defagos Thank you for the tests on Monterey. A Mac mini M1 with Big Sure has the same crash with production version 3.4.0.

So, I updated the "Make this app available" to "MacOS 12.0" for the 5 Play SRG application on AppStoreConnect.

For now, I didn't pass the "Verify compatibility" check, proposed by Apple.

defagos commented 2 years ago

Here are the steps to update the project to compile on M1 (and Intel as before):

Use Google Cast SDK binaries with arm64 simulator support. Google is working on arm64 simulator binaries, not sure if they will be available with CocoaPods as well, otherwise we'll need a way to integrate the XCFramework instead.
Edit the Application.xcconfig files and remove EXCLUDED_ARCHS.
Remove the same EXCLUDED_ARCHS code from the Podfile as well.

Alternatively, for Google Cast M1 simulator compatibility, it might be possible to use a hack on M1 to tweak the binary integrated with CocoaPods (or the framework directly). If all solutions fail it might be possible to tweak the project so that binaries are not linked with the iOS simulator build on M1, but that requires conditional compilation and it is likely an ugly solution.

I'll stop there for the moment, as I don't want to spend too much time investigating this issue while Google is still working on delivering binaries. If nothing changes when we receive our M1 Macs we'll investigate the other possibilities listed above.

pyby commented 2 years ago

Google provided a beta version with dynamic XCFrameworks: https://issuetracker.google.com/issues/174048822

We created a temporary SPM repository to distributed it: https://github.com/SRGSSR/GoogleCastSDK-ios-no-bluetooth
Fix an issue in a Info.plist of ios-arm64/GoogleCast.framework: DTSDKName, DTPlatformName and CFBundleSupportedPlatforms MUST declare an "iphoneos" platform, not an "iphonesimulator" one.

Proposition is on feature/googlecast-sdk-xcframework branch.

pyby commented 2 years ago

The Play iOS 3.5.1-378 build is released in production and validated by Apple as well.

Both Play iOS 3.5.1-378 and Play tvOS 1.5.1-32 builds were uploads on AppStoreConnect from a Mac mini M1 and Xcode 13.3.0

SRGSSR / playsrg-apple

M1 project compatibility #174