iOS is the operating system for iPhone.

All subtopics
Posts under iOS topic

Post

Replies

Boosts

Views

Activity

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
3w
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
187
3w
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
289
3w
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
742
3w
Best practice Replacement for Edit Button on iPhone Duo
On the iPhone Duo the standard "Edit" button for navigation bars is a text-based button, and text-based buttons are not pushed to the vertical toolbars on the Duo. This looks sometimes silly, if it is the only remaining button that can not be placed in the vertical toolbar and which has the result that an almost empty horizontal navigation bar must be kept visible as well. So I guess it would be good idea to have an icon-based replacement for the Editor button to avoid having two toolbars on the Duo. Is there a best practice for the icon to pick for such an edit button? Would be "square.and.pencil" (SF Symbols) a good choice? Or better the "pencil .circle", because the "square" one is often used for text-based input? Anything better?
4
0
1.2k
3w
How can I start developing my first game with Xcode and Reality Composer Pro on my own? 🎛️
Hello everyone!! 😊🤗 I'm starting to learn development for Apple platforms and I'd like to ask for some guidance on how to get started. My goal is to gradually develop my own video game using Xcode and Reality Composer Pro. The idea is to create an educational game with 3D environments and elements, so I also want to learn programming, experience design, and 3D content creation as I progress ⭐️ At the moment, I don't have much money to afford to hire developers to mentor me or take expensive courses 😔( My mother is sick and all our resources and budget are focused on her and her treatment. ) but I do have something I think is very important: a strong desire to learn, time, and the willingness to study and practice. I don't expect someone else to do the project for me; I want to learn how to build it myself. My main question is: where should I begin? I already have experience playing Swift Playgrounds, and I find it fascinating 🤩 but I'm looking for the next step: I'd like to know what Apple concepts, courses, documentation, or resources you would recommend I study first to learn how to use Xcode and Reality Composer Pro correctly, especially with the Apple Developer tutorials. Which videos specifically do you recommend I study? If anyone started in a similar way or has experience developing apps or games with these tools, I would greatly appreciate any advice on a learning path. Thank you so much for taking the time to read this and for any guidance you can give me! You truly don't know what this means to me. Thank you so much. 🙏🚀
2
0
1k
3w
iPhone Duo: navigation bar item briefly moves to vertical bar during fullScreen dismissal despite .disabled
On the folded iPhone Duo display, a navigation bar item briefly moves into the vertical bar during dismissal of a full-screen modal, then jumps back to the top. Both navigation controllers consistently return .disabled from preferredVerticalBarBehavior, with childForPreferredVerticalBarBehavior returning nil. Environment Xcode 27.1 RC (27A9275), iOS 27.1 SDK, iPhone Duo simulator, folded outer display in portrait. Steps to reproduce Run the single-file UIKit example below in a scene-based app with a generated launch screen and no main storyboard. Tap the gear button on the Home screen to present Settings using .fullScreen. Tap the close button on Settings. Watch the Home screen's gear button during the dismissal animation. Expected The gear button stays in the top horizontal navigation bar throughout the transition, because the vertical bar preference is .disabled on both navigation controllers. Actual For part of the dismissal, the gear button appears below the status icons in the right-hand vertical bar region. It then jumps back to the top horizontal bar. The underlying tab bar also temporarily moves from the bottom to the right before returning. This reproduces with an otherwise empty view, standard UIKit containers, and the default bar appearance. No app code changes safeAreaInsets, bar frames, or animation timing. During the presentation/dismissal cycle, the Home view's logged right safe-area inset changes from 0 to 88 points and back to 0. In our app, content constrained to the safe area visibly narrows during the same transient change. In separate comparisons, returning .disabled from the root tab controller and content controllers, or requesting setNeedsUpdateOfVerticalBarConfiguration in appearance callbacks, did not eliminate the issue. Changing the modal to .overFullScreen avoided it in the tested simulator, but changes the underlying view controller lifecycle. The example below intentionally keeps .fullScreen to reproduce the problem. Is this expected behavior, or a known UIKit issue? Is there a supported way to keep .disabled effective throughout a fullScreen presentation/dismissal? Has this been addressed in a newer SDK/runtime? I have not tested iOS 27.2 or a physical Duo device. Minimal reproduction (one Swift file): import UIKit @main final class DemoAppDelegate: UIResponder, UIApplicationDelegate { func application(_ application: UIApplication, configurationForConnecting session: UISceneSession, options: UIScene.ConnectionOptions) -> UISceneConfiguration { let configuration = UISceneConfiguration(name: "Demo", sessionRole: session.role) configuration.delegateClass = DemoSceneDelegate.self return configuration } } final class DemoSceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options: UIScene.ConnectionOptions) { guard let scene = scene as? UIWindowScene else { return } let home = DemoController() home.title = "首页" let navigation = DemoNavigationController(rootViewController: home) navigation.tabBarItem = UITabBarItem(title: "首页", image: UIImage(systemName: "house"), selectedImage: nil) let tabs = UITabBarController() if #available(iOS 18.0, *) { tabs.mode = .tabBar } tabs.viewControllers = [navigation] let window = UIWindow(windowScene: scene) window.rootViewController = tabs self.window = window window.makeKeyAndVisible() } } final class DemoNavigationController: UINavigationController { // 与音剪一致:导航容器固定横向栏,不转发给子页面。 @available(iOS 27.1, *) override var preferredVerticalBarBehavior: UIVerticalBarBehavior { .disabled } @available(iOS 27.1, *) override var childForPreferredVerticalBarBehavior: UIViewController? { nil } } final class DemoController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .systemBackground if title == "设置" { navigationItem.leftBarButtonItem = UIBarButtonItem(systemItem: .close, primaryAction: UIAction { [weak self] _ in self?.dismiss(animated: true) }) } else { navigationItem.rightBarButtonItem = UIBarButtonItem( image: UIImage(systemName: "gearshape"), primaryAction: UIAction { [weak self] _ in let settings = DemoController() settings.title = "设置" let navigation = DemoNavigationController(rootViewController: settings) navigation.modalPresentationStyle = .fullScreen self?.present(navigation, animated: true) }) } } override func viewDidLayoutSubviews() { super.viewDidLayoutSubviews() print("[DuoDemo] \(title ?? "") safe=\(view.safeAreaInsets) nav=\(navigationController?.navigationBar.frame ?? .zero) tab=\(tabBarController?.tabBar.frame ?? .zero)") } }
0
2
498
3w
Repeated App Review Rejections Despite Fixes — How Do We Get Specific Feedback?
Hi everyone, We're an independent development team preparing to launch our first iOS app and we've been stuck in the App Review process for over a month. We've received repeated rejections citing the same issues, even after making changes specifically intended to address Apple's feedback. Our biggest challenge isn't necessarily the rejection itself. We're happy to make whatever changes are required to comply with Apple's guidelines. The problem is that we're struggling to get clarification about what specifically remains noncompliant. We've responded through App Store Connect requesting additional details, but haven't received meaningful clarification. We've also contacted Apple Developer Support without getting a clear path toward resolution. We're now in a situation where we're submitting updated builds without knowing whether we're actually addressing the review team's concerns. My questions for developers who have experienced something similar: Has anyone successfully resolved repeated rejections where App Review continued citing the same guideline after fixes were implemented? Is there an effective way to request a conversation with an App Review representative or obtain more specific technical feedback? Are there any additional channels or approaches that have helped you break out of this cycle? We're not looking to bypass Apple's guidelines. We simply want to understand exactly what needs to change so we can get our app compliant and launched. Any advice or firsthand experience would be greatly appreciated. Thank you!
2
0
297
3w
Issues with AVRoutePickerView channel switching
We are developing a voice call application that uses AVRoutePickerView, allowing users to switch between an iPhone, a speaker, and Bluetooth earphones. However, we have encountered an intermittent issue: when switching from the speaker to Bluetooth earphones, the earphones remain in a loading state, and the audio channel subsequently switches back to the speaker. How can we resolve this issue? Here is the sample code: let session = AVAudioSession.sharedInstance() do { try session.setCategory(.playAndRecord, mode: .default, options: [.allowBluetooth]) try session.overrideOutputAudioPort(isBluetoothConnected ? .none : .speaker) try session.setPreferredSampleRate(48000) try session.setPreferredIOBufferDuration(0.02) try session.setActive(true, options: []) INFO(" >>> start: hasBluetooth=\(isBluetoothConnected), inputs: \(session.currentRoute.inputs.map { $0.portType }) outputs: \(session.currentRoute.outputs.map { $0.portType })") } catch { ERROR("(error.localizedDescription)") }
5
0
2.1k
4w
Toolbar background behaviour
Say i have a scrollview: I find it’s dumb how if you have the safe area inset or any kind of element below the toolbar, the background of those will extend to the top edge of the screen (by default), yet if the scrollview scrolls to the toolbar the toolbar background just “appears”, covering the existing background— its even worse cuz the toolbar background is there by default even when you didn’t set it in code. It seems more like a bug; I feel like this is something the SwiftUI team should improve upon. How about disabling toolbar background by default? Just wanted to get some more perspectives.
0
0
390
4w
App pending review for 8+ days with no feedback – Apple ID 6818113456
Hello Apple Review Team, I am contacting you regarding my application (Apple ID: 6818113456), which has been in “Pending Review” for more than 8 days without any updates. I have dedicated a lot of time and effort to developing this application, and I have also paid the $100 Apple Developer Program fee in order to publish it. During these days, I have tried contacting Apple Support by email and also by phone, but I have not received a response or been able to reach someone who could help me. According to the information provided by Apple, review times are normally expected to be around 24–48 hours. Therefore, I would kindly ask you to check the status of my application and let me know if there is any issue preventing the review from moving forward. I would greatly appreciate any help or update regarding the status of my application. I am available to provide any additional information or make any necessary changes. Thank you so much for your time and support. We look forward to hearing from you. Best regards
0
0
205
4w
iOS System Language does not change to Albanian or Macedonian
Hello, I’m trying to determine whether Albanian (sq) and Macedonian (mk) are supported as full system display languages on iOS. When I go to: Settings → General → Language & Region → iPhone Language Albanian and Macedonian are not available as system languages. However, both languages appear to have support in other parts of iOS. For example, Apple currently lists Albanian and Macedonian among the supported QuickType keyboard languages. 
https://www.apple.com/in/ios/feature-availability/?utm_source=chatgpt.com I have tested this behavior on: - iOS 16.7 - iOS 17.5 - iOS 26.6.1 - iOS 27.0.1 In all tested versions, I cannot change the iPhone system/display language to Albanian or Macedonian. I would like to clarify: 1. Are Albanian (sq) and Macedonian (mk) officially supported as iOS system/display languages? 2. If they are not supported, is there an official Apple documentation page listing the supported iOS system languages? 3. Is there any API or mechanism available to an app to determine whether a language is supported as a system UI language, as opposed to being supported only for keyboards or other language features? 4. Are there plans to add Albanian and Macedonian as full iOS system languages? I understand that app localization is separate from the iOS system language. Apple documentation explains that an app's localization is determined from the user's preferred languages and the localizations provided by the app. 
https://developer.apple.com/library/archive/qa/qa1828/_index.html?utm_source=chatgpt.com https://developer.apple.com/documentation/foundation/locale/preferredlanguages?changes=_11&utm_source=chatgpt.com I’m specifically asking about Apple's own iOS system UI, not localization of a third-party application. Expected: Selecting Albanian or Macedonian as the iPhone language should make the iOS system UI appear in that language, if the language is supported. Actual: Albanian and Macedonian cannot be selected as the iPhone's system/display language. Could someone from Apple confirm whether this is expected behavior and whether these languages are currently unsupported as full iOS system languages? Thank you.
3
0
311
4w
SwiftData: "backing data was detached from a context without resolving attribute faults" when deleting a model shown in a @Query driven list
A dashboard screen lists cameras from a @Query. Each row is a child view that holds the model instance: @Query(filter: #Predicate { $0.device?.isSelected == true }) private var cameras: [CameraModel] List { ForEach(cameras) { camera in CameraCellView(camera: camera) //holds let camera: CameraModel } } The row reads model attributes in its body (camera.name, camera.cameraType, camera.thumbnailData). It also has a 1-second timer that updates a "last snapshot" subtitle, so it redraws on its own. A settings screen is pushed on top of the dashboard in the same NavigationStack. It deletes a camera like this: camera.modelContext?.delete(camera) try? camera.modelContext?.save() Immediately after the delete, the app crashes in the dashboard row's body when it reads an attribute: Fatal error: This backing data was detached from a context without resolving attribute faults: PersistentIdentifier(...) - \CameraModel.cameraType This is not 100% reproducible. The whole error message is: Thread 1: Fatal error: This backing data was detached from a context without resolving attribute faults: PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(backing: SwiftData.PersistentIdentifier.PersistentIdentifierBacking.managedObjectID(0x8f8ff6c009fee652 x-coredata://65230C45-6F86-4B64-AEAB-6AAA9CB72D24/CameraModel/p16))) - \CameraModel.cameraType I understand this is due to a small gap where the SwiftUI view is rerendered before Query updates the view because of the deletion and the SwiftUI view points at a nonexistent SwiftData record. I'm just wondering what's a good way of avoiding that? SwiftData is used project-wide so this can potentially happen on nearly every view.
0
0
111
4w
Can CXCallObserver detect missed cellular calls while an iOS app is suspended?
Hello, I am developing an iPhone application to help users avoid missing important phone calls. The intended behavior is: A user receives a regular cellular call through the built-in iPhone Phone app. The user does not answer the call. Our application automatically detects the missed call. The application schedules repeated local notifications until the user acknowledges the missed call. The critical requirement is that detection must work while our application is in the background, without the user reopening it. Implementation We currently use CXCallObserver to observe cellular call events. When an incoming call ends without being connected, we classify it as a missed call and schedule notifications using UNUserNotificationCenter. Test environment Device: iPhone 17 iOS: 26.7.1 Distribution target: Standard App Store, Japan Testing: Physical device without an attached Xcode debugger Observed behavior Scenario A: Our application is visible immediately before the iPhone is locked. Missed calls have been detected and notifications scheduled after more than 30 to 60 minutes of device lock. Scenario B: Our application is moved to the background before the iPhone is locked, for example by returning to the Home Screen or opening Safari. Missed calls are not detected promptly, even after only a short period in the background. When the user subsequently opens our application, CXCallObserver callbacks may arrive and the earlier missed call is then detected. This defeats the purpose of the application because the user must reopen it to receive alerts. Questions Is CXCallObserver expected to deliver callbacks while its application is suspended, or only when the process is executing? Is there any supported public iOS API, extension, or background execution mechanism that allows a third-party application to detect missed calls from the built-in Phone app while the application is suspended or terminated? Can a regular cellular missed-call event wake or relaunch a third-party application? If CXCallObserver cannot support this use case, is there another Apple-supported solution available to ordinary App Store applications distributed in Japan? We are looking for an approach that does not require external hardware, carrier integration, private APIs, or unsupported background execution techniques. If this use case is not supported by the public iOS SDK, confirmation of that limitation would be very helpful. Thank you for your guidance.
1
0
304
Oct ’26
Issue with layoutMarginsGuide under iOS 26
Before I file a bug report I wanted to verify that I'm not missing something. If I setup a view controller in a navigation controller and I add a view with a constraint that lines it up with the view controller's view's layoutMarginsGuide (leadingAnchor or trailingAnchor), in several cases the view will not line up with buttons added in the navigation bar. Under iOS 18 everything lines up as expected. To demonstrate, create a new iOS project based on Swift/Storyboard. Setup the storyboard to show a UINavigationController with one UIViewController. Then in ViewController.swift (the one embedded in the navigation controller), use the following code: import UIKit class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .yellow title = "Layout Margins" let leftCancel = UIBarButtonItem(systemItem: .cancel) navigationItem.leftBarButtonItem = leftCancel let rightCancel = UIBarButtonItem(systemItem: .cancel) navigationItem.rightBarButtonItem = rightCancel let leftView = UIView() leftView.backgroundColor = .blue leftView.translatesAutoresizingMaskIntoConstraints = false self.view.addSubview(leftView) let rightView = UIView() rightView.backgroundColor = .red rightView.translatesAutoresizingMaskIntoConstraints = false self.view.addSubview(rightView) NSLayoutConstraint.activate([ leftView.widthAnchor.constraint(equalToConstant: 80), leftView.heightAnchor.constraint(equalToConstant: 80), leftView.leadingAnchor.constraint(equalTo: self.view.layoutMarginsGuide.leadingAnchor), leftView.topAnchor.constraint(equalTo: self.view.layoutMarginsGuide.topAnchor), rightView.widthAnchor.constraint(equalToConstant: 80), rightView.heightAnchor.constraint(equalToConstant: 80), rightView.trailingAnchor.constraint(equalTo: self.view.layoutMarginsGuide.trailingAnchor), rightView.topAnchor.constraint(equalTo: self.view.layoutMarginsGuide.topAnchor), ]) } } This adds a "Cancel" button to both ends of the navigation bar and it adds two little square views lined up with the leading and trailing layout margins. Here's the results: iPad running iPadOS 26 beta 3 (note the misalignment). This is really jarring when trying to align another glass button below the cancel button: iPad running iPadOS 18.5 (aligned just fine): iPhone in portrait running iOS 26 beta (aligned just fine): iPhone in landscape running iOS 26 beta (no alignment at all): iPhone in portrait running iOS 18.5 (aligned just fine): iPhone in landscape running iOS 18.5 (aligned just fine): Under iOS 26 on an iPhone (simulator at least) in portrait, the cancel buttons line up with the colored squares. That's good. In landscape, the colored squares have much larger margins as expected (due to the larger safe areas caused by the notch), but the cancel buttons in the navigation bar are not using the same margins. This one is debatable. Under iOS 18 the cancel buttons use larger margins to match the larger safe area. But I can see why under iOS 26 they changed this since the navigation bar doesn't interfere with the notch. But it's inconsistent. Under iOS 26 on an iPad (simulator at least), it's wrong in any orientation. Despite the lack of any notch or need for a larger safe area, the colored squares are indented just a bit more than the buttons in the navigation bar. I see no reason for this. Under iOS 18 everything lines up as expected. My real question at this point: Is the mismatched margins on an iPad under iOS 26 between the buttons in the navigation bar and other views added to the view controller a likely bug or am I missing something?
3
0
1.5k
Oct ’26
toolbarMinimizationBehavior(_:for:) crashes on some iOS 27.0.0 devices: "missing weak symbol" despite #available(iOS 27.0, *)
We are seeing a production crash that only affects devices reporting iOS 27.0.0. Devices on 27.0.1 and later, and on iOS 26, are unaffected. The app is built with Xcode 27.0 (the same binary shape appears with the Xcode 27.1 RC toolchain), deployment target iOS 26.0. The crashing code is a plain availability-gated call: extension View { @ViewBuilder func disableNavigationBarMinimization() -> some View { if #available(iOS 27.0, *) { toolbarMinimizationBehavior(.never, for: .navigationBar) } else { self } } } Crash report excerpt (addresses and app symbols removed): crash_info_entry_0: Failed to look up symbolic reference at <addr> - offset <n> - symbol <nearest stripped symbol> in <app binary> - pointer at <addr> is likely a reference to a missing weak symbol Crashed: com.apple.main-thread 0 libsystem_kernel.dylib __pthread_kill 2 libsystem_c.dylib abort 3 libswiftCore.dylib <redacted> 9 libswiftCore.dylib swift_getTypeByMangledName + 908 10 libswiftCore.dylib swift_getTypeByMangledNameInContext2 + 248 11 <app> __swift_instantiateConcreteTypeFromMangledNameV2 12 <app> specialized closure #1 in View.disableNavigationBarMinimization() 13 <app> closure #1 in SomeView.body.getter What we established: Because the deployment target is 26.0 and the API is @available(iOS 27.0, *), the app weak-imports both the function and its opaque result type descriptor. dyld_info -imports on the binary shows: _$s7SwiftUI4ViewPAAE27toolbarMinimizationBehavior_3forQrAA07ToolbareF0V_AA0H9PlacementVdtF [weak-import] (from SwiftUI) _$s7SwiftUI4ViewPAAE27toolbarMinimizationBehavior_3forQrAA07ToolbareF0V_AA0H9PlacementVdtFQOMQ [weak-import] (from SwiftUI) The call site has to instantiate the opaque return type's metadata before calling the function. That is the frame that aborts. So when dyld binds the descriptor to null, #available(iOS 27.0, *) passes and the process still dies. The symbol is present and exported on the iOS 27.0 build we can inspect locally (24A437, via Xcode's DeviceSupport symbols), and the same code runs fine on the iOS 27.0 simulator runtime (24A434). We cannot reproduce the crash on any device we own. The SwiftUI binary in 24A437 exports both toolbarMinimizeBehavior(_:for:) / ToolbarMinimizeBehavior and toolbarMinimizationBehavior(_:for:) / ToolbarMinimizationBehavior. The iOS 27.1 SDK only declares the latter, still annotated @available(iOS 27.0, *). This looks like a rename late in the 27.0 cycle. Our working theory is that some iOS 27.0.0 builds in the field (earlier 27.0 builds, possibly the ones preinstalled on new devices) predate the rename and only contain toolbarMinimizeBehavior, so the renamed symbol is absent and the weak import resolves to null. Questions: Is the @available(iOS 27.0, *) annotation on toolbarMinimizationBehavior(_:for:) accurate for every shipped 27.0.0 build? Should it be 27.0.1 or 27.1? Is there a supported way to guard against a missing opaque type descriptor at runtime, short of raising the availability check? Feedback filed as FB25095054.
0
0
263
Oct ’26
New submission stuck in review for 3 weeks, expedite or support ticket didn't help.
Submitted my third brand new on 15 Sep. Three weeks later it's still sitting in "Waiting for Review". Sent an expedite request on the 27th, heard nothing. By now the build in review is already pretty outdated, and I might have to wait another two weeks after sending the newer version. But I don't want to pull it and end up at the back of the queue. Anyone else seeing waits this long right now? And if it gets approved, does an update usually go through faster, or should I swap the build while I'm waiting?
1
0
236
Oct ’26
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
3w
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
187
Activity
3w
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
289
Activity
3w
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
742
Activity
3w
Best practice Replacement for Edit Button on iPhone Duo
On the iPhone Duo the standard "Edit" button for navigation bars is a text-based button, and text-based buttons are not pushed to the vertical toolbars on the Duo. This looks sometimes silly, if it is the only remaining button that can not be placed in the vertical toolbar and which has the result that an almost empty horizontal navigation bar must be kept visible as well. So I guess it would be good idea to have an icon-based replacement for the Editor button to avoid having two toolbars on the Duo. Is there a best practice for the icon to pick for such an edit button? Would be "square.and.pencil" (SF Symbols) a good choice? Or better the "pencil .circle", because the "square" one is often used for text-based input? Anything better?
Replies
4
Boosts
0
Views
1.2k
Activity
3w
How can I start developing my first game with Xcode and Reality Composer Pro on my own? 🎛️
Hello everyone!! 😊🤗 I'm starting to learn development for Apple platforms and I'd like to ask for some guidance on how to get started. My goal is to gradually develop my own video game using Xcode and Reality Composer Pro. The idea is to create an educational game with 3D environments and elements, so I also want to learn programming, experience design, and 3D content creation as I progress ⭐️ At the moment, I don't have much money to afford to hire developers to mentor me or take expensive courses 😔( My mother is sick and all our resources and budget are focused on her and her treatment. ) but I do have something I think is very important: a strong desire to learn, time, and the willingness to study and practice. I don't expect someone else to do the project for me; I want to learn how to build it myself. My main question is: where should I begin? I already have experience playing Swift Playgrounds, and I find it fascinating 🤩 but I'm looking for the next step: I'd like to know what Apple concepts, courses, documentation, or resources you would recommend I study first to learn how to use Xcode and Reality Composer Pro correctly, especially with the Apple Developer tutorials. Which videos specifically do you recommend I study? If anyone started in a similar way or has experience developing apps or games with these tools, I would greatly appreciate any advice on a learning path. Thank you so much for taking the time to read this and for any guidance you can give me! You truly don't know what this means to me. Thank you so much. 🙏🚀
Replies
2
Boosts
0
Views
1k
Activity
3w
iPhone Duo: navigation bar item briefly moves to vertical bar during fullScreen dismissal despite .disabled
On the folded iPhone Duo display, a navigation bar item briefly moves into the vertical bar during dismissal of a full-screen modal, then jumps back to the top. Both navigation controllers consistently return .disabled from preferredVerticalBarBehavior, with childForPreferredVerticalBarBehavior returning nil. Environment Xcode 27.1 RC (27A9275), iOS 27.1 SDK, iPhone Duo simulator, folded outer display in portrait. Steps to reproduce Run the single-file UIKit example below in a scene-based app with a generated launch screen and no main storyboard. Tap the gear button on the Home screen to present Settings using .fullScreen. Tap the close button on Settings. Watch the Home screen's gear button during the dismissal animation. Expected The gear button stays in the top horizontal navigation bar throughout the transition, because the vertical bar preference is .disabled on both navigation controllers. Actual For part of the dismissal, the gear button appears below the status icons in the right-hand vertical bar region. It then jumps back to the top horizontal bar. The underlying tab bar also temporarily moves from the bottom to the right before returning. This reproduces with an otherwise empty view, standard UIKit containers, and the default bar appearance. No app code changes safeAreaInsets, bar frames, or animation timing. During the presentation/dismissal cycle, the Home view's logged right safe-area inset changes from 0 to 88 points and back to 0. In our app, content constrained to the safe area visibly narrows during the same transient change. In separate comparisons, returning .disabled from the root tab controller and content controllers, or requesting setNeedsUpdateOfVerticalBarConfiguration in appearance callbacks, did not eliminate the issue. Changing the modal to .overFullScreen avoided it in the tested simulator, but changes the underlying view controller lifecycle. The example below intentionally keeps .fullScreen to reproduce the problem. Is this expected behavior, or a known UIKit issue? Is there a supported way to keep .disabled effective throughout a fullScreen presentation/dismissal? Has this been addressed in a newer SDK/runtime? I have not tested iOS 27.2 or a physical Duo device. Minimal reproduction (one Swift file): import UIKit @main final class DemoAppDelegate: UIResponder, UIApplicationDelegate { func application(_ application: UIApplication, configurationForConnecting session: UISceneSession, options: UIScene.ConnectionOptions) -> UISceneConfiguration { let configuration = UISceneConfiguration(name: "Demo", sessionRole: session.role) configuration.delegateClass = DemoSceneDelegate.self return configuration } } final class DemoSceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options: UIScene.ConnectionOptions) { guard let scene = scene as? UIWindowScene else { return } let home = DemoController() home.title = "首页" let navigation = DemoNavigationController(rootViewController: home) navigation.tabBarItem = UITabBarItem(title: "首页", image: UIImage(systemName: "house"), selectedImage: nil) let tabs = UITabBarController() if #available(iOS 18.0, *) { tabs.mode = .tabBar } tabs.viewControllers = [navigation] let window = UIWindow(windowScene: scene) window.rootViewController = tabs self.window = window window.makeKeyAndVisible() } } final class DemoNavigationController: UINavigationController { // 与音剪一致:导航容器固定横向栏,不转发给子页面。 @available(iOS 27.1, *) override var preferredVerticalBarBehavior: UIVerticalBarBehavior { .disabled } @available(iOS 27.1, *) override var childForPreferredVerticalBarBehavior: UIViewController? { nil } } final class DemoController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .systemBackground if title == "设置" { navigationItem.leftBarButtonItem = UIBarButtonItem(systemItem: .close, primaryAction: UIAction { [weak self] _ in self?.dismiss(animated: true) }) } else { navigationItem.rightBarButtonItem = UIBarButtonItem( image: UIImage(systemName: "gearshape"), primaryAction: UIAction { [weak self] _ in let settings = DemoController() settings.title = "设置" let navigation = DemoNavigationController(rootViewController: settings) navigation.modalPresentationStyle = .fullScreen self?.present(navigation, animated: true) }) } } override func viewDidLayoutSubviews() { super.viewDidLayoutSubviews() print("[DuoDemo] \(title ?? "") safe=\(view.safeAreaInsets) nav=\(navigationController?.navigationBar.frame ?? .zero) tab=\(tabBarController?.tabBar.frame ?? .zero)") } }
Replies
0
Boosts
2
Views
498
Activity
3w
Repeated App Review Rejections Despite Fixes — How Do We Get Specific Feedback?
Hi everyone, We're an independent development team preparing to launch our first iOS app and we've been stuck in the App Review process for over a month. We've received repeated rejections citing the same issues, even after making changes specifically intended to address Apple's feedback. Our biggest challenge isn't necessarily the rejection itself. We're happy to make whatever changes are required to comply with Apple's guidelines. The problem is that we're struggling to get clarification about what specifically remains noncompliant. We've responded through App Store Connect requesting additional details, but haven't received meaningful clarification. We've also contacted Apple Developer Support without getting a clear path toward resolution. We're now in a situation where we're submitting updated builds without knowing whether we're actually addressing the review team's concerns. My questions for developers who have experienced something similar: Has anyone successfully resolved repeated rejections where App Review continued citing the same guideline after fixes were implemented? Is there an effective way to request a conversation with an App Review representative or obtain more specific technical feedback? Are there any additional channels or approaches that have helped you break out of this cycle? We're not looking to bypass Apple's guidelines. We simply want to understand exactly what needs to change so we can get our app compliant and launched. Any advice or firsthand experience would be greatly appreciated. Thank you!
Replies
2
Boosts
0
Views
297
Activity
3w
Issues with AVRoutePickerView channel switching
We are developing a voice call application that uses AVRoutePickerView, allowing users to switch between an iPhone, a speaker, and Bluetooth earphones. However, we have encountered an intermittent issue: when switching from the speaker to Bluetooth earphones, the earphones remain in a loading state, and the audio channel subsequently switches back to the speaker. How can we resolve this issue? Here is the sample code: let session = AVAudioSession.sharedInstance() do { try session.setCategory(.playAndRecord, mode: .default, options: [.allowBluetooth]) try session.overrideOutputAudioPort(isBluetoothConnected ? .none : .speaker) try session.setPreferredSampleRate(48000) try session.setPreferredIOBufferDuration(0.02) try session.setActive(true, options: []) INFO(" >>> start: hasBluetooth=\(isBluetoothConnected), inputs: \(session.currentRoute.inputs.map { $0.portType }) outputs: \(session.currentRoute.outputs.map { $0.portType })") } catch { ERROR("(error.localizedDescription)") }
Replies
5
Boosts
0
Views
2.1k
Activity
4w
Toolbar background behaviour
Say i have a scrollview: I find it’s dumb how if you have the safe area inset or any kind of element below the toolbar, the background of those will extend to the top edge of the screen (by default), yet if the scrollview scrolls to the toolbar the toolbar background just “appears”, covering the existing background— its even worse cuz the toolbar background is there by default even when you didn’t set it in code. It seems more like a bug; I feel like this is something the SwiftUI team should improve upon. How about disabling toolbar background by default? Just wanted to get some more perspectives.
Replies
0
Boosts
0
Views
390
Activity
4w
App pending review for 8+ days with no feedback – Apple ID 6818113456
Hello Apple Review Team, I am contacting you regarding my application (Apple ID: 6818113456), which has been in “Pending Review” for more than 8 days without any updates. I have dedicated a lot of time and effort to developing this application, and I have also paid the $100 Apple Developer Program fee in order to publish it. During these days, I have tried contacting Apple Support by email and also by phone, but I have not received a response or been able to reach someone who could help me. According to the information provided by Apple, review times are normally expected to be around 24–48 hours. Therefore, I would kindly ask you to check the status of my application and let me know if there is any issue preventing the review from moving forward. I would greatly appreciate any help or update regarding the status of my application. I am available to provide any additional information or make any necessary changes. Thank you so much for your time and support. We look forward to hearing from you. Best regards
Replies
0
Boosts
0
Views
205
Activity
4w
iOS System Language does not change to Albanian or Macedonian
Hello, I’m trying to determine whether Albanian (sq) and Macedonian (mk) are supported as full system display languages on iOS. When I go to: Settings → General → Language & Region → iPhone Language Albanian and Macedonian are not available as system languages. However, both languages appear to have support in other parts of iOS. For example, Apple currently lists Albanian and Macedonian among the supported QuickType keyboard languages. 
https://www.apple.com/in/ios/feature-availability/?utm_source=chatgpt.com I have tested this behavior on: - iOS 16.7 - iOS 17.5 - iOS 26.6.1 - iOS 27.0.1 In all tested versions, I cannot change the iPhone system/display language to Albanian or Macedonian. I would like to clarify: 1. Are Albanian (sq) and Macedonian (mk) officially supported as iOS system/display languages? 2. If they are not supported, is there an official Apple documentation page listing the supported iOS system languages? 3. Is there any API or mechanism available to an app to determine whether a language is supported as a system UI language, as opposed to being supported only for keyboards or other language features? 4. Are there plans to add Albanian and Macedonian as full iOS system languages? I understand that app localization is separate from the iOS system language. Apple documentation explains that an app's localization is determined from the user's preferred languages and the localizations provided by the app. 
https://developer.apple.com/library/archive/qa/qa1828/_index.html?utm_source=chatgpt.com https://developer.apple.com/documentation/foundation/locale/preferredlanguages?changes=_11&utm_source=chatgpt.com I’m specifically asking about Apple's own iOS system UI, not localization of a third-party application. Expected: Selecting Albanian or Macedonian as the iPhone language should make the iOS system UI appear in that language, if the language is supported. Actual: Albanian and Macedonian cannot be selected as the iPhone's system/display language. Could someone from Apple confirm whether this is expected behavior and whether these languages are currently unsupported as full iOS system languages? Thank you.
Replies
3
Boosts
0
Views
311
Activity
4w
SwiftData: "backing data was detached from a context without resolving attribute faults" when deleting a model shown in a @Query driven list
A dashboard screen lists cameras from a @Query. Each row is a child view that holds the model instance: @Query(filter: #Predicate { $0.device?.isSelected == true }) private var cameras: [CameraModel] List { ForEach(cameras) { camera in CameraCellView(camera: camera) //holds let camera: CameraModel } } The row reads model attributes in its body (camera.name, camera.cameraType, camera.thumbnailData). It also has a 1-second timer that updates a "last snapshot" subtitle, so it redraws on its own. A settings screen is pushed on top of the dashboard in the same NavigationStack. It deletes a camera like this: camera.modelContext?.delete(camera) try? camera.modelContext?.save() Immediately after the delete, the app crashes in the dashboard row's body when it reads an attribute: Fatal error: This backing data was detached from a context without resolving attribute faults: PersistentIdentifier(...) - \CameraModel.cameraType This is not 100% reproducible. The whole error message is: Thread 1: Fatal error: This backing data was detached from a context without resolving attribute faults: PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(backing: SwiftData.PersistentIdentifier.PersistentIdentifierBacking.managedObjectID(0x8f8ff6c009fee652 x-coredata://65230C45-6F86-4B64-AEAB-6AAA9CB72D24/CameraModel/p16))) - \CameraModel.cameraType I understand this is due to a small gap where the SwiftUI view is rerendered before Query updates the view because of the deletion and the SwiftUI view points at a nonexistent SwiftData record. I'm just wondering what's a good way of avoiding that? SwiftData is used project-wide so this can potentially happen on nearly every view.
Replies
0
Boosts
0
Views
111
Activity
4w
Can CXCallObserver detect missed cellular calls while an iOS app is suspended?
Hello, I am developing an iPhone application to help users avoid missing important phone calls. The intended behavior is: A user receives a regular cellular call through the built-in iPhone Phone app. The user does not answer the call. Our application automatically detects the missed call. The application schedules repeated local notifications until the user acknowledges the missed call. The critical requirement is that detection must work while our application is in the background, without the user reopening it. Implementation We currently use CXCallObserver to observe cellular call events. When an incoming call ends without being connected, we classify it as a missed call and schedule notifications using UNUserNotificationCenter. Test environment Device: iPhone 17 iOS: 26.7.1 Distribution target: Standard App Store, Japan Testing: Physical device without an attached Xcode debugger Observed behavior Scenario A: Our application is visible immediately before the iPhone is locked. Missed calls have been detected and notifications scheduled after more than 30 to 60 minutes of device lock. Scenario B: Our application is moved to the background before the iPhone is locked, for example by returning to the Home Screen or opening Safari. Missed calls are not detected promptly, even after only a short period in the background. When the user subsequently opens our application, CXCallObserver callbacks may arrive and the earlier missed call is then detected. This defeats the purpose of the application because the user must reopen it to receive alerts. Questions Is CXCallObserver expected to deliver callbacks while its application is suspended, or only when the process is executing? Is there any supported public iOS API, extension, or background execution mechanism that allows a third-party application to detect missed calls from the built-in Phone app while the application is suspended or terminated? Can a regular cellular missed-call event wake or relaunch a third-party application? If CXCallObserver cannot support this use case, is there another Apple-supported solution available to ordinary App Store applications distributed in Japan? We are looking for an approach that does not require external hardware, carrier integration, private APIs, or unsupported background execution techniques. If this use case is not supported by the public iOS SDK, confirmation of that limitation would be very helpful. Thank you for your guidance.
Replies
1
Boosts
0
Views
304
Activity
Oct ’26
Issue with layoutMarginsGuide under iOS 26
Before I file a bug report I wanted to verify that I'm not missing something. If I setup a view controller in a navigation controller and I add a view with a constraint that lines it up with the view controller's view's layoutMarginsGuide (leadingAnchor or trailingAnchor), in several cases the view will not line up with buttons added in the navigation bar. Under iOS 18 everything lines up as expected. To demonstrate, create a new iOS project based on Swift/Storyboard. Setup the storyboard to show a UINavigationController with one UIViewController. Then in ViewController.swift (the one embedded in the navigation controller), use the following code: import UIKit class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .yellow title = "Layout Margins" let leftCancel = UIBarButtonItem(systemItem: .cancel) navigationItem.leftBarButtonItem = leftCancel let rightCancel = UIBarButtonItem(systemItem: .cancel) navigationItem.rightBarButtonItem = rightCancel let leftView = UIView() leftView.backgroundColor = .blue leftView.translatesAutoresizingMaskIntoConstraints = false self.view.addSubview(leftView) let rightView = UIView() rightView.backgroundColor = .red rightView.translatesAutoresizingMaskIntoConstraints = false self.view.addSubview(rightView) NSLayoutConstraint.activate([ leftView.widthAnchor.constraint(equalToConstant: 80), leftView.heightAnchor.constraint(equalToConstant: 80), leftView.leadingAnchor.constraint(equalTo: self.view.layoutMarginsGuide.leadingAnchor), leftView.topAnchor.constraint(equalTo: self.view.layoutMarginsGuide.topAnchor), rightView.widthAnchor.constraint(equalToConstant: 80), rightView.heightAnchor.constraint(equalToConstant: 80), rightView.trailingAnchor.constraint(equalTo: self.view.layoutMarginsGuide.trailingAnchor), rightView.topAnchor.constraint(equalTo: self.view.layoutMarginsGuide.topAnchor), ]) } } This adds a "Cancel" button to both ends of the navigation bar and it adds two little square views lined up with the leading and trailing layout margins. Here's the results: iPad running iPadOS 26 beta 3 (note the misalignment). This is really jarring when trying to align another glass button below the cancel button: iPad running iPadOS 18.5 (aligned just fine): iPhone in portrait running iOS 26 beta (aligned just fine): iPhone in landscape running iOS 26 beta (no alignment at all): iPhone in portrait running iOS 18.5 (aligned just fine): iPhone in landscape running iOS 18.5 (aligned just fine): Under iOS 26 on an iPhone (simulator at least) in portrait, the cancel buttons line up with the colored squares. That's good. In landscape, the colored squares have much larger margins as expected (due to the larger safe areas caused by the notch), but the cancel buttons in the navigation bar are not using the same margins. This one is debatable. Under iOS 18 the cancel buttons use larger margins to match the larger safe area. But I can see why under iOS 26 they changed this since the navigation bar doesn't interfere with the notch. But it's inconsistent. Under iOS 26 on an iPad (simulator at least), it's wrong in any orientation. Despite the lack of any notch or need for a larger safe area, the colored squares are indented just a bit more than the buttons in the navigation bar. I see no reason for this. Under iOS 18 everything lines up as expected. My real question at this point: Is the mismatched margins on an iPad under iOS 26 between the buttons in the navigation bar and other views added to the view controller a likely bug or am I missing something?
Replies
3
Boosts
0
Views
1.5k
Activity
Oct ’26
toolbarMinimizationBehavior(_:for:) crashes on some iOS 27.0.0 devices: "missing weak symbol" despite #available(iOS 27.0, *)
We are seeing a production crash that only affects devices reporting iOS 27.0.0. Devices on 27.0.1 and later, and on iOS 26, are unaffected. The app is built with Xcode 27.0 (the same binary shape appears with the Xcode 27.1 RC toolchain), deployment target iOS 26.0. The crashing code is a plain availability-gated call: extension View { @ViewBuilder func disableNavigationBarMinimization() -> some View { if #available(iOS 27.0, *) { toolbarMinimizationBehavior(.never, for: .navigationBar) } else { self } } } Crash report excerpt (addresses and app symbols removed): crash_info_entry_0: Failed to look up symbolic reference at <addr> - offset <n> - symbol <nearest stripped symbol> in <app binary> - pointer at <addr> is likely a reference to a missing weak symbol Crashed: com.apple.main-thread 0 libsystem_kernel.dylib __pthread_kill 2 libsystem_c.dylib abort 3 libswiftCore.dylib <redacted> 9 libswiftCore.dylib swift_getTypeByMangledName + 908 10 libswiftCore.dylib swift_getTypeByMangledNameInContext2 + 248 11 <app> __swift_instantiateConcreteTypeFromMangledNameV2 12 <app> specialized closure #1 in View.disableNavigationBarMinimization() 13 <app> closure #1 in SomeView.body.getter What we established: Because the deployment target is 26.0 and the API is @available(iOS 27.0, *), the app weak-imports both the function and its opaque result type descriptor. dyld_info -imports on the binary shows: _$s7SwiftUI4ViewPAAE27toolbarMinimizationBehavior_3forQrAA07ToolbareF0V_AA0H9PlacementVdtF [weak-import] (from SwiftUI) _$s7SwiftUI4ViewPAAE27toolbarMinimizationBehavior_3forQrAA07ToolbareF0V_AA0H9PlacementVdtFQOMQ [weak-import] (from SwiftUI) The call site has to instantiate the opaque return type's metadata before calling the function. That is the frame that aborts. So when dyld binds the descriptor to null, #available(iOS 27.0, *) passes and the process still dies. The symbol is present and exported on the iOS 27.0 build we can inspect locally (24A437, via Xcode's DeviceSupport symbols), and the same code runs fine on the iOS 27.0 simulator runtime (24A434). We cannot reproduce the crash on any device we own. The SwiftUI binary in 24A437 exports both toolbarMinimizeBehavior(_:for:) / ToolbarMinimizeBehavior and toolbarMinimizationBehavior(_:for:) / ToolbarMinimizationBehavior. The iOS 27.1 SDK only declares the latter, still annotated @available(iOS 27.0, *). This looks like a rename late in the 27.0 cycle. Our working theory is that some iOS 27.0.0 builds in the field (earlier 27.0 builds, possibly the ones preinstalled on new devices) predate the rename and only contain toolbarMinimizeBehavior, so the renamed symbol is absent and the weak import resolves to null. Questions: Is the @available(iOS 27.0, *) annotation on toolbarMinimizationBehavior(_:for:) accurate for every shipped 27.0.0 build? Should it be 27.0.1 or 27.1? Is there a supported way to guard against a missing opaque type descriptor at runtime, short of raising the availability check? Feedback filed as FB25095054.
Replies
0
Boosts
0
Views
263
Activity
Oct ’26
New submission stuck in review for 3 weeks, expedite or support ticket didn't help.
Submitted my third brand new on 15 Sep. Three weeks later it's still sitting in "Waiting for Review". Sent an expedite request on the 27th, heard nothing. By now the build in review is already pretty outdated, and I might have to wait another two weeks after sending the newer version. But I don't want to pull it and end up at the back of the queue. Anyone else seeing waits this long right now? And if it gets approved, does an update usually go through faster, or should I swap the build while I'm waiting?
Replies
1
Boosts
0
Views
236
Activity
Oct ’26