Wes Davis (via John Gruber, Mastodon):
Instagram head Adam Mosseri just announced a video editing app called Edits. Mosseri said the app is meant to rival CapCut, a video editing app that went offline along with TikTok. Edits is available for preorder on the iOS App Store.
Wesley Hilliard (MacRumors):
The Edits app announcement was likely planned to take advantage of the TikTok ban and entice people to move to Instagram Reels right away. Videos posted from Edits to Reels will get performance metrics provided in the app.
[…]
Apple has worked at the edges of social media for years without diving all the way in. The company is still clearly bruised after the failure of Ping.
Despite that, many apps and features on iPhone toe the line between fun tool and social platform. One of those tools was Clips, which arrived in 2017 to little fanfare and has been forgotten since.
Baz:
I don’t know about CapCut or Edits, but Clips was a half-arsed copy of the editor built in to TikTok (although I’ve not used that for a few years either).
The best thing about Clips was it made your videos stand out from TikTok-made ones as it had different effects. UI-wise, it was just a clone.
John Gruber:
Apple makes a lot of apps, and they could easily afford to assign a team to make Clips truly great. It’s no different than 20–25 years ago, when Apple dedicated itself to making iMovie and Final Cut both great apps. It’s no different than the motivation to create GarageBand.
[…]
There are actually a lot of interesting UI ideas in Clips. But if Apple isn’t interested in making Clips truly great for people who actually love editing videos using their phones, they should just abandon it. Make it great or give up. Keeping it around as an also-ran that no one uses is a bad look. This is the sort of thing Apple should pride itself on: best-of-breed creative tools.
John Gruber:
Clips is alarming, a dead canary.
Greg Pierce:
Mark my words, Apple’s Journal app is the next Clips. Clever, well executed. Then abandoned. Also like Clips, and in a more glaringly limiting way, iPhone only. Could be amazing, but no reason to invest in it as a user.
Previously:
CapCut Clips Edits Instagram iOS iOS 18 iOS App Meta TikTok Video
Douglas Hill (Bluesky):
Is there a best practice for implementing description and debugDescription for main actor classes with Swift strict concurrency?
Currently, he’s checking the current thread and not trying to read the object if it’s the wrong one.
I’ve run into a similar issue with Core Data. Managed objects are supposed to be confined to a single queue, but it’s easy for them to leak, as they get included in the user info dictionaries of notifications and errors. If you try to log an error you’ll get undefined behavior or a crash if com.apple.CoreData.ConcurrencyDebug is enabled.
Maybe it’s OK to override description and dispatch it to the correct queue. The object knows its own context, after all, and the context knows the queue. But I’ve always had the suspicion that performing within description could cause a deadlock or something. So, instead, I sometimes try to catch Core Data errors and generate/store the description before they cross the thread boundary.
Concurrency Core Data iOS iOS 18 Mac macOS 15 Sequoia Programming Swift Concurrency
Lawrence Abrams (via Ric Ford):
As you can see below, a fake USPS shipping issue and a fake unpaid road toll text were sent from unknown senders, and iMessage automatically disabled the links.
While neither of these phishing lures is new, we noticed that these smishing texts, and others seen recently, ask users to reply with “Y” to enable the link.
Bruce Schneier:
But because they came from unknown phone numbers, the links did not work. So—this is the new bit—the messages said something like: “Please reply Y, then exit the text message, reopen the text message activation link, or copy the link to Safari browser to open it.”
I saw it once, and now I am seeing it again and again. Everyone has now adopted this new trick.
iOS iOS 18 Mac macOS 15 Sequoia Messages.app Phishing Short Message Service (SMS)
Kyle Wiggers (Hacker News):
Google says it has begun requiring users to turn on JavaScript, the widely used programming language to make web pages interactive, in order to use Google Search.
In an email to TechCrunch, a company spokesperson claimed that the change is intended to “better protect” Google Search against malicious activity, such as bots and spam, and to improve the overall Google Search experience for users.
[…]
One of Google’s motivations here may be inhibiting third-party tools that give insights into Google Search trends and traffic. According to a post on Search Engine Roundtable on Friday, a number of “rank-checking” tools — tools that indicate how websites are performing in search engines — began experiencing issues with Google Search around the time Google’s JavaScript requirement came into force.
John Gruber:
But the bottom line is that with this change, Google Search is more of an app than it is a website.
[…]
Whether it’s a justifiable decision or not, I don’t buy for a second that it’s a necessary decision on Google’s part. Thus I find this decision sad, but given the course Google has been on for the last 15 years or so, I’m also unsurprised. Old original Google was a company of and for the open web. Post 2010-or-so Google is a company that sees the web as a de facto proprietary platform that it owns and controls. Those who experience the web through Google Chrome and Google Search are on that proprietary not-closed-per-se-but-not-really-open web.
[…]
Here’s a good thread on Hacker News discussing the change, with some interesting commentary on the state of the no-JavaScript web. Also worth pointing out that Kagi, the best search engine in the world, works fine without JavaScript.
Previously:
Google Search JavaScript Web
