Apple Maps Guides

Hello, I’m experiencing repeated rejections related to Guideline 2.1 – App Completeness for an iOS app using auto-renewable subscriptions, and I’m struggling to understand what is missing, as the purchase flow works correctly in sandbox and TestFlight. App setup: iOS app built with React Native (Expo + react-native-iap) Auto-renewable subscriptions: • Monthly: €4.99 • Yearly: €39.99 Paid Apps Agreement accepted Subscriptions configured and active in App Store Connect Privacy Policy and Apple Standard EULA included: • Visible inside the app on the subscription screen • Added in App Store metadata What App Review reports: App Review states they are unable to buy the in-app purchase, resulting in a rejection under Guideline 2.1 (App Completeness). What works correctly: getSubscriptions() returns valid products in sandbox Subscription titles, prices, and durations are displayed in the app UI requestSubscription() is triggered when tapping the subscribe button Apple purchase sheet appears and com

I’d like to confirm the expected behavior of StoreKit 2 in the Sandbox environment regarding unfinished consumable transactions across devices. Scenario: Device A and Device B are signed in with the same Sandbox Apple ID A consumable in-app purchase is completed on Device A The transaction may be verified or unverified, but transaction.finish() is not called The app is then launched on Device B and listens for Transaction.updates Question: In this scenario, is it expected that Device B will or will not receive a callback for this unfinished consumable transaction? Or is it by design that unfinished consumable transactions are not guaranteed to be delivered across devices, regardless of verification state?

I am implementing BLE scanning and connection using CoreBluetooth in a Flutter application with native iOS Swift code. BLE scanning and connection work correctly in the foreground and for a short time after the app is sent to the background. However, after some time in the background, BLE scanning stops and the device is no longer discovered. The app appears to be suspended by iOS. Key Observation: When location services are actively in use (navigation arrow visible in the iOS status bar), BLE scanning and reconnection work reliably in the background. When location services are not actively running, BLE scanning stops in the background even though the app has “Always Allow” location permission. Expected Result BLE scanning and connection should continue to function in the background using the Bluetooth LE background mode, without relying on active location updates. Actual Result BLE scanning starts successfully App enters background After some time, scanning stops Device is no longer discovered BLE works agai

Hello! I've been successfully using StartCalendarInterval in Launch[Agent|Daemon] *.plists for years. You know the deal: Mac is sleeping when CalendarInterval passes, then launchd runs the job when Mac is awoken. (This behavior is described at the bottom of an Apple doc from 2016 -- exactly how it worked before!) Recently, behavior has changed: with the computer asleep, when the date/time of the CalendarInterval passes, macOS runs the job! Even when sleeping. However, it gets stranger: macOS will start a job when sleeping, but then suspend it in the middle. I wrote a timestamped log to check this behavior: I see job start, pause in the middle, then resume hours later when a user wakes the computer. This all makes me think that sleep on macOS in the past few years is now defined differently -- perhaps an Apple Silicon change? But I can't find documentation that covers this. Buried in a WWDC video, maybe? Has anyone else seen this change in launchctl calendar scheduled jobs?

I'm experiencing a persistent issue where all my notarization submissions remain stuck in In Progress indefinitely. This is my first time notarizing an app. Environment: macOS 26.2 (Tahoe) Using xcrun notarytool submit Team ID: Y7T24GD249 App: Electron-based desktop application (~400MB) Stuck submissions (oldest to newest): 51412777-848c-4be1-a952-5ff32d6653f9 - Feb 4, 4:39 PM UTC (48+ hours) 9c4f94a1-d59a-4607-adf1-94c82fb4254b - Feb 4, 11:23 PM UTC 1c593512-ef55-4801-ba60-8b1bbc5a6f66 - Feb 4, 11:30 PM UTC de66e5cf-143c-40ec-ba62-2f07609044b4 - Feb 5, 1:39 PM UTC 964b2196-ad2e-4503-b15f-dc7f6a996ef0 - Feb 5, 2:25 PM UTC c8fdcccf-46cd-4609-bc33-faaa8fad696f - Feb 6, 5:11 PM UTC What I've tried: Verified Developer ID Application certificate is valid Checked code signatures with codesign -vvv --deep --strict Submitted both .zip and .dmg formats Checked Apple System Status (shows operational) notarytool log returns Record not found for all submissions Is there a known issue affecting first-time notariz

Hello, I have a problem generating a 2048-bit FairPlay Streaming certificate. I tried generating SDK v26.x certificate in two ways. (1) Use existing certificate (2) Create new certificate Though, in both ways, Apple gives me a certificate bundle of 1024-bit certificate. (fps_certificate.bin) I've uploaded 2048-bit CSR on creating a certificate. Just to note, I have created a SDK v4.x certificate few years ago. Have anyone bumped into a same issue? Or am I missing something?

I am writing to request a status update on my organization’s enrollment in the Apple Developer Program. Our application has been in Pending status for 10 days, and we have not received any requests for further documentation. Please help to solve my issue