I currently have a iOS app live on the App Store but I also want to release it on Android, the whole code is in Swift so would that be possible or would I have to rewrite my whole apps code in a different coding language.

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.

今天上午开始TestFlight一直都是processing。

My app allows to save user-selected URLs in a list and browse them with a tap. A user reported that the app often shows that when browsing their saved entry for "On My iPad", it's apparently empty (it contains no files). I saved "On My iPad" in my own list some time ago and noticed that the same issue occurs. The URL seems to be correctly resolved from the saved bookmark data, but I noticed that url.startAccessingSecurityScopedResource() returns false. The other URL I saved some time ago is iCloud Drive, which I can access without issues. If I select "On My iPad" again in a file importer, create new bookmark data from it and resolve the URL from it, access works correctly. I create bookmark data like this: let data = try url.bookmarkData(includingResourceValuesForKeys: [.localizedNameKey, .pathKey, .volumeIsLocalKey]) and resolve URLs like this: let url = try URL(resolvingBookmarkData: data, bookmarkDataIsStale: &bookmarkDataIsStale) bookmarkDataIsStale is false for both the working and not working URLs for "On My iPad". The two bookmark data are different though, even if url.path is the same. What could be the issue?

I am seeing a regression with XCUIDevice.shared.appearance = .dark in UI tests that only affects xcodebuild, not Xcode’s UI test runner. Setup • UI tests written using XCTest • Dark mode forced in setUp() using: XCUIDevice.shared.appearance = .dark • Tests target an iOS simulator • Same test target, same scheme Expected behavior The app launches in Dark Mode for UI tests, as it did previously. Actual behavior • When running UI tests from Xcode (Product > Test), Dark Mode is applied correctly. • When running the same UI tests via xcodebuild test, Dark Mode is ignored and the app launches in Light Mode. • No test failures, no warnings, no logs indicating the appearance override was skipped. Regression details • This used to work on older iOS versions when running via xcodebuild. • The regression appears after updating iOS simulators (exact version boundary still unclear). • No relevant changes were made to the test code, scheme, or CI configuration. • xcodebuild otherwise launches and runs UI tests normally. Notes • The issue is specific to XCUIDevice.shared.appearance. • Other UI test functionality behaves as expected. • This makes CI results inconsistent with local Xcode runs and breaks visual assumptions in snapshot and layout-based tests. Question Is this a known regression or an intentional behavior change in recent iOS / Xcode versions? If intentional, what is the supported way to reliably force Dark Mode in UI tests when running via xcodebuild? This currently makes xcodebuild-based CI UI testing unreliable compared to Xcode’s test runner.

Introduction: I’m encountering a consistent crash in production on iOS 26.2 (build 23C55). The crash occurs deep within libicucore when calling [NSDateFormatter dateFromString:]. Crash Summary: Exception Type: SIGSEGV (SEGV_ACCERR) Fault Address: 0xffffffff Thread: Crashed on Main Thread (Thread 0) Library: libicucore.A.dylib Code Snippet: The crash is triggered by the following method. It converts a string to an NSDate using a specific format and locale: // 获取日期date - (NSDate *)getDateWithTime:(NSString *)time formatter:(NSString *)formatterStr { NSDateFormatter *formatter = [[NSDateFormatter alloc] init]; [formatter setDateFormat:formatterStr]; formatter.timeZone = [NSTimeZone timeZoneWithName:@"Asia/Shanghai"]; formatter.locale = [[NSLocale alloc] initWithLocaleIdentifier:@"en_US_POSIX"]; return [formatter dateFromString:time]; } Backtrace: Here is the relevant part of the crash report: Incident Identifier: E24485B6-C53E-4115-A6CF-A7E4A952AD50 CrashReporter Key: 21FAC1CF-F56B-409A-98AA-351D3D2EB06C Hardware Model: iPhone18,2 Code Type: ARM-64 Parent Process: [1] Date/Time: 2026-01-12T01:32:25Z OS Version: iPhone OS 26.2 (23C55) Report Version: 105 SDK Version: 0.0.4 Exception Type: SIGSEGV Exception Codes: SEGV_ACCERR at 0xffffffff Crashed Thread: 0 Thread 0 Crashed: 0 libicucore.A.dylib 0x000000019b81def8 0x19b74a000 + 868088 1 libicucore.A.dylib 0x000000019b7da91c 0x19b74a000 + 592156 2 libicucore.A.dylib 0x000000019b8d8340 0x19b74a000 + 1631040 3 libicucore.A.dylib 0x000000019b8eae18 0x19b74a000 + 1707544 4 libicucore.A.dylib 0x000000019b8eb600 0x19b74a000 + 1709568 5 libicucore.A.dylib 0x000000019b878be4 0x19b74a000 + 1240036 6 libicucore.A.dylib 0x000000019b87ae84 0x19b74a000 + 1248900 7 libicucore.A.dylib 0x000000019b87b2dc 0x19b74a000 + 1250012 8 libicucore.A.dylib 0x000000019b9564ac 0x19b74a000 + 2147500 9 libicucore.A.dylib 0x000000019b954afc 0x19b74a000 + 2140924 10 libicucore.A.dylib 0x000000019b952794 0x19b74a000 + 2131860 11 libicucore.A.dylib 0x000000019b98689c 0x19b74a000 + 2345116 12 CoreFoundation 0x00000001895dbfe0 0x18953d000 + 651232 13 CoreFoundation 0x00000001895dbaa0 0x18953d000 + 649888 14 Foundation 0x0000000186d2029c 0x186b88000 + 1671836 15 Foundation 0x00000001874a62dc 0x186b88000 + 9560796 16 Foundation 0x00000001874a6384 0x186b88000 + 9560964 17 xxxx 0x0000000105ea6e30 -[xxxxx getDateWithTime:formatter:] + 168 and Thread 0 crashed with ARM-64 Thread State: pc: 0x000000019b81def8 fp: 0x000000016f96bc10 sp: 0x000000016f96bbd0 x0: 0x00000000ffffffff x1: 0x000000019ba1e8e0 x2: 0x0000000000000002 x3: 0x000000000000000b x4: 0x0000000000000074 x5: 0x0000000000000069 x6: 0x0000000000000000 x7: 0xfffff0003ffff800 x8: 0x000000009ba18014 x9: 0x00000001148dffd0 x10: 0x0000000000000002 x11: 0x0000000000000004 x12: 0x0000000000000220 x13: 0x0000000000000030 x14: 0x000000015b6f36b8 x15: 0x000000015cfe0000 x16: 0x00000002a19d0ff0 x17: 0x00000001f5590a70 x18: 0x0000000000000000 x19: 0x000000016f96bc30 x20: 0x0000000000000000 x21: 0x000000015cfe3200 x22: 0x000000019ba18014 x23: 0x0000000000000000 x24: 0x000000015cfe32a0 x25: 0x0000000000000003 x26: 0x0000000000000000 x27: 0x0000000000000000 x28: 0x000000015cfe3200 lr: 0x000000019b7da958 cpsr: 0x00000000a0000000

Hello, I have an iOS camera app that captures exposure brackets and performs custom HDR processing. On iOS 26, I’m observing a visual difference between: a single photo captured at –2 EV, and the –2 EV frame from an exposure bracket (–2 / 0 / +2 EV). On iOS 26: The single –2 EV image looks natural and consistent. The –2 EV image from the bracket appears clamped / distorted, most noticeably in high dynamic range scenes (highlight compression and loss of detail). On iOS 18, both approaches produce visually identical and correct –2 EV images. The issue only appears for bracketed captures on iOS 26. Attachments (examples) iOS 26 Single capture –2 EV (JPEG): /Users/danilobudimir/Downloads/ios26SingleImage/JPEG image-4006-8B77-51-0.jpeg Single capture –2 EV — Capture report (dumped settings): /Users/danilobudimir/Downloads/ios26SingleImage/UnderExposureDebug_CaptureReport_2026-01-09T15-59-20Z.md Bracket capture –2 EV frame (JPEG): /Users/danilobudimir/Downloads/bracket_iOS26/JPEG image-45CE-9793-A5-0.jpeg Bracket capture — Capture report (dumped settings): /Users/danilobudimir/Downloads/bracket_iOS26/UnderExposureDebug_CaptureReport_2026-01-09T15-55-42Z.md iOS 18 Single capture –2 EV (JPEG): /Users/danilobudimir/Downloads/ios18SingleImage/JPEG image-47FD-AF73-28-0.jpeg Single capture –2 EV — Capture report: /Users/danilobudimir/Downloads/ios18SingleImage/UnderExposureDebug_CaptureReport_2026-01-09T16-25-27Z.md Bracket capture — –2 EV frame (JPEG): /Users/danilobudimir/Downloads/bracket_iOS18/JPEG image-4A4C-9E93-46-0.jpeg Bracket capture — Capture report: /Users/danilobudimir/Downloads/bracket_iOS18/UnderExposureDebug_CaptureReport_2026-01-09T16-27-23Z.md Question Is there any new behavior in iOS 26 AVFoundation related to: AVCapturePhotoBracketSettings, tone mapping / HDR preprocessing, or internal image processing applied specifically to bracketed frames? Is there a new flag, format requirement or opt-out mechanism required to preserve linear underexposed frames in exposure brackets?

Hello All, I come to ask a question that I haven't been able to find the docs. I continue to work on implementing declarative management and while working there is a question/concern I have. I have noticed that during some destructive testing, if the device is attempting to fetch a configuration and the server responds with a 503 (or any server related error) then the device will wipe all configurations and attempt to reapply them. Is there any way to prevent this by intercepting status codes or would the only real solution be to force down a temp/test config if the real config can't be fetched from the server?

Hi, I'm experiencing an issue with my app. I use Firebase as my server, and it is great. Still, there is one issue: when I send push notifications from my app to users, the users will get the notification if the app is open, but not when it is closed. I have tried many solutions to fix it, even asking AI, but the issue is still there. I would be happy to give you access to Firebase and the Xcode workspace, as I have no clue how to fix it.

Dear Apple Customer Support, I’m developing a new Swift iPadOS app and I want the app to run in landscape only (portrait disabled). In Xcode, under Target > General > Deployment Info > Device Orientation, if I select only Landscape Left and Landscape Right, the app builds successfully, but during upload/validation I receive this message and the upload is blocked: “Update the Info.plist: Support for all orientations will soon be required.” Could you please advise what the correct/recommended way is to keep an iPad app locked to landscape only while complying with the current App Store upload requirements? Is there a specific Info.plist configuration (e.g., UISupportedInterfaceOrientations~ipad) or another setting that should be used? Thank you,

Hi, We recently updated our app icon, but the push notification icon has not been updated on some devices. It still shows the old icon on: • iPhone 16 Pro — iOS 26 • iPhone 14 — iOS 26 • iPad Pro 11” (M4) — iOS 18.6.2 • iPhone 16 Plus — iOS 18.5 After restarting these devices, the push notification icon is refreshed and displays the new version correctly. Could you advise how we can ensure the push notification icon updates properly on all affected devices without requiring users to restart? Thank you.

When I call this method on a thread that isn`t thread. And chose main thread check on target, The Console show the world : Main Thread Checker: UI API called on a background thread: -[UIApplication canOpenURL:] PID: 8818, TID: 10191278, Thread name: (none), Queue name: com.myqueue.canopen, QoS: 0 Backtrace: 4 TestDemo 0x0000000102f6c068 __39-[AppTools isExists:]_block_invoke_3 + 892 5 CoreFoundation 0x000000019e22995c 7519E999-1053-3367-B9D5-8844F6D3BDC6 + 1042780 6 CoreFoundation 0x000000019e12ec98 7519E999-1053-3367-B9D5-8844F6D3BDC6 + 15512 7 TestDemo 0x0000000102f6bba0 __39-[AppTools isExists:]_block_invoke_2 + 424 8 libdispatch.dylib 0x0000000103a4d7fc _dispatch_call_block_and_release + 24 9 libdispatch.dylib 0x0000000103a4ebd8 _dispatch_client_callout + 16 10 libdispatch.dylib 0x0000000103a55b48 _dispatch_lane_serial_drain + 744 11 libdispatch.dylib 0x0000000103a566e4 _dispatch_lane_invoke + 448 12 libdispatch.dylib 0x0000000103a61adc _dispatch_workloop_worker_thread + 1324 13 libsystem_pthread.dylib 0x000000019df72b88 _pthread_wqthread + 276 14 libsystem_pthread.dylib 0x000000019df75760 start_wqthread + 8

I'm working on the control widget which should display the SF image on the UI, but I have found that it cannot be displayed stably. I have three ExampleControlWidget which is about the type egA egB and egC, it should all be showed but now they only show the text and placeholder. I'm aware of the images should be SF image and I can see them to show perfectly sometimes, but in other time it is just failed. This's really confused me, can anyone help me out? public enum ControlWidgetType: Sendable { case egA case egB case egC public var imageName: String { switch self { case .egA: return "egA" case .egB: return "egB" case .egC: return "egC" } } } struct ExampleControlWidget: ControlWidget { var body: some ControlWidgetConfiguration { AppIntentControlConfiguration( kind: kind, provider: Provider() ) { example in ControlWidgetToggle( example.name, isOn: example.state.isOn, action: ExampleControlWidgetIntent(id: example.id), valueLabel: { isOn in ExampleControlWidgetView( statusText: isOn ? Localization.on.text : Localization.off.text, bundle: bundle, widgetType: .egA //or .egB .egC ) .symbolEffect(.pulse) } ) .disabled(example.state.isDisabled) } .promptsForUserConfiguration() } } public struct ExampleControlWidgetView: View { private let statusText: String private let bundle: Bundle private var widgetType: ControlWidgetType = .egA public init(statusText: String, bundle: Bundle, widgetType: ControlWidgetType) { self.statusText = statusText self.bundle = bundle self.widgetType = widgetType } public var body: some View { Label( statusText, image: .init( name: widgetType.imageName, // the SF Symbol image id bundled in the Widget extension bundle: bundle ) ) } } This is the normal display: These are the display that do not show properly: The results has no rules at all, I have tried to completely uninstall the APP and reinstall but the result is same.

i export apple SF as custom sf for test. code is simple: var body: some ControlWidgetConfiguration { StaticControlConfiguration( kind:"ControlWidgetConfiguration" ) { ControlWidgetButton(action: DynamicWidgetIntent()) { Text("test") Image("custom_like") } }.displayName("test") } as we can see, it can't show image in the preview. but it can show image in the Control widget center. am i do some thing wrong?

On iOS 18 and lower version, my application supports automatically switching to [System settings - Personal Hotspot] directly. But on iOS 26, my application will be redirected to [System settings- Apps]. Does iOS 26 disable the behavior of directly jumping to the system hotspot page? If support, could you share the API for iOS 26?

Project Background： I am developing a third-party custom keyboard for iOS whose primary feature is real-time voice input. In my current design, responsibilities are split as follows: 1. The container (main) app is responsible for: Audio recording Speech recognition (ASR) 2. The keyboard extension is responsible for: Providing the keyboard UI Initiating the voice input workflow Receiving transcription results via an App Group Inserting recognized text into the active text field using textDocumentProxy.insertText(_:) Intended User Flow The intended workflow is: The user is typing in a third-party app (for example, WeChat) using my custom keyboard. The user taps a “Voice Input” button in the keyboard extension. The keyboard extension activates the container app so that audio recording and ASR can begin. After recording has started, control returns to the original app where the user was typing. The container app continues running in the background, maintaining active audio recording and ASR. Recognized text is continuously streamed back to the keyboard extension and inserted into the current cursor position in real time. Observed Industry Behavior Some popular third-party keyboards on iOS, such as WeChat Keyboard and Doubao Keyboard, appear to provide a similar user experience in which: Voice input can be initiated directly from the keyboard while typing in another app. The user remains (or returns) in the original typing context after voice input starts. Speech recognition continues and text is streamed into the active text field without interrupting the typing experience. I would like to better understand how this type of workflow aligns with iOS platform capabilities and supported APIs. My Questions Is it supported by iOS public APIs for a custom keyboard extension to activate its container app to start audio recording and ASR, then return to the original host app while the container app continues recording and performing ASR in the background? If this workflow is not supported, are there any Apple-recommended or supported alternative architectures for achieving a similar user experience, especially when audio recording and ASR logic are currently implemented in the container app rather than in the keyboard extension? Goal My goal is to design a solution that is fully compliant with iOS public APIs and platform constraints, while providing a real-time voice input experience comparable to existing third-party keyboards on the platform. Any guidance on supported APIs, recommended architectures, or relevant documentation would be greatly appreciated.

If there is this situation: A text message is sent from a sender and gets classified as junk (by a text filtering extension) with the result that it gets send to the spam folder as expected. A text message with different content is sent from the same sender and gets classified as allowed, however it also gets sent to the spam folder. If the above is repeated but after step 1 the message is deleted, then in step 2 the message doesn't get sent to the spam folder. So the presence of the message from step 1 being in the spam folder is having an effect on the behavior of step 2. Expected beahavour (if so, why?), or a defect?

The clock on the lock screen is too big. This is very noticeable on the serif font, the maximum size goes beyond the frame, and rests on the frame of the phone display. (Screenshot 1 & Screenshot 3) This is especially evident if you use the enlarged interface (using the Large Text function), here the time goes completely out of the frame and conflicts with the frame of the phone screen. (Screenshot 2 & Screenshot 4)

Has anyone else run across this after manually renewing an expired developer account? Happens when I go to the "Certificates, Identifiers, & Profiles" page and click on anything. Also unable to download any of the iOS SDK's. Any ideas?

Hello, Our iOS app (Flutter + Swift) was rejected under Guideline 2.5.1 with the following message: The app uses or references the following non-public or deprecated APIs: Runner Classes: __SwiftValue From our investigation, __SwiftValue appears to be an internal Swift runtime class automatically generated by the Swift compiler for Swift–Objective-C bridging. It is not imported, referenced, or used directly in our source code. We verified that: The symbol exists only in the compiled Runner binary It is not referenced by any third-party framework explicitly It appears in standard Swift runtime behavior We previously removed a legitimate private API (PGHostedWindow) from a dependency and resubmitted, after which this new rejection appeared. Questions: Is __SwiftValue considered a private API usage by App Review, or is this a false positive? Are there recommended build settings or mitigations to prevent this symbol from being flagged? Should this be escalated for manual review? Any guidance from Apple engineers or developers who encountered similar rejections would be greatly appreciated. Thank you.