Real Pic Simulator Key | Added By Users
Julio Cesar Thap
I am trying to get a large (and working on Xcode 11!) project building in Xcode 12 (beta 5) to prepare for iOS 14. The codebase was previously in Objective-C, but now it contains both Objective-C and Swift, and uses pods that are Objective-C and/or Swift as well.
Xcode 12 is actually the stepping stone for Apple silicon which unfortunately is not yet available (when the answer was written). But with that platform we are going to get an arm64-based macOS where simulators will also run on the arm64 architecture unlike the present Intel-based x86_64 architecture.
Xcode usually depends on the "Run Destination" to build its libraries/applications. So when a simulator is chosen as the "Run Destination", it builds the app for available simulator architectures and when a device is chosen as the "Run Destination" it builds for the architecture that the device supports (arm*).
xcodebuild, in the Xcode 12+ build system considers arm64 as a valid architecture for simulator to support Apple silicon. So when a simulator is chosen as the run destination, it can potentially try to compile/link your libs/apps against arm64 based simulators, as well. So it sends clang(++) some -target flag like arm64-apple-ios13.0-simulator in --- format and clang tries to build/link against an arm64-based simulator that eventually fails on an Intel based Mac.
But xcodebuild tries this only for Release builds. Why? Because, "Build Active Architecture Only (ONLY_ACTIVE_ARCH)" build settings is usually set to "No" for the "Release" configuration only. And that means xcodebuild will try to build all architectural variants of your libs/apps for the selected run destination for release builds. And for the Simulator run destination, it will includes both x86_64 and arm64 now on, since arm64 in Xcode 12+ is also a supported architecture for simulators to support Apple silicon.
Simply putting, Xcode will fail to build your application anytime it tries the command line, xcodebuild, (which defaults to release build, see the general tab of your project setting) or otherwise and tries to build all architectural variants supported by the run destination. So a simple workaround to this issue is to set "Build Active Architecture Only (ONLY_ACTIVE_ARCH)" to Yes in your libraries/apps, even for release mode.
I personally don't like the second line since pods shouldn't pollute the target project and it could be overridden in the target settings, itself. So it should be the responsibility of the consumer project to override the setting by some means. However, this could be necessary for successful linting of podspecs.
One thing I was concerned about that what will be the impact of this when we actually archive the libraries and applications. During archiving applications usually take the "Release" configuration and since this will be creating a release build considering only the active architecture of the current run destination, with this approach, we may lose the slices for armv7, armv7s, etc. from the target build. However, I noticed the documentation says (highlighted in the attached picture) that this setting will be ignored when we choose "Generic iOS Device/Any Device" as the run destination, since it doesn't define any specific architecture. So I guess we should be good if we archive our app choosing that as a run destination.
You should initially try to update both CocoaPods and the dependencies for your library/app, and then, if that doesn't work, contact the vendors of any dependencies you are using to see if they have an update in progress to add support for arm64 Simulator slices on M1 Macs.
There are a lot of answers on here marked as correct suggesting that you should exclude arm64 from the list of supported architectures. This is at best a very temporary workaround, and at worst it will spread this issue to other consumers of your libraries. If you exclude the arm64 Simulator slice, there will be performance impacts on apps that you're developing in the Simulator (which in turn can lead to reduced battery time for your shiny new M1 kit while you're developing your amazing ideas).
I was able to "clear out" the VALID_ARCHS build setting by adding it back in as a user-defined build setting (with no values), running the project (which failed), and then deleting the VALID_ARCHS build setting. After that, I was able to run on the simulator.
This ultimately means the built binary and the environment (device/simulator) you're running it in, will need to match. Otherwise some system libraries won't exist on the operating system, or the CPU instructions can't get processed.
During active development, you want to build things fast. It doesn't make sense for you to actively build architectures you don't need to use. That means if you're building into a device, then you only want to build for that platform-architecture combo. You don't want to build the other combinations.
For an app it may make less sense to make an archive for the simulator platform, however for a framework, your consumer is another developer. That developer will be building your framework into a simulator and into a real device. Hence you need to support both platforms and architectures.
If the library named in the error message is from a vendor, seeUpdate pre-compiled libraries fromvendors. If you have source code for the library, rebuild the library as anXCFramework with support for the simulator on Apple silicon. To learnhow to build an XCFramework, see Creating a multiplatform binaryframeworkbundle.
Additionally in big teams, some developers may be on an M1, while some others are on older Intel based MacBooks. You never know maybe some day there'd be an M5 Macbook, that will have a distinct architecture. So it's good to be considerate of how you make your project/product/framework compatible for your own devs and your library consumers.
To be perfectly clear, this was an issue in pre-xcode 12. But not every project setup would face this. You'd only face this if you had some pre-compiled dependency from a vendor (who didn't share their source code, but just shared the FAT binary so you can build the app for both device and sim), otherwise if you had access to the source code then your archive wouldn't contain compilations for both architectures. It would only contain binaries for targeted architecture.
Make sure you look into ALL Project AND Target AND Pod Project AND Pod Target settings. If one of them excludes a certain architecture then you can't build your app for that architecture. Often this could be in your Podfile.
If you pay attention to the error message you get, it should be easy to navigate your way to the target that doesn't support. Once you identify the target, then you have to identify when/where it gets compiled using the notes in the two paragraphs above.
This way you only override the iOS simulator's compiler architecture as your current cpu's architecture. Compared to others, this solution will also work on computers with Apple Silicon.
As of Sep 19, 2022, none of the existing answers worked for me. Most answers suggests to exclude arm64 from build settings, after this is done, it gives fatal error: module map file not found
This is probably not a long time solution, but for quickly addressing the issue. After upgrading to MAC OS 13.5 with Xcode 14.3.1, there is no more open with Rosseta option anymore, but you do the following to run it on Rosseta.
First thing first, to all the developer who are suggesting exclude arm64 for your project will work yes it will compile but after installation when you try to open it, it will show a popup with the message, "the developer of this App needs to be update it to work with this version of iOS". This is because as per apple "In iOS 11 and later, all apps use the 64-bit architecture" and if you exclude arm64 for your project it will not open App on iOS 11 and later.
I was having issues building frameworks from the command line. My framework depends on other frameworks that were missing support for ARM-based simulators. I ended up excluding support for ARM-based simulators until I upgrade my dependencies.
"The Build Settings editor no longer includes the Valid Architectures build setting (VALID_ARCHS), and its use is discouraged. Instead, there is a new Excluded Architectures build setting (EXCLUDED_ARCHS). If a project includes VALID_ARCHS, the setting is displayed in the User-Defined section of the Build Settings editor. (15145028)"
I was able to resolve this issue by manually editing the project file (I could not figure out how to remove the item from the project file using Xcode) and removing all lines referring to VALID_ARCHS. After that, I am able to build for the simulator fine.
I am noticing that these odd USR/USER waypoints are sometimes automatically added into my flight plan in either the SID or STAR section and it's really annoying as to what they are??? They can't be deleted and it seems like this a bug. I have researched and see that others are facing the same issues.
I only saw that today when preparing to land in KBOS. Wanted to shortcut the approach and selected direct to A10 when I realized that it deleted my complete flight plan in the modded neo FMS. Selected then KBOS manually as destination and that became such a user waypoint. Made sense to me. But not that the whole plan is deleted once I select direct to....
A USER fix is one that the sim drops when an approach or Direct To is activated. A USR waypoint is a waypoint on a procedure, usually an approach procedure, that is defined by a non-ICAO waypoint. There's a problem in the way that these waypoints, that are held exclusively in an airport data file and not in the main ICAO database, are parsed and displayed. We are indeed working around this with a revised flight plan manager by loading them in a different way.
Not being able to delete them is a different issue. In the default flight plan management regime, the approach is actually held in a separate flight plan managed by the sim gps engine, separate from the rest of the flight plan, which includes departure, enroute and arrival waypoints. There is not a way in the default flight plan system to amend or alter an approach procedure in any way, so that's why these can't be interacted with. Part of our work is pulling approach waypoints into the main plan to eliminate this limitation, but that's still a pretty big work in progress.
7fc3f7cf58