Search results for

Building for iOS Simulator, but the linked and embedded framework ‘XX.framework‘ was built for

186,301 results found

Post

Replies

Boosts

Views

Activity

Reply to Cannot build archive when using xcodebuild -archive
Guess everyone building a fat lib will have this problem. The arm64 architecture for the simulator (Apple Silicon) conflicts with the arm64 built for a device and LIPO doesn't want to merge. In my build, I just force the architecture to x86_64 and i386 when building for the sim. Now, just need to figure out cocoapods with this changes... Edit: https://stackoverflow.com/questions/63607158/xcode-12-building-for-ios-simulator-but-linking-in-object-file-built-for-ios
Topic: Programming Languages SubTopic: Swift Tags:
Sep ’20
Persistent "Framework 'Flutter' Not Found" Error When Building iOS Simulator
I'm currently facing a recurring issue while attempting to build my Flutter app for the iOS simulator. The build process fails with the following error Error (Xcode): Framework 'Flutter' not found Error (Xcode): Linker command failed with exit code 1 Steps I've Taken: Recreated the ios/ folder and cleared derived data: Used flutter clean to clean the project. Reinstalled CocoaPods with pod deintegrate followed by pod install. Verified Configuration: Checked AppDelegate and framework paths within Xcode. Set the deployment target to 14.0 in the Podfile. Additional Actions: Performed flutter clean again, followed by removal of Pods, .symlinks, and Flutter.framework under ios/. Updated CocoaPods, ensured all dependencies in pubspec.yaml are current. Added FirebaseCore initialization in AppDelegate.swift to resolve previous Firebase integration issues. Despite these efforts, the Framework 'Flutter' not found error persists. Here's the
1
0
1.1k
Jan ’25
Reply to Framework does not load on simulator
Hei guys,I also have the same or a similar problem. I have a workspace with several app projects, framework projects and pods, where some framework project depends on other framework projects and the app projects depend on different framework projects and pods.The framework dependencies are registered under Embedded Binaries on each target. There the path to each framework refers to build/Debug-iphoneos. And I have no idea how to change that, except if I manually edit the project file. And it looks like that path comes from this attribute sourceTree = BUILT_PRODUCTS_DIR; In the Build settings of the app target where the dependencies are used, the Pre-configuration Build Products Path is set to $(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME), but this always gets compiled into build/Debug-iphoneosIs there any variable which at run phase will provide correctly iphoneos or iphonesimulator, depending whether
Feb ’17
Using separate device and simulator frameworks
We're incorporating a third-party framework into our iOS app. It is provided to us as two separate frameworks, one with arm64 code (for devices), and one with x86 code (for the simulator).How do I include these frameworks in my iOS Xcode project such that if I target the simulator, the simulator version of the framework gets linked and embedded, and if I target a dervice, the device version gets linked and embedded?Most people online try to make a fat Framework, but as I understand it, cross-platform Frameworks have never been supported by Xcode.How does Xcode handle this with the OS Frameworks? I guess you never have to embed those, but I do nee to embed my framework.Thanks.
3
0
5.2k
Sep ’17
iOS, embedding and distributing frameworks.
Hi everyone, I have to encapsulate some frameworks in one for distributing purpose. So, let suppose that we have the following frameworks Framework1, Framework2, ..., FrameworkN, and we have to distribute all in one - FrameworkAll, that is/contains a common wrapper over all those frameworks, wrapper that should be the FrameworkAll public api . What is the recommended & correct way to do this? How about nested frameworks in app store review? Should I consider to build Frameworks$[1..n] as a statics libraries? Any hint or advice would be welcome, thanks an advance.
1
0
527
Dec ’21
Reply to Xcode/iOS Simulator running with x86_64 instead of arm64 architecture
[quote='772788021, Thiru_Adla, /thread/772788, /profile/Thiru_Adla'] why Xcode still expects frameworks with x86_64 architecture. [/quote] Xcode supports arm64 apps for the iOS simulator, and has since the introduction of Apple silicon Macs. The problem arises when I use FFMPEG frameworks, these frameworks are working on arm64, so they should work on iOS Simulator Libraries need to rebuild for the iOS simulator to support Apple silicon Macs. Having arm64 support that is originally intended for an iOS device is not enough, it needs to be specifically built for the simulator, so the errors you are seeing in your project are probably enumerated in Technote 3117. Since you're using a third-party library, you should be looking for their support in getting an updated build that supports the iOS Simulator with an arm64 architecture. If you're using the library in your Xcode project i
Jan ’25
building for OSX, but linking in object file built for iOS
Hi.I'm trying to build some software written in C on a Mac (a Mac Mini to be specific) such that the software can be used with iOS running on an ARM chip. The Mac is running OS X v10.10.5, and it has Xcode v7.2.1 installed.Building the software as static libraries seems to work fine. But when the build tried to build dynamic libraries, I saw this error:ld: library not found for -ldylib1.10.5.oclang: error: linker command failed with exit code 1 (use -v to see invocation)The build is specifying an -isysroot qualifier with this as the value:/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdkThere is a file named dylib1.10.5.o in this directory:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/libBut there is no such file in what I guess would be the corresponding directory for the iPhone:/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/
3
0
5.2k
Oct ’17
Reply to xcode 9 ld: library not found for -lswiftSwiftOnoneSupport for architecture x86_64
Hi,Any further updates on this? I added the -L/Library/Developer/CommandLineTools/usr/lib/swift_static/macosx/ to 'the other linker flags' and I have my codebase on two machines, 1 is giving me the same swiftUIKit error as above and the other is giving me the following:ld: warning: URGENT: building for iOS simulator, but linking in object file (/Library/Developer/CommandLineTools/usr/lib/swift_static/macosx/libswiftCore.a(KnownMetadata.cpp.o)) built for OSX. Note: This will be an error in the future. ld: warning: URGENT: building for iOS simulator, but linking in object file (/Library/Developer/CommandLineTools/usr/lib/swift_static/macosx/libswiftFoundation.a(Foundation.o)) built for OSX. Note: This will be an error in the future. ld: framework not found CoreServices for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)
Oct ’17
Reply to Auto switching between a Device and Simulator Framework
If you can have the framework project present in the same workspace as your application, you can try this:Use a shared build folder for your workspace and/or individual projects (File > Workspace/Project Settings > Advanced > Build Location)Build your frameworks targeting 'iOS Device so that when the frameworks are added the references are valid (if you select a simulator for this step, this won't work, ...who knows why this is necessary)Add the framework(s) to the project that is going to use them (probably under linked frameworks and libraries), and once they show up on the project navigator, select each one and make sure that Location (under file inspector, on your right side pane) is set to Relative to Build Products. This will make your project looks for them using the BUILT_PRODUCTS_DIR environment variable, so no relative or absolute paths will be embedded in your project file (
Topic: UI Frameworks SubTopic: AppKit Tags:
Jun ’15
Reply to Building for iOS Simulator-x86_64 but attempting to link with file built for iOS Simulator-arm64 in Xocde 12
I can't run the simulator anymore on MacBook Pro & Xcode 12. What's the fix for this? library built using clangm64 -miphoneos-version-min=9.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk App built using standard arch linker output: building for iOS Simulator-arm64 but attempting to link with file built for iOS Simulator-x86_64
Dec ’20
Reply to ITMS-90426: Invalid Swift Support when uploading VisionOS app to Appstore Connect with dylib
[quote='765288021, FrankNDB, /thread/765288, /profile/FrankNDB'] I also need to include a c++ library, which I've added as a dylib [/quote] This is the source of the error message. Pure dylib files are not supported on Apple's platforms except for macOS. Placing content in a bundle says: iOS, watchOS, and tvOS support third-party frameworks but don’t support third-party standalone dynamic libraries, which are those outside a framework bundle, typically with the .dylib filename extension. The only exception to this rule is the Swift system libraries provided by Xcode. Treat visionOS as iOS in this context. This library needs to be built and embedded as a framework, which defines a specific layout of the binary and supporting files on disk within the application bundle. TN2435: Embedding Frameworks In An App is an older, but still relevant resource for how to accomplish this. If this library is one you build yourself, you
Oct ’24
Reply to Universal Frameworks and Requirements for Deployment
This doesn’t depend on the architectures for which the frameworks are built, it depends on the platforms for which the frameworks are built—and in our ecosystem, devices and simulators are considered different platforms. Therefore, if you’re developing and deploying for macOS, the provider of the frameworks should build them as a universal binary for x86_64 and arm64 architectures since both architectures are in use on one platform. However, if you’re developing and deploying for iOS, the provider of the frameworks should provide separate simulator and device frameworks, since those are separate platforms and must not be combined into a single binary, regardless of the architectures involved. (A simulator binary can have both arm64 and x86_64, after all, since the simulator runs on both macOS architectures.)
Jul ’24