How to Change the MacOS High Sierra System Font to Lucida Grande

Change macOS High Sierra System Font to Lucida Grande

Do you wish you had Lucida Grande as the system font in macOS High Sierra? Wish no more, it’s possible to easily change the system font away from San Francisco and to the fan favorite Lucida Grande again in macOS 10.13.

Some of you are probably confused so let’s cover some quick background; Some Mac users may prefer the older Lucida Grande system font that existed on Mac OS for many years prior to the introduction of Yosemite, where it was changed to Helvetica Neue, and then again in El Capitan and onward where the system font changed again to San Francisco. The difference between the system fonts is subtle but noticeable in overall spacing and thickness, and some users may prefer one to the other. If you’re one of us who enjoys the easy-on-the-eyes Lucida Grande font and you’re running macOS High Sierra, you can use a nice little tool to easily switch between those two system fonts on your Mac. System font readability is one of those topics that some users care greatly about, and others could not care any less about and won’t even notice. Obviously if you don’t miss the older Lucida Grande system font then you’re probably not the target audience for this particular tool. But if you do, it’s super easy to change in macOS High Sierra and this utility is a great little add-on.

How to Switch the macOS High Sierra System Font to Lucida Grande

You should backup your Mac before using this utility. It’s very unlikely something will go wrong, but if something does you’ll be glad you have made a fresh backup beforehand. Also, it’s good practice to routinely back up your Mac anyway 🙂

  1. Get macOSLucidaGrande from Luming Yin’s Github page here
  2. Launch macOSLucidaGrande, then click on the “Lucida Grande” tab and then click on the green check button to install the font on the Mac
  3. Restart the Mac for the system font change to take full effect

Change the MacOS System Font to Lucida Grande

Once you reboot you will find that Lucida Grande is the default system font everywhere, in menus, title bars, window bars, all system text will be switched over.

For the most part the effects are flawless, but you may notice some curious font issues with groups of browser tabs and various apps, whether or not that is acceptable to you is your choice.

If you decide you’re not into Lucida Grande, you can easily change back to the High Sierra default system font of San Francisco again by relaunching the app and clicking the “San Fransisco” tab followed by clicking the green check button, and again rebooting the Mac.

Restore San Francisco as System Font in Mac High Sierra

The change between Lucida Grande and San Francisco is fairly subtle. Lucida Grande has larger spacing and is a bit thicker, making it easier on the eyes for some users, whereas San Francisco has tighter spacing and is thinner overall. Many users might not even notice the change.

The animated GIF below shows San Francisco versus Lucida Grande in the Finder:

Lucida Grande versus San Francisco system font

For those who care about this sort of thing because they find Lucida Grande easier to read, you may appreciate some other tips to improve the readability of text and fonts on a Mac include disabling transparency effects in Mac OS, increasing interface contrast, and increasing all text and font sizes by changing the Mac resolution. The latter option is less than ideal for many users because it reduces the screen resolution and available screen space on a Mac, but it does make things appear larger as a trade-off. The Mac does not have a bold fonts option (yet anyway), which is unfortunate, but such a feature does exist in the iOS world.

This tool is a revamped version with High Sierra support of something we have covered in the past for Sierra, and has been a topic covered for El Capitan and Yosemite as well. So if you have an older MacOS version as well you can change the font there too if you’d like, though it’s worth pointing out that the macOSLucidaGrande tool works with all modern versions of macOS that used San Francisco, including High Sierra, Sierra, and El Capitan.

Microsoft and GitHub team up to take Git virtual file system to macOS, Linux

One of the more surprising stories of the past year was Microsoft’s announcement that it was going to use the Git version control system for Windows development. Microsoft had to modify Git to handle the demands of Windows development but said that it wanted to get these modifications accepted upstream and integrated into the standard Git client.

That plan appears to be going well. Yesterday, the company announced that GitHub was adopting its modifications and that the two would be working together to bring suitable clients to macOS and Linux.

Microsoft wanted to move to Git because of Git’s features, like its easy branching and its popularity among developers. But the transition faced three problems. Git wasn’t designed for such vast numbers of developers—more than 3,000 actively working on the codebase. Also, Git wasn’t designed for a codebase that was so large, either in terms of the number of files and version history for each file, or in terms of sheer size, coming in at more than 300GB. When using standard Git, working with the source repository was unacceptably slow. Common operations (such as checking which files have been modified) would take multiple minutes.

The company’s solution was to develop Git Virtual File System (GVFS). With GVFS, a local replica of a Git repository is virtualized such that it contains metadata and only the source code files that have been explicitly retrieved. By eliminating the need to replicate every file (and, hence, check every file for modifications), both the disk footprint of the repository and the speed of working with it were greatly improved. Microsoft modified Git to handle this virtual file system. The client was altered so that it didn’t needlessly try to access files that weren’t available locally and a new transfer protocol was added for selectively retrieving individual files from a remote repository.

Internally, this proved successful, with Windows development being substantially migrated to Git in May of this year. But what of the broader Git community?

Microsoft says that, so far, about half of its modifications have been accepted upstream, with upstream Git developers broadly approving of the approach the company has taken to improve the software’s scaling. Redmond also says that it has been willing to make changes to its approach to satisfy the demands of upstream Git. The biggest complexity is that Git has a very conservative approach to compatibility, requiring that repositories remain compatible across versions.

GitHub’s interest and involvement is motivated by the company’s desire to address the needs of enterprise customers. The open source, free GitHub hosting doesn’t need the scaling work Microsoft has done—obviously, if someone is using standard Git, today then standard Git must be good enough for their development process. But on the paid, enterprise side, the situation can be a little different. Certain industries have large repositories that pose problems with Git; for example, game repositories are often physically large not because they have millions of files and decades of history, but because of their large number of graphics and other assets. The scaling improvements that Microsoft has made to Git are useful for this kind of large repository, too. As such, having the same family of improvements available in GitHub will enable the company to better serve these communities.

Microsoft itself has had similar demands from enterprise; the company told us that Siemens wanted to move away from the Team Foundation Server version control to using Git instead. But it’ll only be able to do this once the scaling improvements had been made; right now, TFS version control scales better.

As the name would imply, GVFS requires a file system driver to work. The Windows division worked with the engineering team to add features to Windows to make this efficient. The intent is to eventually make this capability into a supported, extensible API and, at some point, move systems such as the new OneDrive placeholders to use the same API.

Microsoft and GitHub are also working to bring similar capabilities to other platforms, with macOS coming first, and later Linux. The obvious way to do this on both systems is to use FUSE, an infrastructure for building file systems that run in user mode rather than kernel mode (desirable because user-mode development is easier and safer than kernel mode). However, the companies have discovered that FUSE isn’t fast enough for this—a lesson Dropbox also learned when developing a similar capability, Project Infinite. Currently, the companies believe that tapping into a macOS extensibility mechanism called Kauth (or KAuth) will be the best way forward.

Apple developing new 3D sensor system for 2019 iPhone rear camera, according to Bloomberg

Bloomberg today reports that Apple is developing a new 3D sensor system for the 2019 iPhone. This sensor would work differently to the TrueDepth sensor system used for Face ID and would be used to add depth sensing features to the rear camera.

Adding depth data to the rear camera would allow for more advanced augmented reality applications. iPhone X and iPhone 8 Plus simulate depth by using a dual-camera system, and comparing the parallax of the images from the two lenses.

Try Amazon Prime 30-Day Free Trial

Bloomberg says that Apple would use different technology for the rear-camera 3D system than the technology used by the TrueDepth camera system.

The TrueDepth system shines about 30,000 dots outward, which is then captured and analyzed. The distortion of these dots creates the depth map. This is how Face ID gets the 3D data it needs to check for a facial identity match and unlock the device.

The report says the new sensor for the 2019 iPhone back camera relies on a time-of-flight algorithm, measuring how long it takes for a laser to hit an object and bounce back.

However, the TrueDepth tech would remain for the front camera. The new time-of-flight system would only be added for the back-facing camera, according to the supposed Apple roadmap.

KGI’s Ming-Chi Kuo previously reported not to expect major changes to the camera system for 2018, and that TrueDepth will not be the solution for the back camera.

The Bloomberg report does not address whether Apple would abandon the dual-lens camera system if it adopted the Infrared laser 3D sensor, which would be able to create much more accurate depth maps than the disparity maps produced by the parallax optics system.

It is unlikely it would do that, however, as the two-camera system on iPhones is used for more than just measuring depth. The second lens enables a 2x optical zoom and light data from both sensors are sometimes combined to make better quality single photos.

Bloomberg says the motivation for the new rear 3D sensors is augmented reality. Virtual objects would be able to be positioned more realistically if the device knew about the location of physical objects and barriers in a room. Apple CEO Tim Cook has been very bullish on the opportunities in AR; Apple is rumored to be working on a augmented-reality headset for launch as early as 2020.