You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On macOS 14/15, using LanguageModelSession.respond(to:) / streamResponse(to:) with String and defining Tool that returns String fail to compile because String: Generable is only available on macOS 26
Thanks for giving this a try, @tpae. String conforms to AnyLanguageModel.Generable in these lines, which target the default package requirements of macOS 14:
Hey @mattt , thanks for getting back to me. I have a WIP PR for my project here: https://github.com/dinoki-ai/osaurus/pull/112 (fyi there's other issues in the repo but getting stuck with this one for now)
I don't have FoundationModels referenced anywhere, so not sure how it's being resolved.
/osaurus/osaurus/Services/ChatEngine.swift:51:15 Conformance of 'String' to 'Generable' is only available in macOS 26.0 or newer
hey @mattt , i was able to build successfully, after downgrading my XCode to 16. It seems like XCode 26 tries to bundle in Foundation Models even when I don't have any references of it.
hey @mattt , i was able to build successfully, after downgrading my XCode to 16. It seems like XCode 26 tries to bundle in Foundation Models even when I don't have any references of it.
Interesting! That would explain why I was having trouble reproducing this. I was testing on my Sequoia machine with Xcode 16.4 and everything worked fine.
Do you think it might be better to avoid conflicting with Foundation Models for future compatibility?
Alas, the shadowing that creates this conflict is part of the main value proposition of this library — that it's a drop-in replacement. It's inconvenient, but the issue will eventually become moot as more developers move their base target to OS 26 over time.
Back to the earlier point: This seems like a bug in Xcode 26. Or else, it could be something we could fix with the right build settings. I just opened #22, which documents this problem and provides a workaround.
Alas, the shadowing that creates this conflict is part of the main value proposition of this library — that it's a drop-in replacement. It's inconvenient, but the issue will eventually become moot as more developers move their base target to OS 26 over time.
Doesn't this cause it to conflict when FoundationModel is supported?
I don't think it should, no. Here's my understanding of how Swift resolves names to symbols here:
We import Foundation Models, which makes all of the public APIs exported by that module available in the scope of SystemLanguageModel.swift
We declare a new actor named SystemLanguageModel, which shadows a symbol with the same name from Foundation Models, and takes precedence.
Throughout the rest of the file, we use fully-qualified names (e.g. FoundationModels. SystemLanguageModel) to distinguish between the two.
I believe the current test coverage proves that things are working as expected. Are you concerned that this conditional import of Foundation Models is the underlying cause of this issue? Or was this a more general concern about how the project works?
I don't have any issues with the direction of the project, thank you for working on this. My concern was more on the lines of investigation and curiosity. I'm learning through the process and I'm grateful for your guidance.
I will investigate this issue further and report back.
Activity
mattt commentedon Nov 1, 2025
Thanks for giving this a try, @tpae.
Stringconforms toAnyLanguageModel.Generablein these lines, which target the default package requirements of macOS 14:https://github.com/mattt/AnyLanguageModel/blob/8dc8946db62bfc1f24dac4050b2483e431ecea35/Sources/AnyLanguageModel/Generable.swift#L115-L136
Can you please share a code sample, or check that the compiler isn't resolving to
FoundationModels.Generable?tpae commentedon Nov 2, 2025
Hey @mattt , thanks for getting back to me. I have a WIP PR for my project here: https://github.com/dinoki-ai/osaurus/pull/112 (fyi there's other issues in the repo but getting stuck with this one for now)
I don't have FoundationModels referenced anywhere, so not sure how it's being resolved.
mattt commentedon Nov 3, 2025
Thanks for sharing, @tpae. I've got a spare machine that's still holding out on Tahoe, so I'll spend some time today troubleshooting on that.
tpae commentedon Nov 6, 2025
hey @mattt , i was able to build successfully, after downgrading my XCode to 16. It seems like XCode 26 tries to bundle in Foundation Models even when I don't have any references of it.
tpae commentedon Nov 6, 2025
Do you think it might be better to avoid conflicting with Foundation Models for future compatibility?
mattt commentedon Nov 6, 2025
Interesting! That would explain why I was having trouble reproducing this. I was testing on my Sequoia machine with Xcode 16.4 and everything worked fine.
Alas, the shadowing that creates this conflict is part of the main value proposition of this library — that it's a drop-in replacement. It's inconvenient, but the issue will eventually become moot as more developers move their base target to OS 26 over time.
Back to the earlier point: This seems like a bug in Xcode 26. Or else, it could be something we could fix with the right build settings. I just opened #22, which documents this problem and provides a workaround.
tpae commentedon Nov 6, 2025
I agree, I really want this to work. I do see you are importing Foundation Model here:
https://github.com/mattt/AnyLanguageModel/blob/c7c829e034fe6ea73e1d8f657ee8c89813370016/Sources/AnyLanguageModel/Models/SystemLanguageModel.swift#L2
Doesn't this cause it to conflict when FoundationModel is supported?
mattt commentedon Nov 9, 2025
I don't think it should, no. Here's my understanding of how Swift resolves names to symbols here:
SystemLanguageModel.swiftSystemLanguageModel, which shadows a symbol with the same name from Foundation Models, and takes precedence.FoundationModels. SystemLanguageModel) to distinguish between the two.I believe the current test coverage proves that things are working as expected. Are you concerned that this conditional import of Foundation Models is the underlying cause of this issue? Or was this a more general concern about how the project works?
tpae commentedon Nov 10, 2025
I don't have any issues with the direction of the project, thank you for working on this. My concern was more on the lines of investigation and curiosity. I'm learning through the process and I'm grateful for your guidance.
I will investigate this issue further and report back.
tpae commentedon Nov 26, 2025
It seems that if I don't build with Xcode 26, it does not include Foundation Models, even when I'm using macOS 26
mattt commentedon Dec 11, 2025
This may be resolved with #59
mattt commentedon Sep 2, 2026
@tpae I believe #59 resolved this. Can you confirm on 0.9.0? I'll close this in a week or so otherwise.
mattt commentedon Sep 11, 2026
Closing now. Happy to reopen if this is still a problem!
Require Swift 6.3