Closed awcchungster closed 1 year ago
I believe the fix is applying this Podfile change
You can often fix these problems by disabling / re-enabling:
[x] Automatically manage signing
That's not a fix. This issue affected a lot of apps, including our main app.
I recommend upgrading your dev environment to Xcode 14, if you haven't already to replicate. I'm working on getting my machine to Xcode 13 to test this example.
I recommend upgrading your dev environment to Xcode 14
I've been running XCode 14 for weeks.
/example app works here but I haven't done a fresh install of the /example in months though and it's probably overdue for an upgrade on its react-native@66.1
.
Ok, I booted a fresh clone. I found I had to configure a [Team][v]
for a number of unusual items. After working through those, the demo boots and simulated-task successfully executes.
If there's an easy fix to bypass having to configure [Team][v]
for those, great.
Booting the app, I notice a Thread Performance Checker
stacktrace. This has nothing to do with background-fetch
and does not prevent the app from running. It's most likely related to RN and would go away by upgrading react-native
in the /example app.
Thread Performance Checker: Thread running at QOS_CLASS_USER_INTERACTIVE waiting on a lower QoS thread running at QOS_CLASS_DEFAULT. Investigate ways to avoid priority inversions
PID: 4585, TID: 932134
Backtrace
=================================================================
3 FetchDemo 0x0000000104fb3c44 -[_RCTSRRunLoopThread runLoop] + 44
4 FetchDemo 0x0000000104fb3974 __49+[NSRunLoop(RCTSRWebSocket) RCTSR_networkRunLoop]_block_invoke + 116
5 libdispatch.dylib 0x000000010765204c _dispatch_client_callout + 20
6 libdispatch.dylib 0x0000000107653bbc _dispatch_once_callout + 136
7 FetchDemo 0x0000000104fb38d8 +[NSRunLoop(RCTSRWebSocket) RCTSR_networkRunLoop] + 84
8 FetchDemo 0x0000000104fad930 -[RCTSRWebSocket _connect] + 68
9 FetchDemo 0x0000000104fac6d4 -[RCTSRWebSocket open] + 300
10 FetchDemo 0x0000000104f8f730 -[RCTReconnectingWebSocket start] + 148
11 FetchDemo 0x0000000104f7f294 -[RCTPackagerConnection init] + 404
12 FetchDemo 0x0000000104f7f0e0 __49+[RCTPackagerConnection sharedPackagerConnection]_block_invoke + 36
13 libdispatch.dylib 0x000000010765204c _dispatch_client_callout + 20
14 libdispatch.dylib 0x0000000107653bbc _dispatch_once_callout + 136
15 FetchDemo 0x0000000104f7f094 +[RCTPackagerConnection sharedPackagerConnection] + 84
16 FetchDemo 0x0000000105014134 -[RCTDevSettings initialize] + 148
17 FetchDemo 0x0000000104f68744 -[RCTModuleData _initializeModule] + 96
18 FetchDemo 0x0000000104f67364 -[RCTModuleData setUpInstanceAndBridge:] + 2040
19 FetchDemo 0x0000000104f69b5c -[RCTModuleData instance] + 1168
20 FetchDemo 0x0000000104f056fc -[RCTCxxBridge moduleForName:lazilyLoadIfNecessary:] + 680
21 FetchDemo 0x0000000104f72a24 -[RCTModuleRegistry moduleForName:lazilyLoadIfNecessary:] + 128
22 FetchDemo 0x0000000104f72998 -[RCTModuleRegistry moduleForName:] + 48
23 FetchDemo 0x00000001050278e8 -[RCTPerfMonitor devMenuItem] + 84
24 FetchDemo 0x00000001050277a4 -[RCTPerfMonitor setModuleRegistry:] + 124
25 Foundation 0x00000001afa8d0b4 AA92CD58-561A-3414-92F4-B4120298B39A + 430260
26 FetchDemo 0x0000000104f67b18 -[RCTModuleData setModuleRegistryForInstance] + 372
27 FetchDemo 0x0000000104f67304 -[RCTModuleData setUpInstanceAndBridge:] + 1944
28 FetchDemo 0x0000000104f69d8c __25-[RCTModuleData instance]_block_invoke + 44
29 FetchDemo 0x0000000104fd1538 RCTUnsafeExecuteOnMainQueueSync + 52
30 FetchDemo 0x0000000104f699fc -[RCTModuleData instance] + 816
31 FetchDemo 0x0000000104f09f68 __49-[RCTCxxBridge _prepareModulesWithDispatchGroup:]_block_invoke + 156
32 libdispatch.dylib 0x0000000107650598 _dispatch_call_block_and_release + 32
33 libdispatch.dylib 0x000000010765204c _dispatch_client_callout + 20
34 libdispatch.dylib 0x0000000107662904 _dispatch_main_queue_drain + 1456
35 libdispatch.dylib 0x0000000107662344 _dispatch_main_queue_callback_4CF + 44
36 CoreFoundation 0x00000001b5676a08 42C5C917-0447-3995-B50F-DE4D132C2435 + 633352
37 CoreFoundation 0x00000001b5658368 42C5C917-0447-3995-B50F-DE4D132C2435 + 508776
38 CoreFoundation 0x00000001b565d1e4 CFRunLoopRunSpecific + 612
39 GraphicsServices 0x00000001ee47d368 GSEventRunModal + 164
40 UIKitCore 0x00000001b7b0cd88 7B942FA4-CB76-3375-9972-F58C14492FB4 + 3812744
41 UIKitCore 0x00000001b7b0c9ec UIApplicationMain + 340
42 FetchDemo 0x0000000104a684fc main + 100
43 dyld 0x00000001d3981948 341BBF64-6034-357E-8AA6-E1E4B988E03C + 88392
For what it's worth, I've had to turn off code signing for resource bundles since Xcode 14 came out. The stanza everyone has settled on (where they haven't narrowed scope slightly to it's library-specific, for specific libraries) is:
https://github.com/CocoaPods/CocoaPods/issues/11402#issuecomment-1201464693
That one obliterates the need for signing on all resource bundles on all targets
react-native is using a patch that does the same but constrained to just their libraries, not sure if it's released yet or not since I'm doing full app style
I upgraded react-native
in /example
from 0.66.1 -> 0.70.2
.
No more code-signing issues from a fresh install.
(with code-signing hack)
post_install do |installer|
react_native_post_install(
installer,
# Set `mac_catalyst_enabled` to `true` in order to apply patches
# necessary for Mac Catalyst builds
:mac_catalyst_enabled => false
)
# Code signing hack.
installer.pods_project.targets.each do |target|
if target.respond_to?(:product_type) and target.product_type == "com.apple.product-type.bundle"
target.build_configurations.each do |config|
config.build_settings['CODE_SIGNING_ALLOWED'] = 'NO'
end
end
end
0.70.3 came out this morning (my time) with the react-native-specific hack cherry-picked for the release, FWIW. Kind of a mess, but thank goodness for ruby power in postinstall ;-)
but thank goodness for ruby power
Yea, I saw we have a Gemfile
now. I used to use ruby quite a bit, once-upon-a-time.
re: the ruby profile, Nice! For the Gemfile and .ruby-version I actually detest them, I delete them immediately. It's not really a ruby project, and I use rvm to manage my rubies and manage my cocoapods separately, I'm really bugged by react-native attempting to manage that ancillary toolchain for me. But I am a minority in that opinion :shrug:
Your Environment
Plugin version: 4.1.2 Platform: iOS OS version: 16.0.2 Device manufacturer / model: iPhone React Native version (react-native -v): "0.68.2" Plugin config
Xcode 14.0
Expected Behavior
The example starts an app on my iPhone
Actual Behavior
PhaseScriptExecution failed with nonzero exit code AND
Pods.xcodeproj error project: Signing for "React-Core-AccessibilityResources" requires a development team. Select a development team in the Signing & Capabilities editor.
Note: I already have a dev team selected.
Steps to Reproduce
Context
Debug logs