Has anyone been able to create a Control Center widget that opens a snippet view? There are stock Control Center widgets that do this, but I haven't been able to get it to work. Here's what I tried: struct SnippetButton: ControlWidget { var body: some ControlWidgetConfiguration { StaticControlConfiguration( kind: "xxx.xxx.snippetWidget" ) { ControlWidgetButton(action: SnippetIntent()) { Label("Show Snippet", systemImage: "map.fill") } } .displayName(LocalizedStringResource("Show Snippet")) .description("Show a snippet.") } } struct SnippetIntent: ControlConfigurationIntent { static var title: LocalizedStringResource = "Show a snippet" static var description = IntentDescription("Show a snippet with some text.") @MainActor func perform() async throws -> some IntentResult & ProvidesDialog & ShowsSnippetView { return .result(dialog: IntentDialog("Hello!"), view: SnippetView()) } } struct SnippetView: View { var body: some View { Text("Hello!") } }

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?

Hello, I'm trying to create game in macos with transperent titlebar. The title bar t stay transperent when I click inside, but changed to gray when the window resize or get out of focus. How can I make it stay transperent all the time? I did all of this: window.styleMask.insert(.fullSizeContentView) window.titlebarAppearsTransparent = true window.titlebarSeparatorStyle = .none window.titleVisibility = .hidden window.isMovableByWindowBackground = true window.isOpaque = false window.backgroundColor = .black in the swiftUI view created zstack that start with: var body: some View { ZStack { Color.black.ignoresSafeArea() help please :) Thanks.

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?

When using the Password AutoFill feature, after entering a password and navigating to another page, a system prompt appears asking whether to save the password to the keychain (as shown in the figure). If this prompt is not dismissed and the app is moved to the background, then brought back to the foreground, the prompt automatically disappears. However, after this occurs, all input fields within the app become unresponsive to keyboard input—no keyboard will appear when tapping any text field. The only way to restore keyboard functionality is to force-quit the app and relaunch it. How can this issue be resolved?

Hello， We’re seeing an iPad-specific Launch Screen issue related to multitasking window sizes. Environment Device: iPad (iPadOS 26) Device orientation: Landscape App is launched in a small window where the app window is portrait-shaped (width < height) Issue When the iPad is in landscape but the app is launched as a portrait-shaped small window, the LaunchScreen.storyboard appears to be rendered/layouted as landscape, not matching the actual window geometry. As a result, the Launch Screen content is clipped / partially missing (we see blank/empty area at the bottom during launch). After the app finishes launching, our first view controller uses the correct window size and the UI looks fine — the problem is mainly during the Launch Screen phase. What we checked LaunchScreen.storyboard uses Auto Layout and is expected to adapt to screen/window size. This only reproduces when the device orientation and the app window aspect ratio don’t match (landscape device + portrait-shaped app window, or vice versa). When device orientation and window shape are aligned, the Launch Screen displays correctly. Question Is it expected that iPadOS renders LaunchScreen.storyboard based on the interface orientation / size class rather than the actual window bounds in multitasking scenarios? If not expected, what is the recommended way to ensure the Launch Screen matches the app’s actual window size/aspect ratio at launch (without using code, since Launch Screen is static)? Are there any additional diagnostics or recommended steps to help us investigate and confirm the root cause (e.g., specific logs, APIs/values to capture at launch such as UIWindowScene bounds, interfaceOrientation, size classes, or any guidance on how Launch Screen snapshots are chosen/cached in multitasking)? Thank you.

hello im using the new IOS 26 api for passkey creation ASAuthorizationAccountCreationProvider however it only seems to work with apple's Passwords app. Selecting 3rd party password apps (1Password, google chrome, etc) does not create the passkey. The sign up sheet gives me the option to save in 3rd party apps, but when I select a 3rd party app, I just get the ASAuthorizationError cancelled error? So I dont even know what the problem is? When selecting "Save in Passwords(apple's app)" during the sign up it works fine Has anyone else run into this issue? Is there something I need to do enable 3rd party apps?

Memory leak in CarPlay when using CPTabBarTemplate Reproduced using the code example "Integrating CarPlay with Your Music App" from the official Apple documentation - https://developer.apple.com/documentation/carplay/integrating-carplay-with-your-music-app Steps to reproduce the leak: Download and run the example on CarPlay. Select the Settings tab. Click the first item in the list "Use Apple Music". Click Back button. Repeat steps 3 and 4 several times. Open Debug Memory Graph in xCode and search for "CPGridTemplate" - the count will be greater than 0. Conditions under which the memory leak disappears: If you open and switch to all tabs one by one, the leak disappears.

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?

We're seeing a sharp uptick in BaseBoard/FrontBoardServices crashes since we migrated from UIApplicationDelegate to UIWindowSceneDelegate. Having exhausted everything on my end short of reverse engineering BaseBoard or making changes without being able to know if they work, I need help. I think all I need to get unstuck is an answer to these questions, if possible: What does -[BSSettings initWithSettings:] enumerate over? If I know what's being enumerated, I'll know what to look for in our app. What triggers FrontBoardServices to do this update? If I can reproduce the crash--or at least better understand when it may happen--I will be better able to fix it Here's two similar stack traces: App_(iOS)-crashreport-07-30-2025_1040-0600-redacted.crash App_(iOS)-crashreport-07-30-2025_1045-0600-redacted.crash Since these are private trameworks, there is no documentation or information on their behavior that I can find. There are other forum posts regarding this crash, on here and on other sites. However, I did not find any that shed any insight on the cause or conditions of the crash. Additionally, this is on iPhone, not macOS, and not iPad. This post is different, because I'm asking specific questions that can be answered by someone with familiarity on how these internal frameworks work. I'm not asking for help debugging my application, though I'd gladly take any suggestions/tips! Here's the long version, in case anyone finds it useful: In our application, we have seen a sharp rise in crashes in BaseBoard and FrontBoardServices, which are internal iOS frameworks, since we migrated our app to use UIWindowSceneDelegate. We were using exclusively UIApplicationDelegate before. The stack traces haven't proven very useful yet, because we haven't been able to reproduce the crashes ourselves. Upon searching online, we have learned that Baseboard/Frontsoardservices are probably copying scene settings upon something in the scene changing. Based on our crash reports, we know that most of our users are on an iPhone, not an iPad or macOS, so we can rule out split screen or window resizing. Our app is locked to portrait as well, so we can also rule out orientation changes. And considering the stack trace is in the middle of an objc_retain_x2 call, which is itself inside of a collection enumeration, we are assuming that whatever is being enumerated probably was changed or deallocated during enumeration. Sometimes it's objc_retain_x2, and sometimes it's a release call. And sometimes it's a completely different stack trace, but still within BaseBoard/FrontBoardServices. I suspect these all share the same cause. Because it's thread 0 that crashed, we know that BaseBoard/FrontBoardServices were running on the main thread, which means that for this crash to occur, something might be changing on a background thread. This is what leads me to suspect a race condition. There are many places in our app where we accidentally update the UI from a background thread. We've fixed many of them, but I'm sure there are more. Our app is large. Because of this, I think background UI are the most likely cause. However, since I can't reproduce the crash, and because none of our stack traces clearly show UI updates happening on another thread at the same time, I am not certain. And here's the stack trace inline, in case the attachments expire or search engines can't read them: Thread 0 name: Thread 0 Crashed: objc_retain_x2 (libobjc.A.dylib) BSIntegerMapEnumerateWithBlock (BaseBoard) -[BSSettings initWithSettings:] (BaseBoard) -[BSKeyedSettings initWithSettings:] (BaseBoard) -[FBSSettings _settings:] (FrontBoardServices) -[FBSSettings _settings] (FrontBoardServices) -[FBSSettingsDiff applyToMutableSettings:] (FrontBoardServices) -[FBSSettingsDiff settingsByApplyingToMutableCopyOfSettings:] (FrontBoardServices) -[FBSSceneSettingsDiff settingsByApplyingToMutableCopyOfSettings:] (FrontBoardServices) -[FBSScene updater:didUpdateSettings:withDiff:transitionContext:completion:] (FrontBoardServices) __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke_2 (FrontBoardServices) -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] (FrontBoardServices) __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke.cold.1 (FrontBoardServices) __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke (FrontBoardServices) _dispatch_client_callout (libdispatch.dylib) _dispatch_block_invoke_direct (libdispatch.dylib) __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ (FrontBoardServices) -[FBSMainRunLoopSerialQueue _targetQueue_performNextIfPossible] (FrontBoardServices) -[FBSMainRunLoopSerialQueue _performNextFromRunLoopSource] (FrontBoardServices) __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ (CoreFoundation) __CFRunLoopDoSource0 (CoreFoundation) __CFRunLoopDoSources0 (CoreFoundation) __CFRunLoopRun (CoreFoundation) CFRunLoopRunSpecific (CoreFoundation) GSEventRunModal (GraphicsServices) -[UIApplication _run] (UIKitCore) UIApplicationMain (UIKitCore) (null) (UIKitCore) main (AppDelegate.swift:0) 0x1ab8cbf08 + 0

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

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 &gt; General &gt; Deployment Info &gt; 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,