What's the best practices to adopt iPhone Duo for a production UIKit app? What few things we need to consider during the development? "As long as we use auto layout, it should be fine" is this correct term for iPhone Duo? Meaning, as long as our app use proper auto layout, our app should be able to support iPhone Duo properly.

I have an App where I use the UISheetPresentationController to present a menu as a "drawer" (like the "FindMy" or "Maps") App. Because the sheet is presented over a map, I made the sheet semi-transparent/blurry, so the Map shines through, which looks nice. The sheet is using a UITableView with the "insetGroup" style, so the table cells have the nice rounded borders and there are margins to the sheet borders. When running the App on the iPhone Duo (Simulator) on the outer display, the tableView does no longer respect the "insetGroup" style, it is rendered like it would have the "plain" style, which destroys everything that look good. No rounded borders, no margins. However if I opt-out of the automatic "vertical toolbar behavior" (overriding preferredVerticalBarBehavior so it returns "disabled"), then everything looks great again, however then the sheet content might overlap with the sidebar icons and camera because it now covers the whole area up to the right screen border. Is this supposed to be this way (if yes, why?), is there a way to fix this, or do we have to wait for a bugfix within iOS 27.1? The tableview still claims to have the "insetGrouped" style, just it does not render this way. I did not see any similar issues under other circumstances. Only UISheetPresentationController seems to be affected by this. Is there a way to correctly detect if the App is running on an iPhone Duo, so we could use this detection to add workarounds for such issues?

Hello, I am investigating a recurring crash that appears to be originating within the system's network stack. OS Version: iPhone OS 26.1 (23B85) Role: Foreground Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000 Exception Codes: 0x0000000000000001, 0x0000000000000000 Triggered by Thread: 19 Description: The crash is triggered by Thread 19 and occurs deep within libquic.dylib during a QUIC recovery timer event. Based on the backtrace, the failure happens in quic_recovery_pto. The issue seems to occur when a protocol instance schedules a wakeup, leading to a null pointer dereference in the system library. Crashed Thread Backtrace snippet:Thread 19 Crashed: Thread 19 Crashed: 0 libquic.dylib 0x00000001a00a38cc quic_recovery_pto + 72 (quic_recovery.c:1259) 1 libquic.dylib 0x00000001a00a3390 quic_recovery_timer_fired + 132 (quic_recovery.c:1460) 2 libquic.dylib 0x00000001a00a1f8c quic_timer_run + 248 (quic_timer.c:210) 3 Network 0x000000018ec76cbc __nw_protocol_instance_schedule_wakeup_block_invoke + 76 (protocol_implementation.cpp:5847) 4 Network 0x000000018eba34e0 __nw_context_reset_timer_block_with_time_block_invoke + 268 (context.cpp:2224) 5 libdispatch.dylib 0x00000001c84727ec _dispatch_client_callout + 16 (client_callout.mm:85) 6 libdispatch.dylib 0x00000001c845d664 _dispatch_continuation_pop + 596 (queue.c:349) 7 libdispatch.dylib 0x00000001c8470528 _dispatch_source_latch_and_call + 396 (source.c:601) 8 libdispatch.dylib 0x00000001c846f1fc _dispatch_source_invoke + 844 (source.c:966) 9 libdispatch.dylib 0x00000001c8463288 _dispatch_workloop_invoke + 1612 (queue.c:4761) 10 libdispatch.dylib 0x00000001c846c3ec _dispatch_root_queue_drain_deferred_wlh + 292 (queue.c:7265) 11 libdispatch.dylib 0x00000001c846bce4 _dispatch_workloop_worker_thread + 692 (queue.c:6859) 12 libsystem_pthread.dylib 0x00000001ec0623b8 _pthread_wqthread + 292 (pthread.c:2696) 13 libsystem_pthread.dylib 0x00000001ec0618c0 start_wqthread + 8 (:-1) Can anyone provide insights into what might be causing libquic to access an invalid address in this context? Any help or suggestions for further diagnostics would be greatly appreciated.

Saving any CKQuerySubscription to the private database fails in the Production environment with CKError 12 (badRequest): “attempting to create a subscription in a production container”. The same subscriptions save fine in Development. The schema, including the needed QUERYABLE index, has been deployed to Production. This looks like the same issue as FB22867235 and Developer Forums thread 826814. Container: iCloud.com.darkstardev.chorecalendar Environment: Production (TestFlight build 0.2 (5)) Device / OS: iPhone18,2, iOS 27.0.1 App: Core Data with NSPersistentCloudKitContainer (private and shared stores), sharing a zone with CKShare Database: privateCloudDatabase of the share owner’s account Zone: the Core Data share zone, com.apple.coredata.cloudkit.share.7653A214-0824-4D0D-BC02-4270E0826376 Subscription: CKQuerySubscription on recordType CD_Mark predicate CD_status == "waiting" options .firesOnRecordCreation and .firesOnRecordUpdate zoneID set to the share zone Schema: CD_Mark has a QUERYABLE index on CD_status in Production, which I verified in the CloudKit Console. All three notificationInfo variants fail the same way in Production. All three succeed in Development: An alert with titleLocalizationKey, alertLocalizationKey and alertLocalizationArgs ["CD_kidName", "CD_choreName"] A plain alert with titleLocalizationKey and alertLocalizationKey, without args A silent subscription with shouldSendContentAvailable = true and desiredKeys Because even the silent subscription is refused, the cause isn’t the alert configuration. Production refuses CKQuerySubscription creation for this container. Steps to reproduce: Install the TestFlight build, signed in as the share owner. Create and share a family record through NSPersistentCloudKitContainer. Turn on the in-app setting that saves the subscription. Expected: the subscription is saved, and a push arrives when a participant creates or updates a waiting CD_Mark record. Actual: all three saves fail. Error text: “Error saving record subscription with id check-ins-com.apple.coredata.cloudkit.share.7653A214-0824-4D0D-BC02-4270E0826376 to server: attempting to create a subscription in a production container” (CKError 12). Already tried: Deploying the schema from Development to Production. Turning the setting off and on again a day later.

The Problem On opening a PDF document in the Preview app, PDF widget annotations appear pixelated/rasterized. This problem exists with button, text, and choice widget subtypes. The pixelation becomes more apparent when zoomed in. Expected Results PDF widgets should appear sharp and smooth, without pixelation. In previous versions of the Preview app, widgets appear vector-based as expected. Impact on User Experience PDF widgets appear pixelated and inconsistent with text content in the same PDF document. Widgets do not look like elements of an interactive form but, instead, resemble low-quality embedded images. Affected Apps/OSs: Preview 11.0 (1147), as well as other apps that use PDFKit, on macOS Golden Gate 27.0 (26A428). A similar problem appears to affect PDFKit on iOS 27.0 and iPadOS 27.0 as well. Feedback/bug report: FB24843022

Updated my iOS apps for the Duo, partially rewriting the interface to better match the Duo and I am a bit puzzled - lets say it this way - that AppStore doesn't show the submitted Duo Screenshots nor the announced ">ready for Duo" badge. Am i the only one - or did I miss something or is it still not rolled out?

The Problem When a user toggles radio buttons or checkboxes in a PDF using Preview, the widgets disappear following subsequent interactions after the file is saved and reopened. This renders the form fields unusable. Steps to Reproduce the Problem Open a PDF with radio buttons or checkboxes in Preview. Toggle a radio button or checkbox. Save and close the file. Re-open the PDF in Preview. Toggle the same button again. The button (and any others with the same field name) will disappear. Expected Results Toggling a radio button or checkbox should update the field value without causing the button (or related buttons) to disappear. This behavior is consistent with previous versions of PDFKit. What is Happening In Preview, interacting with radio buttons and checkboxes correctly updates their appearance as expected. Saving the PDF, however, causes the appearance dictionary to reference a new N entry that is a single appearance stream unassociated with any state. The annotation's AS entry is not updated. The original N entry remains but is no longer referenced. Subsequent interactions fail to update the visual presentation because the appearance stream is missing. Impact on User Experience Radio buttons and checkboxes may disappear and become unusable when toggled. PDF documents become irreparably altered after a button is toggled and the file is saved. PDF file size significantly increases when the file is saved. Users may believe they have successfully completed a form, only for the data to become inaccessible or invisible to recipients. Forms may need to be completely restarted or recreated from scratch if the original becomes unusable. The corrupted PDF structure might cause the file to render incorrectly or crash in third-party PDF viewers. Affected Apps/OSs Tested with Preview 11.0 (1147), as well as other apps that use PDFKit, on macOS Golden Gate 27.0 (26A428). This problem also affects PDFKit on iOS 27.0 and iPadOS 27.0. Feedback/bug report: FB24866826 Related Sample Output Original PDF File Checkbox widget annotation (6 0 obj), its appearance dictionary (17 0 obj), and normal appearance dictionary (18 0 obj). Button is not checked. 6 0 obj << /Border [ 0 0 0 ] /Rect [ 90 390 110 410 ] /T (button1) /F 4 /Subtype /Widget /DA (/.AppleSystemUIFont 13 Tf 0 g) /MK 16 0 R /C [ 0 ] /AP 17 0 R /V /Off /M (D:20260919225320Z00'00') /AS /Off /FT /Btn /Type /Annot /Ff 0 >> endobj 17 0 obj << /N 18 0 R >> endobj 18 0 obj << /Yes 20 0 R /Off 22 0 R >> endobj PDF File after Save Checkbox widget annotation object (6 0 obj), its new appearance dictionary object (8 0 obj), a new normal appearance stream object (20 0 obj), and the original appearance stream dictionary (now 21 0 obj). File saved after user checked button. 6 0 obj << /Ff 0 /Type /Annot /AS /Off /AP 8 0 R /MK 9 0 R /C [ 0 ] /FT /Btn /M (D:20260919225320Z00'00') /DA (/.AppleSystemUIFont 13 Tf 0 g) /Subtype /Widget /F 4 /Border [ 0 0 0 ] /Rect [ 90 390 110 410 ] /T (button1) /V (Yes) >> endobj 8 0 obj << /N 20 0 R >> endobj 20 0 obj << /Filter /FlateDecode /Resources << /ColorSpace << /CS1 [ /ICCBased 29 0 R ] /CS2 [ /ICCBased 30 0 R ] >> >> /BBox [ 0 0 20 20 ] /Type /XObject /Subtype /Form /Length 123 >> stream x UéA ¬0 Ô}≈|†≈nà¢úÛÇ* —SA =}Ïr(»ñµ≤w◊€YËà’|ÙÎŒç'óRï∂#SäÏÌü∞¢S‰Ì§ôRÌX }–É•åY Éçˆ BŒ H " *â´8™ˆZø6z⁄ÿ ”ú6ɀ੠"∫t˘‹;'¬ endstream endobj 21 0 obj << /Off 22 0 R /Yes 23 0 R >> endobj Note: No object references 21 0 obj in the PDF.

Our app's first version (1.0.0) was submitted on October 1 and has been in "Waiting for Review" ever since, with no change in status and no messages in App Store Connect. What we've done so far: Confirmed that all agreements are active and there are no pending action items in App Store Connect Sent a status inquiry through Contact Us on October 15. A case was opened, but there's been no reply. Tried to reach Developer Support by phone, but couldn't get through because call volume was too high. It's a free app for a local church congregation. If something on our side is blocking the review, we'd be glad to fix it. Could someone from App Review take a look, or tell us whether the submission needs to resubmitted? We also have a newer version (1.3.x) ready on TestFlight. If it would help, we're happy to replace the submitted build with it. Should we keep 1.0.0 in the queue or resubmit with the newer build? App: New York Chinese SDA Church (Apple ID 6816789535), version 1.0.0. Status inquiry case: 102997976922

Feedback ID: FB24937933 I’m seeing a persistent launch failure across multiple unrelated apps on an iPhone 15 Pro Max. Affected apps include Telegram, Box, LinkedIn, Amazon, Apple Podcasts, Shazam, and others. The behavior is consistent: I launch the app. The app stays on a black or frozen launch screen. After approximately 19–20 seconds, iOS terminates the app. Retrying may occasionally work temporarily, but the problem returns. Crash reports from multiple unrelated apps show essentially the same termination: EXC_CRASH / SIGKILL 0x8BADF00D scene-create watchdog transgression More importantly, the main thread repeatedly shows this pattern: xpc_connection_send_message_with_reply_sync NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY -[__NSURLBackgroundSession setupBackgroundSession] -[__NSURLBackgroundSession initWithConfiguration:delegate:delegateQueue:delegateDispatchQueue:] This appears to indicate that the app’s main thread is synchronously waiting for an XPC-backed system service while creating a background NSURLSession, and the response does not arrive before the scene-create watchdog timeout. I first reproduced this on iOS 26.6.2 and the problem still occurs after updating to iOS 27.0 (24A437). Troubleshooting already performed: • Force restart • Network Settings Reset • Background App Refresh disabled • VPN/proxy disabled • Affected apps deleted and reinstalled • iOS updated from 26.6.2 to 27.0 Because the same stack pattern is occurring across multiple unrelated third-party apps, as well as Apple apps such as Podcasts and Shazam, this does not appear to be isolated to a single application. Apple Support has also told me that similar cases have been reported and that the issue may be addressed in a future software update. Has anyone seen a system-level NSURLBackgroundSession / XPC service enter this kind of stuck state across multiple applications? Is there a known issue involving the background URLSession service or related networking daemon that could cause synchronous XPC calls during app launch to block until the watchdog terminates the process? I have submitted the full crash reports through Feedback Assistant under FB24937933.

I submitted my app for review on October 13, and it has been waiting for review ever since. I have already requested an expedited review and contacted Apple Developer Support, but nothing has changed and I have not heard back yet. I worked really hard to build the app and this wait is very discouraging. Please someone help! Submission ID is: 4356e8f3-612d-4faa-b871-ff1c9fef6bdf App ID: 6799765037

Since iOS 27.0, domain-bound SMS one-time codes are no longer offered above the keyboard in our app, where the code is entered on a web page in a WKWebView, although the app is associated with the domain through webcredentials. The same SMS is offered in Safari on the same device, and it is offered in our app on iOS 26.6 and iOS 18. SMS format (last line per the domain-bound code format): Your verification code is: 123456 @app.example.com #123456Setup Several builds of the same app with different bundle IDs (App Store, internal, development), all under one team Entitlement com.apple.developer.associated-domains: webcredentials:app.example.com (plus two more environments of the same domain) AASA at https://app.example.com/.well-known/apple-app-site-association: 200, application/json, no redirect, same content on app-site-association.cdn-apple.com: {"webcredentials":{"apps":["TEAMID.com.example.app","TEAMID.com.example.app.internal","TEAMID.com.example.app.dev"]}} The code field is an <input type="tel" autocomplete="one-time-code"> in a WKWebView showing a page on that domain. We also tested a native field with the one-time-code content type (the app is built with Flutter; the field is a Flutter TextField with the one-time-code autofill hint). Steps Open the verification page in the app and focus the code field. Receive the SMS above. Expected: the code is offered in the QuickType bar, as it is in Safari on the same domain and as it is in our app on iOS 26.6 and iOS 18. Actual: nothing is offered. The keyboard log: kbd Received verification code from Messages kbd One Time Code field has been entered. kbd Retrieving Current One-Time Codes for App kbd Current verification code is domain-bound to <mask.hash: '…'>. kbd Domain-bound verification code is NOT valid for app <mask.hash: 'X'>. E kbd Could not fetch application record for application identifier: <mask.hash: 'X'>. kbd Returning 0 available one-time codesWhat we checked swcd downloads the AASA for all domains without errors after a reinstall. The installed app's entitlements (read from the device) contain the expected application-identifier and associated domains; the profile is validated. The failure is the same in the WKWebView field and in a native one-time-code field, in the App Store build, a distribution-signed internal build and a development build, and in an older app version that used to work. The masked application identifier in the log (X above) is the same for two builds with different bundle IDs, so the lookup does not seem to use the app's bundle ID. All our builds share CFBundleExecutable = Runner (the Flutter default) and the same CFBundleName. The same app build and the same SMS work on iOS 26.6 and iOS 18.x, so the change happened between iOS 26.6 and 27.0. An SMS without the @domain #code line is offered in the app on iOS 27 (Returning 1 available one-time code), although Could not fetch application record is still logged. Questions Is this a known iOS 27 regression, or is there a new requirement for apps to receive domain-bound codes? What application identifier does the keyboard use for this lookup, and can anything in the app's configuration (for example the executable name) affect it? Device: iPhone 17 Pro Max, iOS 27.0

Hey Apple Developer Relations, App Review Team, and anyone else reading this,I wanted to share what’s been going on with my app because I’m honestly stuck and not sure what else to do.I’m an indie developer working on Marque: Car Collection — my first iOS app. I paid for the Developer Program, spent a lot of time getting everything ready, fixed the issues from the previous rejection, and submitted a new build.It’s been over a week now and I still have no idea what’s happening with it.Quick timeline: Oct 6: My previous submission got rejected under Guideline 5.1.2(i) (App Tracking Transparency). Oct 14: I submitted a fixed build, version 1.1.0 (24), with an updated ATT implementation, revised App Privacy details, and detailed notes explaining the changes. Since then (11 days as of Oct 25): It’s been sitting in “Waiting for Review” and hasn’t even moved to “In Review.” I’ve contacted Developer Support and asked on the forums, but I haven’t gotten any real answers. No one has asked for more information, explained what’s going on, or given me any idea when the review might actually start.I get that reviews can take longer sometimes, especially with a first app, subscriptions, or privacy-related stuff. I’m not asking anyone to just approve it without looking at it.What bothers me is the complete lack of communication. Right now I have no way of knowing: whether my build is just waiting in the normal queue or if something’s wrong with it when I can realistically plan a launch if there’s any point in contacting support again since I haven’t gotten a useful response so far I’m still paying for the Developer Program, but I have zero visibility into what’s happening with my submission.Apple holds developers to high standards. It would be nice to get at least basic transparency in return.So I have a few straightforward questions: Why has my corrected build been stuck in “Waiting for Review” for 11 days? Is there any way to confirm it’s properly in the queue and not stuck because of some technical or admin issue? Why hasn’t my support request gotten a real response? Is there an escalation path for indie developers when a submission just sits there with no explanation? If Apple can’t provide a status update, what options do developers have when they’re paying for the program but can’t get any information about their release? I’d really appreciate it if someone from Developer Relations or App Review could take a look and give me some kind of explanation (or point me to someone who can).I’d also be interested to hear from other developers who’ve dealt with similar long waits in “Waiting for Review,” especially with first apps.The issue isn’t just that the review is taking longer than expected. It’s that when something seems off, there’s almost no way to figure out what’s actually going on.Indie developers put a lot of time, money, and effort into building for Apple’s ecosystem. Clear communication shouldn’t be this hard.Thanks for reading. Marque Development Team

While an AVAudioPlayer/AudioUnit is rendering to AirPods over A2DP with system Spatial Audio + Head Tracking enabled, switching the shared AVAudioSession to playAndRecord + voiceChat (A2DP → HFP) blocks the main thread for tens of seconds on synchronous AVAudioSession APIs (setCategory / setMode / channel getters / setPreferred*). iOS hang detection reports a Severe Hang of 41.02 s. Stopping playback and deactivating the session before the identical switch completes in ~87 ms. Feedback: FB25324099 Environment iPhone 15 Pro (iPhone16,1), iOS 27.0.1 (24A446) AirPods worn; Spatial Audio + Head Tracking on AVFoundation-only repro (no third-party SDK): https://github.com/shinobuwz/ios27-spatial-audio-stall-repro Info.plist: LSApplicationCategoryType = public.app-category.games, LSSupportsGameMode = YES; does NOT set AVGameBypassSystemSpatialAudio (those two keys are required for system Spatial Audio on this path) Steps Wear AirPods with Spatial Audio + Head Tracking enabled Launch the repro app; allow mic (or use auto-repro) Play 440 Hz (BluetoothA2DP, spatial=1) After ~2 s, run Repro: keep playing and switch to PlayAndRecord + VoiceChat Compare with Control: stop playback + setActive:NO, then the same switch Expected: each call returns in ms; whole reconfiguration ≪ 50 ms Actual (cold launches): configuration total 20.8–28.9 s (options=13); with options=237 ≈ 36.2 s; first input buffer ~40–58 s from switch start. Control ≈ 87 ms. Evidence in the repo: docs/MEASUREMENTS-2026-10-26.md, evidence/*.log, hangs.xml, main-thread stacks in avas::client::SessionCore (sync XPC to the audio daemon). Even inputNumberOfChannels / outputNumberOfChannels getters stall for seconds. Question: Is this a known regression on iOS 27? Any workaround besides stopping all rendering AudioUnits before the HFP switch? Happy to attach sysdiagnose / Instruments / screen recording if useful.

Hi, I'm developing an iOS app that uses a third-party library compiled with GraalVM Native Image and packaged as a dynamic framework. During a privacy compliance review, I found several Required Reason APIs in the compiled library. Their actual uses do not appear to fit Apple's documented approved reasons. 1. File Timestamp APIs (stat, fstat, lstat) The runtime uses these APIs to inspect system timezone files such as /etc/localtime, primarily checking file types, symbolic links, and sizes. However, reason C617.1 appears to cover files within the app's own containers, not system files. 2. Disk Space API (fstatvfs) The runtime uses fstatvfs to obtain filesystem block alignment information (f_frsize) for Direct I/O, rather than checking available disk space. This does not appear to match reason E174.1. 3. System Boot Time API (mach_absolute_time) The runtime uses this API to implement a monotonic clock, potentially including random seed initialization. Reason 35F9.1 covers elapsed-time measurements and timers, but does not clearly address random seeding. Questions Do these uses require Required Reason API declarations? If so, which approved reasons apply? How should developers handle API references included in a compiled runtime that may never execute in the app? If no approved reason matches these uses, what is the recommended compliant approach? The app does not use these APIs for tracking or device fingerprinting. I want to ensure the framework's Privacy Manifest accurately reflects its actual behavior rather than declaring unsupported reasons. Any guidance would be greatly appreciated. Thank you!

Hi, I've discovered that my Keyboard Extension is unable to detect any hinge status update on iPhone Duo. I tired both UIKit and SwiftUI approach - nothing works. Is there any workaround to make it work? Reproducible demo: https://www.icloud.com/iclouddrive/0460exMJtAdRkpk8EDjb751nw Xcode 27.1 (27A9269) iOS 27.1 beta 1 (24A94401) I also created a bug report: FB24883137

Hi, We understand that we need to have a D-U-N-S number to change the name of the personal account.But can we create a D-U-N-S number for a company located in the KOSOVO Republic. We do not have the KOSOVO Republic options in the address options. How should we act in such situations? Should we choose from the existing options? In order not to waste time without generating a DUNS number, can you give information on this subject? Thanks for Helping

I am looking for guidance from Apple or other developers who have experienced a similar Guideline 4.3(a) rejection. I submitted an independently developed iPhone/iPad application, Canvasz AI: Passport ID Photo, for App Review. On September 30, 2026, the app was rejected under Guideline 4.3(a) – Design – Spam, with a general statement that the app appeared to share a similar binary, metadata, and/or concept with apps submitted by other developers. The problem is that I have not been able to determine what Apple actually considers similar. Canvasz AI was developed independently and was not created from a purchased template, white-label application, cloned application, or repackaged source code. The application includes product-specific functionality such as: Real-time face-position and distance guidance before taking a photo On-device face detection and format-aware automatic framing Passport/document head-size framing logic On-device background segmentation, matting, and replacement without uploading the user's photo to a processing server One source photo converted into multiple destination classes, including passport/visa/ID photos, profile images, social-media formats, and banners Batch generation/export of supported formats from one source photo An enhancement pipeline intended to preserve facial detail rather than apply a generic beauty filter Seven localized languages iPhone and iPad layouts Portrait and landscape support No account or signup requirement Core photo processing that works locally/on-device Following the rejection, I replied through App Store Connect asking whether the concern related specifically to: Binary/source-code similarity Metadata Visual assets/UI The application concept itself I also performed an additional source-provenance and similarity audit. The audit documented progressive source-control history and compared Canvasz AI against my other independently developed applications. It found no byte-identical application-specific source/assets across the compared applications, the common files identified were normal Flutter/iOS/Android generated framework/scaffolding files. I attached the forensic technical clarification report to App Review and offered to provide source-control history, architecture information, screenshots, development evidence, or additional technical information if required. I first replied on September 30 and followed up again on October 5. I still did not receive clarification identifying the actual similarity concern. I subsequently resubmitted the application on October 12, 2026, with detailed App Review notes and the forensic report attached. As of October 25, 2026, both the app and its in-app purchase remain Waiting for Review. I understand that App Review may require additional time, especially after a previous Guideline 4.3 rejection. I am not asking for special treatment or asking Apple to disclose another developer's confidential application or internal detection systems. What I need is enough actionable information to understand how to comply. Apple's published Guideline 4.3 states that apps in established categories may be accepted when they provide a meaningfully different or improved experience. I therefore have three specific questions: If an independently developed application receives a 4.3(a) rejection referring to "binary, metadata, and/or concept," how can the developer determine which of those dimensions actually caused the rejection? If source provenance and independent development evidence are provided, but no clarification is received, what additional evidence is normally useful for demonstrating that an application is not a template, clone, or repackaged application? For the "meaningfully different or improved experience" standard, should differentiation be evaluated on the complete user workflow and experience, or is overlap in individual features sufficient to trigger Guideline 4.3? I have invested significant development, testing, localization, and product-design effort into building a genuine application intended to provide useful functionality to users. I fully respect Apple's need to prevent spam, cloned apps, white-label applications, and low-effort template submissions. I support that objective. However, without knowing whether the concern is source code, metadata, UI/assets, or the concept itself, it is extremely difficult for an independent developer to make a meaningful correction instead of making speculative changes. I would appreciate guidance from Apple or developers who have encountered this situation and successfully obtained actionable clarification. Thank you.

Since iOS 27 beta we are seeing a behavior change in our video streaming app and I would like to know whether others can reproduce it. Behavior on iOS 27 beta: Fully opening the Notification Center pauses playback. Audio continues for about 5 more seconds, then the app is suspended. Closing the Notification Center leaves the player paused. On iOS 26 the same build keeps playing in this situation. Setup: AVQueuePlayer playing video with audio, not muted audiovisualBackgroundPlaybackPolicy = .automatic (default) AVAudioSession category .playback, UIBackgroundModes: audio entitlement AVPictureInPictureController attached with canStartPictureInPictureAutomaticallyFromInline = true Filed as FB23893965 Questions: Can anyone reproduce this on iOS 27 beta? Is this intentional or a regression?

Hi everyone! My app has been approved for Private Distribution in App Store Connect. Under “Distribution for Business and Education,” I selected “Apple Account” and entered several Apple IDs, but the app doesn’t appear in the App Store on those devices. Could someone explain the procedure and next steps after entering the Apple IDs? How can those users access and download the app? Thanks!

Let's say we start with a fully open iPhone Duo. We then present a view controller as a form sheet or page sheet. If the device is then rotated between landscape and portrait, the view controller's viewWillTransition(to:with:) is called to reflect the change in size between orientations. So far so good. Now put the fully open Duo in landscape. Then partially close the Duo. The presented view controller will automatically move off to the left half of the screen to avoid the fold. That's expected. However, the view controller's viewWillTransition(to:with:) is NOT called in this case even though its size has changed. Does this seem like a bug or is this somehow expected? I have a particular view controller that needs to know its size has changed so it can make some adjustments. Other lifecycle methods such as viewDidLayoutSubviews are called but I'd prefer to have viewWillTransition(to:with:) called.