Hi everyone, when I was doing some testing on macOS 15 + Xcode 16 Beta 4 I noticed that my app's performance took a significant hit. A simple task that previously was completed within 15 seconds or less now took about a minute to complete. I came to the conclusion that the only plausible cause could be the way .task {} and asynchronous functions are handled. Starting several .task{} and calling async functions from within using macOS 14.5 and Xcode 15.4 results in following log output: task1 started task3 started task2 started task4 started --> task2 ended --> task3 ended --> task4 ended --> task1 ended` Running the same code on macOS 15.0 + Xcode 16 Beta 4 will result in the following log output: task1 started --> task1 ended task2 started --> task2 ended task3 started --> task3 ended task4 started --> task4 ended In the first example the code is executed in 'parallel'. All tasks are started and doing there respective work. In second example a task is started and we are waiting for it to complete before the other tasks are started. I could start to rewrite my code to get the results I desire, however I'm wondering if this is a bug in regards to macOS 15 + Xcode 16 Beta 4 and the way .task {} and asynchronous functions are handled. The output is quite different after all. What's your take on this? If you want to try it out for yourself you can use the following sample code: import SwiftUI struct ContentView: View { func func1() async -> Int { print("task1 started") var myInt: Int = 0 while myInt < 999999999 { myInt += 1 } print(" --> task1 ended") return 1 } func func2() async -> Int { print("task2 started") var myInt: Int = 0 while myInt < 999999 { myInt += 1 } print(" --> task2 ended") return 2 } func func3() async -> Int { print("task3 started") var myInt: Int = 0 while myInt < 999999 { myInt += 1 } print(" --> task3 ended") return 3 } func func4() async -> Int { print("task4 started") var myInt: Int = 0 while myInt < 999999999 { myInt += 1 } print(" --> task4 ended") return 4 } var body: some View { VStack { Text("Hello, world!") } .task { await func1() } .task { await func2() } .task { await func3() } .task { await func4() } } } #Preview { ContentView() }

So any time I create a class that's both @Observable and Codable, e.g. @Observable class GameLocationManager : Codable { I get a warning in the macro expansion code: @ObservationIgnored private let _$observationRegistrar = Observation.ObservationRegistrar() Immutable property will not be decoded because it is declared with an initial value which cannot be overwritten. I've been ignoring them for now, but there are at least a half a dozen of them now in my (relatively small) codebase, and I'd like to find a solution (ideally one that doesn't require me to write init(decoder:) for every @Observable class in my project...), especially since I'm not sure what the actual consequences of ignoring this might be.

Hi, I'm new to swift but have experience with coding in general. Following the app dev training tutorial, came across this line of code: var wrapper: ErrorWrapper { ErrorWrapper(error: someVal) } My question is, why not just do this... var wrapper: ErrorWrapper = ErrorWrapper(error: someVal) Is it a conventions thing or is there some purpose, code seems to work either way. My understanding of closures is that they are just lambda functions, so in the first codeblock, all it's doing is calling a function that returns the instantiated ErrorWrapper object. Why not just assign the variable to it?

Example1: let num = NSDecimalNumber(string: "0.123456789012345678909") let formatter = NumberFormatter() formatter.numberStyle = .decimal formatter.usesGroupingSeparator = true formatter.maximumFractionDigits = 25 formatter.minimumFractionDigits = 25 formatter.minimumIntegerDigits = 1 let str = formatter.string(from: num) ?? "" print(str) output "0.1234567890123460000000000" Example2: let num = NSDecimalNumber(string: "12323.123456789012345678909") let formatter = NumberFormatter() formatter.numberStyle = .decimal formatter.usesGroupingSeparator = true formatter.maximumFractionDigits = 25 formatter.minimumFractionDigits = 25 formatter.minimumIntegerDigits = 1 let str = formatter.string(from: num) ?? "" print(str) output "12,323.1234567890000000000000000" How to correctly format the contents of the above two inputs？

Hello! I have an application written in Objective-c/C++ and I would like it to have support for OTA updates. I implemented the logic through two executable files, one of which was responsible for launching and updating the first, but this option did not pass Apple's review. Could you tell me how this functionality can be implemented and so that it meets the requirements of the App Store.

I think I found a bug in the Objective-C++ compiler, linker, or runtime. Here’s the scenario: We have a macOS app written in Swift. To control hardware from a 3rd party manufacturer, we use a couple SDKs provided by the manufacturer. The SDKs use dynamically loaded libraries and the interface is defined in C++ headers. To bridge between our Swift code and the C++ APIs we have a private Cocoapod that wraps the 3rd party interface with Objective-C++ classes. The two SDKs each provide an interface for discovering attached devices using a callback class that the programmer provides. By accident we named both callback implementations DiscoveryCallback, but this was not a compiler error because neither class was publicly declared, and each was defined in the .mm file where it was used. However, the problem we’re seeing is this: We want to discover Videohub devices, so we register a new instance of DiscoveryCallback (defined in the same .mm file as this code) with the Videohub SDK. A Videohub device is connected and the SDK calls a method on our callback. Surprise! The callback we registered in step 1 was actually the one intended for Decklink devices, defined in a completely different .mm file. This violates all sorts of assumptions and our app quickly crashes. The funny thing is, the two implementations of DiscoveryCallback have completely different method names. The Videohub SDK is supposed to be calling NewVideohubDevice, yet somehow it successfully calls DeckLinkDeviceArrived on an instance of a class it shouldn’t even know about. So the compiler has checked that our intended DiscoveryCallback matches the protocol that the SDK expects, but at runtime the compiled code instantiates a completely different implementation of DiscoveryCallback and somehow doesn’t immediately fail; we still call a method on it that doesn’t even share a name with the intended target. I imagine at this point the method names are long forgotten and are just pointers in a table. I don’t know if this is a bug in the compiler, the Objective-C++ runtime, or if this is just “working as designed” undefined behavior that I should have avoided by not giving two private classes the same name. I know it’s possible to use a private API simply by redeclaring it in my own code, and this seems related to that, but I feel like the compiler or linker should have warned me that I had two implementations of the same class, or if that is not an error, then the runtime should have instantiated the class that was privately defined in the same source file where it was used. Obviously I can’t share our entire project; I’d like to provide some sample code that replicates the issue, but I don’t have time to do that right now. I’m posting this to see if other developers have had a similar experience.

When i try to run break statement in default case, it doesn't run and shows 'Closure containing control flow statement cannot be used with result builder 'ViewBuilder'' error.Why it doesn't run and how to solve this trouble?

Hi, everyone. I am trying to print out “Hello, world” by creating a Command Line tool project. I try to type “swiftc Hello.swift” to compile it in the terminal but instead of having a file named Hello.swift, I have a file named by default Hello.xcodeprojec. How I can solve this issue?

For some time now Xcode has been downloading crash reports from users of my app about crashes related to arrays. One of them looks like this: ... Code Type: ARM-64 Parent Process: launchd [1] User ID: 501 Date/Time: 2024-07-18 14:59:40.4375 +0800 OS Version: macOS 15.0 (24A5289h) ... Crashed Thread: 0 Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x00000001045048b8 Termination Reason: Namespace SIGNAL, Code 5 Trace/BPT trap: 5 Terminating Process: exc handler [1771] Thread 0 Crashed: 0 MyApp 0x00000001045048b8 specialized Collection.map<A>(_:) + 596 1 MyApp 0x00000001045011e4 MyViewController.validateToolbarButtons() + 648 (MyViewController.swift:742) ... The relevant code looks like this: class MyViewController { func validateToolbarButtons() { let indexes = tableView.clickedRow == -1 || tableView.selectedRowIndexes.contains(tableView.clickedRow) ? tableView.selectedRowIndexes : IndexSet(integer: tableView.clickedRow) let items = indexes.map({ myArray[$0] }) ... } } The second crash looks like this: ... Code Type: X86-64 (Native) Parent Process: launchd [1] User ID: 502 Date/Time: 2024-07-15 15:53:35.2229 -0400 OS Version: macOS 15.0 (24A5289h) ... Crashed Thread: 0 Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 4 Illegal instruction: 4 Terminating Process: exc handler [13244] Thread 0 Crashed: 0 libswiftCore.dylib 0x00007ff812904fc0 _assertionFailure(_:_:flags:) + 288 1 MyApp 0x0000000101a31e04 specialized _ArrayBuffer._getElementSlowPath(_:) + 516 2 MyApp 0x00000001019d04eb MyObject.myProperty.setter + 203 (MyObject.swift:706) 3 MyApp 0x000000010192f66e MyViewController.controlTextDidChange(_:) + 190 (MyViewController.swift:166) ... And the relevant code looks like this: class MyObject { var myProperty: [MyObject] { get { ... } set { let items = newValue.map({ $0.id }) ... } } } What could cause such crashes? Could they be caused by anything other than concurrent access from multiple threads (which I'm quite sure is not the case here, as I only access these arrays from the main thread)?

I am getting an following error while compiling the Fortran file with "gfortran TEST_1_fortran_only_fixed.f" ld: unsupported tapi file type '!tapi-tbd' in YAML file '/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/lib/libSystem.tbd' for architecture x86_64 collect2: error: ld returned 1 exit status Please help me to solve this issue

Just when I think I am finally starting to understand Swift I come across a gotcha like the following: I have two object, a swiftui display and one of data to be displayed. Ok, sounds easy. The data is read out of a JSON file so I have a set of arrays and dictionaries. The data is valid when read, it is definitely there, but when I go to display it, its gone. Just vanished. Wasted about a day on this so far, and I’ve seen it before, the inability to pass out of an object an array or dictionary with contents intact. If I create an array var, and not let the system do it, contents are preserved. So, in the data object I’ll have something like this: struct DataObject{ var item: [String:Any] item=JSONData serialized out of memory, and may have say, 12 fields } In my SwiftUI module I have: var item=dataObject.item dataObject.item now has 0 fields. I can allocate and initialize a dictionary in DataObject and those elements come through fine. So it seems like the stuff being serialized from JSON is being deleted out from under me.

Hi all, I just wanted to ask how people were using ModelActor with the Swift 6 language mode enabled. My current implementation involves passing the ModelContainer to my ModelActor, which worked in Sonoma and previous betas of Sequoia, however in the current Beta 3, I get this error: "Sending 'self.modelContext.container' risks causing data races" I am a bit confused by this, as from what I understand, ModelContainer conforms to Sendable, so ideally this error should not be thrown. Is this a bug in Beta 3? Thanks in advance.

Why doesn’t deinit support async? At the end of a test, I want to wipe data from HealthKit, and it’s delete function is asynchronous.

We use XCode 15.2 to build our application, but we found that the app crashes on iOS 12.1.1, while it works without crashing on iOS 12.5.7. We discovered that the crash is related to ImageLoaderMachO::doModInitFunctions. We're not sure what is causing this.

When I run the code, xCode shows me this error "Expressions are not allowed at the top level" While the code is correct and runs in the main.swift file only. And also runs in online compilers. please give me solution...

Hi @all, I get follow error: needs -Onone Swift optimization level. how can I solve this? thank you for the help greeting Fabian

I came across a useful repo on GitHub: https://github.com/GianniCarlo/DirectoryWatcher/blob/master/Sources/DirectoryWatcher/DirectoryWatcher.swift self.queue = DispatchQueue.global() self.source = DispatchSource.makeFileSystemObjectSource(fileDescriptor: descriptor, eventMask: .write, queue: self.queue) self.source?.setEventHandler { [weak self] in self?.directoryDidChange() } self.source?.setCancelHandler() { close(descriptor) } self.source?.resume() How do I translate this to OC version? I have an app that was written in OC and I plan to incorporate this directory watcher into the project.

During my analysis of the binary size changes after compiling Swift source code, I discovered symbols with the ".island" suffix. I couldn't find meaningful information about this suffix through my search, so I decided to reach out for assistance. While comparing the changes in binary size after modifying specific code, I noticed a significant increase (from 33MB to 520MB). Upon analyzing the symbols of the enlarged binary using the nm command, I found the following pattern: t _$s12{SomeSymbol}WOb t _$s12{SomeSymbol}WOb.island t _$s12{SomeSymbol}WOb.island2 t _$s12{SomeSymbol}WOb.island3 When I output the symbols of the binary using nm, I noticed many symbols with the same name but different ".island", ".island2", ".island3" suffixes. Disassembling the binary showed that functions with these suffixes simply delegate calls sequentially: x.island3 -> x.island2 -> x.island1 -> x. It appears that these symbols serve as delegates for function calls, but I would like to understand why such duplicated functions with these suffixes are generated. Could someone help me to provide some insights on this matter?

I'm the developer of 8th (https://8th-dev.com), which compiles the program at run-time, on the device. There used to be an iOS version which worked, but it seems things have changed since then. I'm trying to distribute an iOS version of an app written in 8th, and am encountering "SIGKILL - CODESIGNING" when trying to execute freshly compiled code. I am doing the 'sys_icache_invalidate' thing after writing into a mmap'ed bit of memory (rwx). I'm not writing into memory that was codesigned, so I don't know why the error is that. Anyway, the question is: is it possible any more to do what I used to be able to do?

'consume' applied to value that the compiler does not support. This is a compiler bug. Please file a bug with a small example of the bug. public func requestTopicsAndSubTopics() async throws -> (topics: [Topic], subTopics: [String: [SubTopic]]) { var subTopics = [String: [SubTopic]]() let topics = try await getTopics().sorted { $0.index < $1.index } try await withThrowingTaskGroup(of: ([SubTopic], String).self) { [weak self] group in guard let self else { return } for topic in topics { guard let topicId = topic.id else { throw Error.missingId } group.addTask { let subTopics = try await self.getSubtopics(topicId: topicId).sorted { $0.name < $1.name } return (consume subTopics, topicId) } } for try await (resultedSubTopics, topicId) in group { subTopics.updateValue(resultedSubTopics, forKey: topicId) } } return (consume topics, consume subTopics) }