Update cocoapod to support arm64 simulators on m1 Macs

Question

Update cocoapod to support arm64 simulators on m1 Macs

evelant opened this issue 4 years ago · 33 comments

The cocoapod for this library is outdated and does not compile for iOS simulator on arm64 (Apple M1) Macs. Due to this arm64 Mac owners are forced to compile their apps in x86_64 emulated mode.

Here is a description of the update needed to resolve this problem from another library where this was recently fixed:

Latest version of Cocoapods should be installed.

for the binary distributed framework, Apple XCFramework Bundle, that contains all architectures, is used. The format is the same as when used in Swift packages. / Note: this did not work originally with Cocoapods when both x86 and amr64 simulator binaries were present in the framework, but seems working now

No architecture is excluded in Cocoapod podspec or XCFramework project configurations. In Internet, there are various workarounds described, that in order to make Cocoapods working recommend excluding the arm64 simulator architecture in the configurations. This makes the app compilable for devices, but the app then obviously did not compile or run for simulators on M1 Macs.

Steps to Reproduce

Attempt to compile a project with react-native-google-signin on an arm64 Mac for the iOS simulator

Expected Behavior

arm64 Macs have been available for some time now, the library should compile for simulators running on them

Actual Behavior

Compilation fails with

ld: in /path/to/project/ios/Pods/GoogleSignIn/Frameworks/GoogleSignIn.framework/GoogleSignIn(GIDEMMErrorHandler_3a47e13d8ca81b41e9cdb7ef5468004a.o), building for iOS Simulator, but linking in object file built for iOS, file '/path/to/project/ios/Pods/GoogleSignIn/Frameworks/GoogleSignIn.framework/GoogleSignIn' for architecture arm64

Environment

MacOS 11.2 (arm64 M1)
react-native 0.63.3
google-signin 5.0.0
RNGoogleSignin 5.0.0 (pod)

Answer 1 · 2021-02-19T21:21:24.000Z

I'm not using M1 Mac, but I also get this specific error when running the app in release mode. --configuration=Release

Answer 2 · 2021-02-20T01:19:36.000Z

I am also getting this error running on release mode and not using M1 Mac.

Answer 3 · 2021-02-25T21:55:16.000Z

I think this is more a problem with the google sdk rather than with the cocoapod, no?

Answer 4 · 2021-03-01T21:04:39.000Z

@petea ia marked as a maintainer in the pod page, but that pod don't see a update in a long time

Answer 5 · 2021-03-01T21:17:01.000Z

firebase/firebase-ios-sdk#7208

Answer 6 · 2021-03-18T08:59:21.000Z

I'm not using M1 Mac, but I also get this specific error when running the app in release mode. --configuration=Release

any update?

Answer 7 · 2021-06-29T19:16:36.000Z

Some people mirror the sdk with the arm64 support.
https://github.com/AckeeCZ/OpenGoogleSignInSDK

Is there any change we can use this as a dependency for this project?
I'm not sure how to help including it

Answer 8 · 2021-07-01T12:04:45.000Z

Some people mirror the sdk with the arm64 support.
https://github.com/AckeeCZ/OpenGoogleSignInSDK

Is there any change we can use this as a dependency for this project?
I'm not sure how to help including it

+1

Answer 9 · 2021-07-01T12:18:57.000Z

Have you tried replacing it? Could be an option if it's easy to replace with the original library

Answer 10 · 2021-07-08T23:14:05.000Z

I'm happy to announce that next week we'll be making a substantive update to Google Sign-In for iOS that will provide Simulator support on M1 Macs among other improvements. I'll provide another update here as soon as the new release is available.

Answer 11 · 2021-07-08T23:59:55.000Z

@petea fantastic! I actually had a go this afternoon at switching to the OpenGoogleSignInSDK from @AckeeCZ and found that for this module it would be pretty non-trivial to switch, so having the current underlying SDK working for M1 macs will be a big win.

Just in case someone else has a better time of it than me or someone else wants to know why I say it's difficult here:

OpenGoogleSignInSDK is Swift while this is Objective-C. Swift is the right choice, but the interop is missing (@objc marks in the SDK etc) so either PR to the SDK there or convert to Swift here
OpenGoogleSignInSDK is published for Swift Package Manager but react-native ecosystem is cocoapods (for now), so PR a podspec there (not hard, but something to do) for interop here
OpenGoogleSignInSDK does not appear to have the button APIs that this module needs, that was where I went "oh no" and stopped

It's software, so anything is possible, and the OpenGoogleSignInSDK looks like a great solution - but for an Objective-C/Cocoapods project that needs more APIs than it currently has it would require a lot of adaptation.

So I'll wait a week :-)

Cheers

Answer 12 · 2021-07-13T21:27:08.000Z

Google Sign-In iOS 6.0.0 has been released and is now open source on GitHub!

https://github.com/google/GoogleSignIn-iOS

Answer 13 · 2021-07-14T22:19:00.000Z

@mikehardy Have you had any chance to look into the upgrade?

Answer 14 · 2021-07-14T23:54:34.000Z

any update?

Answer 15 · 2021-07-15T01:05:42.000Z

Nope sorry. On billable work more than full time at the moment.

Answer 16 · 2021-07-15T17:02:21.000Z

I took another look at this morning. Unfortunately the change from v5 to v6 of the GoogleSignIn library represents a wide-ranging set of breaking API changes.

https://github.com/google/GoogleSignIn-iOS/releases/tag/6.0.0

API surface updates
- GIDSignIn
  - sharedInstance is now a class property.
  - signIn is now signInWithConfiguration:presentingViewController:callback: and always requests basic profile scopes.
  - addScopes:presentingViewController:callback: is the new way to add scopes beyond basic profile to a currently signed-in user.
  - restorePreviousSignIn is now restorePreviousSignInWithCallback:.
  - disconnect is now disconnectWithCallback:.
  - The GIDSignInDelegate protocol has been removed in favor of GIDSignInCallback and GIDDisconnectCallback blocks.
  - All sign-in flow configuration properties have been moved to GIDConfiguration.
- The GIDConfiguration class had been added to represent the configuration needed to sign in a user.
- GIDAuthentication
  - getTokensWithHandler: is now doWithFreshTokens:.
  - The GIDAuthenticationHandler typedef has been renamed GIDAuthenticationAction.
  - refreshTokensWithHandler: has been removed, use doWithFreshTokens: instead.
- GIDSignInButton no longer makes calls to GIDSignIn internally and will need to be wired to an IBAction or similar in order for you to call signInWithConfiguration:presentingViewController:callback: to initiate a sign-in flow.

Things here that make it hard to actually do the work:

The example is out of date, react-native 0.61.1, I don't believe it even works with Xcode 12.5, so it is not a great basis for work here, and it's a custom job (not the result of npx react-native init GoogleSignInExample or anything) so it's special-purpose work to update it, at which point it will go stale again etc.
This library uses some sort of promise wrapper that I haven't seen before. Is it even necessary?
Personal issue: I'm fairly terrible at Objective-C

So, I ran out of time budget on this one again. Not sure when/if I'll have another time slice but what we really need here is someone with react-native skills to refresh the example app here as a basis for development, and with Objective-C skills to get busy with it.

It would probably be easier to use the sample app in the new repository as a basis for a fresh implementation from scratch.

Answer 17 · 2021-07-15T20:26:56.000Z

That's unfortunate, sadly I can't help either since I don't do Objective C, can you think of any workaround to disable google-signin in the build for simulator?

Answer 18 · 2021-07-15T20:35:02.000Z

Yeah, in my project I'm currently running a new "arm64-hack" package.json script that does an rm -f on the RNGoogleSignin.podspec file and then pod install again. No podspec? No iOS build for it.

Then in AppDelegate.m I use an #ifndef __arm64__ / #endif compiler directive pair around all the things that include google sign in items (the .h file reference, the link handling reference lower in the file) so they aren't touched since they no longer exist (pod install` doesn't install the library with no podspec...)

At that point, you've hacked out the iOS bits that touch google signin. The last item that might catch you out is that if you are running under VS Code and attempt to compile in the terminal inside VSCode you'll run into the bug where VSCode terminals are running under Rosetta 2 for some reason, which I will cross-link with this reference here: microsoft/vscode#116763

It will work if you use Terminal outside VS Code though.

My app is now running (or, limping) along on Apple Silicon, just without this google signin functionality at the moment.

Answer 19 · 2021-07-15T23:51:29.000Z

I will look into that, thanks a lot for your iinput

Answer 20 · 2021-07-16T17:55:18.000Z

This migration guide should help - https://developers.google.com/identity/sign-in/ios/quick-migration-guide

Answer 21 · 2021-07-16T18:09:10.000Z

That is a help - thanks @paulb777 - happy to see anyone else do a PR here of course, but if not I may have a timeslice for it again next week

Answer 22 · 2021-07-16T18:15:50.000Z

Also the example at firebase/quickstart-ios#1222 might be a useful template.

Answer 23 · 2021-07-18T18:12:07.000Z

Hi, I created a sign in library using the new module over the weekend. It is still very WIP and currently hosted at https://github.com/kalvin807/react-native-google-sign-in. Take a look if you are currently migrating your app :)

Answer 24 · 2021-07-19T14:59:57.000Z

@kalvin807, I attempted to create an ephemeral PR between your module and this one and it is not even a fork of this repo so I was unable to compare changes. This repo has 2300+ stars indicating a sizable community of interested people, I'm not sure why you would base your work in a hard-fork manner given the maintenance notice on the repo:

If you want to get involved in the maintenance of this module, let me know and I'll invite you to the repo! Ideally, I'd like you to have some track record in OSS before I do that - you can easily contribute from a fork too, in order to build that track record. :)

It appears you just need to ask if you would like to make wide-ranging changes like your first issue / release 1.0 roadmap.

Given the openness to new collaborators in that message, hard-fork doesn't seem warranted unless I'm missing a technical reason for it?

Curious if I'm missing something.

Answer 25 · 2021-07-20T02:06:27.000Z

@mikehardy I was planned to create a new library instead, but I do agree you on the popularity of the project already gained. I will create merge my project into this by PRs, to merge the new example and support on new iOS google signin module

Answer 26 · 2021-07-20T15:24:07.000Z

Oh that's excellent! Never underestimate the power of community over time - out of those 2300 stars, it may not seem like a lot of PRs come vs the amount of people using it, but if even 1% contribute back that's 20 people that can help test things and report issues and port to the latest react-native API (or whatever) which is an unbelievable benefit when it comes to year 3 or year 4 of a project. Always better to keep a community in one spot of you can.

I'm excited to see the PRs and can help test, myself. I'm interested in getting the new arm64-capable version of underlying SDK merged of course, I just don't have time for the actual Objective-C work since I'm so slow at Objective-C 😅

Answer 27 · 2021-07-29T14:02:35.000Z

Hi guys, I see that there is a lot of progress, So I am wondering if that will be solved in the near future?

Answer 28 · 2021-08-15T12:19:01.000Z

Hello folks, I have started the work to upgrade this lib to google sign in SDK v6 to unblock this issue.

I am planning to work on this in some spare time over the next few weeks. If you want to support me, you can do that via a one-time sponsorship here or by a regular, recurring sponsorship. All sponsorships are appreciated and will motivate me to spend time on this, such as this Sunday morning. 🤗

First step is almost done here #982 - updating the example app to latest RN. Next up I'll look into upgrading the underlying sdk. Thank you! 🙂

Answer 29 · 2021-08-15T21:22:08.000Z

That's excellent @vonovak - honestly the example app being out of date was one of the biggest stumbling blocks for me to collaborate, I am so tired of fiddling with example apps ;-) - I usually just auto-generate them for that reason

Once you've got that merged, if there's any progress I'll be happy to work with you to test on an M1 mac etc

Answer 30 · 2021-08-16T06:19:54.000Z

@mikehardy yes, example apps are that kind of work that does not really add anything new but still needs to be done 😆 . I'll look at that auto-generation script, thanks!

I'll let you know when there's something to test - I don't have a M1 macbook.

Answer 31 · 2021-08-24T20:13:56.000Z

hello folks, I am pleased to report I made some progress and the latest google sign in sdk can be tested by installing

yarn add @react-native-google-signin/google-signin@alpha

see more in #972 (comment)

Answer 32 · 2021-08-24T21:47:40.000Z

Fantastic @vonovak !! I'll do another round of testing on my M1 machine with this test-integrated and if I see anything I'll let you know. Assuming this works, with iOS+Hermes working on M1 with react-native 0.65 I'm down to one library left: fbsdk :-). Bit by bit...

Answer 33 · 2022-08-16T16:25:28.000Z

Hi all,
I am still getting duplicate symbols error on my M1 macs. version react-native-google-signin/google-signin@8.0.0.

Previously I was using react-native-google-signin, different from this one. It could not build for arm64. So I did

yarn remove react-native-google-signin
yarn add react-native-google-signin/google-signin@8.0.0
cd ios && pod install

But I'm getting the duplicate symbols error. Been stuck on this for some days now.