Hi @keltouma
I see that the react-native-push-notification repository says the following:
State of the repository
This repository is not actively maintained. The main reason is time. The second one is probably the complexity of notifications on both iOS and Android. Since this project probably need a huge refactor to fix some issue or to implement new features. I think you should probably consider these alternatives: Notifee free since september or react-native-notifications.
If you insist on using react-native-push-notification 
it’s not 100% clear to me what exactly you need to do. At least some of the instructions for @react-native-community/push-notification-ios (which react-native-push-notification depends on) seem to imply that they are needed for “background mode”, so maybe if you don’t need that then you won’t need to do that part of the installation instructions? But I suppose it would be safest to do it all. In order to do this in the managed workflow you will need to write a config plugin to make all those changes during the build process.
You would also need to write a config plugin for Android support.
react-native-notifications would also require you to write config plugins.
On the other hand, notifee apparently has written a config plugin. They mention it in their installation docs:
Their docs are a bit misleading, though. They say “Finally, ensure you run expo prebuild […]”.
I don’t blame them, though, because the Expo docs sort of used to imply that you should run expo prebuild or expo run:*.
expo prebuild (or expo run which runs expo prebuild in the background) will generate the native projects in the ios and android directories. This effectively switches you to the Bare workflow. You can manually revert to the Managed workflow. But there’s generally no need to use expo prebuild if you just want to work similarly to how you’re used to with Expo Go.
If you install a dependency like notifee or react-native-push-notification, it needs native code that is not included in the Expo SDK or in the Expo Go app. So if you try to call the code in Expo Go (or in an app built with the classic expo build build service) then it will give you errors similar to “null is not an object (evaluating …)” because the native code that it needs does not exist in the app.
But what you can do instead is build a custom dev client. This is basically like a custom version of Expo Go that includes all of your dependencies, including any native code that they depend on. You can then run that instead of Expo Go. Similarly, when building the production app you will build with eas build instead of with expo build.