Apple Maps Guides

Hi everyone, I am really not sure where else to go for a piece of mind because our recent review experience has been far from clear (and probably fair). We are a photo editing app developers who deal with AI models, effects and transformations on a constant basis. I believe last year we (like many other apps in the category) introduced effects that get two people in different photos and unite them in one cute/fun/cozy/emotional picture. Be it a couple, a mother and daughter - you name it. Of course all the templates are pre-set, there is no option for users to generate any scene by text-to-image or image-to-image model. Otherwise it would be unsafe. When submitting our app to review in May, 2025 we first faced the situation that this kind of effects are not welcome because of: Guideline 1.1 - Safety - Objectionable Content The app references or includes features that some users may find objectionable or could be used to create objectionable content. Specifically: The app includes templates for generating cont

Hi everyone, I’m currently stuck with repeated App Store rejections under Guideline 3.1.2 (Subscriptions) and I honestly don’t know what else I can change. Apple keeps stating that the Privacy Policy link and Terms of Use (EULA) are missing from the app metadata. However, to the best of my knowledge, everything is already in place: The Privacy Policy link is: ✅ added in the Privacy Policy field in App Store Connect ✅ shown on the paywall ✅ accessible inside the app ✅ included in the app description The Terms of Use (Apple Standard EULA) are: ✅ linked in the app description ✅ shown on the paywall ✅ accessible inside the app This setup has been in place for multiple submissions, yet the app continues to be rejected with the same message saying these links are missing. At this point, I’m unsure: whether Apple expects the links in a very specific field or screen whether the reviewer is checking a different location or if I’m misunderstanding where exactly Apple requires these l

Hi everyone, I'm building a task management app that layers on top of EventKit/Reminders. I'm also moderating /r/AppleReminders. I see a confusion around the semantics of dates on both the developer side and on the user side. I'm trying to map the standard productivity mental model to the EKReminder implementation and hitting some walls. In productivity contexts, a task tends to have three distinct dates: Start Date: When the task becomes actionable — Don’t alert the user before this date. Notification: When the device should buzz/ping the user — Meaning that they can get started on the task. Due Date: Hard deadline — If the system works well, tasks are meant to rarely be past-deadline; productivity systems are about meeting deadlines rather than about missing them. The EventKit Reality Here is what I’m seeing in practice, and I’m hoping someone can correct me if I’m wrong: Field Description In Practice (Reminders App) startDateComponents Docs say start date of the task Seemingly unused? I can set it

Hi Team, We have a requirement for device-to-device communication using the Multipeer Connectivity framework without requiring Wi- Fi connectivity. Current Status: Multipeer communication works successfully when Wi-Fi is enabled Connection fails when using Bluetooth-only (Wi-Fi disabled, in Airplane Mode) Concern: We've found forum suggesting that Multipeer Connectivity over Bluetooth-only has been restricted since iOS 11, despite Apple's documentation stating support for both Wi-Fi and Bluetooth transports. Request: Could you please confirm: Whether Bluetooth-only Multipeer Connectivity is officially supported in current iOS versions( iOS 18.0+)? If there are specific configurations or entitlements required for Bluetooth-only operation? Any known limitations or alternative approaches for offline device-to-device communication? This clarification will help us determine the appropriate implementation strategy for our offline communication requirements. Thank you.

I have been working on a multi-platform multi-touch HID-standard digitizer clickpad device. The device uses Bluetooth Low Energy (BLE) as its connectivity transport and advertises HID over GATT. To date, I have the device working successfully on Windows 11 as a multi-touch, gesture-capable click pad with no custom driver or app on Windows. However, I have been having difficulty getting macOS to recognize and react to it as a HID-standard multi-touch click pad digitizer with either the standard Apple HID driver (AppleUserHIDEventDriver) or with a custom-coded driver extension (DEXT) modeled, based on the DTS stylus example and looking at the IOHIDFamily open source driver(s). The trackpad works with full-gesture support on Windows 11 and the descriptors seem to be compliant with the R23 Accessory Guidelines document, §15. With the standard, matching Apple AppleUserHIDEventDriver HID driver, when enumerating using stock-standard HID mouse descriptors, the device works fine on macOS 14.7 Sonoma