Closed ghost closed 2 years ago
ghost
commented
3 years ago I found https://blog.inventic.eu/2015/03/os-x-codesign-failed-bundle-format-is-ambiguous-could-be-app-or-framework/ without trying that.
Does this framework use symbolic links?
I have some frameworks in use, but this would be the first with symbolic links. Are these necessary?
fermoya
commented
3 years ago Hi @AshStefanOltmann . This framework shouldn’t have any symbolic link but I might be wrong as it uses a project file to build the xcframework, I could have added a symbolic link there by mistake.
Have you tried adding the xcframework with the latest (non-beta) macOS and Xcode? Is this something that just happens compiling for Rosetta? What about when compiling for arm64?
Just in case, I guess you’ve followed this tutorial to embed the framework. I wrote that a while ago, before the first M1 came out. I’m also thinking that this xcframework is compiled by using the latest Xcode (not the beta version). There might be something different in the compilation there. Something you can try is downloading the repo and executing ./scripts/build_xcframework.sh. Don’t forget to first use xcode-select -s <path/to/beta/>Xcode.app. Then, you could use that binary instead.
I've never seen that kind of error 🤔
ghost
commented
3 years ago I Use Kotlin Multiplatform 1.5.21 to build my shared xcframework which does not support arm64 - this will change with recently released 1.5.30, but for now I can only test Rosetta - and I will need to provide a Rosetta installation for non-M1 user of my app anyway.
Also I do use async/await, so non-beta XCode can't compile my project right now.
I will try to build the framework myself as you suggested.
ghost
commented
3 years ago Same error as before.
It's the resign step that fails.
I have my own shared xcframework and also the Sentry.io framework in my project with "Embed & sign" - no issues there.
/Users/sol/Library/Developer/Xcode/DerivedData/MyApp-fdxfwjrcotubsrgvsztcciskrqlg/Build/Products/Debug/MyApp.app: replacing existing signature
/Users/sol/Library/Developer/Xcode/DerivedData/MyApp-fdxfwjrcotubsrgvsztcciskrqlg/Build/Products/Debug/MyApp.app: bundle format is ambiguous (could be app or framework)
In subcomponent: /Users/sol/Library/Developer/Xcode/DerivedData/MyApp-fdxfwjrcotubsrgvsztcciskrqlg/Build/Products/Debug/MyApp.app/Contents/Frameworks/SwiftUIPager.framework@AshStefanOltmann the xcframework contains a binary for arm64 (the M1). If not supported, could this be the issue?
Is Flutter what you're using? I'm reading a lot of answers where people basically remove stuff from folders:
https://www.gitmemory.com/issue/flutter-webrtc/flutter-webrtc/421/735307303
https://www.gitmemory.com/issue/flutter/flutter/77173/790272366
ghost
commented
3 years ago @AshStefanOltmann the xcframework contains a binary for arm64 (the M1). If not supported, could this be the issue?
I don't know, maybe. Nice that you already provide one. I wait for Kotlin 1.5.30 to be broadly adopted until I can build my shared framework with it.
Is Flutter what you're using? I'm reading a lot of answers where people basically remove stuff from folders:
Nope, no flutter. I use Kotlin Multiplatform Mobile. I build my shared code module with that.
This means I have a native XCode project with a native SwiftUI where I want to include your framework. Kotlin should have no effect here.
fermoya
commented
3 years ago @AshStefanOltmann I cannot test it myself because I don't have a M1. Have you tried what those links I shared above suggest? Technically it's a matter of making sure that the macos-arm64 binary is removed from the binary
ghost
commented
2 years ago Did you fix the problem or is now a "won't fix" solution?
fermoya
commented
2 years ago @AshStefanOltmann i hadn’t gotten any response in a while and that’s why I closed it 🤷🏻♂️
Feel free to reopen and provide more information. I shared a possible solution in my previous comment
ghost
commented
2 years ago @fermoya Your solution of removing the macos-arm64 could only be a workaround for now. In the long-term you need to provide a universal XCFramework for iOS & macOS and both architectures. Otherwise there is unfortunately not much use for me.
fermoya
commented
2 years ago @AshStefanOltmann xcframeworks contain all possible symbols for every single platform supported by Apple. macOS-arm64 refers to the M1 and M2 chips. You’re having problems with Rosetta, which simulates the old Intel chip.
this seems to me as a Kotlin multi platform problem. I’m giving support to the required platforms
Describe the bug The compilation for "My Mac (Rosetta)" on MacBook M1 fails with "bundle format is ambiguous (could be app or framework)".
To Reproduce I added the framework via manual install to my SwiftUI Multiplatform project. It compiles for iOS, but fails for macOS.
Expected behavior Compile.
Screenshots / Videos If applicable, add screenshots to help explain your problem.
Environment: