Overview

When creating an icon using icon composer, I cant upload a build to testflight/App Store connect. Running on device from Xcode works fine, but as soon as I archive and upload to App Store Connect, I get an error saying the icon contains an alpha channel

Everytime when iOS simulator is launched I het a lot of repeated "*** quit unexpectedly" alerts. Where "***" is a mix of "managedappdistributiond","healthappd", and "findmylocated" Even after the simulator is launched I still het random "*** quit unexpectedly" alerts. Very annoying because the alerts deactivates the active window This is on an MacBook Pro M3 Max,, Xcode 15.2, Sonoma 14.2.1, it also happens with Xcode 15.1 A co developer (MacBook Pro M1 Max,Xcode 15.2, Sonoma 14.2.1) does not have the issue Any idea how I can prevent this from happening? Update Every mentioned service crash happens in libswiftCore.dylib at 0x1929f3938 assertionFailure(:_:file:line:flags:) + 248

If the extension uses manifest v3 and a background script in the form of a service worker, then in Safari it is not possible to open the background script debugging window. If I expand the Developer menu in Safari, there is nothing under Web Extension Background Data (or disappear after click), which is an error. In other browsers (Edge, Chrome, Opera, Firefox) this works correctly. If I switch the background script back to non-persistent script mode, everything works fine and from the Developer menu and the Web Extension Background Data submenu I am able to open the background script debugging window for the extension. Am I doing something wrong?

I have a few view controllers in a large UIKit application that previously started showing content right below the bottom of the top navigation toolbar. When testing the same code on iOS 26, these same views have their content extend under the navigation bar and toolbar. I was able to fix it with: if #available(iOS 26, *, *) { self.edgesForExtendedLayout = [.bottom] } when running on iOS 26. I also fixed one or two places where the main view was anchored to self.view.topAnchor instead of self.view.safeAreaLayoutGuide.topAnchor. Although this seems to work, I wonder if this was an intended change in iOS 26 or just a temporary bug in the beta that will be resolved. Were changes made to the safe area and edgesForExtendedLayout logic in iOS 26? If so, is there a place I can see what the specific changes were, so I know my code is handling it properly? Thanks!

When I create a SwiftUI toolbar item with placement of .keyboard on iOS 26, the item appears directly on top of and in contact with the keyboard. This does not look good visually nor does it match the behavior seen in Apple's apps, such as Reminders. Adding padding to the contents of the toolbar item only expands the size of the item but does not separate the capsule background of the item from the keyboard. How can I add vertical padding or spacing to separate the toolbar item capsule from the keyboard?

I've had no issue calling image files in my .swift files, but they are causing crashes when used in my .SKS files. When I set a sprite texture to an image in the inspector/ editor bar, at runtime when that sprite is being called I get the error: "Cannot get value with size 16. The type encoded as {CGRect={CGPoint=dd}{CGSize=dd}} is expected to be 32 bytes." From my research it has something to do with Apple switching from 32 to 64 bite machines. From chatGPT “SpriteKit under the hood uses NSKeyedUnarchiver to load your .sks file. That unarchiver decodes each archived property by reading a fixed‑size blob of bytes and mapping it into a C struct. In your case it ran into a mismatch”. I am using a 64-bite machine to write my code and 64-bite simulators and physical devices, so there isn't a clear cause of the mismatch. My scenes play fine in Xcode 16's preview window and my code builds, it just crashes at runtime. When I don’t use image textured assets in the SKS file it works fine. It loads animated labels, and plain color squares. I’ve been able to work around this for static things like a sprite with a background texture by. in a normal non-game swift file, writing code like: if let scene = SKScene(fileNamed: "GameScene2") { let bg = SKSpriteNode(imageNamed: "YourBackgroundImage") bg.position = CGPoint(x: scene.frame.midX, y: scene.frame.midY) bg.zPosition = -1 scene.addChild(bg) } The issue now is I want to make a particle emitter and other non static sprites, but my understanding of their properities isn’t deep enough to create them without the editor. Also when I set SKTexture in a swift file that causes the same runtime crash with the 16/32 error. Could you help me figure out how to fix the bug so I can use the editor again? Otherwise could you help me figure out how to write a workaround like I do for background images? I have a feeling the answer is in writing my own NSKeyedUnarchiver but I don’t know how to make sure it’s called instead of the default one. I've already tried cleaning my code multiple times and deleting and reading sprite nodes. Thank you.

In previous versions of the simulator, it was possible to import files into the Files app by dragging them from the Finder into the Simulator. It appears that in the iOS 26 Simulator, this opens the file in Safari. I've only tried it with .json files so far. The documentation at https://developer.apple.com/documentation/xcode/sharing-data-with-simulator says that the original behaviour should happen: To add files to Simulator, select one or more files in Finder on your Mac, then click the Share button. Select Simulator from the share destination list. Choose the simulated device from the drop-down list. Simulator opens the Files app, and lets you select where to save the files. I'd love to learn if this is intentional behaviour, and if so, what workarounds there might be. I use this pattern quite a lot, as I have a HealthKit app, and I've built a system that allows me to export workouts as JSON files from a real device, that I can then import into a simulator for testing. Edit: I found a workaround. Make a folder in Files.app, then search for it within ~/Library/Developer/CoreSimulator/Devices. Open the folder in Finder, then add any files you want to be available in the Simulator.

iPhone7 : iOS 14.0 Beta 5 Xcode-beta Mac OS : 10.15.5 (19F101) crash info : ** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[PHPhotoLibrary presentLimitedLibraryPickerFromViewController:]: unrecognized selector sent to instance xxxxxx' terminating with uncaught exception of type NSException my code: (void)viewDidAppear:(BOOL)animated {   [super viewDidAppear:animated];   if (@available(iOS 14, *)) {     [[PHPhotoLibrary sharedPhotoLibrary] presentLimitedLibraryPickerFromViewController:self];   } }

My team is preparing for iOS 18, and wanted to add intents using assistant schemas that are iOS 18 and above restricted. We noticed that the result builder for AppShortcuts added support for limitedAvailabilityCondition from iOS 17.4 so we marked the whole struct as available from it. The app compiles but writing a check like below inside appShortcuts property a crash will happen in iOS 17.5 runtime. (Removing the #available) is solving this problem. if #available(iOS 18, *) { AppShortcut( intent: SearchDonut(), phrases: [ "Search for a donut in \(.applicationName)" ], shortTitle: "search", systemImageName: "magnifyingglass" ) } We tried out putting the os check above and returning shortcuts in arrays and that both compiles and runs but then AppShortcuts.strings sends warnings that the phrases are not used (This phrase is not used in any App Shortcut or as a Negative Phrase.) because the script that extracts the phrases somehow fails to perform when shortcuts are written like below: static var appShortcuts: [AppShortcut] { if #available(iOS 18.0, *) { return [ AppShortcut( intent: CreateDonutIntent(), phrases: [ "Create Donut in \(.applicationName)", ], shortTitle: "Create Donut", systemImageName: "pencil" ) ] } else { return [ AppShortcut( intent: CreateDonutIntent(), phrases: [ "Create Donut in \(.applicationName)", ], shortTitle: "Create Donut", systemImageName: "pencil" ) ] } } This is very problematic because we can't test out on TF with external users new intents dedicated for iOS 18. We filed a radar under FB15010828

When we use AppIntents to configure WidgetKit complications, the description we provide in IntentRecommendation is ignored after applying a .watchface file that includes those intent configurations. In the Watch app, under Complications, the labels shown next to each slot do not match the actual complications on the face—they appear to be the first strings returned by recommendations() rather than the selected intent configuration. Steps to Reproduce Create an AppIntent used by a WidgetKit complication (e.g., .accessoryRectangular). Provide multiple intent recommendations with distinct descriptions: struct SampleIntent: AppIntent { static var title: LocalizedStringResource = "Sample" static var description = IntentDescription("Sample data") @Parameter(title: "Mode") var mode: String static func recommendations() -> [IntentRecommendation<Self>] { [ .init(intent: .init(mode: "A"), description: "Complication A"), .init(intent: .init(mode: "B"), description: "Complication B"), .init(intent: .init(mode: "C"), description: "Complication C") ] } func perform() async throws -> some IntentResult { .result() } } Add two of these complications to a Modular Duo face (or any face that supports multiple slots), each with different intent configurations (e.g., A in one slot, B in another). Export/share the face to a .watchface file and apply it on another device. Open the Watch app → the chosen face → Complications. Expected Each slot’s label in Complications reflects the specific intent configuration on the face (e.g., “Complication A”, “Complication B”), matching what the complication actually renders. Actual The labels under Complications do not match the visible complications. Instead, the strings shown look like the first N items from recommendations(), regardless of which configurations are used in each slot. Notes The complications themselves render correctly on-watch; the issue is the names/labels displayed in the Watch app UI after applying a .watchface. Filed Feedback: FB20915258

Hello Team I tried to enroll using the Apple Developer app on both my Mac and my iPhone and I keep getting the "Unknown error" please try again popup. I'm on the latest macOS and iOS version, have everything in line to the requirements, but nothing seems to be working. Can someone guide me if there's something I've not done right?

I'm being faced with an issue when using SwiftUI's WebView on iOS 26. In many websites, the top/bottom content is unaccessible due to being under the app's toolbars. It feels like the WebView doesn't really understand the safe areas where it's being shown, because the content should start right below the navigation bar, and only when the user scrolls down, the content should move under the bar (but it's always reachable if the users scroll back up). Here's a demo of the issue: Here's a 'fix' by ensuring that the content of the WebView never leaves its bounds. But as you can see, it feels out of place on iOS 26 (would be fine on previous OS versions if you had a fully opaque toolbar): Code: struct ContentView: View { var body: some View { NavigationStack { WebView(url: URL(string: "https://apple.com")).toolbar { ToolbarItem(placement: .primaryAction) { Button("Top content covered, unaccessible.") {} } } } } } Does anyone know if there's a way to fix it using some sort of view modifier combination or it's just broken as-is?

On devices and simulators with iOS 26.1, the animation does not work correctly (the initial and final screens are distorted). I use open class func transition(with view: UIView, duration: TimeInterval, options: UIView.AnimationOptions = [], animations: (() -> Void)?, completion: ((Bool) -> Void)? = nil) with options: .transitionFlipFromRight

I Keep getting this error if I try to enroll in the developer program, why is this? Please tell me how to fix this of why this is happening!

All of these issues appear when the search controller is set on the view controller's navigationItem and the search controller's searchBar has its scopeButtonTitles set. So far the following issues are affecting my app on iOS/iPadOS 26 as of beta 7: When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .integratedButton, and the searchBarPlacementAllowsToolbarIntegration is set to false (forcing the search icon to appear in the nav bar), on both iPhones and iPads, the scope buttons never appear. They don't appear when the search is activated. They don't appear when any text is entered into the search bar. FB19771313 I attempted to work around that issue by setting the scopeBarActivation to .manual. I then show the scope bar in the didPresentSearchController delegate method and hide the scope bar in the willDismissSearchController. On an iPhone this works though the display is a bit clunky. On an iPad, the scope bar does appear via the code in didPresentSearchController, but when any scope bar button is tapped, the search controller is dismissed. This happens when the app is horizontally regular. When the app on the iPad is horizontally compact, the buttons work but the search bar's text is not correctly aligned within the search bar. Quite the mess really. I still need to post a bug report for this issue. But if issue 1 above is fixed then I don't need this workaround. When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .stacked, and the hidesSearchBarWhenScrolling property of the navigationItem is set to false (always show the search bar), and this is all used in a UITableViewController, then upon initial display of the view controller on an iPhone or iPad, you are unable to tap on the first row of the table view except on the very bottom of the row. The currently hidden scope bar is stealing the touches. If you activate and then cancel the search (making the scope bar appear and then disappear) then you are able to tap on the first row as expected. The initially hidden scope bar also bleeds through the first row of the table. It's faint but you can tell it's not quite right. Again, this is resolved by activating and then canceling the search once. FB17888632 When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to integrated or .integratedButton, and the toolbar is shown, then on iPhones (where the search bar/icon appears in the toolbar) the scope buttons appear (at the top of the screen) the first time the search is activated. But if you cancel the search and then activate it again, the search bar never appears a second (or later) time. On an iPad the search bar/icon appears in the nav bar and you end up with the same issue as #1 above. FB17890125 Issues 3 and 4 were reported against beta 1 and still haven't been fixed. But if issue 1 is resolved on iPhone, iPad, and Mac (via Mac Catalyst), then I personally won't be affected by issues 2, 3, or 4 any more (but of course all 4 issues need to be fixed). And by resolved, I mean that the scope bar appears and disappears when it is supposed to each and every time the search is activated and cancelled (not just the first time). The scope bar doesn't interfere with touch events upon initial display of the view controller. And there are no visual glitches no matter what the horizontal size class is on an iPad. I really hope the UIKit team can get these resolved before iOS/iPadOS 26 GM.

In iOS 26, the Slider control no longer respects the step parameter. For example, import SwiftUI struct ContentView: View { @State private var sliderValue: CGFloat = 16 var body: some View { Slider( value: $sliderValue, in: 0...100, step: 5, onEditingChanged: { editing in print(sliderValue) } ) } } In iOS 18, this prints values like 5, 35, 60, 95, etc. In iOS 26.0 (release version), this prints floats that are not rounded to the nearest 5, and the slider does not snap to values ending in 5. Feedback report number: FB20320542

I paid for the developer account subscription on November 9, and as of now, the status is still pending. I’ve already contacted the support center for help more than three days ago, but I haven’t received any reply or even an acknowledgment email. How do they even operate? The delay is completely unreasonable. Has anyone else experienced the same thing?

Since a few days, I'm trying to fetch our private SPM repo hosted on Azure via Xcode but without success. Actually they now accept only ssh key RSA-SHA2-256 or RSA-SHA2-512. So I created a new SSH key, but it seems the problem persists when I try to fetch spm repo or git clone via xcode: "You’re using ssh-rsa that is about to be deprecated and your request has been blocked intentionally. Any SSH session using SSH-RSA is subject to brown out (failure during random time periods). Please use rsa-sha2-256 or rsa-sha2-512 instead. For more details see aka.ms/ado-ssh-rsa-deprecation. remote: ERROR_SSH_UNSUPPORTED_CIPHER (7) (-20)" Even so I'm choosing the good new ssh key, it seems Xcode is sending wrong information about the new generated ssh key. Anyone is experiencing the same here?

0 CoreText TDecorationRun::CalculateGlyphIntersections(CGAffineTransform, TRun const&, double, double, std::__1::function<void (double, double)> const&) const + 1704 1 CoreText TDecorationRun::CalculateGlyphIntersections(CGAffineTransform, TRun const&, double, double, std::__1::function<void (double, double)> const&) const + 1440 2 CoreText void TDecorationRun::DrawDecorationRun<(anonymous namespace)::TRunAdapter>(CGContext*, (anonymous namespace)::TRunAdapter, (anonymous namespace)::TRunAdapter, double)::'lambda'(CGPoint, CGPoint)::operator()(CGPoint, CGPoint) const + 508 3 CoreText TDecorator::DrawDecoration(TLineDrawContext const&, TLine const&, TInlineVector<DecorationOverride, 30ul> const*) + 2356 4 CoreText TLine::DrawUnderlines(CGContext*) const + 104 5 CoreText TLine::DrawGlyphs(CGContext*) const + 292

Just wanted to clarify some expected behaviors here. It seems that there are two distinct behaviors for Live Activity flows for freshly installed apps. When you start a Live Activity for the first time and the user hasn't yet clicked on Allow/Don't Allow in the activity interface, there are two different sequences: Starting a Live Activity locally Request a Live Activity locally via Swift Live Activity starts .pushTokenUpdates is immediately triggered, even if the Allow/Don't Allow buttons appear under the Activity UI Starting a Live Activity via push-to-start Send a push-to-start notification to launch a Live Activity Live Activity starts .pushTokenUpdates is not triggered, and .pushToken returns nil. If a user clicks on Allow in the Activity UI, only then is .pushTokenUpdates triggered.