Just to clarify, it is build 4100 that adds native Apple Silicon support.
We weren’t originally able to include it because we had to backport Mac arm64 support to Python 3.3, since we include that for compatibility with ST3 packages.
I don't think the community, or Sublime HQ, would benefit much from an open-source version. I do, however, believe it would be amazing if they released their UI library. I think we are all curious to know how text rendering is done, how UI elements are drawn, is it using GPU or not, OpenGL/DirectX? etc.
ST3 is pure software rendering using Skia. Releasing our UI toolkit wouldn't be of much value to others as we regularly make changes and refactor things that break API compatibility. No one wants to use a UI toolkit that has next to no documentation and is constantly changing underneath them.
Excellent to see the continual progress of my favourite text editor. So long as the quality bar stays high and the price doesn’t become unreasonable, Sublime Text has a customer in me.
It simply means that it has been built for the ARM processor (as opposed to intel, which all previous Mac apps were built for) and therefore does not need to run in the Rosetta emulation layer.
Practically speaking most users probably won’t notice a difference. Apple silicon native apps might be a bit faster and use less battery than their intel counterparts.
Programming languages like C, C++ and Objective C are compiled to machine code. Apple Silicon support means it is compiled for the ARM instruction set rather than x86. The Apple M1 chip can execute either, ARM code natively and x86 through the Rosetta translation layer. Native ARM code will run a bit faster.
In theory this is done by changing a flag to the compiler. In practice most code needs some changes. They also had to get ARM versions of any pre-compiled libraries, and there may be some differences in how to interact with the operating system. If they used any hand-written assembly code that also had to be rewritten.
it means it has native binaries for Apple M1 chip. so if you are on Apple M1 (latest macbook pro 13", mac mini) then the app will run slightly faster and take less memory.
If you are not on Apple M1, then it makes no difference to you
We kindly ask that users who are interested in being part of the ST4 beta join the Discord server, and that download links not be shared outside of that community.
This allows us to have a better feedback loop and tighter communication.
Offtopic: It's crazy that 1 product from Apple made all developers working on perfecting their ARM support in the world, I think the impact it will have in the server space is still underestimated.
Seems like a strage thing to invest Resources into. Minority computing, minority hardware, with a minority of programmers, on a text editor that doesn't need intensive processing power. Maybe Apple paid for it so they could get a headline out of it? All of this seems incredibly unnecessary.
Has sublime has ran out of things to work on? LateStageTextEditors
Some time in the not so distant future all apple computers will run Apple Silicon. VSCode now has AS support. These text editors do a lot of indexing work in the background and can easily hit the CPU quite hard while doing that. It's not unheard of for the fans on my intel mac to spin up when I first open a new project in Sublime Text, anything that makes it more efficient is welcome in my eyes.
Possibly the biggest differentiator that Sublime Text has going for it is its lack of bloat/overhead compared to it's rivals, which use Electron or the JVM. If you hand-wave away the performance cost of Rosetta you are eliminating their biggest advantage.
I been using ST4 with LSP Package ( Community Package ), It is enough in my use case... to forever remove VSCode.
I am looking at removing IntelliJ soon. I cant remember the last time I used CLion/IntelliJ... only times is using it for debugging hard issues... Maybe if I get better at LLDB/GDB I would never need clion.
Might be minority of programmers, but I'd bet it's actually a significant percentage of the users (probably including the developers and the early adopters on their Discord). They might not be looking at the entire market for text editors, but more at keeping their current users happy. Just my speculation though...
We weren’t originally able to include it because we had to backport Mac arm64 support to Python 3.3, since we include that for compatibility with ST3 packages.
Edit: I should note that my original tweet thread has a few more details https://twitter.com/wbond/status/1379401771911643136
I didn't know v4 was coming out soon, but I'll probably upgrade just to stay on the bleeding edge and to support independent development.
What does it mean for an app to have Apple Silicon support? How to check if my app has it?
Practically speaking most users probably won’t notice a difference. Apple silicon native apps might be a bit faster and use less battery than their intel counterparts.
In theory this is done by changing a flag to the compiler. In practice most code needs some changes. They also had to get ARM versions of any pre-compiled libraries, and there may be some differences in how to interact with the operating system. If they used any hand-written assembly code that also had to be rewritten.
If you are not on Apple M1, then it makes no difference to you
https://download.sublimetext.com/sublime_text_build_4101_x64...
https://download.sublimetext.com/sublime_text_build_4101_mac...
https://download.sublimetext.com/sublime-text_build-4101_arm...
You need active ST3 license to use this build.
This allows us to have a better feedback loop and tighter communication.
Offtopic: It's crazy that 1 product from Apple made all developers working on perfecting their ARM support in the world, I think the impact it will have in the server space is still underestimated.
Has sublime has ran out of things to work on? LateStageTextEditors
Sure, ARM Macs may be a minority now, but it's hardly a wasted investment when the proportion is only going to increase.
I am looking at removing IntelliJ soon. I cant remember the last time I used CLion/IntelliJ... only times is using it for debugging hard issues... Maybe if I get better at LLDB/GDB I would never need clion.