iOS is the operating system for iPhone.

Posts under iOS tag

200 Posts

Post

Replies

Boosts

Views

Activity

iPhone Duo - Buggy margin shift while dragging down a modal view controller
Has anyone else run into this issue? If you present a view controller and set its isModalInPresentation property to true, then when you try to drag down the view controller (which can't be dismissed), the view controller's content on the side of the vertical toolbar is shifted inward. This happens on a closed iPhone Duo. Even the title shifts if the vertical toolbar is on the left side. To replicate, create a Swift/UIKit project. Edit the main storyboard by deleting the default view controller scene and add a navigation controller (and its default root view controller). Set the class for the root view controller to ViewController. Then replace the default ViewController.swift code with the following: import UIKit class ViewController: UITableViewController { override func viewDidLoad() { super.viewDidLoad() let modal = UIBarButtonItem(systemItem: .add, primaryAction: .init(handler: { _ in let vc = ViewController() vc.title = "Some Modal" // If the following is true, dragging the modal view controller // down results in the table margins being shifted on whichever // side has a vertical toolbar. This happens on the iPhone Duo // when closed in either portrait or landscape. Whichever side // has the vertical toolbar gets shifted. // When the iPhone Duo is open the modal appears in a form sheet // and it does not demonstrate the issue. // The navigation title is also affected when the iPhone Duo is // closed and in landscape with the vertical toolbar on the left. // If the following is false, dismissing the modal by dragging it // down does NOT result in any change in the table's margins. vc.isModalInPresentation = true // false let nc = UINavigationController(rootViewController: vc) self.present(nc, animated: true) })) navigationItem.rightBarButtonItem = modal } } extension ViewController { override func numberOfSections(in tableView: UITableView) -> Int { 2 } override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { 4 } override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { // Some simple table cells to demonstrate the margin shift let cell = tableView.dequeueReusableCell(withIdentifier: "cell") ?? UITableViewCell(style: .value1, reuseIdentifier: "cell") cell.textLabel?.text = "Some Text" cell.detailTextLabel?.text = "Value" cell.accessoryType = .disclosureIndicator return cell } } Build and run the app with Xcode 27.1 and run it on an iPhone Duo (simulated or real). Tap the + icon to display the modal view controller (just another instance of ViewController). Now try to drag down the modal view controller. Notice the margin shift if the Duo is closed. There is no margin shift is the Duo is open or if isModalInPresentation is set to false. This has been reported as FB25221160.
1
0
653
1w
How to get the iOS 27.1 APIs in the Xcode 27.1 Developer Documentation window?
I have Xcode 27.1. When I open the Developer Documentation window, it only has the 27.0 APIs. While running Xcode 27.1 if I go to Xcode -> Settings -> Components -> Developer Documentation -> Info, the info window shows the Xcode version as 27.0 and the Developer Documentation Version as 10M13950. Xcode -> About Xcode definitely shows version 27.1. It's very difficult trying to work on iPhone Duo support when the developer documentation doesn't show any of the iOS 27.1 APIs. Is there any way to get the proper documentation loaded?
1
0
636
1w
Third-party keyboards get an extra 17pt gap at the top after switching apps on iOS 27 beta.
Feedback submitted: FB24460699 The sample projects are attached to the feedback report. Environment:iOS27 Beta6; iPhone 17Pro Problem:I have encountered a consistently reproducible third-party custom keyboard layout issue in iOS 27.0 beta 1 through beta 6. The custom keyboard initially appears correctly. If I switch apps while the text input remains focused and the keyboard remains visible, and then return to the host app, the system adds a 17-point area above the custom keyboard extension. Steps to reproduce Install and enable a third-party custom keyboard. Switch to the sample custom keyboard and open the host app so that the text editor in the center receives focus. Do not dismiss the keyboard or remove focus from the editor. Return to the Home Screen or switch to another app. Return to the host app. A new blank area now appears above the custom keyboard content. I tested both a system-determined extension view height and an extension view explicitly constrained to 180 points. Both configurations produce exactly the same change. After the foreground transition, the following extension-side values remain unchanged: view.bounds inputView.bounds extension.window.bounds view.safeAreaInsets, which remains {0, 0, 0, 0} The requested 180-point extension height Only the system keyboard frame received by the host app increases by 17 points. I also drew a rounded pink boundary inside the transparent extension root view. When the issue occurs, the new area appears outside that boundary. I tested several third-party keyboards and reproduced the issue with all of them. This suggests that the behavior is caused by iOS rather than by my app. Questions On iOS 27, is it expected behavior for a custom keyboard to gain a 17pt top area after its host app returns from the background? If this is a system issue, is there any workaround that can be used until it is fixed?
9
8
1.6k
1w
Feature request: level metering for MusicKit playback (FB25234486)
Hi everyone, I'm building a tvOS app that shows analog VU meters for the music playing, in the style of vintage hi-fi amplifiers and tape decks. It works well with local and network files played through AVAudioEngine, where I can tap the signal and measure real levels. With Apple Music, though, there's no way to get even basic level information. The content is DRM-protected, SystemMusicPlayer and ApplicationMusicPlayer render audio outside the app's audio graph, and MusicKit has no metering API. My current workaround is to analyze the song's 30-second preview and replay its level envelope in a loop. It looks plausible, but it isn't in sync with the actual music. I filed FB25234486 asking for a read-only metering API on MusicPlayer, similar to what AVAudioPlayer already offers: let rms = musicPlayer.averagePower(forChannel: 0) // dBFS let peak = musicPlayer.peakPower(forChannel: 0) // dBFS This wouldn't expose any audio samples: just one RMS and one peak value per channel, at a low, capped rate (around 30 Hz). Those numbers can't be turned back into audio, so content protection wouldn't be weakened, and the values could be computed inside the system's playback process. It would make a number of use cases possible: VU and peak meters, audio-reactive visualizers, ambient lighting synced to the music (HomeKit, smart lights), loudness displays, and accessibility features such as visual feedback of the music for hard-of-hearing users. If you need this too, please file your own feedback and mention FB25234486. Duplicate reports help Apple gauge demand. And if anyone has found a supported way to get playback levels from MusicKit today, I'd love to hear about it. Thanks!
0
0
107
1w
App Stuck in "Waiting for Review" for 10 Days
Hi everyone, The app was submitted for review 10 days ago, and since then, its status has remained "Waiting for Review" with absolutely no movement. Current situation: App Name: Complex S.I.L.A App ID: 6818184948 Platform: iOS Status: Waiting for Review Waiting time: 10 days No updates or requests for additional information from Apple We understand that review times can vary, but 10 days without any activity seems unusually long. Has anyone experienced similar delays recently? Is there anything we can do to get the submission reviewed? If an Apple engineer or forum moderator could check whether the submission is stuck or requires any action from our side, we would really appreciate it. Thanks in advance!
1
0
209
1w
Live Activities render blank after a TestFlight update; chronod reports zero widget extensions until reboot
After updating an internal test app through TestFlight, newly started Live Activities sometimes fail to render. Activity.request succeeds, but the Dynamic Island shows an empty tappable area and the Lock Screen shows no Live Activity. Rebooting the device restores rendering. Is there a supported way to recover from this state without asking the user to reboot? Configuration Device: iPhone18,1 OS for the captured reproduction: iOS 27.0.1 (24A446) Distribution: TestFlight, internal testers only. This app bundle is not published on the App Store. We have reproduced the issue with builds made using both Xcode 26 and Xcode 27. Deployment target: iOS 17.0 The widget extension contains an ActivityConfiguration for Live Activities only, with no Home Screen widgets. Our QA team also reported similar symptoms after app updates on iOS 17.4.1 (iPhone 15 Pro Max) and iOS 26.5 (iPhone 11). We do not have diagnostic logs from those devices, so we cannot confirm that they have the same underlying cause. Bundle identifiers below have been consistently replaced with com.example.internalapp and com.example.internalapp.widgets for this public post. Steps to reproduce Install a build of the app containing the Live Activity widget extension. Update to a newer build through TestFlight. After the update completes, launch the app and start a Live Activity using Activity.request(attributes:content:pushType: nil). Check the Dynamic Island and Lock Screen. This is intermittent: it has happened after several app updates, but not every update. In the captured reproduction, the activity was started about two minutes after installation completed. Expected and observed behavior We expect the Live Activity to render on the Dynamic Island and Lock Screen, with taps opening the app through its widgetURL. Instead: Activity.request succeeds and liveactivitiesd starts the activity. The Dynamic Island has an empty tappable area and the Lock Screen shows nothing. Tapping the empty area opens the app without the activity's widgetURL. Updating the activity's content does not restore rendering. After rebooting, newly started Live Activities render normally. QA has also seen rendering recover after an undetermined wait without rebooting. Relevant diagnostic observations The following is an abbreviated, redacted excerpt from a locally collected sysdiagnose. Times are JST (UTC+09:00), on 2026-10-18. Ellipses indicate omitted fields; the activity identifier has also been redacted. During installation, runningboardd records a RBSPreventLaunchLimitation covering the app and its extensions. While installation is still in progress, chronod ignores the widget extension: 22:38:45.295 runningboardd ... RBSPreventLaunchLimitation ... ... com.example.internalapp.widgets ... com.example.internalapp ... 22:38:45.549 chronod [com.apple.chrono:extensions] Ignoring restricted or unknown extension com.example.internalapp.widgets 22:38:47.178 installcoordinationd -[IXSCoordinatedAppInstall setComplete:] ... com.example.internalapp ... complete! 22:38:47.292 chronod [com.apple.appinstallation:TransactionLog] com.example.internalapp ... applicationsDidInstall When a Live Activity is started later, chronod repeatedly reports zero extensions for the app's container: 22:40:41.221 liveactivitiesd [com.apple.activitykit:activityManager] Starting activity: id: <activity-id>; ... state: active ... 22:40:41.254 chronod [com.apple.chrono:descriptor] Reloading descriptors for 0 extensions in container com.example.internalapp with reason: activityRendererInitiated 22:40:53.543 chronod [com.apple.chrono:descriptor] Reloading descriptors for 0 extensions in container com.example.internalapp with reason: activityRendererInitiated 22:40:55.707 chronod [com.apple.chrono:descriptor] Reloading descriptors for 0 extensions in container com.example.internalapp with reason: reload descriptors requested by client The installation logs also show the widget extension's provisioning profile being found and its data container being created. These observations suggest that extension discovery may not have recovered after the installation restriction was lifted, but we have not established the root cause. We noticed a potentially related watchOS WidgetKit report referencing FB24619522. Its author reported that their issue was resolved with watchOS 27.0 / iOS 27.0; we do not know whether our Live Activity issue is related. Questions Is there a supported API or recovery procedure that makes the system rediscover the Live Activity extension after an app update? Are there known TestFlight installation or extension configuration conditions that could explain this sequence? Which additional ActivityKit/WidgetKit diagnostics would help distinguish an app configuration issue from a system extension discovery issue? The full sysdiagnose is being kept out of this public post because it contains device and account diagnostics.
0
0
117
1w
iPhone Duo Simulator fails boot with “Data Migration Failed” on Xcode 27.1
I’m seeing a reproducible iPhone Duo Simulator boot failure in Xcode 27.1. Environment Xcode 27.1 / 27A9275 macOS Tahoe 26.6.2, then 26.7.1 Apple silicon Mac iPhone Duo / V68 / iPhone19,4 iOS 27.1 Simulator Runtime builds 24A94232 and 24A94425 Failure Running: xcrun simctl bootstatus -b terminates with: Status=3, isTerminal=YES Data Migration Failed Fresh Duo devices reproduced the failure on both runtime builds. During fresh migrations, DataMigrator logged: Reporting migration failure due to migration progress window incident On one fresh-device run, all 35 recorded migration plugins completed successfully, but the aggregate migration result was false and no failed-plugin identifier was exposed. I also tested: brand-new Duo simulator data restarting the correct CoreSimulatorService explicitly selecting runtime 24A94425 updating macOS from 26.6.2 to 26.7.1 An ordinary iPhone simulator on iOS 27.0 works on the same Mac. The failure occurs before any application is installed or launched. Feedback filed: FB25221101 Has anyone else seen this with the iPhone Duo Simulator in Xcode 27.1?
0
0
125
1w
XCode 27 stuck when building
Hello, I started writing my app on Xcode 26 and everything worked super smoothly. A build would take less than a minute and would immediately open the app on my iPhone 13 Pro. After updating to XCode 27 a build would still finish in the same amount of time, but it would only open the app maybe once out of 10 attempts, most of the time though nothing happens. No matter how long I wait, if I disconnect, reconnect, unlock my phone, it seems like xcode doesn't even notice. I display the build time inside the app and when I manually open the app I can see that it's from the last time the build successfully launched the app automatically. So it's stuck somewhere between building and loading it onto my phone I assume. I recently updated my phone to an 18 Pro and the issue persists. Connection is via USB-C cable. Anyone have any suggestions what might be wrong? Thank you!
0
0
174
2w
libquic.dylib crash during QUIC path migration on iOS 26 (quic_migration_probe_path / nw_protocol_data_access_buffer)
libquic.dylib crashes with a null/invalid buffer access in nw_protocol_data_access_buffer during QUIC connection path migration on iOS 26. App code is not in the stack — this is entirely within Apple system libraries. We are seeing a consistent crash on iOS 26 that does not reproduce on iOS 17 or iOS 18. The crash occurs on a background thread ("com.apple.network.connections") with no application code in the crashed thread's stack. The crash trace begins in quic_migration_probe_path and terminates in nw_protocol_data_access_buffer + 180, suggesting a use-after-free or buffer lifetime violation during QUIC connection path migration (e.g., Wi-Fi ↔ Cellular handoff). This crash does not appear to be reproducible on demand — it correlates with network path transitions while QUIC connections are active. Our app uses standard URLSession with default/ephemeral session configurations and does not explicitly enable HTTP/3; iOS 26 is automatically upgrading eligible connections. Crash thread (abbreviated): 0 libquic.dylib quic_conn_send_packet + 144 1 libquic.dylib quic_conn_continue_sending + 424 2 libquic.dylib __quic_conn_send_frames_for_key_state_block_invoke_2 + 1244 3 Network nw_protocol_data_access_buffer + 180 ← crash 4 Network nw_protocol_data_copy_buffer 5 Network nw_endpoint_flow_output_frames 6 libquic.dylib quic_conn_send_frames_for_key_state 7 libquic.dylib quic_conn_send_frames 8 libquic.dylib quic_migration_probe_path + 1464 9 libquic.dylib quic_migration_path_established + 2608 10 libquic.dylib __quic_migration_path_event_block_invoke.21 11 libquic.dylib quic_migration_path_event 12 Network nw_protocol_implementation_connected There is no app code in the crashed thread. This is a regression introduced in iOS 26, where libquic.dylib was separated into its own dynamic library and new path migration probe logic was introduced.
9
0
1.4k
2w
iOS 27 terminates a running app while MDM converts it to a managed app
We're working on an iOS app distributed through the App Store and installed on an MDM-enrolled device. Our MDM server uses InstallApplication to take management of the already-installed and running app. On iOS 27 betas 3 and 4, processing this command causes iOS to terminate the app and its extensions with SIGKILL. The same flow and MDM payload work without terminating the app on earlier iOS versions (iOS <=26). Environment OS: iOS 27 betas 3 and 4 Does not happen: iOS 26 or iOS 16.7.15 Device: iPhone SE 2nd Gen Enrollment: MDM-enrolled device Distribution: App Store app App state: Already installed and running when management is requested MDM command: InstallApplication Minimal MDM command The MDM server sends an InstallApplication command for the already-installed app: Attributes = { Removable = false; }; ChangeManagementState = Managed; Identifier = "APP_BUNDLE_ID"; InstallAsManaged = true; ManagementFlags = 1; RequestType = InstallApplication; We also tested the equivalent command using iTunesStoreID = APP_STORE_ID instead of Identifier, and removing InstallAsManaged. The targeted running app was terminated in the same way. Steps to reproduce Install and launch the App Store app as an unmanaged app. Enroll the iPhone in MDM. While the app is running, send the MDM InstallApplication command to take management of the existing installation. Observe the unified logs for mdmd, appstored, manageddeviced, installcoordinationd, and runningboardd. The issue can also be reproduced by initiating the same server-side flow while the app is already in the background. iOS 27 log sequence The command is accepted and appstored starts the managed-app tasks. manageddeviced then attempts to mark the app as managed using a null persona (this differs from iOS <26): The running app has a valid persona. After the failed mapping, installcoordinationd explicitly asks RunningBoard to terminate the app to disassociate that persona: After termination, removing the valid persona also fails. The managed-app task later reports success despite the mapping failures and termination. Earlier iOS comparison As an example, on iOS 16.7.15, using the same MDM command, **iOS routes the request through dmd with persona: default. The app remains alive and receives managed-app change notifications. Expected The existing installation becomes managed without terminating the running app, consistent with the behavior on earlier iOS versions. Actual manageddeviced tries to associate the app with persona (null) and fails with MIInstallerErrorDomain Code 191. That failure causes installcoordinationd to request termination of the app and its extensions to disassociate their valid persona. runningboardd terminates them with SIGKILL (isUserKill=0). The subsequent removal of the only valid persona fails with Code 242, although the managed-app task later reports success. Documentation checked The payload follows the documented InstallApplication flow for taking management of an existing app: Apple Docs WWDC26 app MDM updates We have not found a malformed field that explains the iOS 27-only failure. More info Detailed logs and additional info can be found on the Feedback report.
5
5
5.3k
2w
CarPlay - Navigation Entitlement
We went through Apple's CarPlay documentation and, based on what we found, CarPlay provides templates for both Navigation and Audio, and our app has entitlements for both. One thing we would like to confirm before proceeding with implementation is whether a single app can expose both Navigation and Audio experiences in CarPlay, using both entitlements. Specifically, can the same CarPlay app provide a navigation experience (e.g., using CPMapTemplate) while also exposing an Audio/"Now Playing" experience, or does Apple expect these experiences to be implemented as separate apps or otherwise treated as separate CarPlay experiences? We'd also like to confirm whether CarPlay now allows an app to display a split-screen interface with navigation/map content on one side and audio controls or "Now Playing" controls on the other side. If so, is this something a single app with both Navigation and Audio entitlements can implement? The documentation explains the available templates and entitlements, but we couldn't find explicit guidance on whether the same app can leverage both Navigation and Audio experiences or whether these can be presented together in a split-screen layout. We'd like to clarify this before implementing the "Now Playing" screen, to ensure our approach aligns with Apple's CarPlay requirements and guidelines.
2
0
1.6k
2w
How to preserve collection view scroll anchor when folding/unfolding iPhone Duo
The following question was asked in the Oct 13 iPhone Duo group lab: when you unfold iPhone Duo after you’ve scrolled down, does UIKit keep the position or should we re-anchor ourselves? The answer was various scroll views like collection views and text views will handle this for you to keep visible items visible, which also works when resizing the window on iPad. This is not working for me with a simple UICollectionView. What do I need to do to obtain this behavior? class ViewController: UIViewController, UICollectionViewDataSource { override func viewDidLoad() { super.viewDidLoad() let layout = UICollectionViewFlowLayout() layout.itemSize = CGSize(width: 80, height: 80) layout.minimumInteritemSpacing = 8 layout.minimumLineSpacing = 8 layout.sectionInsetReference = .fromLayoutMargins let collectionView = UICollectionView(frame: .zero, collectionViewLayout: layout) collectionView.translatesAutoresizingMaskIntoConstraints = false collectionView.backgroundColor = .systemBackground collectionView.dataSource = self collectionView.insetsLayoutMarginsFromSafeArea = true collectionView.register(UICollectionViewCell.self, forCellWithReuseIdentifier: "Cell") view.addSubview(collectionView) NSLayoutConstraint.activate([ collectionView.topAnchor.constraint(equalTo: view.topAnchor), collectionView.leadingAnchor.constraint(equalTo: view.leadingAnchor), collectionView.trailingAnchor.constraint(equalTo: view.trailingAnchor), collectionView.bottomAnchor.constraint(equalTo: view.bottomAnchor) ]) } func collectionView(_ collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int { 5000 } func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell { let cell = collectionView.dequeueReusableCell(withReuseIdentifier: "Cell", for: indexPath) var content = UIListContentConfiguration.cell() content.text = String(indexPath.item) content.textProperties.alignment = .center cell.contentConfiguration = content var background = UIBackgroundConfiguration.clear() background.backgroundColor = .secondarySystemBackground cell.backgroundConfiguration = background return cell } } Run the app on iPhone Duo Scroll down to cell 100 on the outer display Unfold the device Expected: It should stay scrolled to item 100 Actual: It scrolled down to item 225 (or more accurately, the content offset did not change, more content was added higher up with the contentSize shrinking due to the expanded width) In the past I've put so much work into trying to maintain the expected scroll position for orientation changes on iPhone and iPad/Mac Catalyst resize events, it's surprisingly incredibly hard to get working in every scenario, so I am SUPER interested to learn the system can do it for us!
0
0
217
2w
iOS 27: print(to:) silently drops every job after the first
The problem On iOS 27, UIPrintInteractionController.print(to:completionHandler:) works on its first call in a process. Every subsequent call is accepted (print(to:) returns true and printInteractionControllerWillStartJob fires), but the completion handler is never invoked: nothing prints, didFinishJob never fires, no error is produced, and no job appears in Print Center. I expected each call to submit an independent job and invoke its completion handler, as it does on iOS 26 and earlier with the identical binary. Steps to reproduce Build an app that prints without the print panel, using a retained UIPrinter from UIPrinterPickerController. Submit a job: let controller = UIPrintInteractionController.shared let info = UIPrintInfo(dictionary: nil) info.outputType = .general info.jobName = "job-\(n)" controller.printInfo = info controller.printingItem = pdfData // valid PDF, canPrint(data) == true controller.delegate = self let started = controller.print(to: savedPrinter) { _, completed, error in print("completion", completed, String(describing: error)) } print("started", started) First job: started == true, both willStartJob and didFinishJob fire, the completion handler runs with completed == true, and the page prints. Submit a second job the same way, same process. started == true and willStartJob fires with printInfo.printerID populated and printPaper negotiated to the same values as the successful job. Then nothing. No didFinishJob, no completion handler, no error, no page, nothing in Print Center. A third job: print(to:) returns false synchronously, since the shared controller still considers job two in flight. System information iPad, iPadOS 27.0 developer beta 6 Built against iOS 26.2 SDK (Xcode 26.2). Same binary works on iOS 26. Reproduced on two unrelated printers: Brother QL-820NWB and Canon MF420 Series. Content is a small PDF (~11 to 13 KB); canPrintData: returns true. Troubleshooting tried Restarted the iPad and reinstalled the app. Each buys exactly one successful print before the failure returns. Compared observable state between the working and hung jobs. Identical in every respect. During a hang, printed the same content to the same printer from Files via the share sheet. Worked normally, including on repeat. Paused in the debugger during the hang. No blocked thread; no PrintKit frame, XPC wait, or semaphore anywhere in bt all. Called contactPrinter before each job on the retained printer. Returned true quickly, and the job still hung. Implemented printInteractionControllerParentViewController(_:) in case a presentation context was missing. UIKit never calls it on this path. Workaround Creating a new UIPrintInteractionController per job resolves it completely. A long-lived instance the app creates itself fails exactly like .shared does, so the issue is reuse of a controller that has already run a job, not the shared singleton specifically. Is per-job instantiation the supported pattern? The docs say the shared instance "represents a print job" but don't state whether a controller may be reused for a second job, and every sample I can find uses sharedPrintController with the present… methods rather than print(to:).
5
7
1.5k
2w
AppStore.sync() throws StoreKitError.unknown after password submission in TestFlight
I'm investigating a Restore Purchases failure in my app, PW Paycheck, which uses StoreKit 2. TestFlight purchases of consumable checks and an annual subscription have succeeded, but restoring purchases repeatedly fails. The failing call is: try await AppStore.sync() Apple displays an account password prompt. I enter my password and tap OK, after which the call throws. Our typed error classifier and NSError conversion report: StoreKitError.unknown StoreKit.StoreKitError: 2 This is the StoreKit.StoreKitError domain, not SKErrorDomain. We have not established whether authentication succeeded internally or what causes the failure. Environment: Physical iPhone 16 Pro; installed through TestFlight. App version 1.0 (20), bundle com.ggeller.pwpaycheck. In-app OS report: Version 26.6.2 (Build 23G90). Reported StoreKit price storefront: USA / 143491. Annual subscription: com.ggeller.pwpaycheck.pro.annual. Developed and uploaded using Swift Playgrounds on iPad. I have a Windows laptop and no Mac access. Steps: Open the TestFlight app with an existing unexpired annual test subscription. Open Payment Options and tap Restore Purchases. Enter the password in Apple's prompt and tap OK. AppStore.sync() throws the error above. The app then refreshes entitlements and displays a restore failure message. Observed results: Verified active subscription access is recognized before and after the failed operation. We do not count this as successful restoration. The subscription was canceled but still unexpired during the captured attempt. Build 19 produced the same NSError domain/code on Wi-Fi and cellular. Build 20 captured the typed .unknown classification on Wi-Fi. Our logger captured no additional underlying error. The latest attempt started at 2026-10-14T13:59:09Z and completed at 13:59:25Z, including the post-failure entitlement refresh. We are not treating this as evidence of a timeout. The restore action is user initiated, guarded against duplicate operations, and waits for an earlier entitlement refresh to finish before calling AppStore.sync(). What supported diagnostic or configuration check would help distinguish possible causes of this error, particularly without access to Xcode's device console? Also, how should we isolate a TestFlight-specific restore failure in a focused sample while preserving the relevant app/account context? A separate sample has been prepared, but compilation and reproduction are still pending.
0
0
170
2w
Public API for real-time ambient light chromaticity on iPhone Air
I am developing a noncommercial graduation project for display color measurement with an iPhone Air. Is there a supported public API or entitlement for real-time chromaticity and illuminance readings from the built-in ambient light sensor? SensorKit's 24-hour data holding period does not fit this use. If this is unavailable, where should I submit an API enhancement request?
2
0
223
2w
App Store Rejection Under Guideline 4.2 (Minimum Functionality) – Hybrid Capacitor App With Native iOS Features and External Booking System
Summary I am seeking clarification regarding an App Store rejection under Guideline 4.2 – Design – Minimum Functionality, specifically around expectations for booking and payment flows in apps that rely on third-party, industry-standard reservation platforms. This app is a production application for a licensed transportation (black car / limo) service. It includes multiple native iOS features implemented via Capacitor and custom Swift plugins. However, the booking and payment flow depends on a third-party transportation platform (RideBits) that does not currently support deep linking with prefilled parameters or programmatic booking APIs. Before committing to a significant architectural change, I am hoping to understand whether Apple’s expectation under Guideline 4.2 is that all transactional booking and payment flows must be fully native and controlled by the app developer, even when third-party systems are operationally required. ⸻ App Context The app is designed for a real transportation business and is not a content, marketing, or browsing application. It is purpose-built for trip booking, pickup coordination, and customer interaction. The third-party platform (RideBits) handles: • Dispatch and driver assignment • Vehicle inventory and pricing rules • Payment processing • Trip lifecycle management This platform is central to business operations and is commonly used in this industry. ⸻ Native Functionality Implemented The app includes meaningful native iOS functionality beyond web content, including: • Native Core Location access (with permission handling) • Native reverse geocoding using CLGeocoder via a custom Swift Capacitor plugin • Native clipboard integration • Native iOS share sheet integration • Apple Maps deep linking • Custom CAPBridgeViewController with explicit plugin registration All native plugins were verified at runtime and tested on physical devices and simulators. ⸻ Booking Flow Constraint The third-party platform does not currently support: • Deep links with prefilled booking parameters • Passing pickup/dropoff data via URL • Native SDK embedding • APIs for programmatic booking creation As a result, even when pickup data is collected natively, users must re-enter details within the booking flow. ⸻ App Review Outcome Despite adding additional native functionality, the app was rejected again under Guideline 4.2, with feedback stating the experience is not sufficiently differentiated from web browsing and that features such as Core Location or sharing alone are not robust enough. ⸻ Clarification Requested I am hoping to better understand Apple’s expectations in this scenario: 1. Is Apple’s expectation that core booking and payment flows must be fully native to satisfy Guideline 4.2, regardless of industry-standard third-party dependencies? 2. Would an app be considered acceptable if the booking UI is native, but final transaction submission occurs through a third-party system? 3. Are there known precedents for service or transportation apps using third-party booking platforms that have successfully passed review? 4. Is the issue primarily technical (missing native features), or conceptual (core value relies on an external flow)? ⸻ Purpose of This Post Before undertaking a major rebuild of pricing, payments, and booking logic in-house, I want to ensure there is no App Store–acceptable architecture that allows: • Meaningful native functionality, and • Continued use of a third-party operational booking platform. Any guidance or shared experience would be greatly appreciated.
2
0
707
2w
iPhone Duo - Buggy margin shift while dragging down a modal view controller
Has anyone else run into this issue? If you present a view controller and set its isModalInPresentation property to true, then when you try to drag down the view controller (which can't be dismissed), the view controller's content on the side of the vertical toolbar is shifted inward. This happens on a closed iPhone Duo. Even the title shifts if the vertical toolbar is on the left side. To replicate, create a Swift/UIKit project. Edit the main storyboard by deleting the default view controller scene and add a navigation controller (and its default root view controller). Set the class for the root view controller to ViewController. Then replace the default ViewController.swift code with the following: import UIKit class ViewController: UITableViewController { override func viewDidLoad() { super.viewDidLoad() let modal = UIBarButtonItem(systemItem: .add, primaryAction: .init(handler: { _ in let vc = ViewController() vc.title = "Some Modal" // If the following is true, dragging the modal view controller // down results in the table margins being shifted on whichever // side has a vertical toolbar. This happens on the iPhone Duo // when closed in either portrait or landscape. Whichever side // has the vertical toolbar gets shifted. // When the iPhone Duo is open the modal appears in a form sheet // and it does not demonstrate the issue. // The navigation title is also affected when the iPhone Duo is // closed and in landscape with the vertical toolbar on the left. // If the following is false, dismissing the modal by dragging it // down does NOT result in any change in the table's margins. vc.isModalInPresentation = true // false let nc = UINavigationController(rootViewController: vc) self.present(nc, animated: true) })) navigationItem.rightBarButtonItem = modal } } extension ViewController { override func numberOfSections(in tableView: UITableView) -> Int { 2 } override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { 4 } override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { // Some simple table cells to demonstrate the margin shift let cell = tableView.dequeueReusableCell(withIdentifier: "cell") ?? UITableViewCell(style: .value1, reuseIdentifier: "cell") cell.textLabel?.text = "Some Text" cell.detailTextLabel?.text = "Value" cell.accessoryType = .disclosureIndicator return cell } } Build and run the app with Xcode 27.1 and run it on an iPhone Duo (simulated or real). Tap the + icon to display the modal view controller (just another instance of ViewController). Now try to drag down the modal view controller. Notice the margin shift if the Duo is closed. There is no margin shift is the Duo is open or if isModalInPresentation is set to false. This has been reported as FB25221160.
Replies
1
Boosts
0
Views
653
Activity
1w
How to get the iOS 27.1 APIs in the Xcode 27.1 Developer Documentation window?
I have Xcode 27.1. When I open the Developer Documentation window, it only has the 27.0 APIs. While running Xcode 27.1 if I go to Xcode -> Settings -> Components -> Developer Documentation -> Info, the info window shows the Xcode version as 27.0 and the Developer Documentation Version as 10M13950. Xcode -> About Xcode definitely shows version 27.1. It's very difficult trying to work on iPhone Duo support when the developer documentation doesn't show any of the iOS 27.1 APIs. Is there any way to get the proper documentation loaded?
Replies
1
Boosts
0
Views
636
Activity
1w
Third-party keyboards get an extra 17pt gap at the top after switching apps on iOS 27 beta.
Feedback submitted: FB24460699 The sample projects are attached to the feedback report. Environment:iOS27 Beta6; iPhone 17Pro Problem:I have encountered a consistently reproducible third-party custom keyboard layout issue in iOS 27.0 beta 1 through beta 6. The custom keyboard initially appears correctly. If I switch apps while the text input remains focused and the keyboard remains visible, and then return to the host app, the system adds a 17-point area above the custom keyboard extension. Steps to reproduce Install and enable a third-party custom keyboard. Switch to the sample custom keyboard and open the host app so that the text editor in the center receives focus. Do not dismiss the keyboard or remove focus from the editor. Return to the Home Screen or switch to another app. Return to the host app. A new blank area now appears above the custom keyboard content. I tested both a system-determined extension view height and an extension view explicitly constrained to 180 points. Both configurations produce exactly the same change. After the foreground transition, the following extension-side values remain unchanged: view.bounds inputView.bounds extension.window.bounds view.safeAreaInsets, which remains {0, 0, 0, 0} The requested 180-point extension height Only the system keyboard frame received by the host app increases by 17 points. I also drew a rounded pink boundary inside the transparent extension root view. When the issue occurs, the new area appears outside that boundary. I tested several third-party keyboards and reproduced the issue with all of them. This suggests that the behavior is caused by iOS rather than by my app. Questions On iOS 27, is it expected behavior for a custom keyboard to gain a 17pt top area after its host app returns from the background? If this is a system issue, is there any workaround that can be used until it is fixed?
Replies
9
Boosts
8
Views
1.6k
Activity
1w
Feature request: level metering for MusicKit playback (FB25234486)
Hi everyone, I'm building a tvOS app that shows analog VU meters for the music playing, in the style of vintage hi-fi amplifiers and tape decks. It works well with local and network files played through AVAudioEngine, where I can tap the signal and measure real levels. With Apple Music, though, there's no way to get even basic level information. The content is DRM-protected, SystemMusicPlayer and ApplicationMusicPlayer render audio outside the app's audio graph, and MusicKit has no metering API. My current workaround is to analyze the song's 30-second preview and replay its level envelope in a loop. It looks plausible, but it isn't in sync with the actual music. I filed FB25234486 asking for a read-only metering API on MusicPlayer, similar to what AVAudioPlayer already offers: let rms = musicPlayer.averagePower(forChannel: 0) // dBFS let peak = musicPlayer.peakPower(forChannel: 0) // dBFS This wouldn't expose any audio samples: just one RMS and one peak value per channel, at a low, capped rate (around 30 Hz). Those numbers can't be turned back into audio, so content protection wouldn't be weakened, and the values could be computed inside the system's playback process. It would make a number of use cases possible: VU and peak meters, audio-reactive visualizers, ambient lighting synced to the music (HomeKit, smart lights), loudness displays, and accessibility features such as visual feedback of the music for hard-of-hearing users. If you need this too, please file your own feedback and mention FB25234486. Duplicate reports help Apple gauge demand. And if anyone has found a supported way to get playback levels from MusicKit today, I'd love to hear about it. Thanks!
Replies
0
Boosts
0
Views
107
Activity
1w
App Stuck in "Waiting for Review" for 10 Days
Hi everyone, The app was submitted for review 10 days ago, and since then, its status has remained "Waiting for Review" with absolutely no movement. Current situation: App Name: Complex S.I.L.A App ID: 6818184948 Platform: iOS Status: Waiting for Review Waiting time: 10 days No updates or requests for additional information from Apple We understand that review times can vary, but 10 days without any activity seems unusually long. Has anyone experienced similar delays recently? Is there anything we can do to get the submission reviewed? If an Apple engineer or forum moderator could check whether the submission is stuck or requires any action from our side, we would really appreciate it. Thanks in advance!
Replies
1
Boosts
0
Views
209
Activity
1w
Live Activities render blank after a TestFlight update; chronod reports zero widget extensions until reboot
After updating an internal test app through TestFlight, newly started Live Activities sometimes fail to render. Activity.request succeeds, but the Dynamic Island shows an empty tappable area and the Lock Screen shows no Live Activity. Rebooting the device restores rendering. Is there a supported way to recover from this state without asking the user to reboot? Configuration Device: iPhone18,1 OS for the captured reproduction: iOS 27.0.1 (24A446) Distribution: TestFlight, internal testers only. This app bundle is not published on the App Store. We have reproduced the issue with builds made using both Xcode 26 and Xcode 27. Deployment target: iOS 17.0 The widget extension contains an ActivityConfiguration for Live Activities only, with no Home Screen widgets. Our QA team also reported similar symptoms after app updates on iOS 17.4.1 (iPhone 15 Pro Max) and iOS 26.5 (iPhone 11). We do not have diagnostic logs from those devices, so we cannot confirm that they have the same underlying cause. Bundle identifiers below have been consistently replaced with com.example.internalapp and com.example.internalapp.widgets for this public post. Steps to reproduce Install a build of the app containing the Live Activity widget extension. Update to a newer build through TestFlight. After the update completes, launch the app and start a Live Activity using Activity.request(attributes:content:pushType: nil). Check the Dynamic Island and Lock Screen. This is intermittent: it has happened after several app updates, but not every update. In the captured reproduction, the activity was started about two minutes after installation completed. Expected and observed behavior We expect the Live Activity to render on the Dynamic Island and Lock Screen, with taps opening the app through its widgetURL. Instead: Activity.request succeeds and liveactivitiesd starts the activity. The Dynamic Island has an empty tappable area and the Lock Screen shows nothing. Tapping the empty area opens the app without the activity's widgetURL. Updating the activity's content does not restore rendering. After rebooting, newly started Live Activities render normally. QA has also seen rendering recover after an undetermined wait without rebooting. Relevant diagnostic observations The following is an abbreviated, redacted excerpt from a locally collected sysdiagnose. Times are JST (UTC+09:00), on 2026-10-18. Ellipses indicate omitted fields; the activity identifier has also been redacted. During installation, runningboardd records a RBSPreventLaunchLimitation covering the app and its extensions. While installation is still in progress, chronod ignores the widget extension: 22:38:45.295 runningboardd ... RBSPreventLaunchLimitation ... ... com.example.internalapp.widgets ... com.example.internalapp ... 22:38:45.549 chronod [com.apple.chrono:extensions] Ignoring restricted or unknown extension com.example.internalapp.widgets 22:38:47.178 installcoordinationd -[IXSCoordinatedAppInstall setComplete:] ... com.example.internalapp ... complete! 22:38:47.292 chronod [com.apple.appinstallation:TransactionLog] com.example.internalapp ... applicationsDidInstall When a Live Activity is started later, chronod repeatedly reports zero extensions for the app's container: 22:40:41.221 liveactivitiesd [com.apple.activitykit:activityManager] Starting activity: id: <activity-id>; ... state: active ... 22:40:41.254 chronod [com.apple.chrono:descriptor] Reloading descriptors for 0 extensions in container com.example.internalapp with reason: activityRendererInitiated 22:40:53.543 chronod [com.apple.chrono:descriptor] Reloading descriptors for 0 extensions in container com.example.internalapp with reason: activityRendererInitiated 22:40:55.707 chronod [com.apple.chrono:descriptor] Reloading descriptors for 0 extensions in container com.example.internalapp with reason: reload descriptors requested by client The installation logs also show the widget extension's provisioning profile being found and its data container being created. These observations suggest that extension discovery may not have recovered after the installation restriction was lifted, but we have not established the root cause. We noticed a potentially related watchOS WidgetKit report referencing FB24619522. Its author reported that their issue was resolved with watchOS 27.0 / iOS 27.0; we do not know whether our Live Activity issue is related. Questions Is there a supported API or recovery procedure that makes the system rediscover the Live Activity extension after an app update? Are there known TestFlight installation or extension configuration conditions that could explain this sequence? Which additional ActivityKit/WidgetKit diagnostics would help distinguish an app configuration issue from a system extension discovery issue? The full sysdiagnose is being kept out of this public post because it contains device and account diagnostics.
Replies
0
Boosts
0
Views
117
Activity
1w
iPhone Duo Simulator fails boot with “Data Migration Failed” on Xcode 27.1
I’m seeing a reproducible iPhone Duo Simulator boot failure in Xcode 27.1. Environment Xcode 27.1 / 27A9275 macOS Tahoe 26.6.2, then 26.7.1 Apple silicon Mac iPhone Duo / V68 / iPhone19,4 iOS 27.1 Simulator Runtime builds 24A94232 and 24A94425 Failure Running: xcrun simctl bootstatus -b terminates with: Status=3, isTerminal=YES Data Migration Failed Fresh Duo devices reproduced the failure on both runtime builds. During fresh migrations, DataMigrator logged: Reporting migration failure due to migration progress window incident On one fresh-device run, all 35 recorded migration plugins completed successfully, but the aggregate migration result was false and no failed-plugin identifier was exposed. I also tested: brand-new Duo simulator data restarting the correct CoreSimulatorService explicitly selecting runtime 24A94425 updating macOS from 26.6.2 to 26.7.1 An ordinary iPhone simulator on iOS 27.0 works on the same Mac. The failure occurs before any application is installed or launched. Feedback filed: FB25221101 Has anyone else seen this with the iPhone Duo Simulator in Xcode 27.1?
Replies
0
Boosts
0
Views
125
Activity
1w
XCode 27 stuck when building
Hello, I started writing my app on Xcode 26 and everything worked super smoothly. A build would take less than a minute and would immediately open the app on my iPhone 13 Pro. After updating to XCode 27 a build would still finish in the same amount of time, but it would only open the app maybe once out of 10 attempts, most of the time though nothing happens. No matter how long I wait, if I disconnect, reconnect, unlock my phone, it seems like xcode doesn't even notice. I display the build time inside the app and when I manually open the app I can see that it's from the last time the build successfully launched the app automatically. So it's stuck somewhere between building and loading it onto my phone I assume. I recently updated my phone to an 18 Pro and the issue persists. Connection is via USB-C cable. Anyone have any suggestions what might be wrong? Thank you!
Replies
0
Boosts
0
Views
174
Activity
2w
libquic.dylib crash during QUIC path migration on iOS 26 (quic_migration_probe_path / nw_protocol_data_access_buffer)
libquic.dylib crashes with a null/invalid buffer access in nw_protocol_data_access_buffer during QUIC connection path migration on iOS 26. App code is not in the stack — this is entirely within Apple system libraries. We are seeing a consistent crash on iOS 26 that does not reproduce on iOS 17 or iOS 18. The crash occurs on a background thread ("com.apple.network.connections") with no application code in the crashed thread's stack. The crash trace begins in quic_migration_probe_path and terminates in nw_protocol_data_access_buffer + 180, suggesting a use-after-free or buffer lifetime violation during QUIC connection path migration (e.g., Wi-Fi ↔ Cellular handoff). This crash does not appear to be reproducible on demand — it correlates with network path transitions while QUIC connections are active. Our app uses standard URLSession with default/ephemeral session configurations and does not explicitly enable HTTP/3; iOS 26 is automatically upgrading eligible connections. Crash thread (abbreviated): 0 libquic.dylib quic_conn_send_packet + 144 1 libquic.dylib quic_conn_continue_sending + 424 2 libquic.dylib __quic_conn_send_frames_for_key_state_block_invoke_2 + 1244 3 Network nw_protocol_data_access_buffer + 180 ← crash 4 Network nw_protocol_data_copy_buffer 5 Network nw_endpoint_flow_output_frames 6 libquic.dylib quic_conn_send_frames_for_key_state 7 libquic.dylib quic_conn_send_frames 8 libquic.dylib quic_migration_probe_path + 1464 9 libquic.dylib quic_migration_path_established + 2608 10 libquic.dylib __quic_migration_path_event_block_invoke.21 11 libquic.dylib quic_migration_path_event 12 Network nw_protocol_implementation_connected There is no app code in the crashed thread. This is a regression introduced in iOS 26, where libquic.dylib was separated into its own dynamic library and new path migration probe logic was introduced.
Replies
9
Boosts
0
Views
1.4k
Activity
2w
iOS 27 terminates a running app while MDM converts it to a managed app
We're working on an iOS app distributed through the App Store and installed on an MDM-enrolled device. Our MDM server uses InstallApplication to take management of the already-installed and running app. On iOS 27 betas 3 and 4, processing this command causes iOS to terminate the app and its extensions with SIGKILL. The same flow and MDM payload work without terminating the app on earlier iOS versions (iOS <=26). Environment OS: iOS 27 betas 3 and 4 Does not happen: iOS 26 or iOS 16.7.15 Device: iPhone SE 2nd Gen Enrollment: MDM-enrolled device Distribution: App Store app App state: Already installed and running when management is requested MDM command: InstallApplication Minimal MDM command The MDM server sends an InstallApplication command for the already-installed app: Attributes = { Removable = false; }; ChangeManagementState = Managed; Identifier = "APP_BUNDLE_ID"; InstallAsManaged = true; ManagementFlags = 1; RequestType = InstallApplication; We also tested the equivalent command using iTunesStoreID = APP_STORE_ID instead of Identifier, and removing InstallAsManaged. The targeted running app was terminated in the same way. Steps to reproduce Install and launch the App Store app as an unmanaged app. Enroll the iPhone in MDM. While the app is running, send the MDM InstallApplication command to take management of the existing installation. Observe the unified logs for mdmd, appstored, manageddeviced, installcoordinationd, and runningboardd. The issue can also be reproduced by initiating the same server-side flow while the app is already in the background. iOS 27 log sequence The command is accepted and appstored starts the managed-app tasks. manageddeviced then attempts to mark the app as managed using a null persona (this differs from iOS <26): The running app has a valid persona. After the failed mapping, installcoordinationd explicitly asks RunningBoard to terminate the app to disassociate that persona: After termination, removing the valid persona also fails. The managed-app task later reports success despite the mapping failures and termination. Earlier iOS comparison As an example, on iOS 16.7.15, using the same MDM command, **iOS routes the request through dmd with persona: default. The app remains alive and receives managed-app change notifications. Expected The existing installation becomes managed without terminating the running app, consistent with the behavior on earlier iOS versions. Actual manageddeviced tries to associate the app with persona (null) and fails with MIInstallerErrorDomain Code 191. That failure causes installcoordinationd to request termination of the app and its extensions to disassociate their valid persona. runningboardd terminates them with SIGKILL (isUserKill=0). The subsequent removal of the only valid persona fails with Code 242, although the managed-app task later reports success. Documentation checked The payload follows the documented InstallApplication flow for taking management of an existing app: Apple Docs WWDC26 app MDM updates We have not found a malformed field that explains the iOS 27-only failure. More info Detailed logs and additional info can be found on the Feedback report.
Replies
5
Boosts
5
Views
5.3k
Activity
2w
CarPlay - Navigation Entitlement
We went through Apple's CarPlay documentation and, based on what we found, CarPlay provides templates for both Navigation and Audio, and our app has entitlements for both. One thing we would like to confirm before proceeding with implementation is whether a single app can expose both Navigation and Audio experiences in CarPlay, using both entitlements. Specifically, can the same CarPlay app provide a navigation experience (e.g., using CPMapTemplate) while also exposing an Audio/"Now Playing" experience, or does Apple expect these experiences to be implemented as separate apps or otherwise treated as separate CarPlay experiences? We'd also like to confirm whether CarPlay now allows an app to display a split-screen interface with navigation/map content on one side and audio controls or "Now Playing" controls on the other side. If so, is this something a single app with both Navigation and Audio entitlements can implement? The documentation explains the available templates and entitlements, but we couldn't find explicit guidance on whether the same app can leverage both Navigation and Audio experiences or whether these can be presented together in a split-screen layout. We'd like to clarify this before implementing the "Now Playing" screen, to ensure our approach aligns with Apple's CarPlay requirements and guidelines.
Replies
2
Boosts
0
Views
1.6k
Activity
2w
How to preserve collection view scroll anchor when folding/unfolding iPhone Duo
The following question was asked in the Oct 13 iPhone Duo group lab: when you unfold iPhone Duo after you’ve scrolled down, does UIKit keep the position or should we re-anchor ourselves? The answer was various scroll views like collection views and text views will handle this for you to keep visible items visible, which also works when resizing the window on iPad. This is not working for me with a simple UICollectionView. What do I need to do to obtain this behavior? class ViewController: UIViewController, UICollectionViewDataSource { override func viewDidLoad() { super.viewDidLoad() let layout = UICollectionViewFlowLayout() layout.itemSize = CGSize(width: 80, height: 80) layout.minimumInteritemSpacing = 8 layout.minimumLineSpacing = 8 layout.sectionInsetReference = .fromLayoutMargins let collectionView = UICollectionView(frame: .zero, collectionViewLayout: layout) collectionView.translatesAutoresizingMaskIntoConstraints = false collectionView.backgroundColor = .systemBackground collectionView.dataSource = self collectionView.insetsLayoutMarginsFromSafeArea = true collectionView.register(UICollectionViewCell.self, forCellWithReuseIdentifier: "Cell") view.addSubview(collectionView) NSLayoutConstraint.activate([ collectionView.topAnchor.constraint(equalTo: view.topAnchor), collectionView.leadingAnchor.constraint(equalTo: view.leadingAnchor), collectionView.trailingAnchor.constraint(equalTo: view.trailingAnchor), collectionView.bottomAnchor.constraint(equalTo: view.bottomAnchor) ]) } func collectionView(_ collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int { 5000 } func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell { let cell = collectionView.dequeueReusableCell(withReuseIdentifier: "Cell", for: indexPath) var content = UIListContentConfiguration.cell() content.text = String(indexPath.item) content.textProperties.alignment = .center cell.contentConfiguration = content var background = UIBackgroundConfiguration.clear() background.backgroundColor = .secondarySystemBackground cell.backgroundConfiguration = background return cell } } Run the app on iPhone Duo Scroll down to cell 100 on the outer display Unfold the device Expected: It should stay scrolled to item 100 Actual: It scrolled down to item 225 (or more accurately, the content offset did not change, more content was added higher up with the contentSize shrinking due to the expanded width) In the past I've put so much work into trying to maintain the expected scroll position for orientation changes on iPhone and iPad/Mac Catalyst resize events, it's surprisingly incredibly hard to get working in every scenario, so I am SUPER interested to learn the system can do it for us!
Replies
0
Boosts
0
Views
217
Activity
2w
iOS 27: print(to:) silently drops every job after the first
The problem On iOS 27, UIPrintInteractionController.print(to:completionHandler:) works on its first call in a process. Every subsequent call is accepted (print(to:) returns true and printInteractionControllerWillStartJob fires), but the completion handler is never invoked: nothing prints, didFinishJob never fires, no error is produced, and no job appears in Print Center. I expected each call to submit an independent job and invoke its completion handler, as it does on iOS 26 and earlier with the identical binary. Steps to reproduce Build an app that prints without the print panel, using a retained UIPrinter from UIPrinterPickerController. Submit a job: let controller = UIPrintInteractionController.shared let info = UIPrintInfo(dictionary: nil) info.outputType = .general info.jobName = "job-\(n)" controller.printInfo = info controller.printingItem = pdfData // valid PDF, canPrint(data) == true controller.delegate = self let started = controller.print(to: savedPrinter) { _, completed, error in print("completion", completed, String(describing: error)) } print("started", started) First job: started == true, both willStartJob and didFinishJob fire, the completion handler runs with completed == true, and the page prints. Submit a second job the same way, same process. started == true and willStartJob fires with printInfo.printerID populated and printPaper negotiated to the same values as the successful job. Then nothing. No didFinishJob, no completion handler, no error, no page, nothing in Print Center. A third job: print(to:) returns false synchronously, since the shared controller still considers job two in flight. System information iPad, iPadOS 27.0 developer beta 6 Built against iOS 26.2 SDK (Xcode 26.2). Same binary works on iOS 26. Reproduced on two unrelated printers: Brother QL-820NWB and Canon MF420 Series. Content is a small PDF (~11 to 13 KB); canPrintData: returns true. Troubleshooting tried Restarted the iPad and reinstalled the app. Each buys exactly one successful print before the failure returns. Compared observable state between the working and hung jobs. Identical in every respect. During a hang, printed the same content to the same printer from Files via the share sheet. Worked normally, including on repeat. Paused in the debugger during the hang. No blocked thread; no PrintKit frame, XPC wait, or semaphore anywhere in bt all. Called contactPrinter before each job on the retained printer. Returned true quickly, and the job still hung. Implemented printInteractionControllerParentViewController(_:) in case a presentation context was missing. UIKit never calls it on this path. Workaround Creating a new UIPrintInteractionController per job resolves it completely. A long-lived instance the app creates itself fails exactly like .shared does, so the issue is reuse of a controller that has already run a job, not the shared singleton specifically. Is per-job instantiation the supported pattern? The docs say the shared instance "represents a print job" but don't state whether a controller may be reused for a second job, and every sample I can find uses sharedPrintController with the present… methods rather than print(to:).
Replies
5
Boosts
7
Views
1.5k
Activity
2w
AppStore.sync() throws StoreKitError.unknown after password submission in TestFlight
I'm investigating a Restore Purchases failure in my app, PW Paycheck, which uses StoreKit 2. TestFlight purchases of consumable checks and an annual subscription have succeeded, but restoring purchases repeatedly fails. The failing call is: try await AppStore.sync() Apple displays an account password prompt. I enter my password and tap OK, after which the call throws. Our typed error classifier and NSError conversion report: StoreKitError.unknown StoreKit.StoreKitError: 2 This is the StoreKit.StoreKitError domain, not SKErrorDomain. We have not established whether authentication succeeded internally or what causes the failure. Environment: Physical iPhone 16 Pro; installed through TestFlight. App version 1.0 (20), bundle com.ggeller.pwpaycheck. In-app OS report: Version 26.6.2 (Build 23G90). Reported StoreKit price storefront: USA / 143491. Annual subscription: com.ggeller.pwpaycheck.pro.annual. Developed and uploaded using Swift Playgrounds on iPad. I have a Windows laptop and no Mac access. Steps: Open the TestFlight app with an existing unexpired annual test subscription. Open Payment Options and tap Restore Purchases. Enter the password in Apple's prompt and tap OK. AppStore.sync() throws the error above. The app then refreshes entitlements and displays a restore failure message. Observed results: Verified active subscription access is recognized before and after the failed operation. We do not count this as successful restoration. The subscription was canceled but still unexpired during the captured attempt. Build 19 produced the same NSError domain/code on Wi-Fi and cellular. Build 20 captured the typed .unknown classification on Wi-Fi. Our logger captured no additional underlying error. The latest attempt started at 2026-10-14T13:59:09Z and completed at 13:59:25Z, including the post-failure entitlement refresh. We are not treating this as evidence of a timeout. The restore action is user initiated, guarded against duplicate operations, and waits for an earlier entitlement refresh to finish before calling AppStore.sync(). What supported diagnostic or configuration check would help distinguish possible causes of this error, particularly without access to Xcode's device console? Also, how should we isolate a TestFlight-specific restore failure in a focused sample while preserving the relevant app/account context? A separate sample has been prepared, but compilation and reproduction are still pending.
Replies
0
Boosts
0
Views
170
Activity
2w
Public API for real-time ambient light chromaticity on iPhone Air
I am developing a noncommercial graduation project for display color measurement with an iPhone Air. Is there a supported public API or entitlement for real-time chromaticity and illuminance readings from the built-in ambient light sensor? SensorKit's 24-hour data holding period does not fit this use. If this is unavailable, where should I submit an API enhancement request?
Replies
2
Boosts
0
Views
223
Activity
2w
App Store Rejection Under Guideline 4.2 (Minimum Functionality) – Hybrid Capacitor App With Native iOS Features and External Booking System
Summary I am seeking clarification regarding an App Store rejection under Guideline 4.2 – Design – Minimum Functionality, specifically around expectations for booking and payment flows in apps that rely on third-party, industry-standard reservation platforms. This app is a production application for a licensed transportation (black car / limo) service. It includes multiple native iOS features implemented via Capacitor and custom Swift plugins. However, the booking and payment flow depends on a third-party transportation platform (RideBits) that does not currently support deep linking with prefilled parameters or programmatic booking APIs. Before committing to a significant architectural change, I am hoping to understand whether Apple’s expectation under Guideline 4.2 is that all transactional booking and payment flows must be fully native and controlled by the app developer, even when third-party systems are operationally required. ⸻ App Context The app is designed for a real transportation business and is not a content, marketing, or browsing application. It is purpose-built for trip booking, pickup coordination, and customer interaction. The third-party platform (RideBits) handles: • Dispatch and driver assignment • Vehicle inventory and pricing rules • Payment processing • Trip lifecycle management This platform is central to business operations and is commonly used in this industry. ⸻ Native Functionality Implemented The app includes meaningful native iOS functionality beyond web content, including: • Native Core Location access (with permission handling) • Native reverse geocoding using CLGeocoder via a custom Swift Capacitor plugin • Native clipboard integration • Native iOS share sheet integration • Apple Maps deep linking • Custom CAPBridgeViewController with explicit plugin registration All native plugins were verified at runtime and tested on physical devices and simulators. ⸻ Booking Flow Constraint The third-party platform does not currently support: • Deep links with prefilled booking parameters • Passing pickup/dropoff data via URL • Native SDK embedding • APIs for programmatic booking creation As a result, even when pickup data is collected natively, users must re-enter details within the booking flow. ⸻ App Review Outcome Despite adding additional native functionality, the app was rejected again under Guideline 4.2, with feedback stating the experience is not sufficiently differentiated from web browsing and that features such as Core Location or sharing alone are not robust enough. ⸻ Clarification Requested I am hoping to better understand Apple’s expectations in this scenario: 1. Is Apple’s expectation that core booking and payment flows must be fully native to satisfy Guideline 4.2, regardless of industry-standard third-party dependencies? 2. Would an app be considered acceptable if the booking UI is native, but final transaction submission occurs through a third-party system? 3. Are there known precedents for service or transportation apps using third-party booking platforms that have successfully passed review? 4. Is the issue primarily technical (missing native features), or conceptual (core value relies on an external flow)? ⸻ Purpose of This Post Before undertaking a major rebuild of pricing, payments, and booking logic in-house, I want to ensure there is no App Store–acceptable architecture that allows: • Meaningful native functionality, and • Continued use of a third-party operational booking platform. Any guidance or shared experience would be greatly appreciated.
Replies
2
Boosts
0
Views
707
Activity
2w