I am planning to build a service that automatically pulls Apple reports and stores them in my database. I was able to successfully retrieve the APP_USAGE report from the Analytics API. It initially generated daily reports for a couple of days, but then the daily report generation stopped. The weekly and monthly reports continue to generate normally. I also checked the readReportRequest response, and the StoppedDueToInactivity field is returned as false. And also, when I compared the monthly reports between the API and the web console, the data does not match. Does anyone have a solution to this issue, or is there a recommended or updated approach for handling this?

Hello Team, we are facing an issue with the certificate validation. When we attempt to validate the session, we are receiving an error. Could you please look into this and advise us on how to resolve the issue? {"error":"Apple returned HTTP 400","body":"\r\n400 The SSL certificate error<\/title><\/head>\r\n\r\n400 Bad Request<\/h1><\/center>\r\nThe SSL certificate error<\/center>\r\nApple<\/center>\r\n<\/body>\r\n<\/html>\r\n"}

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

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).

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; }