We are developing a system consisting of two iOS apps from the same developer (same Team ID): ・App A acquires data from an external accessory. For regulatory/compliance reasons that we cannot detail here, App A must have no networking capability at all. ・App B is intended to receive data from App A and upload it to a server. Two important environmental constraints: ・The deployment environment is a closed local network. The server App B talks to is on the local network, and Internet access is not guaranteed. Therefore, any APNs-dependent approach (silent push, etc.) is not viable. ・Latency requirement: near-real-time is ideal, but a delay of up to a few minutes is acceptable. What we have considered: 1.App Groups shared container — App A can write data, but there is no way to wake App B in the background when new data is written. 2.URL schemes — can launch App B reliably, but bring it to the foreground, which disrupts the user's workflow. 3.BGTaskScheduler — rejected; execution timing is entirely at the system's discretion. 4.Silent push — rejected; requires APNs / Internet connectivity, which we cannot assume (see above). Our current leading candidate is a combination of (1) and (2): App A writes data to the App Groups container, then opens App B via a URL scheme; App B reads the container and uploads. This works, but the foreground app switch on every hand-off is far from ideal. We are aware that some apps abuse background modes (e.g., playing silent audio) to stay resident. We assume this violates App Review Guideline 2.5.4 and is not an option for us — please correct us if there is any legitimate variant of this approach. Questions: 1.Is there any supported mechanism to keep App B running (or reliably woken) in the background, so that it can receive data from App A and upload it — without user interaction and without Internet access? 2.If not, is there any way to mitigate the foreground switch in our current App Groups + URL scheme approach (e.g., returning to App A automatically after the hand-off)? Or would that ping-pong pattern itself be an App Review concern? Any guidance would be appreciated.

Hi everyone, I’ve filed a Feedback report (FB20986470) for a serious issue affecting the Call Directory database when add phone numbers for call blocking. When adding blocking numbers to a Call Directory extension, the system’s CallKit database (/private/var/mobile/Library/CallDirectory/CallDirectory.db) becomes corrupted. The reload call (reloadExtensionWithIdentifier) fails with error code 11 when the system tries to insert blocking entries, and the Console app on macOS shows the following errors: database corruption page 2265525 of /private/var/mobile/Library/CallDirectory/CallDirectory.db at line 81343 of [f0ca7bba1c] database corruption at line 79387 of [f0ca7bba1c] Error Domain=com.apple.callkit.database.sqlite Code=11 "sqlite3_step for query 'INSERT INTO PhoneNumberBlockingEntry (extension_id, phone_number_id) VALUES (?, (SELECT id FROM PhoneNumber WHERE (number = ?))), (?, (SELECT id FROM PhoneNumber WHERE (number = ?))),...)'" After this happens, CallKit becomes fully corrupted on the device and no further numbers can be added, even after: Disabling and re-enabling the extension Restarting the device (either force or soft restart) Reinstalling the app Waiting for a couple of minutes after this issue happens (that CallKit could possibly self-recovered) I also tested other call-blocking apps, and they all fail with the same error. The only thing that recovers the system is a full “Reset All Settings.” This issue has been reported by many users of my app, across multiple iOS versions and devices. Similar related issue reported by another developer: https://developer.apple.com/forums/thread/806129 Steps to Reproduce: Enable the Call Directory extension from a call-blocking app. Add and reload blocking numbers (a few thousand entries). Perform multiple reloads between additions. Check the Console, the corruption errors appear. From this point, all insert attempts fail system-wide. Expected Result: Entries should be inserted successfully, or the system should self-recover without persistent corruption. Actual Result: sqlite3_step fails with Code=11, and the Call Directory database remains corrupted until the user resets all settings. Additional Notes: All numbers are sorted and deduplicated before insertion. Happens intermittently after multiple reloads. The system log always shows internal database failure. Environment: Device: iPhone 16 Plus iOS 18.2 Beta (23C5027f) Xcode 16.1 (17B55) Attachments (included in Feedback FB20986470): sysdiagnose captured immediately after the failure (with Phone app General Profile) It seems like a system-level corruption affecting all Call Directory extensions once it occurs.

I have been implementing a share extension for my app and have added the activation rule NSExtensionActivationSupportsImageWithMaxCount. While testing I've noticed that my app will appear in the Share Sheet as a viable target when the max count is exceeded by up to 2 additional photos. For example if I set max to 4 then my app will appear in the share sheet when the user is sharing 1-6 images. On its own this wouldn't be too problematic, I figured I could put some validation in the extension that specifies the user has exceeded the allowed number. But while debugging the extension under this scenario I noticed that the inputItems array on the NSExtensionContext will only contain the number of items I've defined as the max, and silently drop the extra items. I'm sure users will see this as a bug with my app "losing" the extra images since the OS/Share Sheet provides my app as a valid target. My entire Info.plist <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>NSExtensionAttributes</key> <dict> <key>NSExtensionActivationRule</key> <dict> <key>NSExtensionActivationSupportsWebURLWithMaxCount</key> <integer>1</integer> <key>NSExtensionActivationSupportsImageWithMaxCount</key> <integer>4</integer> </dict> </dict> <key>NSExtensionPointIdentifier</key> <string>com.apple.share-services</string> <key>NSExtensionPrincipalClass</key> <string>$(PRODUCT_MODULE_NAME).ShareViewController</string> </dict> </plist> Entire code implementation of the extension class ShareViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() if let extensionContext { debugPrint(extensionContext) } } } Edit: I've been testing on iOS 26.5 with a minimum deployment of iOS 26.0

I don’t even see the waitlist of the Apple Intelligence program, i think it’s lacking instruction’s how to apply, when it comes out etc.

My device is Hong Kong version iPhone 16e with HK Apple ID. After updating to iOS 27 Beta 1, the "Apple Intelligence & Siri" menu is completely missing from Settings. Only the legacy "Siri" icon appears in that location. There is no option to join the "Try New Siri" waitlist, and none of the AI features are accessible. What I've tried (all failed): · Multiple reboots · Reset All Settings · Reset Location & Privacy · Toggling Siri language between English (US) and Traditional Chinese · Removing and re-adding keyboard languages Hardware eligibility: The device meets all requirements for Apple Intelligence (A17 Pro or later, 8GB RAM). The issue appears to be a system-level configuration loading bug that prevents the OS from recognizing the device as eligible, despite being a Hong Kong unit with a Hong Kong Apple ID. Feedback Assistant ID: FB23733608 Has anyone else with a non-US region device encountered this on iOS 27 Beta 1? Any temporary workaround would be greatly appreciated. Otherwise, I'll wait for Beta 2.

Hello everyone, We are encountering a critical regression introduced in iOS 26.4 that results in permanent workout data loss for users. When invoking HKWorkoutBuilder.finishWorkout(completion:) while the iOS device is locked, the save operation fails completely. However, it fails silently: the completion handler executes but returns both a nil workout and a nil error. Expected Behavior: Before iOS 26.4 finishWorkout resulted in a workout id, and correctly stored the workout data in HealthKit. According to HealthKit data protection documentation, saving data when the device is locked should either succeed (writing to a temporary journal file to be merged upon unlock) or explicitly throw an error such as HKError.Code.errorDatabaseInaccessible. Actual Behavior: Because the framework returns nil for both the object and the error, the application has no way to detect that the save failed. We cannot implement a retry mechanism or queue the save, resulting in silent data loss. Steps to Reproduce: We have built a Minimal Reproducible Example (MRE) that reliably triggers this: Initialize an HKWorkoutBuilder and call beginCollection(withStart:) followed by endCollection(withEnd:). Wrap the finishWorkout call in a short 5-second asynchronous delay, protected by a UIBackgroundTask to prevent app suspension. Lock the physical device during this 5-second window. The finishWorkout completion handler will execute while the device is locked, returning workout == nil and error == nil. Existing Reports: We have filed this via Feedback Assistant (a month ago) and opened a TSI (a week ago), providing the MRE project and a sysdiagnose captured at the time of failure: Feedback ID: FB22396180 TSI Case-ID: 19755043 As we have not yet received a response or a suggested workaround through these official channels, we are reaching out to the community. Has anyone else encountered this silent failure with HKWorkoutBuilder recently? Any insights or escalation help would be greatly appreciated.

I am writing a share extension for my app so users can share images from other apps. I have added the NSExtensionActivationSupportsImageWithMaxCount key to the NSExtensionActivationRule dictionary but I am wondering if there is a way to define the activation rule to say I will accept any number of images, and not have it constrained by a maximum value. Looking at the documentation I've noticed that attachments seem to be the only option that defines a minimum count (NSExtensionActivationSupportsAttachmentsWithMinCount). Is there an undocumented equivalent for images or some particular combination to use? I know I could set the max to be some very high number like 999, but I'm just wondering if there is an "official" supported way to achieve a min count defined on the extensions rules.

In the WWDC19 session "Embedding and Sharing Visually Rich Links" it mentions how the Messages app is able to gain access to the LPLinkMetadata provided to the Share Sheet (direct time link) so that it does not have to load the metadata itself. Looking through the NSExtensionContext's inputItems in my share extension and I could not see anything obvious that would allow my own share extension to read the loaded metadata. Am I missing something or is the metadata not made available? To be clear, I am aware of how to use LPMetadataProvider to fetch the metadata. I just want to know if my share extension can make use of the metadata that the Share Sheet has already loaded.

We got the newly issue that our Test devices keeps us asking for the pin code to "Enable UI Automation". Then it works for some hours or days, but after some time it starts again. "Enable UI Automation" is already enabled in "Settings" - "Developer" menu. The devices are located remotely and we can't access them directly, so this is a big issue for us right now. Is there any way to avoid this?

I've run into numerous rejections for my app with "similar binary code..." and marking my app as spam. I'm not sure what else I can do at this point and would love some tips on what exactly I'm doing wrong, if anything, or whether I should abandon my project. Happy to provide more context once I'm clear whether this is specific to the app submission details or actual code of my app.

Hey everyone, If your iPhone is stuck on "Optimizing Search and Siri" / Indexing at around 85-90% and hard resets or leaving it on wireless charging overnight isn't moving the needle, I found a definitive way to kickstart the daemon and force it to 100%. The Root Cause (Analyzed via macOS Console): By plugging the iPhone into a Mac and checking the Console logs, I noticed that spotlightknowledged and biomed get into an endless loop around Resolved entitled set identifiers to enumerate data resources. The system stalls on verifying developer entitlements and Apple Intelligence security tokens for specific app databases over cellular networks or unstable Wi-Fi. The dasd daemon eventually puts the pipeline into a hidden sleep state to protect the battery, making it look like it's doing nothing. The Solution that forced it to 100%: Use a Wired Connection (Ethernet Adapter): Connect your iPhone directly to your fiber optic router/modem using an RJ-45 Ethernet to USB-C adapter. iOS treats a wired Ethernet connection with the highest background priority. Turn off Cellular/Wi-Fi: Go to Control Center and disable Cellular Data and Wi-Fi entirely to force iOS to route 100% of traffic through the reliable, high-speed wired pipeline. (Verify the "Ethernet" tab appears in Settings). Trigger iCloud Token Refresh: Go to Settings -> [Your Name] -> iCloud -> Saved to iCloud and toggle off/on a major asset like iCloud Drive or Messages. This forces Spotlight to dump the stalled identifiers cache. Force Restart on Cable: Perform a Hard Reset (Vol Up, Vol Down, hold Power) while the Ethernet cable is connected. Let it Cook: Keep Low Power Mode OFF, lock the screen, and leave it alone. How to verify it's definitively done: Keep your Mac Console open and filter for completeness. Gdy to się stanie, zobaczysz ostateczny dziennik świętego Graala: fetchPipelineCompleteness: display=hidden days=3 procent=1.000000 Status the ` spent=1.000000 oznacza solidne 100% uzupełnienia. Zaraz po tym, 「dasd bezpiecznie zabije procesy worker (client process exited /connection invalid), telefon w końcu ostygnie, a żywotność baterii wróci do normy. Zaraz potem wyrzuciłem potoki glp i wszystko jest teraz masłem! Mam nadzieję, że pomoże to każdemu, kto utknął w 88% otchłani!

We’re working on improving the accessibility of a MKMapView that displays custom MKAnnotationView instances. Our implementation is fully accessible with VoiceOver: The custom annotation views expose the correct accessibility information. Users can navigate between annotations using custom accessibility rotors. The overall VoiceOver experience works as expected. However, we’re unable to make the custom MKAnnotationView instances accessible through Full Keyboard Access (FKA). Despite configuring the annotation views as accessibility elements and experimenting with focus-related APIs, the annotations never become reachable through keyboard navigation. They appear to be skipped entirely by the FKA focus system. Is there a supported way to make custom MKAnnotationView instances participate in Full Keyboard Access navigation? If this scenario is currently unsupported, is there a recommended approach or any plans to expose public APIs that would allow developers to provide a keyboard-accessible experience for custom annotations in MKMapView? Any guidance would be greatly appreciated.

Hey all, my first time posting on these forums as I've finally become completely stumped. I'm working to implement a ShareLink to share data between users on my app, and have gotten pretty far (file saves, sends correctly), but am having significant issues getting the link to open in my app when sharing by email and not getting any action at all when tapping a shared link in iMessage. I'll go through my setup below: I have declared my new UTType, and created my new model which conforms to transferable here: struct transferTemplate: Codable { var id: UUID = UUID() var name: String = "TempName" var words: [String] = ["word1","word2"] } extension transferTemplate: Transferable { static var transferRepresentation: some TransferRepresentation { CodableRepresentation(contentType: .oltemplate) } } extension UTType { static var oltemplate: UTType { UTType(exportedAs: "com.overloadapp.oltemplate") } } I have declared the document type in my info.plist: <key>CFBundleDocumentTypes</key> <array> <dict> <key>CFBundleTypeName</key> <string>Template Session</string> <key>LSHandlerRank</key> <string>Owner</string> <key>LSItemContentTypes</key> <array> <string>com.overloadapp.oltemplate</string> </array> </dict> </array> I have declared the Exported Type Identifier: <key>UTExportedTypeDeclarations</key> <array> <dict> <key>UTTypeConformsTo</key> <array> <string>public.json</string> </array> <key>UTTypeDescription</key> <string>Template Session</string> <key>UTTypeIconFiles</key> <array/> <key>UTTypeIdentifier</key> <string>com.overloadapp.oltemplate</string> <key>UTTypeTagSpecification</key> <dict> <key>public.filename-extension</key> <array> <string>oltemplate</string> </array> <key>public.mime-type</key> <array> <string>application/json</string> </array> </dict> </dict> </array> I've also included the "LSSupportsOpeningDocumentsInPlace" boolean to True in the PLIST. My physical ShareLink setup is: @State private var transferred: transferTemplate = transferTemplate(name: "NameTemplate", words: ["One","Two"]) ... ShareLink(item: transferred, preview: SharePreview("Share your template", image: Image("tanLogo"))) Heres where the above code gets you: ShareLink brings up the share sheet and allows you to send the file (with the .oltemplate file extension). Sharing via iMessage will send a file, but within iMessage, the file cannot be opened at all. By email, the file can be opened but does not show any information. If you open the ShareSheet within the email attachment, you can manually choose to open the file in my app. If the file is saved to "Files", it will open my app when it is tapped (work as intended). Heres what I have tried to fix this: Modifying the Exported File Type "Conforms to" value. Ive used public.data, public.text, public.json. Including and not including the mime type I've scoured forums trying to solve this issue, and it doesn't seem like there is a clear cut solution for this issue. I appreciate any help you can provide! Please let me know if I can include any more helpful information.

With Xcode Version 26.5 (17F42) apps can no longer be launched on a real Vision Pro once migrated to visionOS 27 Beta 2. At launch there is an EXC_BAD_ACCESS runtime error in an initialiser. If you launch apps on a real iPhone/Ipad with OS 27 Beta 2 the program will stop before the end of its start, but there is no precise line with the error. Xcode just stop in assembly code in the debugger, in the init phase of Swift where it searches for which objects to instantiate at launch. After investigating, the error comes from a debug setting from Xcode to show the stack trace. To avoid the error when run from Xcode Version 26.5 (17F42) In Xcode, open Product > Scheme > Edit Scheme. Select the Run action in the sidebar, then open the Options tab. Find Queue Debugging and uncheck Enable backtrace recording. If Queue debugging is enabled, then the program crashes when launched It is useful to be able to run apps from the production Xcode to devices with 27 OSes in beta to be able to test that everything will work fine for new versions of apps released before OSes 27 release. Thank you A previous post was made but the cause was badly identified. New Feedback including a sample code FB23384318

Playing the same IPA pronunciations using AVSpeechSynthesisIPANotationAttribute on iOS 26.5 and iOS 27.0 beta 1 yield very different results. It appears as if iOS is ignoring the IPA symbols. FB23041286 Sample app is here: https://github.com/ryanlintott/SpeechSynthesisIPAExample

On my app, some custom views are behind the navigation bar. On systems below iOS 26, I use this code to make the navigation bar transparent： self.navigationController.navigationBar.translucent = YES; self.navigationController.navigationBar.barTintColor = [UIColor clearColor]; [self.navigationController.navigationBar setBackgroundImage:[[UIImage alloc] init] forBarMetrics:UIBarMetricsDefault]; [self.navigationController.navigationBar setShadowImage:[[UIImage alloc] init]]; It works fine and the custom views show up well. But on iOS 26, the navigation bar adds a gradient layer, so the custom views get blocked, which looks a bit weird. Is there a way to remove the gradient layer from the iOS 26 navigation bar?