Summary:
While it would be better to be able to do all of the ownership metadata at the Buck macro level, that proved to be more work than expected.
This diff adds the corresponding pfh label to all targets in `xplat/js/react-native-github` that have a Supermodule label. Once the migration is complete the Supermodules labels will be able to be removed.
Reviewed By: cortinico
Differential Revision: D35221544
fbshipit-source-id: d87d5e266dfb5e6ee087251dc34dff5db299bbaf
Summary:
Changelog: [iOS][Internal] Refactor: Migrate Logbox surface initialization to Fabric when available, in Bridge and Bridgeless modes
# Why
This diff main purpose is to add `RCTErrorNewArchitectureValidation(RCTNotAllowedInAppWideFabric)` in `RCTSurface`, to ensure Paper surfaces are never created in FBiOS.
# The Situation
Before this diff, in Bridged Fabric, `[RCTLogbox show]` initializes a Paper `RCTSurface`, [using `[RCTLogBoxView initWithWindow]`](https://github.com/facebook/react-native/blob/main/React/CoreModules/RCTLogBoxView.mm#L46))
In this diff, in Bridged and Bridgeless Fabric, `[RCTLogbox show]` initializes a Fabric `RCTFabricSurface`.
Before this diff, in Bridgeless Fabric, RCTLogBox posts a "CreateLogBoxSurface" notification to RCTInstance.
In this diff, the notification hack is replaced by the same `RCTFabricSurface` initialization above.
Behavior is the same.
Reviewed By: RSNara
Differential Revision: D35177311
fbshipit-source-id: 6de418af8a01f914c9a806bb8d74915015f9087a
Summary:
In short, if an RCTEventDispatcher observer sends an event on the same thread that the observer was initially on, there will be a deadlock due to `sendEvent` already having the lock active on the `_observers` NSHashTable. An example where this occurred was when we had react-native-gesture-handler trigger an animated event, which then triggered an event on the underlying component being animated as a result of it being an observer on the animation event. Since this all occurred on the main thread, we ended up with a deadlock and the app froze.
To prevent this scenario, I used a `NSRecursiveLock` for _observersLock to be able to dispatch events on the same thread from observers.
joebernard
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fix] - Prevent deadlock when dispatching events from observers on the same thread.
Pull Request resolved: https://github.com/facebook/react-native/pull/33490
Test Plan:
Not sure if there are any tests present for sending events with RCTEventDispatcher already in place, but In regular app usage this solution has proved to be a viable and stable option so far and has prevented the deadlock from occurring.
This would still be thread-safe since we are now allowing the event to be sent through observers on the same thread the initial event was dispatched on. The only issue I could see here is the behavior of sending an event could be changed.
Reviewed By: RSNara
Differential Revision: D35118752
Pulled By: charlesbdudley
fbshipit-source-id: 7e93a8d49841e001b235a437ccca1e072dcc7ab1
Summary:
If an RN app is embedded in a Mac Catalyst app that uses the UIWindowScene API to manage multiple windows, LogBox would fail to render because it didn't know which UIWindowScene to render to. This diff fixes that situation by ensuring that the LogBox window gets rendered in the key window's scene.
Changelog:
[iOS][Fixed] - Update iOS LogBox to render its UIWindow with the key window's UIWindowScene
Reviewed By: appden
Differential Revision: D35027831
fbshipit-source-id: e0df5865f95323b03d08d6b1fb3ec912aa9a9167
Summary:
Changelog: [Internal]
this doesn't really make any sense, first of all CGFloat is a primitive data type so comparing it against nil only will return true if it's 0. but that won't catch cases where CGFloat is uninitialized bc it will be holding junk in memory.
the error checking of the value is already handled in the accessibility manager, so just remove it here.
Reviewed By: p-sun
Differential Revision: D34909365
fbshipit-source-id: 483f9c100433f8533edd784622523c5469c616c2
Summary:
Changelog: [Internal]
for the last 6 months or so, we've been getting this task where the moduleRegistry in RCTDeviceInfo is nil. in this change, i add some logs to see what might be setting this to nil.
in all honestly, i don't really think this is happening, but it would be good to verify.
Reviewed By: sshic
Differential Revision: D34908902
fbshipit-source-id: d375285467a87453605ba0fecfc124bc3bff6e63
Summary:
This PR adds a `dismissActionSheet` method to `ActionSheetIOS` in order to allow dismissing an ActionSheet programmatically. This is especially useful in apps where a user has the ability to open an ActionSheet and then open a push notification that will redirect them to another screen which usually leads to scenarios where the presented ActionSheet has no relation with the current screen.
#### TODO
- [ ] Submit react-native-website PR updating ActionSheetIOS documentation.
## Changelog
[iOS] [Added] - Add dismissActionSheet method to ActionSheetIOS
Pull Request resolved: https://github.com/facebook/react-native/pull/33189
Test Plan:
1. Open the RNTester app and navigate to the ActionSheetIOS page
2. Test `dismissActionSheet` through the `Show Action Sheet and automatically dismiss it` example
https://user-images.githubusercontent.com/11707729/155867546-c6770a49-9b09-45e3-a6b1-4f7645d67dbf.mov
Reviewed By: lunaleaps
Differential Revision: D34518952
Pulled By: cortinico
fbshipit-source-id: 912a9b83ee078f791b42efddf5abb7e1cd09d520
Summary:
alternative solution for https://github.com/facebook/react-native/issues/33379
> when `use_frameworks!` is on, there are errors like:
> ```
> 'FBReactNativeSpec/FBReactNativeSpec.h' file not found
> #import <FBReactNativeSpec/FBReactNativeSpec.h>
> ```
> this error may come from from https://github.com/facebook/react-native/commit/f7e4c07c84b6 regression.
>
> when `use_frameworks!` is on, xcode will search headers from framework directories, the correct imports would be `#import <React_Codegen/FBReactNativeSpec/FBReactNativeSpec.h>` (xcode will transform dash to underscore, so it is `React_Codegen` but not `React-Codegen`). in the other hand, when `use_frameworks!` is off, the correct import is `#import <React-Codegen/FBReactNativeSpec/FBReactNativeSpec.h>`.
>
>
> this fix is specific for old architecture (fabric is off).
>
> when fabric is on, there are other errors from duplicated headers when copying to build folder. [the reason is that framework build would try to flatten headers](https://mkonrad.net/2015/03/29/xcode-static-libraries-preserving-header-directory-structure.html). we have `primitives.h` in different folders and they would be flattened into `React_Fabric.framework/Headers`. to be honest, i don't know how to deal with the problem in the meantime, maybe subspecs are not enough, we should separate them from subspecs to dedicated podspecs so that we can have these targets as different frameworks.
in this alternative fix, i try to add `React-Codegen/React_Codegen.framework/Headers` into header search paths and make original `#import <FBReactNativeSpec/FBReactNativeSpec.h>` reachable.
[this change](https://github.com/facebook/react-native/commit/7a0398c331f22abc619a64b444ec7153357b0a30) in the pr is just a workaround to solve breaking in latest main branch and this is not important to the `use_frameworks!` fix at all. this breaking was coming from https://github.com/facebook/react-native/commit/180495159517dc0bfa103621e5ff62fc04cb3c8b.
## Changelog
[iOS] [Fixed] - Fix iOS build error when Podfile `use_frameworks!` is on and Fabric is off
Pull Request resolved: https://github.com/facebook/react-native/pull/33409
Test Plan:
verify with rn-tester
1. change `fabric_enabled` to false in `packages/rn-tester/Podfile`
2. `USE_FRAMEWORKS=1 pod install`
3. build rn-tester in xcode
Reviewed By: dmitryrykun
Differential Revision: D34817041
Pulled By: cortinico
fbshipit-source-id: 4d1a610e99a807793eb3f64461e0d735c0a9ca9c
Summary:
Hoop up EarlyJsErrorHandler so we could pass js error data to object-c to report.
Changelog:
[iOS][Chagned] - Add function to report early js errors
Reviewed By: RSNara
Differential Revision: D34096343
fbshipit-source-id: fdbc6ea5d1f3cc6ab55fcd22b48bbe8fb1f1ca8f
Summary:
In iOS, the native LogBox that gets rendered for JS errors/warnings is statically sized once and bases that size off of the entire screen's size. This causes issues when being run in a Mac Catalyst app since 1) the sizing is not static since we can resize the window and 2) the size of the LogBox's root should fill the *window* and not the screen. This diff fixes both of these issues.
Changelog:
[iOS][Fixed] - Ensure LogBoxView is sized relative to the key window instead of the full screen
Reviewed By: appden
Differential Revision: D34697076
fbshipit-source-id: 9665fd51bc86ed29837672cec882bac97904b0c8
Summary:
iOS will sometimes invoke the UIAlertAction handler for the cancel button more than once on iPad. This can be reproduced relatively easily by having a button that opens an action sheet and spam tapping outside the action sheet while it is opening. Since native module callbacks can only be invoked once this causes the app to crash here https://github.com/facebook/react-native/blob/main/ReactCommon/react/nativemodule/core/platform/ios/RCTTurboModule.mm#L206.
## Changelog
[iOS] [Fixed] - Fix action sheet callback invoked more than once on iPad
Pull Request resolved: https://github.com/facebook/react-native/pull/33099
Test Plan: Tested on iPad simulator to reproduce the crash and verified that this fixes it.
Reviewed By: philIip
Differential Revision: D34215327
Pulled By: ShikaSD
fbshipit-source-id: 6f406e4df737a57e6dd702dd54260aa72eab31d6
Summary:
Fix for iOS displaying a RedBox for LogBox handled errors, this has been happening since RN 0.65 (in 64.2 and earlier, if it was handled by LogBox then it wouldn't trigger RedBox)
Fixes https://github.com/facebook/react-native/issues/32106
## Changelog
[iOS] [Fixed] - Stop RedBox from appearing for LogBox handled errors
Pull Request resolved: https://github.com/facebook/react-native/pull/32641
Test Plan: Manually tested. Seems to fix things (and RedBox still displays for things like 'Could not connect to development server') but I would appreciate RSNara or someone else who is more familiar with the code to confirm that the original switch was a mistake and not something deliberately changed.
Reviewed By: christophpurrer
Differential Revision: D33661481
Pulled By: cortinico
fbshipit-source-id: c9c262adb3f977ae3f13beb9575d3eaa2445f663
Summary:
Resolves this issue: https://github.com/facebook/react-native/issues/32304.
**NOTE:** This PR is based on a prior PR for this fix: https://github.com/facebook/react-native/pull/32305, I've co-authorized its creator for this change (paddlefish).
Without this change, calling to hide an alert, leaves a `UIWindow` that blocks user interactions with the screen.
The correct way to remove a `UIWindow` in iOS is to set its hidden property to `YES`. Also, it is required to remove all references to the window (the associated `windowScene` for example) and ARC will automatically free this `UIWindow`.
The line after this change, set the `_alertWindow` reference to `nil`, but the window is already associated with a scene (see the screenshots from [this PR](https://github.com/facebook/react-native/pull/32305#discussion_r720521707)). So we also need to remove the `windowScene` from that window, as recommended by Apple: https://developer.apple.com/documentation/uikit/uiwindowscene/3198091-windows.
>To remove the window from the current scene, or move it to a different scene, change the value of the window's windowScene property.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - remove alert's window when call to `hide`.
Pull Request resolved: https://github.com/facebook/react-native/pull/32833
Test Plan: See https://github.com/facebook/react-native/pull/32305
Reviewed By: hramos
Differential Revision: D33460430
Pulled By: lunaleaps
fbshipit-source-id: b13c2c7ee6404f1e1c787265bc4af8a31005bcf1
Summary: Insert casts for implicit int -> CGFloat conversions. This warning category is generally benign and explicitly casting will preserve existing behavior.
Reviewed By: NSProgrammer
Differential Revision: D33303887
fbshipit-source-id: b21adbcf754e707adfe3f8eaa0fe9c3a65380cc5
Summary:
`_labelsForTags` is an array with string labels used only for local profiling, that we had to manually keep it in sync with `RCTPLTag`. Refactor so labels are assigned with switch instead.
Changelog: [iOS] Refactor: Assign string label to each case in RCTPLTag enum for startup performance logging
Reviewed By: fkgozali
Differential Revision: D32889043
fbshipit-source-id: 81da592a160a31b91e78289be0990cc2ff960f29
Summary:
The current implementation of the prelive composer is setting the RN override preference to nil when live shopping ends. However, if the user had a previously set appearance override, this would clear it out.
To resolve this, I cache the user's override preference before we override it, and restore it when live shopping ends.
Additionally, I'm adding a missing callback to restore the override pref when live shopping is dismissed, but not cancelled.
Changelog:
[ReactiveNative][Appearance] - Add function to retrieve overridden RN appearance
Differential Revision: D32564739
fbshipit-source-id: d0b4e06d2bbadad68f172d951609cba3e4587e5d
Summary:
The current implementation of `AccessibilityInfo.announceForAccessibility` will immediately interrupt any existing in progress speech with the announcement. Sometimes this is desirable behaviour, but often you will want to wait until existing speech is finished before reading the new announcement. This change gives us that option.
My personal use case for this feature is a custom text input. When typing on iOS with voiceover enabled, each character is read out after being selected. I wanted to add some additional information after each character to help with the context of what has changed in the input, but I didn't want to override the reading of the character itself.
This feature is supported natively on iOS by constructing an `NSAttributedString` with the property [`accessibilitySpeechQueueAnnouncement`](https://developer.apple.com/documentation/foundation/nsattributedstring/key/2865770-accessibilityspeechqueueannounce), so this change just adds an extra parameter to `AccessibilityInfo.announceForAccessibility` which controls the value of that property on the native side. Adding this as an extra optional parameter with false as the default ensures that existing uses of the function won't be affected.
Unfortunately, this feature doesn't appear to be supported on Android, so the new second property will be iOS only.
## Changelog
[iOS] [Added] - add new argument to announceForAccessibility to allow queueing on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/32637
Test Plan:
I've updated the `announceForAccessibility` section in RNTester with multiple buttons to demonstrate the difference between `queue: false` (default) and `queue: true` and show they work as intended.
Here's the expectation for each button:
- "Announce for Accessibility Immediately": on press, should start reading the button label, then be interrupted by the announcement
- "Announce for Accessibility Queued": on press, should read the button label then read the announcement afterwards
- "Announce for Accessibility Queue Multiple": on press, should read the button label, then read three announcements sequentially, no interruptions
You can see the realisation of those expectations in the following video recorded on an iPhone 12 running iOS 15.0.2:
https://user-images.githubusercontent.com/14826539/142770536-d57bfd69-eba5-444d-9c89-4bf4851ea062.mov
I've also tested the same way on an iPhone 8 running iOS 13.4 and it works exactly the same.
Reviewed By: yungsters
Differential Revision: D32637989
Pulled By: philIip
fbshipit-source-id: 3e90add523f11eb0eb34ea623211249263f257e2
Summary:
In this diff, it moves the codegen output location out of node_modules and to build/generated/ios folder.
A temp pod spec will be created so that those files will be included in the Xcode project.
Changelog: [Internal]
Reviewed By: hramos, cortinico
Differential Revision: D31809012
fbshipit-source-id: ba1c884c8024306ba0fd2102837b7dbebc6e18ac
Summary:
Fixes https://github.com/facebook/react-native/issues/32434: RCTLogBox window is orphaned, covering entire screen.
After this change, the logbox window once again is removed from the screen.
## Changelog
Some third-party SDKs may hold references to created UIWindow, UIViewController, or UIView objects. Doing so means that the current code's `hide` method that releases the reference to the UIWindow in LogBox will not cause the window to be dealloc'd, and thus instead it will remain on the screen. This change explicitly hides the LogBox window when the reference is released, so that even if some other SDK holds onto the window it will still be taken off the screen.
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - 32434
Pull Request resolved: https://github.com/facebook/react-native/pull/32435
Test Plan:
1. Use console.warn to generate a yellow warning message in log box. Also install a third-party SDK that holds onto a reference to UIWindow -- for example the Facebook SDK, the Data Dog SDK, or any number of other SDKs that use `swizzling` to intercept calls like `viewDidAppear:`.
2. click the log
3. tap "dismiss"
4. try to tap anywhere
5. Use Xcode view debugger to inspect the UI state
## Expected
The app still responds to the touch.
In Xcode, there is not an extra UIWindow covering the screen
Reviewed By: philIip
Differential Revision: D31794242
Pulled By: sshic
fbshipit-source-id: 28aa247b3ed3fd60b8e7c2ed7d0606cbf5c42408
Summary:
i saw this a lot in the codebase, it's not optimal bc we're using two selectors when we only need one.
fastmod --extensions m,mm '\[\[(.*) alloc] init]' '[${1} new]' --dir xplat/js/react-native-github/*
i manually updated the callsites that this codemod couldn't handle (e.g., where there were more than one of these instances in a single line)
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D31776561
fbshipit-source-id: 1b16da240e8a79b54da67383d548921b82b05a9f
Summary:
## Context
Right now we are using both LogBox and ExceptionsManager native module to report JS errors in ExceptionsManager.js, from below code we can tell they have some overlapping - when ```__DEV__ === true``` both could report the error.
https://www.internalfb.com/code/fbsource/[5fb44bc926de87e62e6e538082496f22017698eb]/xplat/js/react-native-github/Libraries/Core/ExceptionsManager.js?lines=109-141
## Changes
In this diff overlapping is removed: in ```ExceptionsManager.js``` LogBox will be responsible for showing the error with dialog when ```__DEV__ === true```, when it's prod we'll use ExceptionsManager native module to report the error. As a result LogBox and ExceptionsManager native module don't share responsibilities any more.
Changelog:
[General][Changed] - Remove shared responsibility between LogBox and ExceptionsManager native module
Reviewed By: philIip
Differential Revision: D30942433
fbshipit-source-id: 8fceaaa431e5a460c0ccd151fe9831dcccbcf237
Summary:
This PR fixes a few issues with the Appearance API (as noted here https://github.com/facebook/react-native/issues/28823).
1. For the Appearance API to work correctly on Android you need to call `AppearanceModule.onConfigurationChanged` when the current Activity goes through a configuration change. This was being called in the RNTester app but not in `ReactActivity` so it meant the Appearance API wouldn't work for Android in newly generated RN projects (or ones upgraded to the latest version of RN).
2. The Appearance API wasn't working correctly for brownfield scenarios on Android. It's possible to force an app light or dark natively on Android by calling `AppCompatDelegate.setDefaultNightMode()`. The Appearance API wasn't picking up changes from this function because it was using the Application context instead of the current Activity context.
3. The Appearance API wasn't working correctly for brownfield scenarios on iOS. Just like on Android its possible to force an app light or dark natively by setting `window.overrideUserInterfaceStyle`. The Appearance API didn't work with this override because we were overwriting `_currentColorScheme` back to default as soon as we set it.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
### Fixed
https://github.com/facebook/react-native/issues/28823
* [Android] [Fixed] - Appearance API now works on Android
* [Android] [Fixed] - Appearance API now works correctly when calling `AppCompatDelegate.setDefaultNightMode()`
* [iOS] [Fixed] - Appearance API now works correctly when setting `window.overrideUserInterfaceStyle`
Pull Request resolved: https://github.com/facebook/react-native/pull/29106
Test Plan: Ran RNTester on iOS and Android and verified the Appearance examples still worked [correctly.](url)
Reviewed By: hramos
Differential Revision: D31284331
Pulled By: sota000
fbshipit-source-id: 45bbe33983e506eb177d596d33ddf15f846708fd
Summary:
Changelog: [Internal]
https://fb.workplace.com/groups/rn.support/posts/6677051292343429
ax team is building a tool to extract information about the views for design reviewers, and RN has some AX information that is not working atm because of dependency on whether voiceover is on or not. so, this will give them the ability to programmatically set that field and hopefully be able to get accurate ax info
Reviewed By: ikenwoo
Differential Revision: D31010566
fbshipit-source-id: 4c8a33fce40266b270dd5994442c8472ca88f5dd
Summary:
This pull request aims to remove iOS 11 version check which is no longer needed.
The minimum iOS deployment target for React Native is `iOS 11` but we still have iOS 11 version check like below.
```
#if __IPHONE_OS_VERSION_MAX_ALLOWED >= 110000 /* __IPHONE_11_0 */
if (available(iOS 11.0, *)) {
```
> React Native apps may target iOS 11.0 and Android 5.0 (API 21) or newer.
ref: https://github.com/facebook/react-native#-requirements
------
If there is a team motivation to remove the deprecated methods and classes before iOS 10, I can continue the work in this pull request or in the continuing pull requests.
We have deprecated warnings for these in the project.
- `UIUserNotificationSettings`
- `UILocalNotification`
- `topLayoutGuide` and `bottomLayoutGuide`
- `automaticallyAdjustsScrollViewInsets`
## Changelog
[iOS] [Changed] - Remove iOS 11 version check
Pull Request resolved: https://github.com/facebook/react-native/pull/32151
Reviewed By: sammy-SC
Differential Revision: D30877917
Pulled By: yungsters
fbshipit-source-id: d903ea5d557beeb65ef87bfce572e4db3532b3c5
Summary:
Folly now depends on libc++abi. This solves linker error for RCT-Folly.podspec like this:
```
Undefined symbols for architecture arm64:
"___cxa_increment_exception_refcount", referenced from:
folly::exception_ptr_get_type(std::exception_ptr const&) in libRCT-Folly.a(Exception.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
See https://github.com/react-native-community/releases/issues/251
Note: RNTester was not affected by this bug for some reason, so the only way to verify is via the new app generated via `npx react-native init`.
Changelog: [Fixed][iOS] Unbreak Folly linker error
Reviewed By: lunaleaps
Differential Revision: D30950944
fbshipit-source-id: 3eb146e23faa308a02363761d08849d6801e21ca
Summary:
Changelog:
* Rename `ENABLE_PACKAGER_CONNECTION` macro to a more appropriate name `RCT_DEV_SETTINGS_ENABLE_PACKAGER_CONNECTION` to reflect this is only used in RCT_DEV_SETTINGS
* Introduce `RCT_PACKAGER_LOADING_FUNCTIONALITY` that can be separate from `RCT_DEV_MENU`, by default, it equals to `RCT_DEV_MENU`
Reviewed By: fkgozali
Differential Revision: D30546025
fbshipit-source-id: f409c02dc1486041d7db5abdbf7eb482520fa171
Summary:
RCTBaseViewController uses RCTRootView.bridge to call RCTViewEventEmitter.emit.
## Changes
- RCTEventDispatcher now exposes a method to dispatch RCTViewEventEmitter events.
- RCTRootView (for paper), and RCTSurfaceHostingProxyRootView (for fabric and bridgeless mode) now exports the RCTEventDispatcher by grabbing it from the bridge
- RCTBaseViewController now uses the event dispatcher exported from RCTRootView to dispatch the RCTViewEventEmitter event.
## Benefits
- RCTBaseViewController no longer uses the bridge to dispatch RCTViewEventEmitter events
- In the future, we'll make RCTSurfaceHostingProxyRootView work with bridgeless mode, which'll allow us to remove the bridge/bridgeless fork in RCTBaseViewController.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D30434884
fbshipit-source-id: d961a56ac2abc08a661f8fe7c37926f219b731d0
Summary: Bridge can get invalidated during tear down. If a JS error is thrown then, don't display a LogBox so we don't hit the invalid bridge assert in RCTSurface.
Reviewed By: fkgozali
Differential Revision: D30464848
fbshipit-source-id: 87a8daa95fd06342d194a4805ecfa97279820f2e
Summary:
Merges the Facebook-internal Buck target definitions in `Libraries/` into the BUCK file at the root of the repo (which is currently not synced to GitHub at all). This does not affect how React Native is built in open source.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D27967499
fbshipit-source-id: 39c51a544b3868242598072d24cb6cfb5a6e2d8c
Summary:
I'm going to be flipping the default from autoglob on `fb_apple_library` to `True`. This prepares the target so that there are no behavior changes.
## Changelog: [Internal]
Reviewed By: natestedman
Differential Revision: D29769275
fbshipit-source-id: 7ac04f8a8f7e41ce8d43a81b25ebd063b3a9f3de