Xcode 12.2 beta just showed up in the More downloads section. But 12.0 is still missing.

That's the seed, KMT and not the final release. Note that there are a total of 4 downloads for the GM seed (Xcode itself, command-line tools, etc.). For the final release version there are only two of the four elements there.

Excellent; it's now there.

It took a week to convince Apple Developer Support to add the missing Xcode 12.1 item to the 'More' downloads page. Very frustrating. They kept saying to get it from the Mac App Store. I don't do that myself since, as Claude31 noted above, it's generally faster. Also, I like to have the .xip files around just in case I need to easily go back to a prior version. For example, I think it was an early 11.x (11.2?) version that caused havoc if your storyboards contained UITextView. So at that time, it was very easy for me to just unzip the old version and copy over. All throughout the 11.x releases, the download was available in the 'More' section within 24 hours. But with 12.x, I've had to complain twice now. I suggested that they write a unit test that would fail if an Xcode release doesn't show up there.

Oops; forgot to close this thread. Yes, it was possible to re-use an app name at the same company. Deleted the old app, and was able to add a new app (different bundle ID) with the same name.

Thanks for finding that highlighting issue, BabyJ. You're correct in that it appears that when initially presented, an alert or action sheet will not be using the proper accent for the button normal states. But during interaction, the accent is then used. I have created a sample Xcode project showing the issue and filed feedback: FB8994751

Just stumbled upon this myself. I know I have recently created fresh projects and set the deployment to 14.0. I want to say it was with earlier Xcode 12.x versions? Anyhow, I haven't done any testing with such a setting, but you can select 'Other' and type in a version. e.g. 14.0 or 12.0 Still, it's curious as to why Apple is hiding those initial versions. Perhaps those OS versions are not recommended to have anymore? e.g. enough serious issues found where they are hoping developers will just target the dot versions instead. Just a guess. For me, I'll just pick 14.1 for my new projects. By the time I'm done, iOS 15 release will be right around the corner. For iOS 12.0, I see no problems in requiring 12.1 or even 12.3. The quantity of iOS 12 years is very small and for those that cannot update past 12.x, I would assume they'd probably at least be applying all the security and other updates.

Thankfully, shortly after writing the above, I found a working solution. Inside your app project (that wants to use shared SwiftUI views) you cannot use folder references or create "new group without folder" that will contain the shared items. Instead, I created a regular group inside my app project (just for organization). Then, dragged in the shared views/items. File system: IIKit Views IIAboutView.swift MyApp MyApp.xcodeproj MyApp IIKit + Views (note that this folder is empty; doesn't contain a copy of the IIKit items) Xcode main window: MyApp IIKit Views IIAboutView.swift (location of this is the "real" IIKit shared folder items) MyApp Views ... Completely non-intuative. Going to file a bug since in all my trials, the shared code resides in the same location on disk. Xcode should have worked with either folder references are when placing the shared items inside folders created with "new group without folder".

Nope; the only reason the above worked was because I was using a workspace. But dragging around the shared files ultimately messed that all up. When I recreated an App project, no matter how I drag in the shared source, it cannot be previewed. Folder reference, In a group with/without a folder. An alias also fails since Xcode just dumps the alias file's contents itself into the Xcode editor. Finally, for good measure, tried a swift package as follows, but that also fails. I can live with some of the SwiftUI issues I've been experiencing; most have decent workarounds. But this issue is a deal killer if I cannot share code across my projects. At least with the shared Storyboard file in my UIKit projects, each project would display that storyboard a-ok. So why should a SwiftUI preview be any different? Swift package steps... Created a brand new iOS single view app project. Added a new SwiftUI file (MyView) that simply uses the defaults from the template (i.e. body has a single Text element). Preview at this point works a-ok. Created a new Swift package and added it to the exiting project. Dragged MyView.swift into the package Sources and it will now no longer preview (Cannot preview in this file - active scheme does not build this file).

What the... when searching forums earlier, had a typo, but finally found some threads regarding the preview error. For example: active scheme does not build this file - https://developer.apple.com/forums/thread/117487 In that thread, one solution was to ensure that the file's location (in the Xcode Identity and Type inspector) is set to Relative to Project instead of Relative to Group. So... I re-created groups without folders in my Xcode project. Re-dragged in the shared source. But the preview then worked! Location is set to Relative to Group which makes sense. So why oh why did the first several times of doing this all fail? I had even restarted Xcoded, deleted all derived data earlier this morning during the above trials. Makes not sense that this would just magically start to work. ARG... Created a brand new project to see if now repeatedly will work. Nope! In the project that just started to work, I had previouslly tried the Swift package (but have since deleted that package). So my new theory is that this Xcode project got some configuration added whereas the new project doesn't. Time to compare the project files for clues.

Solution found: At most one Xcode project can be open that contains your shared SwiftUI views. Read on for final details on this crazy journey The plot thickens... Now the project where it started to magically work now fails again. I also found no differences in project settings between all my attempted projects. Also, the original project the houses that shared SwiftUI view... it too now fails with cannot preview in this file... Zapping that project's derived data fixes the issue. Re-opened separate project that had worked above. Still fails. Zapped its derived data. Preview still fails. Zapped shared project's derived data. Preview works! Appears that derived data that is messing up everything. NOTE: For my shared views, I had "wrapped them" inside their own project. But this is most likely messing things up since I have a single SwiftUI file I want to share, but the build system cannot deal with that setup. Then tried the following (also fails). Created a simple folder structure on my data drive (IIKit folder containing a Views subfolder containing IIAboutView.swift). Deleted all derived data. If I open one of my app project, preview works. Once I try to work on another project (even when closing the first), preview dies there. Re-opening the original project, preview dies there too. My derived data is set to "Unique". Tried "Shared" same issues... but then... Previews started to work again. Then it finally clicked. As long you only have one Xcode project open at any given time that uses the shared SwiftUI view source, all is well! I can easily now repeat the issue by opening a second Xcode project. Previews now fail with that error. You have to then close all Xcode projects and just open one. I believe during this morning's vast majority of attempts, I had my IIKit project open. Not a huge deal to only have a single Xcode project open at a time. At least a workaround exists. Will though still file a bug.

Thank you very much nokey4 and Claude31. I hadn't got to the part of working with keyboards yet, but my app does indeed need to modify the return button type as well as to have control over the first responder. And agreed, Claude, in that it seems SwiftUI is only ready for either static displays of information, or very basic interactions. What I will do is to continue to build out a sample app with all the things I need. Then file bugs and annotated the code with FIXMEs referencing the feedback numbers. Hopefully we'll all see these things fill in over time. Once my sample is all working, that should then be the trigger to move to SwiftUI.

Agreed Nick. I started with Swift when it first came out and there were some things that were indeed quite painful. I'm glad though to have started at that point though. And since around five years ago, I have only written Swift code. Nokey4, understood, but I would only move to SwiftUI if I can completely move to it. If having to deal with hosting view controllers and write code to work with the underlying UIKit items, I prefer to stick with pure UIKit instead. Agree that SwiftUI is the future. All we can for now though is to keep filing those bugs.

Appears to be an Apple bug. I got this to happen in all my apps that have a navigation stack with two or more view controllers on it. Long press the back button and you'll get that UILog message. Doesn't matter if the menu has a single item, or multiple items. Also duplicated this in a sample master detail iOS project and attached that to feedback: FB9033847

Very late reply, and I will seek a final answer as I'm in the same boat. I do recall many years back that developers were not allowed to remove localizations as that was deemed removing functionality. I'm hoping this will now be allowed. I localized my main app to eight other languages I believe back in 2011. But these days, the income made outside the US and Canada is effectively zero. And, I have yet to recoup the costs for these localizations. This is ultimately preventing me from adding new features to the app as my income per year is far less of what the additional localization work would cost (since I need eight languages).