Ryan Christoffel:
Hurricane Helene has caused massive damage and taken over 100 lives across several US states. Many thousands of people are without power and/or cell service. But in the wake of the storm, reports have surfaced about a key iOS 18 feature that has been a lifeline for survivors: Messages via satellite.
[…]
To learn more about Messages via satellite, Apple has a support document available here.
Satellite messaging was added in iOS 16 (for iPhone 14 and newer) but only supported contacting emergency services. With iOS 18, you can also contact family and friends when there’s no Wi-Fi or cellular coverage.
Eric Berger:
Unfortunately, the National Climatic Data Center is based in Asheville, North Carolina. As I write this, the center’s website remains offline. That’s because Asheville, a city in North Carolina’s Blue Ridge Mountains, is the epicenter of catastrophic flooding from Hurricane Helene that has played out over the last week. The climate data facility is inoperable because water and electricity services in the region have entirely broken down due to flooding.
[…]
So how does a region nearly 500 miles from the Gulf of Mexico become devastated by flooding from a hurricane that originated there?
The answer is that Helene’s rapid movement inland—it was one of the fastest-moving storms at landfall in the Gulf of Mexico in recent history—created a massive river of atmospheric moisture and funneled it into parts of North Carolina, northern Georgia, and southeastern Tennessee.
Kanishka Singh:
The White House said on Monday dozens of Starlink satellite systems that provide high-speed internet access were in use in North Carolina, with over 100 more in transit to areas devastated by Hurricane Helene.
Tommy Greene (Hacker News):
Spruce Pine sits about an hour northeast of Asheville, Mitchell County, and is home to the world’s biggest known source of ultra-pure quartz—often referred to as “high-purity quartz,” or HPQ. This material is used for manufacturing crucibles, on which global semiconductor production relies, as well as to make components within semiconductors themselves.
[…]
Spruce Pine supplies around 70 percent of the naturally occurring HPQ that is needed for computing devices and products. The site’s market position and significance were underlined in 2019 when a manager for Quartz Corp, one of the two main mining companies that works the deposit, told the BBC: “Inside nearly every cell phone and computer chip you’ll find quartz from Spruce Pine.”
Previously:
Emergency SOS via Satellite iOS iOS 16 iOS 17 iOS 18 Processors Starlink
Paul Haddad:
Anyone know why calling the following in a MainActor class/func
MyTest.increment(1) { result in
NSLog("result=\(result)")
}
crashes (asserts) when building with Swift 6?
I get that its not happy that the completion is coming in on another dispatch_queue but it should complain about it at compile time, or ignore it at run time.
Unfortunately, it seems to be designed this way.
OneSadCookie:
SE-0423 “Dynamic actor isolation enforcement from non-strict-concurrency contexts” adds the crash (otherwise your “safe” Swift 6 code is unsafe).
It’s not that the code is unsafe but that neither the Swift compiler nor the Swift runtime can prove that it’s safe because the MyTest class is written in Objective-C. You are supposed to annotate your Objective-C code so that Swift Concurrency can understand it, though this is not really documented.
Doug Gregor:
In Swift 5 mode, this code silently introduces a data race into the program.
In Swift 6 mode, the data race is caught by the dynamic isolation check. That’s the first point at which the data race can be detected, and the check is there to prevent this race from becoming weird runtime behavior.
This is all as designed. If that Objective-C code were Swift 6 code, we’d catch the error at compile time. As Objective-C, runtime is the earliest it’s possible to detect the race. Enabling Swift 6 language mode means turning previously-unobserved or undiagnosed data races into ones that fail predictably to flush out any contract violations outside of the Swift 6 code. As more code enables Swift 6, the runtime checks get replaced with compile-time.
Swift 6 mode is being “helpful” by proactively crashing the app even though there’s not necessarily a problem. It may be that it just doesn’t understand that GCD is being used to call everything on the right thread.
I get why Swift 6 is designed this way, but I don’t understand how you’re supposed to make the transition. Swift 5 mode gives no errors at compile time and doesn’t even log any errors at runtime. Swift 6 mode gives no errors at compile time and crashes at runtime. To get from one to the other you’re supposed to go through the code line-by-line and not make any mistakes.
Personally, I’m skeptical of the benefit of switching to Swift 6 mode with a hybrid codebase. If you started off with good code, it seems more likely that you’ll get some annotation wrong and have Swift 6 trigger an unnecessary crash than that you actually discover a latent concurrency bug that matters. I think it makes more sense to migrate the code to Swift before flipping the switch. Then you can get errors at compile time instead of at runtime.
Mike Apurin:
I think that Swift 5 mode doing nothing is part of the problem here.
I’ve run in similar issues in Combine and was very blindsided by it. There is no way to progressively discover and deal with such isolation violations, just enabling 6 mode and praying.
But this illustrates that porting your code to Swift doesn’t fully solve the problem, either. It seems that you still have to annotate your closures because of Apple’s code.
Matt Massicotte:
The core problem, in my opinion, was Combine was not updated and that’s bananas.
Previously:
Combine framework Grand Central Dispatch (GCD) iOS iOS 18 Language Design Mac macOS 15 Sequoia Objective-C Programming Swift Concurrency Swift Programming Language
Anthony Ha (Hacker News):
Apple faces a looming deadline to produce what it says are more than 1 million documents related to recent App Store changes.
On Friday, Judge Thomas S. Hixson denied the company’s attempt to extend that deadline, describing the request as “bad behavior.” So Apple’s deadline is still Monday, September 30: “It’s up to Apple to figure out how to meet the deadline, but Monday is indeed the deadline.”
[…]
In August, a judge directed Apple to produce all documents related to how it decided on the new App Store rules. But on Thursday, Apple said Epic’s search terms surfaced more than twice as many documents as expected, so the company needed two more weeks to review what turned out to be “north of 1.3 million documents.”
Ben Lovejoy:
A second judge in the Apple versus Epic Games lawsuit has implied that the Cupertino company has lied to the court. It comes after the original judge strongly implied that Apple had not told the truth about the reasons for its new App Store policy.
A second judge tasked with overseeing Apple’s disclosure of decision-making documents in the antitrust case said that a court filing made by the company was “simply not believable” …
[…]
Apple had claimed its decision wasn’t financially motivated, despite the 27% commission being identical to 30% less the 3% typically charged by payment processors (which would now be paid by Epic). The judge expressed skepticism, and ordered the iPhone maker to hand over all documents leading up to it decision to continue charging commission even on sales made outside the App Store.
[…]
In a response (spotted by The Verge), the Judge Hixson has rejected that request, and said that Apple’s claim that it had only just discovered this error was “simply not believable.”
Wesley Hilliard:
The Epic vs Apple saga resulted in an injunction forcing Apple to remove its anti-steering rules, but Epic wasn’t happy with Apple’s implementation. After more back and forth, Apple was meant to produce 1.3 million documents related to the App Store rules, but it produced something else unexpected on Monday.
Apple has filed for the court to set aside its injunction based on two new sets of precedents that didn’t exist when the injunction was filed. The 32 page court document goes into excruciating detail, and was first shared by X user Vidushi Dyall.
Basically, Apple says the injunction is no longer viable given two specific cases that took place in recent months — Beverage vs Apple and Murthy vs Missouri. The first is a state case that establishes Apple’s anti-steering rules aren’t unfair, and the second is, well, complicated.
Jeff Johnson:
The weird thing about the continuing Epic Games v. Apple case is that Epic is still banned in the US App Store, so even if they win on the anti-steering charge, they can’t take advantage of any remedy.
Previously:
Antitrust App Store Apple Epic Games Fortnite iOS iOS 18 Lawsuit Legal
Jeff Johnson (Mastodon, Hacker News):
Does this prompt appear monthly? No, that would be far too convenient. So how often? Every. Single. Time. You. Try. To. Disable. Bluetooth.
Have I mentioned that Apple re-enables Bluetooth on every OS update on purpose? This behavior continues with macOS 15. Also, Bluetooth is notorious for security vulnerabilities; just google site:support.apple.com bluetooth “security content”.
The prompt warns that I “won’t be able to use a Bluetooth keyboard or mouse,” despite the fact my Mac mini already has a USB keyboard and mouse plugged in. Indeed, the Mac isn’t using any Bluetooth devices, and macOS knows this but doesn’t care. Moreover, the Bluetooth prompt appears even when all Bluetooth-related features are disabled such as AirDrop and Handoff. There’s no “intelligence” to the prompt.
[…]
The issue isn’t whether the existence of a warning makes sense. The issue is that the warning can’t be suppressed. The prompt has no “Don’t ask me again” checkbox.
Phillip Cohen:
thankfully, looks like you can still turn it off without a confirmation by using the shortcut action, but still ridiculous
Jeff Johnson:
The prompt also appears on macOS 14.7 (but not macOS 13.7).
The prompt does not appear on laptops.
Previously:
Bluetooth Mac macOS 15 Sequoia Shortcuts
