Unable to perform Facebook login after updating to Expo Go 2.25.1

Hi All

Recently, I’ve implemented Facebook login in my Expo React Native app by using expo-facebook module, and tested with Expo Go which works well.

However, after I update the Expo Go to the latest version (2.25.1) via App store, it seems that Expo Go is not able to redirect back to my app while performing Facebook login. Attached is the screenshot which shows the error message.

Since it works in the previous version of Expo Go, I’m afraid this might be a bug in the latest version.

Kindly advise, thanks

Platform:
expo-cli 6.0.1
Expo Go 2.25.1
iOS 15.5

Module:
expo-facebook

Hi @adrianlaw823,

We have deprected expo-facebook page with the latest SDk (46) release. However, you can use GitHub - thebergamo/react-native-fbsdk-next

You can read more about deprecated packages in the latest SDK announcement: Expo SDK 46. Today we’re announcing the release of… | by Brent Vatne | Aug, 2022 | Exposition

Hi @amanhimself

Thank you for your reply. I’ll go ahead to try the react-native-fbsdk-next

In my opinion, if those deprecated packages can also be shown under the description of the latest Expo Go app inside App Store and Google Play Store, that would be appreciated. Anyway, thanks again for your help

Hi @adrianlaw823

Did you also upgrade your app to Expo SDK 46? If your app is built with SDK 45 or lower then I believe expo-facebook is supposed to still work.

If you upgrade your app to a new Expo SDK version then you should definitely read about the breaking changes in the release announcement and/or the changelog.

1 Like

Hi @wodin

Forgot to mention, I’m still using SDK45. Few days ago I saw the Expo Go app had an update in the App Store so I just clicked on it. After that, I noticed the Facebook login of my app could not work so I created this post. It turns out that the latest version of Expo Go does not support expo-facebook anymore.

Since my app is still under development and I want to keep using the Expo Go app for testing, I think the only way is switching to react-native-fbsdk-next

1 Like

Hi All

I realise this package cannot be used in the Expo Go app because it requires custom native code.

In that case, I’ll try to use another authentication method. Thanks for the support anyway.

I see. OK, that’s surprising. Then I think it’s reasonable to mention the breaking change in the Expo Go docs on the App/Play Stores.

In case you’re not aware of this you can build a custom dev client (eas build --profile development), which is basically a custom version of Expo Go with your dependencies installed.

Hi @wodin

Thanks for your advice, I’ll consider using the eas build for custom deployment.

Will react-native-fbsdk-next (alternative for expo-facebook) work with SDK 46 while on the classic build and still on the managed flow?

According to this, react-native-fbsdk-next will not work with Expo Go and managed flow since it has native bits. So what would be the backwards compatible option for SDK 46, since SDK 46 still supports managed flow?

You can add it as a plugin by defining it in app.json/app.config.js file and use EAS Build to build your app. For more info on how Expo Config plugins work, please refer to it’s documentation: Config Plugins - Expo Documentation

All SDKs support managed workflows but this type of workflow is useful for the packages/libraries that are also supported by Expo Go app. For libraries like react-native-fbsdk-next which require native configuration and is considered a third party library in Expo’s ecosystem, we recommend building the app through either expo prebuild or eas build commands.

Thanks but my question is related to the classic build. SDK 46 is the last one to support it and it being free I will still be using it for some time still (+ classic builds are indefinite).
So what are my options for facebook login with SDK 46 on managed flow + classic build?

you can also use eas build on the free tier.

1 Like

Classic build command does not support custom native code. If you install a package with a Expo config plugin, you’ll need to add the plugin to your app.json s plugins array, then re-run expo prebuild to sync the changes before rebuilding the native app.

That’s why, as Brent suggested, using eas build on the free tier might be more suitable when using a config plugin from a third-party library.

Since @apps.genie is using the managed workflow I would personally not run expo prebuild.

I would build a dev client using eas build --platform XXX --profile development and use that instead of Expo Go.
Then I’d build the production app with eas build --platform XXX --profile production.

1 Like

thank you guys. It’s probably still me being behind on EAS, but I am not sold on it completely yet and I know I am running out of time on that as well. But this existing update I would still like to be on latest SDK and on classic build. It’s just odd that it was decided for expo-facebook to be removed as part of an SDK version that still supports the classic build and pretty much leaving me no choice but to go the EAS route, since I don’t think I have alternatives to use a facebook login lib that still works with the managed flow and no native bits.

also, would I really need a custom dev client for this @wodin? don’t think I needed something like that with Expo Go and expo-facebook and with react-native-fbsdk-next being almost same as expo-facebook (I assume), I was hoping for it to be a seamless transition behavior wise.

Yes, Expo Go only contains native code needed by what’s in the Expo SDK. If you install something like react-native-fbsdk-next, the native code that it needs is not in Expo Go, so it will not work.

The custom dev client is basically a version of Expo Go that is built just for your app’s dependencies.

2 Likes

in terms of order of steps… I currently have only expo dependencies without any native bits. the app runs fine in Expo Go. is the first step to install react-native-fbsdk-next and then build a custom dev client? or should I do some configuration after installing react-native-fbsdk-next before doing a custom dev build? I guess I am confused on native dependencies… since you can’t test the or even start coding around them, how do you know what to include in the custom dev build?

[EDIT]
Think I finally found this. So that means I first 1) install the package 2) add that plugin section to the existing app.json (not sure I ever used app.config.js and will I need to?) then 3) write code without being able to test it and 4) custom dev client then 5) able to debug in the dev client?

Right. You’ll need to set the app ID, client token etc. in the plugins section, as shown there, before building the dev client.

You can do this in app.json. No need to switch to app.config.js for this.

Not sure which code it is you’re referring to here.

After step 2 you build the dev client. Then you can use your dev client to develop your app. Basically it’s like pretending that you’re using Expo Go and that react-native-fbsdk-next is part of the Expo SDK.

Ok got it. Was just wondering if like there is a way to test the configuration with some code. But sounds like I’d have to build it first. Get a new dev client, then use code to test it. If I run into an error, I change config, go back and rebuild another dev client and then go changing code to test again. I hope that loop doesn’t happen often but sounds like that’s how working with native bits would be?

also, after running eas build --profile development --platform ios, does this mean I am now in the “bare” workflow? Like looking at documentation online, do I now pay attention to the “managed” sections and not the “bare” sections going forward? reason for asking, is that my notifications do not work anymore because it’s missing the projectID or something… and in the docs that is mentioned for the bare workflow…

Like I am confused where the line is between managed and not. I was hoping I can work with both Expo Go and custom Dev client. but only with the Dev Client when I am testing native bits? Or better to forget about Expo Go as soon as I have a package that has native bits (i.e. the facebook one)…