Archive for October 2, 2020

Friday, October 2, 2020

Introducing Swift Atomics

Karoy Lorentey (Hacker News):

I’m delighted to announce Swift Atomics, a new open source package that enables direct use of low-level atomic operations in Swift code. The goal of this library is to enable intrepid systems programmers to start building synchronization constructs (such as concurrent data structures) directly in Swift.


This is enabled by SE-0282, a recently accepted Swift Evolution proposal that explicitly adopted a C/C++-style memory model for Swift, and (informally) described how regular Swift code interoperates with atomic operations. In fact, most APIs in this new package come from previous incarnations of the SE-0282 proposal: they were originally developed by an extremely productive collaborative effort on the Evolution forum.


Atomic access is implemented in terms of dedicated atomic storage representations that are kept distinct from the corresponding regular (non-atomic) type. (E.g., the actual integer value underlying the counter above isn’t directly accessible.)


All atomic operations exposed by this package are guaranteed to have lock-free implementations. Lock-freedom means that the atomic operations are non-blocking – they don’t ever need to wait on the progress of some other thread to complete their own task.


macOS Big Sur Changes for Developers

Free Pascal (via Frank Reiff):

macOS 11 Big Sur introduces many user interface changes that update the appearance of applications and make them more iOS-like. It also adds support for familiar iOS features — such as SF Symbols and text styles.


By default, toolbars are taller, window titles can display inline with controls, and toolbar items no longer include a bezel.

I’ve found that in order to get the new title bar and the preferences toolbar style, you have to build using Xcode 12. It’s not enough to set NSWindow.toolbarStyle.

Even when using the new SDK, setting NSControlSizeLarge on the view doesn’t give you the new large icon style. To get that, you need to use NSToolbarItem.bordered, which requires macOS 10.15, instead of creating the view yourself. So that means separate toolbar implementations if you want to support macOS 10.14 and earlier. Because I’m no longer creating the view myself, I had to switch from NSSegmentedControl to NSToolbarItemGroup, but unfortunately NSMenuToolbarItem doesn’t work when inside of a group.

My main Mac is still on macOS 10.14, so I’m using #if __MAC_OS_X_VERSION_MAX_ALLOWED < 101600 to make the same code compile with both Xcode 11 and Xcode 12.


Update (2020-11-30): Jeff Johnson:

This blog post describes a few things I found while “adapting” my AppKit apps for macOS 11 Big Sur.

Apple Removes RSS Feed Readers From Chinese App Store

Tim Hardwick (also Slashdot):

Apple has reportedly removed two RSS feed reader apps from China’s App Store to comply with Chinese law. Fiery Feeds and Reeder both tweeted that their iOS apps had been removed in China over content that is considered “illegal” in the country.

Too bad the App Store is the only way to install iOS apps.

John Gruber:

It’s completely unclear what explains the three year gap here, and the entire policy makes no sense. Why ban feed readers but not web browsers? At a technical level, feed readers are just web browsers for RSS feeds. China’s Great Firewall should block feeds (and centralized feed aggregating sources) just as easily as it blocks websites.

Perhaps because the apps make it easier to find content when using a VPN to get around the firewall?


Quality Management in Apple’s System Updates Over Time

Howard Oakley:

Surely the most important way to improve quality is to strengthen quality management processes throughout engineering – the principle of building it right first time, rather than expending more effort at detecting and remediating errors. Simply extending the cycle without changing quality management would be very unlikely to result in any improvement. But better quality management doesn’t entail making the cycle any longer, so cycle length is unlikely to be relevant, as was shown by Apple’s only real two-year development cycle with Mac OS X 10.4 Tiger.

This is right if you’re talking about the quality of next the major release when it first ships. But that’s far less important to customers than the quality at the middle and end of the release. Snow Leopard was not an unusually stable release at 10.6.0, but by 10.6.8 it was legendary, and you could keep using that version until you were happy with the state of 10.7.x. Some customers even skipped 10.7 entirely.

With the yearly release cycle, major versions no longer attain that level of refinement because development stops as Apple moves on to the next reelease. And developers are forced to upgrade earlier because taking advantage of the latest SDK requires the new version of Xcode, which requires a current version of macOS. You can now choose between the still buggy macOS 10.15.7 and the soon-to-be macOS 11.0.0, which will have issues out of the gate, as all releases do. Those are not great choices.

Nick Heer:

For the first few public releases of Mac OS X, Apple stuck to a development cycle of well under a year per release. Beginning with the Panther release in 2003, Mac OS X settled into something closer to an eighteen-month gap between x.0 public releases, with a long exception for Tiger. Then, with Mountain Lion in 2012, Apple stated that its intention was to begin releasing a new version of OS X every year; Mountain Lion had a shorter cycle than its predecessors, but it was still longer than any release after.

In all three eras of MacOS development cycles, you will find versions that are legendary for their refinement, and those which are the complete opposite.

Which recent releases are those? macOS 10.14.6 is better than any 10.15, but it retains it share of issues. macOS 10.13.6 has a common Mail IMAP syncing crash that was never fixed. macOS 10.12 was generally a rough release and retained serious PDF bugs throughout its life. My recollection is that macOS 10.11.6 was probably the best since 10.6.8.


Another Developer Account Nearly Terminated

Liu Qia (via Ying Zhong):

There are currently 8 apps. Among which the “RedLine” (aka 红线) is from January 2019 to the present, there are more than 280k users, and they have been featured by AppStore Today many times, as well as by multiple media.


For more than a year, my apps’ reviews and account status are all very good. Until two weeks ago, I submitted a newly developed app called “One Aim”. This is a simple, clean, single-function app. Like my other works, I did it myself from design to development.

On the evening after submission [of 1.0.1], the app changed status to “in review”. Two days later, the review was rejected, and a notice was received saying that the review needs to be extended, and no details were given.

By the morning of September 23, I received a notice saying that my developer account or other accounts associated with the account were fraudulent, and decided to terminate it.

He appealed but was never told the reason, so soon the “investigation was over and the termination was confirmed.”

After going public with the story:

I received a call from the Apple review team on the morning of October 2nd, telling me that my developer account will not be terminated. After I clearly stated that I have not violated the Apple Developer Guidelines, she hopes to continue developing and submitting apps in compliance with the guidelines in the future, and sent me the reason for rejection of the app which caused this incident, and told me to resubmit it for review after modification.