Apple silicon support preview

Apple Silicon Support

With Apple Silicon hardware being released later this year, what does the path look like for you to get your Electron app running on the new hardware?

With the release of Electron 11.0.0-beta.1, the Electron team is now shipping builds of Electron that run on the new Apple Silicon hardware that Apple plans on shipping later this year. You can grab the latest beta with npm install electron@beta or download it directly from our releases website.

How does it work?​

As of Electron 11, we will be shipping separate versions of Electron for Intel Macs and Apple Silicon Macs. Prior to this change, we were already shipping two artifacts, darwin-x64 and mas-x64 , with the latter being for Mac App Store compatibility usage. We are now shipping another two artifacts, darwin-arm64 and mas-arm64 , which are the Apple Silicon equivalents of the aforementioned artifacts.

What do I need to do?​

You will need to ship two versions of your app: one for x64 (Intel Mac) and one for arm64 (Apple Silicon). The good news is that electron-packager , electron-rebuild and electron-forge already support targeting the arm64 architecture. As long as you’re running the latest versions of those packages, your app should work flawlessly once you update the target architecture to arm64 .

In the future, we will release a package that allows you to «merge» your arm64 and x64 apps into a single universal binary, but it’s worth noting that this binary would be huge and probably isn’t ideal for shipping to users.

Update: This package is now available at @electron/universal . You can use it to merge two packaged x64 and arm64 apps into a single binary.

Potential Issues​

Native Modules​

As you are targeting a new architecture, you’ll need to update several dependencies which may cause build issues. The minimum version of certain dependencies are included below for your reference.

Dependency	Version Requirement
Xcode	>=12.2.0
node-gyp	>=7.1.0
electron-rebuild	>=1.12.0
electron-packager	>=15.1.0

As a result of these dependency version requirements, you may have to fix/update certain native modules. One thing of note is that the Xcode upgrade will introduce a new version of the macOS SDK, which may cause build failures for your native modules.

How do I test it?​

Currently, Apple Silicon applications only run on Apple Silicon hardware, which isn’t commercially available at the time of writing this blog post. If you have a Developer Transition Kit, you can test your application on that. Otherwise, you’ll have to wait for the release of production Apple Silicon hardware to test if your application works.

What about Rosetta 2?​

Rosetta 2 is Apple’s latest iteration of their Rosetta technology, which allows you to run x64 Intel applications on their new arm64 Apple Silicon hardware. Although we believe that x64 Electron apps will run under Rosetta 2, there are some important things to note (and reasons why you should ship a native arm64 binary).

• Your app’s performance will be significantly degraded. Electron / V8 uses JIT compilation for JavaScript, and due to how Rosetta works, you will effectively be running JIT twice (once in V8 and once in Rosetta).
• You lose the benefit of new technology in Apple Silicon, such as the increased memory page size.
• Did we mention that the performance will be significantly degraded?

Источник

.NET Development on Apple Silicon

During the last several days, I’ve been experimenting with an Apple M1 device from the perspective of a .NET Developer using a typical developer toolkit: .NET SDKs, Node, JetBrains Rider, other editors, and mobile emulators.

For .NET developers considering using an Apple M1 for their daily development machine, we’ll see what it is currently like to work on these devices. The goal is not to get everything to work, but to share the out-of-the-box experience developers will face in adopting an M1 chipset-driven products.

Apple M1?

On November 1st, 2020, through a mesmerizing drone-driven presentation, Apple unleashed its first chip explicitly designed for its Mac product line. «Unleash» is an appropriate verb, as with the new chipset, Apple’s claims are to deliver performance and efficiency with no compromises.

M1 delivers up to 3.5x faster CPU performance, up to 6x faster GPU performance, and up to 15x faster machine learning, all while enabling battery life up to 2x longer than previous-generation Macs. — Apple

Apple’s claims are promising from a technical perspective, but what about current real-world usage? One of the current issues facing the transition to M1 is the architectural move from the x86 instruction set to the ARM instruction set. To make the transition smoother for everyone adopting these new devices, Apple has implemented a translation layer called Rosetta 2.

Existing Mac apps that have not been updated to Universal will run seamlessly with Apple’s Rosetta 2 technology. — Apple

Let’s give it a try!

.NET Development

My goal from the onset was to experience what the «average» developer would. I didn’t compile any special runtimes or have access to unique installers. Any developer out there will have access to the same environmental conditions. All experiences occurred with x86 translation via Rosetta 2.

Generally, .NET development comes in two choices: Mono and .NET Core. Developers can work with the .NET Framework through software development kits (SDKs). During this trial, I tested Mono, .NET Core 2.1, .NET Core 3.1, and .NET 5. All SDKs successfully built multiple solutions, from small sample Hello, World applications to complex OSS solutions.

I built projects primarily in Rider, and by using the .NET CLI from a terminal. From an anecdotal viewpoint, the experience was uneventful, which makes it remarkable. Code completion, package additions, and development functionality just worked. Build times were respectable but were slightly slower than my personal six-core i7 MacBook Pro. «Slower» is a relative term, and I believe most folks wouldn’t notice this difference as they did their daily work.

Within the .NET ecosytem, there are different development niches, the largest being ASP.NET, a web framework. While testing several web projects, the local development servers could start and service requests as they usually would. Similar to my experience building projects, it was what most developers would expect from a development environment.

Mobile development is another popular focus of .NET developers. The Xamarin SDK included with JetBrains Rider did not work, but a workaround uses the latest SDK version with Visual Studio for Mac, which Rider will recognize. The current master branch of the SDK is broken, but the team is working to address the SDK issue.

During mobile development, I tested targeting Android and iOS devices with the iOS simulators working as expected. The Android emulator would begin to boot, but the device image would not load. During my testing with Android, I attempted both x86 and ARM images with no success. Experienced mobile developers will likely be using physical test devices, so this might not be a deal-breaker.

The biggest issue that might deter .NET developers is the current lack of debugger support for .NET Core SDK solutions. None of the major .NET editors could attach the debugger to a running process. The attempt to do so would throw a StackOverflowException . Exceptions seem to originate from the kernel with a C method named thread_set_state .

Not surprisingly, the debugger shipped with the Mono SDK runs without issue. Mono is designed to run C# on iOS and Android devices natively. Apple and OSS authors of Mono likely resolved issues facing the Mono runtime before Apple Silicon’s official launch.

Developers focusing on Xamarin, which still uses Mono, should have no debugging issues. While not tested, Unity game developers also use Mono, and I assume that will work as well. All promises of reliability are up in the air for Mono devs utilizing P/Invoke calls down to native system calls. Folks will need to test native system calls on a need-by-need basis.

The .NET team has efforts to make .NET 5 compatible with Rossetta 2. Native support is a goal for .NET 6, with planning already starting.

For folks interested in performance, developer Hank G. has done extensive benchmarking utilizing .NET Runtime test harnesses. Hank G. found the Intel chips outperformed the M1 in some cases. In other instances, the opposite occurred. It’s important to keep in mind that the M1 chipset delivers an enjoyable performance experience at almost half the cost of its MacBook Pro predecessors. The mere fact that it can keep up in benchmarks in an unoptimized state is impressive alone. Few will notice the differences between M1 and Intel for daily usage, even during this Rosetta 2 period.

Thoughts around .NET focused development on an M1 device are generally positive. The development time experience of writing and compiling code is uneventful and yawn-inducing (in the right way – it «just works»!). Developers uncomfortable with bleeding-edge pain will likely think twice before purchasing an M1 device, that is unless minor releases of the SDKs address the debugger issues. Current Xamarin and Unity developers still using Mono will have an overall experience that works.

I’ve focused on .NET, but no one programs in a vacuum… What about dependencies?

Dependencies

Containerization has become a popular way of utilizing external dependencies, and Docker is the de-facto way many developers consume databases, cache providers, and more. Sadly, as of writing this post, Docker doesn’t yet work on the M1 chipset. There are always workarounds:

• Install dependencies locally on the host machine.
• Use remote devices or cloud services.
• Other virtualization approaches on the host.

These workarounds have their drawbacks, like network latency, excessive local resource utilization, general upkeep that containers don’t suffer from, but it does get developers working.

Docker has a preview build that supports Apple Silicon and is currently available to folks in the developer preview program. That said, .NET developers will likely struggle to find ARM container images for current dependencies like SQL Server for Linux or the .NET runtime itself. It’s important to remember how Docker containers work. They utilize calls to the host operating system, so calls need to use the ARM instruction set both inside and outside of containers. Since virtualization is occuring, Rosetta 2 cannot convert x86 containers to run on Apple Silicon.

Docker running on Apple Silicon is only the first step in supporting containerization enabled workflows. Solution vendors will need to build images that utilize ARM instruction sets.

As .NET developers, we also have a reliance on the JavaScript ecosystem to deliver frontend experiences. I’m happy to report that Node seems to work, with NPM packages generally working. There are known node packages that rely on native compilation which may not work, but in my testing I was not able to find an issue. I built and ran our JetBrains Guide Gatsby project with no issues. The project utilizes many dependencies, including Yarn, another package management system.

Conclusion

Overall, I had a positive experience programming .NET on an M1 device. Apart from the .NET debugging issue and Docker currently not working, it’s impressive that almost everything seems to just work with Rosetta 2! And keep in mind, it’s not a matter of if there will come native support for specific development scenarios and .NET; it’s only a matter of when.

Источник

Docker Desktop for Apple silicon

Estimated reading time: 3 minutes

Docker Desktop for Mac on Apple silicon is now available as a GA release. This enables you to develop applications with your choice of local development environments, and extends development pipelines for ARM-based applications.

Docker Desktop for Apple silicon also supports multi-platform images, which allows you to build and run images for both x86 and ARM architectures without having to set up a complex cross-compilation development environment. Additionally, you can use docker buildx to seamlessly integrate multi-platform builds into your build pipeline, and use Docker Hub to identify and share repositories that provide multi-platform images.

Download Docker Desktop for Mac on Apple silicon:

System requirements

Beginning with Docker Desktop 4.3.0, we have removed the hard requirement to install Rosetta 2. There are a few optional command line tools that still require Rosetta 2 when using Darwin/AMD64. See the Known issues section below. However, to get the best experience, we recommend that you install Rosetta 2. To install Rosetta 2 manually from the command line, run the following command:

Known issues

• Some command line tools do not work when Rosetta 2 is not installed.
  • The old version 1.x of docker-compose . We recommend that you use Compose V2 instead. Either type docker compose or enable the Use Docker Compose V2 option in the General preferences tab.
  • The docker scan command and the underlying snyk binary.
  • The docker-credential-ecr-login credential helper.

• Not all images are available for ARM64 architecture. You can add —platform linux/amd64 to run an Intel image under emulation. In particular, the mysql image is not available for ARM64. You can work around this issue by using a mariadb image.

  However, attempts to run Intel-based containers on Apple silicon machines under emulation can crash as qemu sometimes fails to run the container. In addition, filesystem change notification APIs ( inotify ) do not work under qemu emulation. Even when the containers do run correctly under emulation, they will be slower and use more memory than the native equivalent.

  In summary, running Intel-based containers on Arm-based machines should be regarded as “best effort” only. We recommend running arm64 containers on Apple silicon machines whenever possible, and encouraging container authors to produce arm64, or multi-arch, versions of their containers. We expect this issue to become less common over time, as more and more images are rebuilt supporting multiple architectures.

• ping from inside a container to the Internet does not work as expected. To test the network, we recommend using curl or wget . See docker/for-mac#5322.
• Users may occasionally experience data drop when a TCP stream is half-closed.

Fixes since Docker Desktop RC 3

• Docker Desktop now ensures the permissions of /dev/null and other devices are correctly set to 0666 ( rw-rw-rw- ) inside —privileged containers. Fixes docker/for-mac#5527.
• Docker Desktop now reduces the idle CPU consumption.

Fixes since Docker Desktop RC 2

• Update to Linux kernel 5.10.25 to improve reliability.

Fixes since Docker Desktop RC 1

• Inter-container HTTP and HTTPS traffic is now routed correctly. Fixes docker/for-mac#5476.

Fixes since Docker Desktop preview 3.1.0

• The build should update automatically to future versions.
• HTTP proxy support is working, including support for domain name based no_proxy rules via TLS SNI. Fixes docker/for-mac#2732.

Fixes since the Apple Silicon preview 7

• Kubernetes now works (although you might need to reset the cluster in our Troubleshoot menu one time to regenerate the certificates).
• osxfs file sharing works.
• The host.docker.internal and vm.docker.internal DNS entries now resolve.
• Removed hard-coded IP addresses: Docker Desktop now dynamically discovers the IP allocated by macOS.
• The updated version includes a change that should improve disk performance.
• The Restart option in the Docker menu works.

Feedback

Your feedback is important to us. Let us know your feedback by creating an issue in the Docker Desktop for Mac GitHub repository.

We also recommend that you join the Docker Community Slack and ask questions in #docker-desktop-mac channel.

Источник