expo: Unable to link react-native-music-control in ExpoKit 35. App crashes.

FWIW, it’s a pretty weird experience that ejecting from a managed project on SDK 36 results in something with autolinking not enabled - more generally, ejecting results in a template that doesn’t already match the template from react-native init from the SDK version’s react-native version. Not sure if I should open a new issue for this, though; it sounds like a known issue and possibly a wontfix?

@brentvatne could you perhaps clarify whether it’s in the scope of expo eject to produce a react native project that is basically what you’d get from react-native init with the matching RN version (plus ExpoKit, if desired)?

we don’t have documentation for it, this is a react-native upstream thing. you can init a new react-native-cli project and copy over the relevant pieces

The gist was that, for both iOS and Android, there were a few crucial steps required to enable autolinking:

• iOS
  • Pulling in the autolinking module
  • Executing the autolink step
• Android
  • Enable autolinking in build.gradle and settings.gradle
  • Pull in the autolinked packages in MainApplication.java ((import, implementation)

There were a variety of other changes, but those were the main ones related to autolinking. However, those were explicitly described in the blog post I linked, in the “Migrate iOS to Autolinking” and “Migrate Android to Autolinking” sections. Are you sure you applied all the changes listed there?

We’re veering a bit out of scope of the issue tracker here, but if you open something on Stack Overflow and link it here, I’d be happy to continue helping to figure out the details.

@pedro-lb not sure if you’ve already sorted this out, but this tutorial should contain the aforementioned relevant pieces: https://reactnative.thenativebits.com/courses/upgrading-react-native/upgrade-to-react-native-0.60/

However, you may then encounter this issue on Android app launch:

TimePickerAndroid tried to override com.facebook.react.modules.timepicker.TimePickerDialogModule.

which I had to solve rather crazily: https://github.com/facebook/react-native/issues/26672#issuecomment-569854865

Perhaps that should be a new issue here as well, but if autolinking isn’t a first-class workflow in ExpoKit projects yet, I’m not sure what that issue should look like either.

Needed to use this at top of podfile:

require_relative ‘…/node_modules/@react-native-community/cli-platform-ios/native_modules’

this in the target:

use_native_modules!

and this at bottom of target:

require_relative ‘…/node_modules/react-native-unimodules/cocoapods.rb’ use_unimodules!( modules_paths: [‘…/node_modules’], exclude: [ ‘expo-bluetooth’, ‘expo-in-app-purchases’, ‘expo-payments-stripe’, ], )

good riddance >:S

Hmmmmmm https://twitter.com/notbrent/status/1228444753982676992

Haven’t tested this or found the version where it landed, but it’s interesting at least.

I totally agree with @brettdh. Ejecting (to bare and ExpoKit) should generate a podfile template which is analog to react-native init. I wasted some hours until my ejected bare project eventually started working.

• Autolinking was missing in the podfile and no hint to this anywhere, pure googling
• Since it was missing, it broke react-native-screens, reanimated, gesture-handler, shared-element, vector icons
• Expo didn’t notify that there are some imports left against “expo” (notifications). It has capabilities to detect that there are modules left which has to be configured, directing to the unimodule article, so ideally it should also report that there is an expo import which will break hardly (It reported that EXPO SDK is missing and nothing more, another hour until I found out why).
• I had to create an empty swift file in my project, target membership against my project + activating swift bridge headers to fix 100 compile issues in xcode
• I had to implement stuff for lottie in 3 different files for android (ok, this might be out of scope, but since expo includes lottie, the eject has to be smoother imho)
• Expo camera maven url in build.gradle was missing (reported missing classes)
• google maven url was missing, caused issues with the integrated build class support lib 3.3.0

Considering these steps, the eject was very painful for me and since expo said “Expo never locks you in”, I had the feeling it did. Now I have to work my way trough firebase. These means tons of refactoring on the server side (laravel) + app (integrating firebase, grabbing tokens, storing them etc).

For me, this was not a good experience.

And there are still a bunch of APIs missing (Splashscreen, AppLoading and a few more).

I know my post got a bit out of scope, but I thought this is the right place instead of opening a new issue

Hmm. I do currently have a working ejected app using ExpoKit SDK 36, autolinking, and react-native-music-control (among other native libs), so maybe there’s something else going on.