I'm trying to debug an issue with the Valgrind tool Helgrind. This is on masOS 11 (I've also seen it on 12, probably the same for other macOS versions). Here is the testcase. #include <pthread.h> #include <string.h> #include <assert.h> #include <errno.h> int main(void) { pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; pthread_cond_t cond = PTHREAD_COND_INITIALIZER; int res; // This time has most definitely passed already. (Epoch) struct timespec now; memset(&now, 0, sizeof(now)); res = pthread_mutex_lock(&mutex); assert(res == 0); res = pthread_cond_timedwait(&cond, &mutex, &now); assert(res == ETIMEDOUT); res = pthread_mutex_unlock(&mutex); assert(res == 0); res = pthread_mutex_destroy(&mutex); assert(res == 0); res = pthread_cond_destroy(&cond); assert(res == 0); } The error that I'm getting from Helgrind is ==56754== Thread #1 unlocked a not-locked lock at 0x1048C7A08 ==56754== at 0x10020E2F9: mutex_unlock_WRK (hg_intercepts.c:1255) ==56754== by 0x10020E278: pthread_mutex_unlock (hg_intercepts.c:1278) ==56754== by 0x7FF80F526813: _pthread_cond_wait (in /usr/lib/system/libsystem_pthread.dylib) ==56754== by 0x10020E812: pthread_cond_timedwait_WRK (hg_intercepts.c:1465) ==56754== by 0x10020E6A8: pthread_cond_timedwait (hg_intercepts.c:1512) ==56754== by 0x100003DD2: main (cond_timedwait_test.c:18) ==56754== Lock at 0x1048C7A08 was first observed ==56754== at 0x10020DE91: mutex_lock_WRK (hg_intercepts.c:1009) ==56754== by 0x10020DD68: pthread_mutex_lock (hg_intercepts.c:1031) ==56754== by 0x100003D7D: main (cond_timedwait_test.c:16) ==56754== Address 0x1048c7a08 is on thread #1's stack ==56754== in frame #5, created by main (cond_timedwait_test.c:7) If I turn on extra tracing then on FreeBSD the Helgrind pthread traces correspond to the C source. On macOS I see an extra mutex. << pthread_mxlock 0x7ff850c41 :: mxlock -> 0 >> << pthread_mxunlk 0x7ff850c41 :: mxunlk -> 0 >> ^^ I don't know what this mutex is << pthread_mxlock 0x1048c7a08 :: mxlock -> 0 >> ^^ this is the user mutex << pthread_mxlock 0x7ff850c41 :: mxlock -> 0 >> << pthread_cond_timedwait 0x1048c79d8 0x1048c7a08 0x1048c79c0<< pthread_mxunlk 0x7ff850c41 :: mxunlk -> 0 >> ^^ pthread_cond_timedwait unlocking the non-user mutex << pthread_mxlock 0x7ff850c41 :: mxlock -> 0 >> << pthread_mxunlk 0x7ff850c41 :: mxunlk -> 0 >> << pthread_mxunlk 0x1048c7a08 [error here] :: mxunlk -> 0 >> << pthread_mxlock 0x1048c7a08 :: mxlock -> 0 >> << pthread_mxlock 0x7ff850c41 :: mxlock -> 0 >> cotimedwait -> 60 >> In these traces the "-> 0" is the return code, showing that all of the calls succeeded. I need to do more debugging inside Helgrind. In the traces above I only see the user mutex being locked and then unlocked. Can anyone explain why I'm seeing an extra mutex in there? I'll have a poke around the XNU source

I made a developer account. I uploaded a photo id, it notified me that it will take 2 business days to get verified, but it has been already 2 weeks. What to do?

I am encountering a cloud signing permission error when archiving and uploading an iOS app using Xcode with Automatically manage signing enabled. Xcode reports that it cannot access or create cloud-managed distribution certificates, and therefore cannot find any App Store provisioning profiles for either the main app target or an associated Notification Service Extension. The error message returned by Apple’s certificate API indicates that access to cloud-managed distribution certificates is forbidden. Error messages Cloud signing permission error You haven't been given access to cloud-managed distribution certificates. Please contact your team's Account Holder or an Admin to give you access. No profiles were found Xcode couldn't find any iOS App Store provisioning profiles matching the app or extension targets. Environment Xcode: 16.x Signing method: Automatic signing (App Store distribution) Apple Developer Program team with existing distribution certificates Apple ID role: Admin (recently upgraded from a lower role) What I have verified Automatic signing is enabled for all targets The correct team is selected Bundle identifiers are valid and already registered The app and extension exist in App Store Connect Distribution certificates already exist in the team (previously created manually) Observed behavior Xcode attempts to access cloud-managed distribution certificates Apple certificate service responds with a permission-denied error As a result, provisioning profiles cannot be generated automatically Question After being upgraded to an Admin role, is there a known delay or additional requirement before an account can access cloud-managed distribution certificates, especially for teams that previously used manually managed distribution certificates? Is there any recommended action (besides waiting or having the Account Holder perform an initial signing operation) to unblock automatic signing in this situation?

I'm having problems constructing the initial stack for the guest executable for Valgrind on macOS 12 Intel. This seemed to work OK for macOS 11 but I'm getting a bad 'apple' pointer on macOS 12. The stack (constructed by Valgrind) looks like this higher address +-----------------+ <- clstack_end | | : string table : | | +-----------------+ | NULL | +-----------------+ | executable_path | (first arg to execve()) +-----------------+ | NULL | - - | envp | +-----------------+ | NULL | - - | argv | +-----------------+ | argc | +-----------------+ | mach_header * | (dynamic only) lower address +-----------------+ <- sp | undefined | : : The problem that I'm having is with the executable path (or the apple pointer). This points to NULL. The actual pointer to the "executable=xxx" string is 16 bytes lower in memory. The code for main starts with Dump of assembler code for function main: 0x0000000100003a90 <+0>: push %rbp 0x0000000100003a91 <+1>: mov %rsp,%rbp 0x0000000100003a94 <+4>: sub $0x60,%rsp 0x0000000100003a98 <+8>: movl $0x0,-0x4(%rbp) 0x0000000100003a9f <+15>: mov %edi,-0x8(%rbp) 0x0000000100003aa2 <+18>: mov %rsi,-0x10(%rbp) 0x0000000100003aa6 <+22>: mov %rdx,-0x18(%rbp) 0x0000000100003aaa <+26>: mov %rcx,-0x20(%rbp) That's the prefix, making space for locals, setting a local variable to 0 then getting the 4 arguments from main in edi, rsi, rdx and rcx as per the SYSV amd64 ABI. I think that it is dyld that puts the apple pointer into rcx. Can anyone tall me how dyld works out the address of the apple pointer?

Hello everyone, I’m experiencing a WeatherKit issue that occurs consistently on both the iOS 26.2 Simulator and a real device running iOS 26.2. Environment: Xcode: latest iOS: 26.2 Occurs on: Simulator AND physical device WeatherKit usage: via WeatherService API (not manual REST) Location Services: authorized (When In Use / Always) Issue: WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "The operation couldn’t be completed." Already verified: WeatherKit capability is enabled for the App ID com.apple.developer.weatherkit entitlement is present Bundle ID matches the App ID App is signed with the correct Team ID Behavior is identical on Simulator and physical device Error occurs before any WeatherKit response is returned Questions: Is this a known issue with WeatherKit on iOS 26.2? Are there any known limitations or requirements for WeatherService related to WeatherDaemon validation? Is there a recommended way to diagnose why WeatherDaemon rejects the request with Code=2? Code: private let weatherService = WeatherService()

It seems I was able to previously download a Disk Image (.dmg) file to install macOS High Sierra. However, I'm now having trouble finding where to download the resource. Any guidance would be greatly appreciated.

I used to resize images (editing width and height when writing the post) in order to avoid ridiculously large images in reading published post. Since a few weeks, that does not work anymore. When I edit, I see the reduced size in Live Preview: But once posted, images are much larger as seen below: Looks like the image is now resized to fill full width. I filed a bug report: Dec 27, 2025 at 1:43 PM – FB21446929 PS: that change ignores @eskimo wise advice "Quinn’s Top Ten DevForums Tips" n°10 (https://developer.apple.com/forums/thread/706527).

Hello, I hope you are doing well. I recently submitted my app for review, and it was rejected. However, I am still unsure about the exact reason for this decision. I carefully reviewed the feedback provided, but some points remain unclear to me. Could you please clarify which specific guidelines were not met, or which parts of the app need to be changed or improved? My goal is to fully understand the issue so I can fix it properly and ensure that the app complies with all App Store Review Guidelines in the future. Thank you in advance for your time and support.

I’m encountering an issue on iOS when rendering a list using React. Each list item uses the array index as the React key and consists of two parts: a header section that uses position: sticky for dynamic sticking behavior, and a body section whose height is automatically adjusted based on its content. When the list data is updated, I sometimes observe that the sticky header content does not update visually in time, even though the underlying data and DOM have changed. // demo.jsx import React, { useState } from 'react'; import { Button } from '@iftide/mobile'; import './style2.less'; // import data1 from './data1.json'; // import data2 from './data2.json'; const prefixCls = 'im-detaillist'; const data1 = [ { sectionTitle: '2025年05月' }, { sectionTitle: '2025年04月' }, { sectionTitle: '2025年03月' } ]; const data2 = [ { sectionTitle: '2023年08月' }, { sectionTitle: '2023年07月' }, { sectionTitle: '2023年06月' }, { sectionTitle: '2023年05月' } ]; export default function App() { const [list, setList] = useState(data1); const [toggle, setToggle] = useState(true); return ( <div> <Button title="更新2" onClick={() => { setToggle(!toggle); setList(data2); }} /> <div className={`${prefixCls}-container2`} style={{ height: `700px` }}> {list.map((section: any, sectionIdx: number) => { return ( <div className={`${prefixCls}`} key={String(sectionIdx)} // id={section.sectionTitle} > <div className={`${prefixCls}-section-title`} role="text"> {section.sectionTitle} </div> <div style={{ background: 'green', height: `${Math.ceil(400 * Math.random()) + 50}px` }} > 省略 </div> </div> ); })} </div> </div> ); } .@{prefixCls}-section-title { position: sticky; position: -webkit-sticky; will-change: transform; top: 0; z-index: 1; padding-left: 11px; width: 100%; height: 30px; font-size: var(--font-size-s); font-weight: 400; line-height: 30px; color: #000000; background-color: #F4F5F7; letter-spacing: 0; }