Mark Gurman:
iTunes has been the way Apple users listen to music, watch movies and TV shows, hear podcasts, and manage their devices for almost two decades. This year, Apple is finally ready to move into a new era. The company is launching a trio of new apps for the Mac – Music, TV, and Podcasts – to replace iTunes. That matches Apple’s media app strategy on iPhones and iPads. Without iTunes, customers can manage their Apple gadgets through the Music app.
Joe Rossignol:
This information lines up with a recent report from 9to5Mac’s Guilherme Rambo, who claimed that iTunes will be renamed to “Music” on the Mac. In other words, iTunes is going away and will be replaced by the new Music app, which is expected to become the new utility for syncing and managing Apple devices.
Allen Pike:
Surprisingly, this new app is said to be based not on the iOS app or a new codebase, but on the venerable iTunes itself.
There will surely be naysayers that claim iTunes should have been tossed entirely. And admittely, if the new Music app ditches iTunes’ interface but can’t cure its deep and baffling love for obtuse modal error dialogs, I too will bemoan its preservation. But arguing for code to be rewritten just because it’s old has never been the right way to build systems that work.
He has a great collection of iTunes error messages.
See also: Stephen Hackett.
Previously: macOS 10.15 to Break Up iTunes.
Update (2019-06-03): Craig Hockenberry:
I haven’t seen it reported elsewhere, but as of last weekend all http://itunes.apple.com links redirect to http://music.apple.com — a likely indicator that the brand is done (the app will be fine for those of us who need it.)
Joe Rossignol:
As noted on Reddit, Apple has abruptly removed all social media content from its iTunes page on Facebook, including posts, photos, and videos. This appears to have happened within the past 24 hours, as a cached version of the iTunes page on Facebook still had content available as of May 31.
See also: Hacker News.
History iTunes Mac Mac App macOS 10.15 Catalina
W3C:
Today W3C and the WHATWG signed an agreement to collaborate on the development of a single version of the HTML and DOM specifications. The Memorandum of Understanding jointly published as the WHATWG/W3C Joint Working Mode gives the specifics of this collaboration. This is the culmination of a careful exploration of effective partnership mechanisms since December 2017 after the WHATWG adopted many shared features as their work-mode and an IPR policy.
Catalin Cimpanu:
Known as the Web Hypertext Application Technology Working Group (WHATWG), this group was formed in 2004 as a response to the W3C’s slow pace of developing a more modern HTML standard, and the W3C’s plans to move HTML towards a variant known as XHTML, with an XML-like structure, which browser vendors at the time did not agree with.
[…]
In many cases, proposed standards would often ship in Chrome or Mozilla even before they were finalized and formally approved by the W3C, showing that most of the time, browser vendors considered getting W3C approval as only a formality, which had little impact on the standards they decided among themselves at the WHATWG.
The two organizations had an official fallout in April 2018, when all WHATWG members -- Apple, Google, Microsoft, and Mozilla -- vehemently and unequivocally opposed the W3C’s plans for approving version 4.1 of the DOM standard.
Laurie Voss:
The W3C has officially acknowledged that it lost control of HTML standards to the WHATWG many years ago.
[…]
[It] essentially just admits what happened already, which is that the major browser makers decide what the web can do. As long as all four are roughly equally powerful I don’t see it being that big an issue.
Update (2019-06-14): Jen Simmons:
Think of all the many HTML elements that were considered and rejected over the years — and we are supposed to be on-board with TOAST? Because a couple guys at Google decided they want it. And they can.
So no to
<footnote>
<author>
<publication-date>
But yes to
<toast>
???
CSS HTML HTML5 Web
Gab (Hacker News):
Progress on our new codebase is going well. For those who don’t know, our plan is to fork existing open source software, Mastodon, which is based on the ActivityPub social networking protocol.
[…]
You’ll be able to log into and use dozens of existing mobile apps that exist on both App Stores with your Gab account and use Gab through these apps.
[…]
Moving to the ActivityPub protocol as our base allows us to get into mobile App Stores without even having to submit and get approval of our own apps, whether Apple and Google like it or not.
App Review’s previous stated rationale for rejecting the Gab app was that the service didn’t do a good enough job of moderating the user-generated content. Gab claimed that they try their best to do this but that Apple’s requirements are impossible to meet. Clearly, Twitter and other social networks don’t always meet them, either. But Twitter is too-big-to-reject, and Gab has a reputation for offensive content, attracting a community of users that were banned or had their posts deleted from Twitter.
This new move is interesting because Mastodon is federated, and as far as I can tell, each sub-community has its own rules. Some of them are probably already less moderated than Gab was, yet they haven’t attracted similar attention, and so the various apps were in no danger of being banned.
I wonder how Apple and Google will respond. I could see them not caring, so long as accessing the Gab content requires typing in a server address. I could also see them requiring apps to actively block that address.
Previously:
Update (2019-07-15): Gab:
Google is now banning open source Fediverse/ActivityPub protocol apps the moment Gab becomes a top trending app.
Our app, like every other Fediverse app, doesn’t have any user content. It can connect to ANY server in the Fediverse. Otherwise it is a blank slate.
We have 7 days to comply with these demands, which are impossible to comply with. The Fediverse is decentralized! We can’t moderate content for thousands of servers we don’t control!
ActivityPub App Store Gab iOS iOS 12 iOS App Mastodon Web
Bruno Rocha:
To put it short, autoreleasepool is still useful in iOS/Swift development as there are still legacy Obj-C classes in UIKit and Foundation that call autorelease, but you likely don’t need to worry about it when dealing with Swift classes due to ARC’s optimizations.
Presumably, pure Swift objects can also be autoreleased when manipulated by Objective-C code. I still find autoreleasepool to be useful, both to reduce peak memory use and to ensure that resources associated with objects will be cleaned up at a particular time.
One pain point has been that XCTestCase doesn’t seem to use pools around its setUp() and tearDown() methods. This led to log messages from Core Data complaining that the SQLite database had been deleted out from under it when the test was over. An autoreleased controller had been retaining the persistent store coordinator.
I ended up making a subclass of XCTestCase with its own lifecycle methods that run inside autorelease pools and are allowed to throw errors.
Automatic Reference Counting (ARC) Core Data Mac macOS 10.14 Mojave Memory Management Programming Swift Programming Language Testing
