Waly Kerkeboom:
Got a new Mac (like I did) and miss the old boot chime?
sudo nvram StartupMute=%00
See also: Mr. Macintosh and Howard Oakley.
Previously:
Update (2020-02-26): Paul McGrane:
It will be interesting to see what this is like on a T1 or T2 Mac during a system software update. I was assuming the main reason it was disabled is there would probably be quite a lot of chimes, to the point of being silly or annoying.
Adam Engst:
When Apple disabled the startup sound by default in 2016, someone discovered that a Terminal command could bring it back […] Unfortunately, that approach stopped working with Mac models in 2017, presumably due to Apple removing the option in a macOS update, and since then, new Macs have started up silently.
[…]
I don’t understand what modern-day Apple has against the startup sound. Sure, make it an option for those who need their Macs to be silent at all times, but it’s a useful indication that the Mac is working as expected—at least to that point in the boot process. Perhaps Apple is trying to encourage the belief that Macs are always available like iPhone and iPads, but reality doesn’t support that.
John Gruber:
Use “01” in place of “00” to turn the chime off.
Update (2020-03-06): Marco Arment:
Finally heard the startup chime on my 16” and I’m so glad I enabled it.
Olivier Roux:
Also very useful as since there is no status light anymore, sometimes you had no way to know whether you had successfully managed to hard reboot your laptop if the screen remained black... startup sound fixes that
Tony Smith:
I had problems with this enabled. If I restart it does the startup chime then powers off again and then back on and played the chime again. Every time I rebooted it did this until I turned the chime off again
Apple T2 Audio Mac MacBook Pro macOS 10.15 Catalina
Ivan Mehta:
Last week, at the 49th CA/Browser Forum, a voluntary consortium of certification authorities, Apple announced that it’ll stop allowing HTTPS certificates on Safari with more than 13 months of validity, later this year.
[…]
As the Register noted, sites like GitHub and Microsoft have certificates with two-year validity. Under Apple’s new rule, these sites will be rejected if these companies will get another two-year certificate after August.
Jason Snell:
The rationale? Shorter certificate lifetimes are safer, for a variety of reasons. For one thing, it prevents a valid (and perhaps abandoned) certificate from being stolen or misappropriated by a bad actor, then used to trick consumers. While there is a process for revoking known bad certificates, it’s cumbersome and many browsers don’t even check the revocation lists.
For another, quick turnaround helps ensure that the certificates are always secured using the latest cryptographic standards.
[…]
The major downside for certificates that expire more often is that it means more work for organizations that have a large number of certificates that they will now need to renew more often.
[…]
At least one previous proposal to reduce the life of accepted certificates has been put to the CA/Browser Forum, but while it was widely supported by browser makers, it didn’t garner enough support from Certificate Authorities to make any head way. So Apple, in its own tried and true fashion, has apparently decided to make a unilateral change for what it believes is the best for users.
Previously:
Update (2020-03-06): Apple:
TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC must not have a validity period greater than 398 days.
This change will affect only TLS server certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS, and tvOS.
Rosyna Keller:
The complaints I’ve heard regarding Apple’s move to 13 month or less TLS cert validity are perfect examples of why the current validity window is too damn long.
For example, “Before, I could completely ignore my site’s security for 5 years and then forget to renew!”
Catalin Cimpanu (via Rosyna Keller):
Google wants to reduce the lifespan of SSL certificates (used to secure HTTPS encrypted traffic) from the current two years to just over a year.
Troy Hunt:
Which brings me to the second point: certificate renewal should be automated and that’s something that you simply can’t do once identity verification is required. DV is easy and indeed automation is a cornerstone of Let’s Encrypt which is a really important attribute of it. I recently spent some time with the development team in a major European bank and they were seriously considering ditching EV for precisely this reason. Actually, it was more than that reason alone, it was also the risk presented if they needed to quickly get themselves a new cert (i.e. due to key compromise) as the hurdles you have jump over are so much higher for EV than they are DV. Plus, long-lived certs actually create other risks due to the fact that revocation is broken so iterating quickly (for example, Let’s Encrypt certs last for 3 months) is a virtue. Certs lasting for 2 years is not a virtue, unless you’re coming from the perspective of being able to cash in on them...
See also: Accidental Tech Podcast and Rich Trouton.
Update (2020-06-11): Dean Coclin:
Chrome joins Apple in limiting public TLS certificates to 398 days starting Sept 1st.
iOS iOS 13 Let’s Encrypt Mac macOS 10.15 Catalina Safari Security SSL/TLS Web
Tim Hardwick:
Despite pushback from Apple, the European Parliament in January voted overwhelmingly for new rules to establish a common charging standard for mobile device makers across the European Union. This article explores what form the EU laws might ultimately take and how they could affect Apple device users in Europe and elsewhere.
To reduce cost, electronic waste and make consumers’ lives easier, Members of the European Parliament (MEPs) want “binding measures” that ensure chargers fit all smartphones, tablets, and other portable devices.
[…]
A progress report provided by the MoU signatories in February 2013 indicated that 90 percent of the new devices placed on the market by the signatories and other manufacturers by the end of 2012 supported the common charging capability. But that statistic was so high only because it took into account the fact that Apple offered a Lightning to micro-USB adapter.
One member of the Commission would note: “[…] The future MoU must be clear in its outcome, we cannot afford to admit adaptors.”
Matt Birchler:
Second, this is addressing a problem that I think we all suspect is going away shortly anyway. Every Apple laptop charges with USB-C. The new iPad Pros released in 2018 use USB-C. Every Mac they sell is all in on USB-C (some would say to a fault). It’s just the iPhone that’s not using the standard, and we all pretty much agree that it’s only a matter of time (1-2 year max) before they switch over there too.
Third, what do we do in 5 years when there is a successor to USB-C that is better in every way? Are phone makers expected to wait for the EU to approve that new connector before they can use it?
Previously:
European Union Hardware iPhone Legal Lightning Power USB-C
Dave Verwer:
The iOS Developer Community Survey is the largest public survey of Apple platform developers ever undertaken. Data collection happened over four weeks between 6th December 2019 and the 7th January 2020. In that month, 2,290 people filled in the questionnaire. This site presents the raw data collected, along with analysis and opinion based on that data.
Dave Verwer:
Almost 70% of people are writing 100% of their personal/hobby Apple platform code in Swift. Given that company/team restrictions and the impact of an existing codebase is much less of an issue in personal/hobby projects. I think this question is a good indicator of developer interest in the language, and what this tells me is that Swift is dominating.
When it comes to apps written for a company, you might expect the number to fall. It does, but not by much.
Larger companies seem to use more Swift than smaller ones.
Dave Verwer:
An average satisfaction of 8.3 is obviously very high, even more so when you think of how critical we developers can be about the languages we use!
[…]
But I believe there are some slightly worrying signals revealed by this question. Only ~66% of people think that Swift is in good hands at Apple? Only ~59% of people believe that the evolution process is working well?
I’m generally like how the language has been evolving, but the progress on tooling and reliability have been frustrating.
The most interesting questions to me are that 75.5% say that they have a “Completely separate/independent codebases for each mobile platform” (I expected much lower) and that 60% say they would use SwiftUI in a new app to ship soon (also expected lower).
Interest in Mac development seems to be low, and respondents who were interested in Mac development preferred Catalyst and SwiftUI to AppKit, which does not bode well for the quality of future apps.
Apple has been talking a lot about machine learning and augmented reality and adding lots of stuff to the frameworks, but interest seems relatively low.
42% of apps were completely free or donationware, with 21% using subscriptions.
App Store App Subscriptions Artificial Intelligence Augmented Reality Business Catalyst (Marzipan) Cocoa Core Data iOS Mac Programming Swift Programming Language SwiftUI Xcode
