I am using Apple's original Lightning Digital AV-adapter (Lightning-to-HDMI dongle) to connect my iPhone to an external display via a HDMI cable. I need to synchronize rendering with the external display's refresh rate, so I create a new CADisplayLink tied to the external display's UIScreen: UIScreen.screens[externalDisplayIdx].displayLink(withTarget:, selector:). The callback is being called regularly, but with increasing delay relative to the CADisplayLink.timestamp, so the next time the callback is called, I have less and less time to draw the next frame (see the snippet below). Assuming 60 FPS, the value of secondsTillDeadline starts at an arbitrary value in the range of approx -0.0001 to 0.0166667, and then it slowly decreases towards zero (and for a brief period it goes into small negative numbers). Once it reaches zero, it flips back to 0.0166667 and continues to decrease again. This cycle repeats indefinitely. Changing the external display's resolution (UIScreen's mode) or the CADisplayLink's preferredFrameRateRange to a lower FPS does not seem to have any effect on the temporal drifting (even the rate of change seem to be the same). When I create a new CADisplayLink for the iPhone's main screen, the value of secondsTillDeadline is stable, it does not drift and it is very close to 0.0166667, as expected. Is this drift caused by the external monitor or by Apple's Lightning-to-HDMI dongle ...or is the problem somewhere else? Can the drifting be stopped? func onDisplayLinkUpdate(displayLink: CADisplayLink) { // Gradually decreases from 0.01667 to -0.0001, then flips back to 0.01667 and continues to decrease let secondsTillDeadline = displayLink.targetTimestamp - CACurrentMediaTime() }

My app currently doesn't specify multiple different appearances (Any, Dark, Tinted) for the App Icon. I want to release an update in which I plan to create a new AppIcon resouce which is going to contain these 3 appearances so that users on iOS 18 can have better experience. Once I will provide the new App Icon with the Any, Dark and Tinted variants, which of these variants will the App Store use for my app on the App Store? Does it depend on the user's system-wide choice of appearance? That is, would the App Store show a different icon appearance for my app for a person using the "Dark" option and a different app icon for the person using the "Light" option? Can I force the App Store to always display the "Any" variant of my icon on the App Store, regardless of the user's dark mode setting? My app targets iOS 13. What would happen if a person running iOS 13 would install the new update of my app, which newly contains all 3 App Icon color appearances? Would the "Any" variant be displayed and would iOS 13 ignore the "Dark" and "Tinted" variants? Or is there no backwards compatibility and older iOS version would display a blank app icon (the icon used by iOS for apps, which do not specify an App Icon)? P.S. Is this documented somewhere? Perhaps in a WWDC video or in documentation? I could not find enough in-depth information on this topic (especially on app icon appearance behavior on iOS 17 and older).

The Metal feature set tables specifies that beginning with the Apple4 family, the "Maximum threads per threadgroup" is 1024. Given that a single threadgroup is guaranteed to be run on the same GPU shader core, it means that a shader core of any new Apple GPU must be capable of running at least 1024/32 = 32 warps in parallel. From the WWDC session "Scale compute workloads across Apple GPUs (6:17)": For relatively complex kernels, 1K to 2K concurrent threads per shader core is considered a very good occupancy. The cited sentence suggests that a single shader core is capable of running at least 2K (I assume this is meant to be 2048) threads in parallel, so 2048/32 = 64 warps running in parallel. However, I am curious what is the maximum theoretical amount of warps running in parallel on a single shader core (it sounds like it is more than 64). The WWDC session mentions 2K to be only "very good" occupancy. How many threads would be "the best possible" occupancy?

How many 32-bit variables can I use concurrently in a single thread of a Metal compute kernel without worrying about the variables getting spilled into the device memory? Alternatively: how many 32-bit registers does a single thread have available for itself? Let's say that each thread of my compute kernel needs to store and work with its own array of N float variables, where N can be 128, 256, 512 or more. To achieve maximum possible performance, I do not want to the local thread variables to get spilled into the slow device memory. I want all N variables to be stored "on-chip", in the thread memory space. To make my question more concrete, let's say there is an array thread float localArray[N]. Assuming an unrealistic hypothetical scenario where localArray is the only variable in the whole kernel, what is the maximum value of N for which no portion of localArray would get spilled into the device memory? I searched in the Metal feature set tables, but I could not find any details.

Will it be possible to get direct access to all the different cameras of Vision Pro via AVFoundation or indirectly via other frameworks? Which sensors (inner and outer color & IR cameras, LiDAR, TrueDepth camera) will developers have access to on visionOS?

I have two Xcode versions installed on my macOS Ventura 13.4. Those are Xcode 14.3 (14E222b) and Xcode 15.0 beta (15A5160n). I do also have an iPhone 13 Pro (iOS 17.0 Developer Beta 21A5248v) and an iPad Pro (iPadOS 16.5). Xcode 14.3 shows both the iPad and the iPhone in "Devices and Simulators", but Xcode 15.0 shows only the iPad. When clicking the "+" button in the bottom left corner of the "Devices and Simulators" of Xcode 15.0, I can only see the iPad in the list of devices. Clicking the "+" button in Xcode 14.3 reveals both devices. What am I doing wrong? How can I make Xcode 15 recognize my iPhone with iOS 17? I have already tried restarting my Mac and my iPhone several times, including Force Restarting, but it didn't help.