Hello, one of my users is experiencing this kind of issue: He taps on my app attached to the Dock. App icons turns gray, indicating the process is started. This state with him looking at his iOS homepage with icon grayed out stays for a second or two. App launches immediately, without displaying the Launch Screen. iPhone 14 Pro Max iOS 16.3.1 (video is from this system, but on 16.6 it happened for the same user too) He claims that the issue happens only when the app was turned off for a longer time (for example a day of inactivity). After this first longer broken launch, next launches works much faster and display launch screen properly.

Hi! Just got Xcode 15-beta and VisionOS SDK installed and tried to run the "hello world" program. As my device got extremely slow, the preview crashed a couple times and is barely usable. I tried running the simulator, it took a long time to load and the interaction with the simulated VisionOS was very slow. I understand it was quite an outdated device and I just want to know if it's something Apple could work on in the future updates OR it is an indicator to get a latest model? Thank you.

I've been playing with functionality of CADisplayLink to programmatically monitor rendering performance in an iOS app. Also spent quite some time in Instruments, of course (e.g. checking the Scroll Hitch Rate), but curious of what it looks like in the field and for specific screens in the app. The documentation says that a CADisplayLink timer object allows your app to synchronize its drawing to the refresh rate of the display. which makes me expect that the provided selector is called somewhat close to vsync events emitted by the underlying hardware. Also, the timestamp property is defined as follows: The time interval that represents when the last frame displayed. So I just use the two successive callbacks to figure out the on-screen duration of the frame while scrolling and decide if there was a hitch or not, like so: @objc private func handleDisplayUpdate(_ displayLink: CADisplayLink) { defer { cachedTimestamp = displayLink.timestamp } guard let cachedTimestamp = cachedTimestamp else { return } let frameTime = displayLink.timestamp - cachedTimestamp if frameTime > aThreshold { // do some lightweight logging } } By using CACurrentMediaTime() call I can see that the handler is called pretty close to what the latest timestamp holds, so it is 1ms-ish behind the recent frame update. However the frameTime intervals are not always a multiple of 16.67ms (assuming the device renders @60fps): while scrolling I can observe the numbers being e.g. 25ms or 43ms. Given that frames are swapped onto the display at vsync points in time only, does the above mean that the timestamp property actually represents something else in the whole render loop?