“iPhone 16 pro”

Description I am observing a critical issue when saving burst photos using the Photos Framework. If a burst photo with the same burstIdentifier already exists in the Recently Deleted album, any new assets saved via PHAssetCreationRequest are automatically merged into that deleted entry instead of appearing in the main Library or All Photos. Environment Framework: Photos Framework (iOS) API: [[PHPhotoLibrary sharedPhotoLibrary] performChanges:...] Code Snippet The following logic is used to save the burst assets: [[PHPhotoLibrary sharedPhotoLibrary] performChanges:^{ // 'paths' is a custom object providing the creation request PHAssetCreationRequest *assetCreationRqst = [paths assetCreationRqst]; assetCreationRqst.favorite = [FavorManager.shared isSetDownloadedAssetFavorite:self.curItem]; PHObjectPlaceholder *placeHolder = assetCreationRqst.placeholderForCreatedAsset; localIdentifier = placeHolder.localIdentifier; } completionHandler:^(BOOL success, NSError * _Nullable error) { if (success) { // The handler re

Can the vehicle‑side UWB module, acting as a Nearby Accessory, perform ranging with multiple iOS phones simultaneously while iOS cell uses background ranging with the vehicle‑side UWB (which involves BLE GATT services)? I mean, when the IOS cell works in the background, it will read the nearby gatt characteristic automatically. If there were multiple phones perform ranging with the accessory, the read characteristic from the accessory side, what shall its content be? Or does the accessory only perform ranging with one phone at a time?

We are currently experiencing an issue that occurs only on iPhone 17 models. In our app, after connecting to an external device, users can download multiple video files stored on the device. When downloading several videos consecutively, the device consistently stops receiving responses midway through the process. As a result, no response is returned, and the connection between the app and the device is eventually lost. This issue does not occur on any iPhone models prior to iPhone 17. It is reproducible across all iPhone 17 devices within our company. This is a critical issue, and we need urgent assistance. The main error logs show two patterns: • Connection loss • Timeout At the OS level, the only error codes we receive are: • -1005 (Network connection lost) • -1001 (Request timed out) Unfortunately, we are unable to obtain more detailed error information beyond these codes, which makes further debugging difficult. We have attached the relevant logs below. We would greatl

Has anyone gotten Postgres to run in a sandboxed app? I am compiling Postgres 18 myself from source and have tried to patch it so it doesn't use sysv (shmem) but it apparently has all kinds of invocations of sysv and once it's sandboxed has issues, e.g.: 2026-02-24 18:26:05.014 EST [4384] FATAL: semctl(65596, 16, SETVAL, 536) failed: Operation not permitted Does anyone know of a way to either make the sandbox relax or make Postgres compatible with sandboxing? I have tried passing flags to initdb to use POSIX semaphores but it always wants to use sysv so I'm finding myself super deep in the weeds of the Postgres source code.

We are developing a video processing app that applies CIFilter chains to video frames. To not force the user to keep the app foregrounded, we were happy to see the introduction of BGContinuedProcessingTask to continue processing when backgrounded. With iOS 26, I was excited to see the com.apple.developer.background-tasks.continued-processing.gpu entitlement, which should allow GPU access in the background. Even the article in the documentation provides exporting video in a film-editing app or applying visual filters (HDR, etc) or compressing images for social media posts as use cases. However, when I check BGTaskScheduler.shared.supportedResources.contains(.gpu) at runtime, it returns false on every iPhone I've tested (including iPhone 15 Pro and iPhone 16 Pro). From forum responses I've seen, it sounds like background GPU access is currently limited to iPad only. If that's the case, I have a few questions: Is this an intentional, permanent limitation — or is iPhone

I've been using Metal compute shaders for lattice quantum chromodynamics simulations and wanted to share the experience in case others are doing scientific computing on Metal. The workload involves SU(2) matrix operations on 4D lattice grids — lots of 2x2 and 3x3 complex matrix multiplies, reductions over lattice sites, and nearest-neighbor stencil operations. The implementation bridges a C++ scientific framework (Grid) to Metal via Objective-C++ .mm files, with MSL kernels compiled into .metallib archives during the build. Things that work well: Shared memory on M-series eliminates the CPU↔GPU copy overhead that dominates in CUDA workflows The .metallib compilation integrates cleanly with autotools builds using xcrun Float4 packing for SU(2) matrices maps naturally to MSL vector types Things I'm still figuring out: Optimal threadgroup sizes for stencil operations on 4D grids Whether to use MTLHeap for gauge field storage or stick with individual buffers Best practices for double precision — some measurements

I'm making my app in Xcode (as an app playground). I understand that the app will be run in a simulator when being evaluated if I choose the Xcode option on the submission form. However, my app looks significantly better on iPhones than on iPads. Is there a way for me to specify which device to use that will be respected by judges? What about device orientation? Thanks.

Environment: Xcode 26.2 Simulator: 26.0 / iPhone 17 Summary: Assigning a specific Unicode string to a UILabel (or any UITextView / text component backed by CoreText) causes an immediate crash. The string contains a visible base character followed by a zero-width non-joiner and two combining marks. let label = UILabel() label.text = u{274D}u{200C}u{1CD7}u{20DB} // ^ Crash in CoreText during text layout Crash stack trace: The crash occurs inside CoreText's glyph layout/shaping pipeline. The combining marks U+1CD7 and U+20DB appear to stack on the ZWNJ (which has no visible glyph), causing CoreText to fail during run shaping or bounding box calculation. Questions: Is this a known CoreText regression in the iOS 26.0 simulator? Is there a recommended fix or a more targeted workaround beyond stripping zero-width Unicode characters? Will this be addressed in an upcoming update