We have developed an iPad application using the ARCL (AR + CoreLocation) library to render Point of Interest (POI) annotations in both an AR view and a standard MapView. The application performs as expected on standard devices. However, we have some iPad covered with strong magnet. This creates significant magnetic interference, resulting in a 90° to 180° heading offset, rendering the AR POI placement and MapView orientation unusable. Technical Challenges & Constraints: Hardware Lock: The magnetic cover is a mandatory business requirement and cannot be removed during field use. Sensor Failure: The internal magnetometer cannot provide an accurate North reference due to the proximity of the cover’s magnets. While CoreLocation and CoreMotion use sensor fusion, the magnetometer remains the primary source for absolute heading. Alternative Orientation Tracking: Is there a documented method to bypass the magnetometer and derive device orientation using only the Gyroscope and Accelerometer (e.g., relative tracking) while still maintaining alignment with geographic coordinates in CoreLocation? Programmatic Offsets: Are there known APIs or mathematical workarounds to programmatically "nullify" or offset a constant magnetic bias once the device is inside the cover? so we can use that offset for ARView and in Mapview as well.

Hi everyone. I'm trying to use https://developer.apple.com/documentation/appstoreserverapi/get-transaction-info to retrieve order information. How can I get the refund status of an order through this API? Also, Apple's webhook notification for refunds includes fields like revocationReason and revocationType. Can these be retrieved through the API? I've noticed that some refund orders have these fields when retrieved using get-transaction-info api, but others don't. I don't know the reason for these differences. Could you please explain? Thank you very much.

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'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?