[ios] Remove legacy notifications module code (#24325)

Remove Amplitude from Expo Go (#22523)

[ios] Use stable manifest ID where applicable (#13280)

[ios] Migrate installation identifier to non-backed-up storage (#11019)

# Why

- iOS companion for https://github.com/expo/expo/pull/11005.
- https://github.com/expo/expo/pull/11019/commits/1e22e

[ios] Migrate installation identifier to non-backed-up storage (#11019)

# Why

- iOS companion for https://github.com/expo/expo/pull/11005.
- https://github.com/expo/expo/pull/11019/commits/1e22e08195b1b4c49650f8243eeb89b5f938b9a5 fixes https://github.com/expo/expo/issues/11008#issuecomment-726370187 ensuring future versioned `EXInstallationIdProvider`s use the common installation ID

# How

Implemented https://github.com/expo/expo/pull/10261#issuecomment-725396140.

- As in https://github.com/expo/expo/pull/11005, the migration code is present in ~3~2 places:
- ~in `ExpoKit` for managed apps relying on legacy notifications~
- in `expo-constants` for bare workflow apps and for managed workflow apps (`EXKernel` now uses `expo-constants` directly to fetch installation ID)
- in `expo-notifications` for bare workflow apps that for some reason do not get UUID migrated by `expo-constants` (eg. because they do not have `expo-constants` installed or have installed in older version).
- To expose common, migrated `deviceInstallUUID` to versioned `expo-constants` code I've added a simple kernel service plugged into already versioned `EXConstantsBinding`s.

# Test Plan

I have verified (previously) that:
- `Constants.installationId` from running Expo client on `master` is the same as `.installationId` returned when running Expo client on this branch
- `expo-notifications`'s installation ID from running Expo client on `master` is the same as `installationId` returned when running Expo client on this branch
- removing and reinstalling Expo client **does not** generate a different installationId (as we know keychain isn't removed!)
- if we fetch an invalid UUID from the Keychain, new UUID is generated
- I experienced an app freeze once on `__ulock_wait`, when waiting for return from `SecItemCopyMatching` which isn't a common issue and were only a few reports online of

# Test approach #2

Test scenarios for installation identifiers:
- **on an experience running on SDK39 when Expo client upgrades**
- SDK39 `EXConstantsService` used `NSUserDefaults.EXDeviceInstallUUIDKey` which is now cleared by migration. Patched `EXConstantsService` uses `EXDeviceInstallUUIDManager` kernel service which provides it with the "common" ID, migrated from the `NSUserDefaults.EXDeviceInstallUUIDKey`, so the value doesn't change. ✅
- SDK39 `EXInstallationIdProvider` used `NSUserDefaults.ABI39_0_0EXDeviceInstallUUIDKey` which is not cleared by any migration. **Identifier keeps being backed-up** but it doesn't change. ⚠️
- **when an experience using SDK39 upgrades to SDK40 in Expo client**
- SDK39 `EXConstantsService` used `NSUserDefaults.EXDeviceInstallUUIDKey` which got migrated to keychain. SDK40 `EXConstantsService` uses the same keychain entry as the migrator, so they're using the same value. ✅
- SDK39 `EXInstallationIdProvider` used `NSUserDefaults.ABI39_0_0EXDeviceInstallUUIDKey` while SDK40 uses common device UUID the sources are obviously different. Token changes. ❌ This is a bug introduced with `expo-notifications` Expo client integration, we can't do anything about it apart from fixing it in SDK40, IDs for old SDKs are already created and will be used in corresponding SDKs and if we didn't do anything about it in SDK40, the ID per experience would change nonetheless, so let's change it this time for the last time.
- when standalone app using SDK39 upgrades to SDK40
- Unversioned SDK39 `EXConstantsService` used `NSUserDefaults.EXDeviceInstallUUIDKey` which gets migrated to keychain, unversioned SDK40 `EXConstantsService` uses the same keychain entry as common UUID, no changes. ✅
- Unversioned SDK39 `EXInstallationIdProvider` used `NSUserDefaults.EXDeviceInstallUUIDKey` which gets migrated to keychain, unversioned SDK40 `EXInstallationIdProvider` uses the same keychain entry as common UUID, no changes. ✅
- when an SDK39 project ejects to bare
- SDK39 `EXConstantsService` used `NSUserDefaults.EXDeviceInstallUUIDKey`, the same which is used in bare, ✅
- SDK39 `EXInstallationIdProvider` used `NSUserDefaults.EXDeviceInstallUUIDKey` in standalone apps, but `NSUserDefaults.ABI39_0_0EXDeviceInstallUUIDKey` in Expo client. Token changes on developers' devices. ⚠️
- when an SDK40 project ejects to bare
- SDK40 `EXConstantsService` used `EXDeviceInstallUUIDKey` keychain entry, the same which is used in bare, ✅
- SDK40 `EXInstallationIdProvider` used `EXDeviceInstallUUIDKey` keychain entry, the same which is used in bare (`EXDeviceInstallUUIDKey`), ✅
- when a bare project upgrades `expo-notifications` or `expo-constants`
- both projects have migrators that move `EXDeviceInstallUUIDKey` value from `NSUserDefaults` to keychain, token doesn't change. ✅

show more ...

[ios][et] Remove Fabric and Crashlytics on iOS (#8160)

# Why

Part of #8047 - not closing yet because I'm gonna make separate PR for Android.

# How

I removed:
- Fabric and Crashlytics from

[ios][et] Remove Fabric and Crashlytics on iOS (#8160)

# Why

Part of #8047 - not closing yet because I'm gonna make separate PR for Android.

# How

I removed:
- Fabric and Crashlytics from `Podfile` and run `pod install`.
- code calling Fabric & Crashlytics libraries.
- `et ios-run-fabric` command and its `run-fabric.sh` build phase in general.
- modifying `Info.plist` while generating dynamic macros, it was used only to apply fabric's api key.
- `et ios-cleanup-dynamic-macros` command - no longer needed if we don't modify `Info.plist`.
- Fabric's key from `Info.plist`.

## Side notes

Previously, once Crashlytics detects a crash, we set a flag in user defaults and then if that flag is set we invalidated cached kernel's bundle. After these changes, kernel's bundle won't be invalidated. I chatted with James and he agrees that we actually don't need this anymore.

# Test Plan

Xcode project builds and works as expected.

show more ...

[ios] Fix dev menu classes being used in detached mode

[ios][home] Add three finger gesture to open the dev menu + some refactoring (#7891)

# Why

Fixes #7644 and brings us closer to the separate `expo-dev-menu` package that can live without kernel.

[ios][home] Add three finger gesture to open the dev menu + some refactoring (#7891)

# Why

Fixes #7644 and brings us closer to the separate `expo-dev-menu` package that can live without kernel.
Also fixed https://twitter.com/bantingGamer/status/1251154340129062917

# How

- Added `EXDevMenuManager` singleton that manages the dev menu. Most parts of it were in kernel or some others classes strongly connected with kernel. Now, kernel is just its delegate.
- Refactored `EXKernelDevMotionHandler` to `EXDevMenuMotionInterceptor` which is much clearer and makes it possible to uninstall the interceptor (these interceptors are kinda hacky, I tried not to do them this way but well, RN does the same ��).
- Added `EXDevMenuGestureRecognizer` for long press gesture, with minimum press duration set to 0.5s and with light impact haptic feedback.
- Added `EXDevMenuGestureInterceptor` that swaps the default implementation of `UIView#gestureRecognizers`, but only for `UIWindow`s. This is needed to make three-finger gesture work everywhere in the app.
- Renamed `EXMenuViewController` to `EXDevMenuViewController` (all dev menu classes should be prefixed by `EXDevMenu`) and again, removed some connections to kernel.
- Added UI in user settings to select dev menu gestures (can select them separately).
- Fixed an issue with dev menu view being below modals in the view hierarchy.

# Test Plan

So far I've tested it only with published experience. I'm gonna do smoke tests on dev apps later.
I mostly focused on testing whether:
- the dev menu works in general (after refactoring)
- three-finger gesture works on the initial screen of the app, on the modals and on the dev menu itself
- all combinations of selected gestures work as expected
- selected gestures persist after killing and relaunching the client

show more ...

[ios][android] Make redbox and rr (android) and cmd+r (ios) reload manifest and JS rather than just JS (#6134)

* [ios] Make cmd+r reload manifest and JS rather than just JS

* [ios] Reload from de

[ios][android] Make redbox and rr (android) and cmd+r (ios) reload manifest and JS rather than just JS (#6134)

* [ios] Make cmd+r reload manifest and JS rather than just JS

* [ios] Reload from dev menu grabs manifest too

* [ios] Clean up reload code and ensure redbox injection code works outside of developer mode

* [android] Reload on dev menu also reloads from manifest

* [ios] Fix typo

* [android] Reload from manifest from redbox and with rr shortcut

* [android] Address feedback

* [react-native-lab] Copy changes to ReactAndroid over

* [android] Clean up extra newlines

* [react-native-lab] Update on sdk-36 branch

show more ...

[ios][home] remove deprecated client-side authentication checks for opening projects

[ios] Upgrade notifications framework to User Notifications Framework (#2316)

* Updated notifications

Moved new permissions files to packages

fix

updated yarn.lock

fixes

Requested cha

[ios] Upgrade notifications framework to User Notifications Framework (#2316)

* Updated notifications

Moved new permissions files to packages

fix

updated yarn.lock

fixes

Requested changes

fix after rabase

Made requested changes

Renamed UserNotificationCenterProxy classes

Run `pod install`

* Post-review fixes

* Minor JS fixes

* Do not remember pending notifications in Expo Client (behavior matching previous one)

* Prevent blocking main queue at all times by EXUserNotificationRequester

* Do not scope categories identifiers in ejected applications

* Apply review comments

* Remove obsolete if condition

* Do not store resolver and rejecter in EXUserNotificationRequester

* Update Pods

* Add support for deleting custom notification categories

* Pass notification to a remembered experience when tapped a notification in backgrounded Expo Client

* Update jest-expo mocks

* Ensure permissions consuming happens on permissions queue in EXRemoteNotificationRequester

* Do not scope notification identifiers

* Change cancelScheduledNotification into cancelScheduledNotificationAsync returning native Promise

* Deny scheduleNotificationAsync with both time and repeat set on iOS

* Allow scheduleNotificationAsync with both time and repeat set on iOS using deprecated UILocalNotification

* Add more notification testing buttons to NCL

* Export EXUserNotificationManager service as kernel service

* Add EXNotificationsIdentifiersManager protocol capable of scoping and unscoping identifiers

* Require both RemoteNotificationManager and UserNotificationManager in EXNotifications module

* Scope and unscope action identifiers by EXUserNotificationManager

* Update pods

show more ...

Fix passing initial notif props to standalone/ExpoKit

See: https://github.com/expo/expo/issues/1691

fbshipit-source-id: 5df7144

add `Updates.reloadFromCache` (#2315)

* [android][sdk][docs] added Updates.reloadFromCache() on android

* [ios] some slight renaming and refactoring in AppLoader to make manifest usage somewhat cle

add `Updates.reloadFromCache` (#2315)

* [android][sdk][docs] added Updates.reloadFromCache() on android

* [ios] some slight renaming and refactoring in AppLoader to make manifest usage somewhat clearer

* [ios] add Updates.reloadFromCache to ios

fbshipit-source-id: 0a0321e

show more ...

Show clearer information on Expo Client error screen for trying to load an app belonging to a different account

see: https://github.com/expo/universe/issues/2251

fbshipit-source-id: 8e79e5b

Use the new push/getExpoPushToken endpoint with new www client

This is a rewrite of how device tokens are registered and sent to our server. There are several changes:
- It uses the new `push/getExp

Use the new push/getExpoPushToken endpoint with new www client

This is a rewrite of how device tokens are registered and sent to our server. There are several changes:
- It uses the new `push/getExpoPushToken` endpoint that both saves the APNs device token and returns an Expo push token.
- *Breaking change:* Notifications.getExpoPushToken will throw if the app doesn't have permission to show notifications, instead of returning an Expo push token (that would later fail when trying to send to it).
- It saves the token in NSUserDefaults only when it has successfully been registered, allowing us to skip re-registering with our server if the token hasn't changed across app starts.
- More detailed error info, should we need it
- Looked over the thread-safety of EXRemoteNotificationManager -- all ivar access happens on the same queue now (which is the main queue, for now, until we leave the deprecated UIApplication API for UserNotifications instead).

Fixes #764

fbshipit-source-id: cb15b20

show more ...

Restore analytics behavior

fbshipit-source-id: 51ce815

Restore ErrorRecovery and clean up visible/invisible app interface

fbshipit-source-id: 917ce6f

Restore Util.reload in standalone and ExpoKit

fbshipit-source-id: d2bd70c

restore ExpoKit project wiring

fbshipit-source-id: 14b07c5

Support JS nux, clean up JS loaded notifs

fbshipit-source-id: b3721f2

support QR code reader from menu

fbshipit-source-id: ebf9f40

clean up loading cases

fbshipit-source-id: fef4e8f

restores full menu functionality except QR button

fbshipit-source-id: 8370f90

support routing notifications

fbshipit-source-id: 49aa8ea

restore linking, util.reload, initial uri, and initial props behavior

fbshipit-source-id: 0c15c1b

add loading view, loading progress, restore splash, consolidate view controllers

fbshipit-source-id: 2e0cfb3