We've had a couple users tell us that Game Center real-time matchmaking doesn't work anymore after updating to iOS 13.4 (just released a few days ago). One user says turn-based matches still work, and only real-time matches are broken. I don't know if this is related to the issues you're seeing or not.

Yes, this is still happening to the users who reported the problem to us. One user even reverted his device to iOS 13.3.1, and real-time auto-match started working for him again. However, I have tested myself on a device running iOS 13.4, and I was not able to reproduce the problem (real-time auto-match worked on my test device). Also, other users are still able to real-time auto-match on iOS 13.4, so the issue isn't happening to everyone.Using the iOS simulator, I've found the following:- the iOS 13.4 simulatorencounters an error and is NOT able to real-time auto-match- the iOS 13.3 simulator encounters the same error and is NOT able to real-time auto-match- the iOS 10.3 simulator IS able to real-time auto-matchI don't know if the 13.X simulator error is related to what's occurring on the actual devices of the users with the problem as I'm not able to reproduce it myself on an actual device. The simulator error is:2020-03-28 14:46:29.383011-0700 <app name>[1761:25471] [Match] initiateRelayRequest returned an error: Error Domain=GKErrorDomain Code=3 "The requested operation could not be completed due to an error communicating with the server." UserInfo={GKServerStatusCode=5008, NSLocalizedDescription=The requested operation could not be completed due to an error communicating with the server., NSUnderlyingError=0x600000c64990 {Error Domain=GKServerErrorDomain Code=5008 "status = 5008, missing required key: self-push-token" UserInfo={GKServerStatusCode=5008, NSLocalizedFailureReason=status = 5008, missing required key: self-push-token}}}Thus the only info I have is the simulator error above, the fact that this problem is happening to some users only, and the models of the devices that these users are using. Is this enough info to submit a bug report?

Yes, I realize that simulators don't behave exactly the same as real devices. That's why I wasn't sure if I really had enough info to submit a bug report since I'm not able to reproduce the issue myself on a real device.

Have you been able to reproduce the problem when debugging on real devices? If so, what errors are you seeing in the device log? Can you paste the errors here?I've tested on a number of real devices running various iOS versions. I can't reproduce the problem on any of my devices. However, only one of my devices is running iOS 13.4.Edit: I now have an iOS 13.4 device that does exhibit the problem. I'll update this post after more testing.

This post might be related to your issue:https://forums.developer.apple.com/thread/130715

Yes, but if you're able to reproduce the issue on real devices, you should file a bug report (https://developer.apple.com/bug-reporting). In your bug report, if you note the errors from your device logs and also include a link to that post to correlate it with other bug reports, it could help Apple track down the bug.

I just submitted a bug report (FB7652145).I reproduced the issue on an iPad Air 2 running iOS 13.4 (17E255). Both real-time auto-matches and real-time invites failed.Device logs showed that findMatchForRequest() succeeded/completed, but then the following errors appeared in the log immediately afterwards:2020-04-04 11:33:40.781004-0700 <app name>[1282:133680] [ViceroyTrace] [ERROR] OSPFParse_ParsePacketHeader:1083 Bad destination count=02020-04-04 11:33:40.781500-0700 <app name>[1282:133585] [ViceroyTrace] [ERROR] ICEGetCandidates:580 /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/AVConference/AVConference-1640.8.1.1/ICE.subproj/Sources/ICE.c:580: ProcessCollectionResponse failed (8015000C)...and the match state never changed to "connected".

The latest iOS update (13.4.1) seems to have fixed this issue, at least for my app. Some users have confirmed this, and on my test device which previously failed, real-time matches now work also. If I hear anything different in the coming days, I'll post back here.

I tried just now, and it's working again.

Game Center seems to be working fine over here. I tested on one device running iOS 13.4.1 and another running iOS 12.4.6. Both devices are on wi-fi. Also, Settings > Game Center loads without issue.

Here is a crash report for the release version (exact same build as the TestFlight beta, which doesn't crash). The release version crashes immediately when the app is run. I don't think it loads any of my code at all.This crash is reproducible. If you use an iOS 10 device to run the release version of my app (details in bug report FB7692530), it will crash. If you run the TestFlight beta, it will not crash.Crash report follows:Incident Identifier: 28D0FA6B-4AB1-4C37-A0A7-EF284E419E4CCrashReporter Key: 3fcddbe8a8f49dd3eca438c0983d3a49990d48e5Hardware Model: iPhone5,2Process: <appname> [328]Path: /private/var/containers/Bundle/Application/55AC7D1A-83D5-44B7-B55D-F1061318BBA3/<appname>.app/<appname>Identifier: com.<company>.<appname>Version: <version> (<build>)Code Type: ARM (Native)Role: ForegroundParent Process: launchd [1]Coalition: com.<company>.<appname> [402]Date/Time: 2020-05-07 13:32:39.7419 +0100Launch Time: 2020-05-07 13:32:37.0000 +0100OS Version: iPhone OS 10.3.4 (14G61)Report Version: 104Exception Type: EXC_BAD_ACCESS (SIGSEGV)Exception Subtype: KERN_INVALID_ADDRESS at 0x0a8a00d4Termination Signal: Segmentation fault: 11Termination Reason: Namespace SIGNAL, Code 0xbTerminating Process: exc handler [0]Triggered by Thread: 0Thread 0 name:Thread 0 Crashed:0 ??? 0x0a8a00d4 0 + 176816340Thread 1:0 libsystem_pthread.dylib 0x1af9a454 start_wqthread + 0Thread 2:0 libsystem_kernel.dylib 0x1aee673c __workq_kernreturn + 81 libsystem_pthread.dylib 0x1af9a8ea _pthread_wqthread + 1150 (pthread.c:2205)2 libsystem_pthread.dylib 0x1af9a45c start_wqthread + 8Thread 3:0 libsystem_kernel.dylib 0x1aee673c __workq_kernreturn + 81 libsystem_pthread.dylib 0x1af9a8ea _pthread_wqthread + 1150 (pthread.c:2205)2 libsystem_pthread.dylib 0x1af9a45c start_wqthread + 8Thread 4:0 libsystem_kernel.dylib 0x1aee673c __workq_kernreturn + 81 libsystem_pthread.dylib 0x1af9a8ea _pthread_wqthread + 1150 (pthread.c:2205)2 libsystem_pthread.dylib 0x1af9a45c start_wqthread + 8Thread 5 name:Thread 5:0 libsystem_kernel.dylib 0x1aed0900 mach_msg_trap + 201 libsystem_kernel.dylib 0x1aed06e0 mach_msg + 44 (mach_msg.c:103)2 CoreFoundation 0x1b6d3be2 __CFRunLoopServiceMachPort + 144 (CFRunLoop.c:2527)3 CoreFoundation 0x1b6d2064 __CFRunLoopRun + 1436 (CFRunLoop.c:2870)4 CoreFoundation 0x1b6251ae CFRunLoopRunSpecific + 470 (CFRunLoop.c:3113)5 CoreFoundation 0x1b624fd0 CFRunLoopRunInMode + 104 (CFRunLoop.c:3143)6 Foundation 0x1bf79af4 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 258 (NSRunLoop.m:367)7 Foundation 0x1bf9676c -[NSRunLoop(NSRunLoop) runUntilDate:] + 86 (NSRunLoop.m:411)8 UIKit 0x212aead8 -[UIEventFetcher threadMain] + 128 (UIEventFetcher.m:313)9 Foundation 0x1c05d8ea __NSThread__start__ + 1122 (NSThread.m:1163)10 libsystem_pthread.dylib 0x1af9c93a _pthread_body + 216 (pthread.c:697)11 libsystem_pthread.dylib 0x1af9c85c _pthread_start + 234 (pthread.c:744)12 libsystem_pthread.dylib 0x1af9a468 thread_start + 8Thread 6:0 libsystem_pthread.dylib 0x1af9a454 start_wqthread + 0Thread 7 name:Thread 7:0 libsystem_kernel.dylib 0x1aed0900 mach_msg_trap + 201 libsystem_kernel.dylib 0x1aed06e0 mach_msg + 44 (mach_msg.c:103)2 CoreFoundation 0x1b6d3be2 __CFRunLoopServiceMachPort + 144 (CFRunLoop.c:2527)3 CoreFoundation 0x1b6d2064 __CFRunLoopRun + 1436 (CFRunLoop.c:2870)4 CoreFoundation 0x1b6251ae CFRunLoopRunSpecific + 470 (CFRunLoop.c:3113)5 CoreFoundation 0x1b624fd0 CFRunLoopRunInMode + 104 (CFRunLoop.c:3143)6 AVFAudio 0x3223682e GenericRunLoopThread::Entry(void*) + 142 (GenericRunLoopThread.h:106)7 AVFAudio 0x3225f58e CAPThread::Entry(CAPThread*) + 1548 libsystem_pthread.dylib 0x1af9c93a _pthread_body + 216 (pthread.c:697)9 libsystem_pthread.dylib 0x1af9c85c _pthread_start + 234 (pthread.c:744)10 libsystem_pthread.dylib 0x1af9a468 thread_start + 8Thread 8 name:Thread 8:0 libsystem_kernel.dylib 0x1aed0900 mach_msg_trap + 201 libsystem_kernel.dylib 0x1aed06e0 mach_msg + 44 (mach_msg.c:103)2 CoreFoundation 0x1b6d3be2 __CFRunLoopServiceMachPort + 144 (CFRunLoop.c:2527)3 CoreFoundation 0x1b6d2064 __CFRunLoopRun + 1436 (CFRunLoop.c:2870)4 CoreFoundation 0x1b6251ae CFRunLoopRunSpecific + 470 (CFRunLoop.c:3113)5 CoreFoundation 0x1b624fd0 CFRunLoopRunInMode + 104 (CFRunLoop.c:3143)6 AudioToolbox 0x1e2441b6 GenericRunLoopThread::Entry(void*) + 142 (GenericRunLoopThread.h:106)7 AudioToolbox 0x1e425fce CAPThread::Entry(CAPThread*) + 1548 libsystem_pthread.dylib 0x1af9c93a _pthread_body + 216 (pthread.c:697)9 libsystem_pthread.dylib 0x1af9c85c _pthread_start + 234 (pthread.c:744)10 libsystem_pthread.dylib 0x1af9a468 thread_start + 8Thread 9:0 libsystem_pthread.dylib 0x1af9a454 start_wqthread + 0Thread 10:0 libsystem_pthread.dylib 0x1af9a454 start_wqthread + 0Thread 0 crashed with ARM Thread State (32-bit): r0: 0xffffffff r1: 0x0a8a00d5 r2: 0x00000030 r3: 0x00000078 r4: 0x43870000 r5: 0x00000000 r6: 0x00000000 r7: 0x00000000 r8: 0x00000000 r9: 0x0037b838 r10: 0x0037ba08 r11: 0x165b9b50 ip: 0x0037b92c sp: 0x0037b850 lr: 0x001238f1 pc: 0x0a8a00d4 cpsr: 0x60000030[binary images cut] - If you need this, please let me know.

Based on this part of the binary images list:Binary Images:0x95000 - 0x16cfff <appname> armv7 <a0e4299e63db3fbebeb8bf66d17ec612> /var/containers/Bundle/Application/55AC7D1A-83D5-44B7-B55D-F1061318BBA3/<appname>.app/<appname>I ran the atos command to look up the address at the link register and got this result:% atos -arch armv7 -o <appname>.app.dSYM/Contents/Resources/DWARF/<appname> -l 0x95000 0x001238f1EVP_CipherInit_ex (in <appname>) + 69This is a function in the openssl library which I built as a static library and linked into my app. I'm using the same library that I built in 2015, and it has been working on iOS 10 devices until now.The only part of the app that uses the openssl library is the code that parses the in-app purchase receipt.Doesn't TestFlight also generate its own in-app purchase receipt if the tester buys an in-app purchase? If so, then both the TestFlight and release versions should run the same openssl code.

I figured out the issue.First, I reproduced the crash on TestFlight by making an in-app purchase, which created a receipt and triggered the openssl code. Thanks for pointing me to the link register, which helped me figure out how to reproduce the crash.Then, I found the problem was caused by selecting the "Include bitcode for iOS content" option when submitting the app to TestFlight/App Store. My theory is that the openssl library (which I built with embedded bitcode) is being recompiled by Apple, using a buggy compiler (possibly the one in Xcode 11.4, which is known to generate incorrect code for armv7).When I unchecked the "Include bitcode for iOS content" option, I was able to run the TestFlight app and make an in-app purchase without the app crashing.

Thanks for confirming this exact situation and also for the tip on how to reproduce locally without TestFlight. Since Apple DTS knew about this after your ticket, I wish they had reverted their compiler to a working one!

You should definitely file your own bug about that. I submitted a bug/suggestion (FB*******) for the sort order.