There is a problem with the launchscreen of my application on iPadOS 26. After release of the windowed mode feature the launchscreen of my fullscreen landscape-only application is being cropped and doesn't stretch to screen's size when the device is in the portrait mode. How can I fix this?

Hi Everyone We are seeking inputs regarding an issue we are observing with Apple App Site Association (AASA) and Universal Links in our iOS application. In our iOS Mobile App, we have a LogIn button which when clicked , opens a webv view to open a login page using WebView. The login flow follows the OAuth mechanism to get the token after successful login. But despite having a correctly configured AASA file and associated domains setup, our application does not consistently handle Universal Links and we simply end up getting a blank page.So, after successful login the control never gets passed back the iOS Mobile app and flow gets stuck on the browser only that just displays a blank page. Earlier the same OAuth flow was working fine when we were using the 'com.test.app://oauth2redirect' comnvention. Based on our investigation, we suspect this behavior may be related to the use of in-app browsers or embedded webviews, rather than an issue with our app or server-side configuration. From our research and observations, it appears that this may be a known iOS behavior and platform limitation, where Universal Links do not automatically work within third-party in-app browsers or webviews (for example, those embedded in apps such as social media or other container applications). Looks like the Universal Links are primarily designed to work when links are opened from system-level contexts such as Safari, Mail, Messages, or Notes, under specific conditions. Given this, we wanted to confirm with you: If you have developed a mobile app earlier that uses the (AASA) and Universal Links in iOS application. Join us with a quick call and we can walkthrough what we have done and see if there is anything missing. Thanks Rahul

After reviewing the following Apple Technote, I have confirmed the statement below: https://developer.apple.com/documentation/technotes/tn3187-migrating-to-the-uikit-scene-based-life-cycle In the next major release following iOS 26, UIScene lifecycle will be required when building with the latest SDK; otherwise, your app won’t launch. While supporting multiple scenes is encouraged, only adoption of scene life-cycle is required. Based on the above, I would appreciate it if you could confirm the following points: Is my understanding correct that the term “latest SDK” refers to Xcode 27? Is it correct that an app built with the latest SDK (Xcode 27, assuming the above understanding is correct) will not launch without adopting the UIScene lifecycle, with no exceptions? Is it correct that an app built with Xcode 26 without UIScene lifecycle support will still launch without issues on an iPhone updated to iOS 27?

I’m building an iOS SDK that is distributed as a binary XCFramework and consumed via Swift Package Manager using a binaryTarget. What I’ve done so far: Built the SDK using xcodebuild archive for device and simulator Created the XCFramework using xcodebuild -create-xcframework The SDK contains a resource bundle with JSON/config files The XCFramework is wrapped using SPM (code-only wrapper target) Currently, the resource bundle exists outside the XCFramework, and the host app needs to add it manually during integration. I want to avoid this and make the SDK completely self-contained. What I’m trying to achieve: Embed the resource bundle inside the SDK framework so that each XCFramework slice contains it Ensure the SDK can load its assets internally at runtime without any host app changes Questions: What is the correct way to embed a .bundle inside a framework so it gets packaged into each XCFramework slice during archiving? Which Xcode build phases or build settings are required for this (e.g., Copy Bundle Resources, SKIP_INSTALL, etc.)? At runtime, what is the recommended approach for locating and loading this embedded bundle from within the SDK code? Any guidance or best practices for achieving this would be helpful.

I've integrated PencilKit into my app, but I've noticed that shape recognition isn't working during drawing, even though it works perfectly in the Notes app. Is this a bug, or is shape recognition simply not supported in PencilKit for Swift?

Hello, I'm trying to make a white-Label sort of thing for my app, that is: a script runs before the app launches, sets a certain LaunchAgent command that sets and environment variable, and based on that variable's value tha main app's icon changes to a certain logo (change only happens in the dock because changing the icon on disk breaks the signature) When the app launches it takes a noticeable time until the dock icon changes to what I want, so I worked around that by setting the app's plist property to hide the dock icon and then when the app is launched I call an objc++ function to display the icon in the dock again (this time it displays as the new icon) The showing happens through [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular]; The problem happens when I try to close the app, it returns back to the old logo before closing which is what I want to prevent. I tried hiding the app dock icon before closing but even the hiding itself changes the icon before hiding The hiding happens through [NSApp setActivationPolicy:NSApplicationActivationPolicyProhibited]; My goal is that the main app icon doesn't appear to the user through the dock, and that the icon that is only visible is the other one that changes during runtime The reason for this is that I have an app that should be visible differently depending on an environment variable that I set using an installer app. The app is the same for all users with very minor UI adjustments depending on that env variable's value. So instead of creating different versions of the app I'd like to have just 1 version that adjusts differently depending on the env variable's value. Somehow this is the only step left to have a smooth experience Feel free to ask more clarification questions I'd be happy to help Thank you

Our app works fine on iOS 26 on other platforms but on iphone17, the text on the popovers is so light it is unreadable when the device is in Light mode. Is anyone else having this issue and if so, do you have any recommendations?

Since Callkit is not supported in mainland China, 'LiveCommunicationKit' is currently being used. When a VoIP push notification is received, the banner does not display correctly, but the phone icon in the top left corner, the ringtone, and vibration are present. I followed the solution in "https://developer.apple.com/forums/thread/774958?answerId=827083022#827083022" to resolve the crash issue, but the banner is still not displayed.

Hello, I'm currently working on an app that will have a different name (and UI) depending on an environment variable that is set by that app's custom installer that I also wrote. I'm trying to change the app name that is displayed in the menu bar (top left) programmatically. I've done some research and found that it's probably not possible to do so because it's fetched from the app's Info.plist The answer is probably already there but I'll ask the question: Is it possible to change the app's name in the menu bar without tampering with the Info.plist (as it will break the signature at runtime, and it can't be done at compile time) The use case here is that I'm shipping a single app with multiple installers, because the app will be the same for all sets of users but it will have minor UI changes (which in my opinion, don't need an entire separate release), the installers will set a flag that the app will, based on, change its UI to the corresponding set of users. For the most part it's been successful but only small issue remain like this one. The reason it's done like that is when updating I'll ship 1 release for all users to update rather than having to ship multiple releases with no difference between them

For some reason, Carplay 18.x works fine, however in under certain situations in our app, Carplay 26.x breaks. The expected grid layout should be : However, this is what we see in some cases when we update our templates. I have not been able to isolate the cause of this issue. Has anyone ever seen this happen on their CarPlay apps and discovered the cause? The data sets fed into the templates are identical, the difference is in some of the timing and update order...

Hello everyone, I have an app that is used in the education sector for high stakes assessment testing. I reviewed a lot of the WWDC2025 information in June, however, it seems we missed something critical in the What's new in UIKIt presentation. That would be the deprecation of UIRequiresFullScreen. We currently use this in our app and have been using it since iOS/iPad OS 9 when our app was written. The deprecation of this property has caused some major issues in our layout. Keep in mind we are a hybrid app so our mobile app is self-hosting a fullscreen version of WKWebView under the hood. This is common across assessment developers in the education sector. I removed the property and went through the migration guide (https://developer.apple.com/documentation/technotes/tn3192-migrating-your-app-from-the-deprecated-uirequiresfullscreen-key) and it doesn't appear to be straight forward on how to lock the orientation in landscape. I tried several different approaches: Requesting the screen orientation lock we had issues where if a user launched it in portrait it would be locked to portrait but we would want to update the display to shift it to landscape as a business requirement supporting both landscape right and landscape left. We also tried overriding the method supportedInterfaceOrientations and utilizing the .landscape enum with no success. It fires just fine but nothing takes effect. Backwards compatibility support there is no guidance on backwards compatibility support and Xcode wants us to do an availability check when using some of the new methods for updating geometry. What is the guidance in this case because we support back to iPadOS 16.0 as a business requirement. Can anyone give us some insight as we are current trying to get ahead of this while 26.3 is still in beta as this would affect our customers deeply because of the UI jank we get as a result of this deprecation.

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,

Hello, I’m reaching out after several days of investigation, as I’ve exhausted all standard troubleshooting steps and would truly appreciate guidance from Apple engineers or experienced developers. I am experiencing a persistent issue where StoreKit does not return any subscription products on any device, despite all subscriptions being fully approved and correctly configured in App Store Connect. What is happening • Auto-renewable subscriptions exist and are approved in App Store Connect • The app is installed from the production App Store (not TestFlight, not sandbox) • initConnection / StoreKit initialization succeeds • Requests for products/subscriptions return an empty result (no errors, no IDs) • In the UI, prices are shown as “Unavailable” • This behavior is 100% reproducible on every device, every Apple ID, every network Important detail This issue is not device-specific, account-specific, or environment-specific: • Tested on multiple iPhones • Tested with different Apple IDs • Tested on different networks • Same result every time — no subscriptions returned Why I believe this is not a code issue The exact same symptoms previously occurred on Google Play, where the root cause turned out to be a store-side configuration flag blocking billing visibility, not an application bug. Because: • StoreKit initializes correctly • No runtime errors occur • The issue is global across devices and users …I strongly suspect there may be an App Store Connect / StoreKit configuration, availability, storefront, agreement, or propagation-related factor that is preventing StoreKit from returning the products at runtime. Is there any known App Store Connect or StoreKit condition where: • subscriptions are approved and visible in App Store Connect • but StoreKit returns an empty result set in production? If so, I would be extremely grateful for guidance on where exactly to verify or correct this. Thank you very much for your time and support — any insight would be hugely appreciated. Kind regards, Mateusz

Has anyone noticed that there are way too many bugs caused by the liquid glass issues? I'm noticing apple adding private layer classes between existing UI views to add glassy effect and no way to disable them. Some of these bugs have no way around without rewriting the code from. For example, search controller doesn't work anymore on iOS 26 but does work on iOS 18. The tab bar controller doesn't show at all on iOS 26 but does on iOS 18. I'm wondering if other people are facing the same issues.

I'm developing an iOS app that handles custom file types (e.g., .k files), and I want to ensure my app's icon appears in Core Spotlight search results, similar to how 两步路户外助手's icon shows up for associated files (as shown in the attached screenshot from iOS search). I know one standard way is to configure CFBundleDocumentTypes in the Info.plist to declare supported document types, which allows the system to associate files with my app and display the icon in search. However, I'm looking for alternative approaches or additional configurations that could achieve this without relying solely on CFBundleDocumentTypes, or perhaps in combination with it for better integration. For context: This is for iOS 26+ (or latest versions). The goal is to have the app icon visible directly in Spotlight/Core Spotlight results when searching for files or content indexed by my app. I've tried basic NSUserActivity and CSSearchableItem indexing, but the icon doesn't always appear as expected for file associations. Has anyone implemented this through other means, like exported UTIs, Launch Services, or custom searchable attributes? Any code snippets, documentation links, or best practices would be appreciated! (Attach your Figure 2 screenshot here to illustrate the desired behavior, e.g., the .k file with the app icon in search results.)

I’m exploring macOS development, comparing Mac Catalyst apps vs native AppKit/SwiftUI apps. What are the main limitations of Catalyst today? In what scenarios is a native AppKit or SwiftUI app unavoidable? Any insights are much appreciated — I’m trying to understand when Catalyst is sufficient and when going native is worth the extra effort.

Hello, I am experiencing an issue related to SFSafariViewController during App Store review, and I would like to ask whether this could be an OS-level behavior or a known issue. App context Our app supports iPhone only During App Review, the reviewer tested the app on an iPad The app was rejected because the keyboard did not appear Issue description The problematic screen presents a sign-up web page using SFSafariViewController When tapping the nickname input field: The keyboard area appears (the layout shifts as if the keyboard will be shown) However, the actual keyboard does not appear Reproducibility We tested this issue on our own physical devices and on iPad simulators with the same app configuration However, we are unable to reproduce the issue in either environment What we have checked The web page uses a standard HTML There is no custom keyboard handling or keyboard-related logic in the app The app simply presents SFSafariViewController with a URL Locale-related question The URL includes a locale parameter (e.g. LOCALE=US) Could the app’s locale, system language, or region settings affect keyboard behavior in SFSafariViewController? Is it possible that a specific locale or language configuration on iPad could cause the keyboard to fail to appear? Questions Is there any known issue or OS-level behavior where the keyboard may fail to appear in SFSafariViewController on iPad? Could this be related to: Locale / language / region settings iPad multitasking or keyboard modes External keyboard state Specific iPadOS versions Are there any recommended workarounds or defensive implementations for this scenario? Any insights or similar experiences would be greatly appreciated. Thank you.

I’m developing a share extension for iOS 26 with Xcode 26. When the extension’s sheet appears, it always shows a full white background, even though iOS 26 introduces a new “Liquid Glass” effect for partial sheets. Expected: The sheet background should use the iOS 26 glassmorphism effect as seen in full apps. Actual behavior: Custom sheets in my app get the glass effect, but the native system sheet in the share extension always opens as plain white. Steps to reproduce: Create a share extension using UIKit Present any UIViewController as the main view Set modalPresentationStyle = .pageSheet (or leave as default) Observe solid white background, not glassmorphism Sample code: swift override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .clear preferredContentSize = CGSize(width: UIScreen.main.bounds.width, height: 300) } Troubleshooting attempted: Tried adding UIVisualEffectView with system blur/materials Removed all custom backgrounds Set modalPresentationStyle explicitly Questions: Is it possible to enable or force the Liquid Glass effect in share extensions on iOS 26? Is this a limitation by design or a potential bug? Any workaround to make extension sheet backgrounds match system glass appearance?

I’m developing a share extension for iOS 26 with Xcode 26. When the extension’s sheet appears, it always shows a full white background, even though iOS 26 introduces a new “Liquid Glass” effect for partial sheets. Expected: The sheet background should use the iOS 26 glassmorphism effect as seen in full apps. Actual behavior: Custom sheets in my app get the glass effect, but the native system sheet in the share extension always opens as plain white. Steps to reproduce: Create a share extension using UIKit Present any UIViewController as the main view Set modalPresentationStyle = .pageSheet (or leave as default) Observe solid white background, not glassmorphism Sample code: swift override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .clear preferredContentSize = CGSize(width: UIScreen.main.bounds.width, height: 300) } Troubleshooting attempted: Tried adding UIVisualEffectView with system blur/materials Removed all custom backgrounds Set modalPresentationStyle explicitly Questions: Is it possible to enable or force the Liquid Glass effect in share extensions on iOS 26? Is this a limitation by design or a potential bug? Any workaround to make extension sheet backgrounds match system glass appearance?

I am trying to set an image as the background in the window of a DMG. The image is: PNG file; 144x144 resolution; 1138x574 size. In macOS Tahoe, the image is added by: selecting the DMG window; opening the "Show View Options" dialog; clicking on "Picture"; dragging the image file to the small square box labelled "Drag image here"; closing "Show View Options" dialog. The DMG is then ejected. In Disk Utility, the image file is converted to "Read Only image (UDRO)". The converted image file is opened and the background image is visible. The image file is then copied to a MacBook running macOS 12 Monterey and opened. The background image is NOT shown. The image file is copied to a Mac mini running macOS 14 Sequoia and opened. The background image is NOT shown. Have read past online discussions in which it was explained that an image file called "background" should be inside a hidden folder called ".background". The above procedure did not do that. Is that old advice still correct for macOS Tahoe ? Has Tahoe somehow broken the method used for setting the background of a Window ? Is the method used in Tahoe different to past versions of macOS ? If so, is there a way of maintaining compatibility with old versions of macOS ? Is there any documentation on how to set the background image of a DMG window which might explain this behaviour ?? Thanks.