I am running Xcode 16.1, macOS 15.1 , iOS 18.1, and I see the error when trying to run the Instruments Network Profile

I am seeing some unexpected behavior, in particular, is seems that iOS is periodically foregrounding my test app with no user intervention. I am curious why this is. I wrote a simple test app to see how long the app would run to collect location while in the background with only "While in Use" location permission. The app will start location updates when foregrounded and continue in the background. While backgrounded, I see the blue arrow in the dynamic island as expected. What is unexpected is that every few days, I see the UI of the app displayed in the foreground, without having foregrounded it myself (and no, I did not tap the blue arrow). This is using the legacy CoreLocation apis on iOS 17.5.1. My question is how/why does this happen?

Setup and status: The app is under an Enterprise dev account. The app has Push Notifications, Remote Notifications and Voice over IP entitlements selected, among other, unrelated (I think) items. On launch, the app successfully registers via PushKit and gets back a valid device token. This token is copied from the Xcode console, and used to send VOIP pushes via the iCloud push console: https://developer.apple.com/notifications/push-notifications-console/ Results: For a debug build loaded onto a physical device, the push console reports successful delivery of the VOIP push to the device. However, VOIP pushes are only received by the app when it is in the foreground. If the app is in the background or not running, it is not woken/launched. The docs mention the need for a special VOIP push certificate, but my understanding is that is required between my server and Apple's servers. Since I am using the push console, I assume that removes the need for the certificate. So, what am I missing?

Is there a way to see ALL the crash logs for a device using Xcode 15? It seems to only display "recent" crashes now. Also, can I just download the crash log, rather than attempting to open to the appropriate place in the project (which is cool, but not not always useful)?

I would like to be able to collect profiling data on a physical device, say when I am going for a run, and later analyze that data using instruments. Is there a way to do that?

I am seeing location permission settings "going away" after upgrading to 17b2. In my app settings it looks like this: Before upgrade: after upgrade: And when I launch my app, it detects that location is not set to Always and prompts me to fix it (expected behavior). Is anybody else seeing this kind of behavior?

The site (https://developer.apple.com/download/)says build number = 12A7209, but the downloaded XCode reports 12A7208. Is this cause for concern? Specifically worried about app store rejection if not building with the actual Xcode GM

The documentation (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Notifications/Articles/NotificationQueues.html ) says: Using the NSNotificationCenter’s postNotification: method and its variants, you can post a notification to a notification center. However, the invocation of the method is synchronous: before the posting object can resume its thread of execution, it must wait until the notification center dispatches the notification to all observers and returns.  Does this mean that each observer's handler must run to completion or are they dispatched asynchronously?

The WWDC 2020 presentation reminds us of the importance of setting activityType appropriately. The documentation states that activityType affects the pausing of location updates. However this blog post (regex.info/blog/2015-12-03/2651) indicates that there may be other side effects, e.g. Snap-to-Road behavior, and that this behavior crosses application boundaries. There is an associated radar (#23737784, openradar.appspot.com/radar?id=6056041628303360). Can you clarify: (1) What specific behaviors are affected by activityType? (2) Can Snap-to-Road be controlled/affected by the app developer (this would be desirable)? (3) Has the referenced radar been addressed?