Post not yet marked as solved
Why is running Xcode under Rosetta essential to your workflow? Perhaps there’s some other way to achieve what you need.
Based on your description, it also sounds like glib may install its own signal handling. That would be another area of investigation to determine why your own signal handler isn’t being invoked.
Post not yet marked as solved
The latest version of Create ML is delivered in Xcode, so you should be able to download and install the Xcode 12 beta to get it.
Post marked as Apple Recommended
A widget is a kind of app extension, and therefore must be deployed within an app.
The new functionality in SwiftUI is part of the SwiftUI framework that’s delivered with macOS 11, thus it’s not something you can back-deploy to an earlier macOS.
Post not yet marked as solved
Please file feedback about the issue you’re running into.
Note that you no longer need to generate an Xcode project from a Swift package; you can use$ cd path/to/SomePackage
$ xcodebuild -scheme SomePackage
to build it with Xcode, which includes support for Xcode’s resource file types.
Post not yet marked as solved
Xcode 12 does not currently include a project template that demonstrates how to use Core Data with the SwiftUI Life Cycle option. You can, of course, set up a Core Data persistence stack by hand and use that in your application, including with the SwiftUI Life Cycle; all the non-SwiftUI Life Cycle project template does is add code and a data model to your project.
Post not yet marked as solved
The LLVM/clang compiler and Swift compiler provided with Xcode are configured not to load plug-ins for security.
Post not yet marked as solved
If you use your extension in another application whose language you have set to Spanish, does it also show your extension in Spanish? I would expect the localization used for an extension to match the localization of the app in which the extension is invoked, not the app that the extension is a part of.
Post not yet marked as solved
It’s often useful to implement a tool by putting most of its logic in a framework, and just making the tool a thin front-end. This makes it very simple to localize, because you can use the same techniques to localize the framework as you would to localize an application. It also makes the logic in the tool more testable, because you can call it from unit tests built against the framework. Finally, it makes it easy to transition your tool into an application, because the logic can be cleanly separated from the front-end. The downside is that you have more than one thing to install wherever you’re going to use it.
As quinn said, you may be better off with an application structure, or possibly even an application: One approach might be to create a very simple application that has both a framework and a command line tool inside it. The framework would contain most of the logic, while the applciation and the tool would both be front-ends to that logic. The application, for example, could work via drag-and-drop, or present a window allowing you to perform some very common functionality, while the command line tool could provide a more complex interface.
Post not yet marked as solved
There is not currently an API for creating extensions of the iWork applications. If there’s something you’d like to do with them that’s not available via their scripting interface or via Accessibility, please file feedback describing your use case.
Post not yet marked as solved
All of the details on the Universal App Quick Start Program are on the web, here: https://developer.apple.com/programs/universal/
Post not yet marked as solved
Often virtualization software requires an update to work with a new version of macOS due to underlying system changes.
What version of VMware are you trying to use, and what version of macOS are you running it on?
Post not yet marked as solved
Yes you can! Both Core Data and SQLite work within SwiftUI.
With respect to Core Data, if you create a new project in Xcode and select either the NSApplication Delegate or UIApplication Delegate life cycle, a “Use Core Data” checkbox will be available. Selecting this checkbox will cause additional code to be added to the new project to initialize a Core Data persistence stack and propagate an NSManagedObjectContext through the application for your UI code to use.
As for SQLite, it’s a lower-level API so there’ll be more work involved in deciding how best to wire it into and use it from your application, and there’s no provided templates demonstrating how to do this since most developers’ persistence needs should be well-addressed by Core Data.
Post not yet marked as solved
In general your application should use the system-provided language selection rather than provide its own mechanism.
To provide the best user experience, your application should also implement support for the standard UI state saving and restoration mechanisms. That way if a user switches away from your application to Settings, changes their preferred language and region for your application, and switches back to your application, the experience will be seamless.
