Daniel Jalkut:
This update adds support for macOS’s standard “Versions” document history, improves the Share Extension to support sending text to MarsEdit, and includes a number of bug fixes across the rich text and plain text editors.
I’m holding off on this update for the moment because I’m seeing a regression viewing and sorting by the Edited Date, but I love the idea of versions support. It works as you’d expect, with a Time Machine–style interface showing two MarsEdit windows, so I get the same font and syntax coloring that I’m used to. It would be nice if it went a bit further and supported synchronized scrolling or coloring for the differences, but it does allow selecting and copying text so I can easily use an external diff tool if necessary. I had been using WordPress’s revisions feature, which is nice in that it colors the differences, but it’s a bit of a pain to pull up, the two-column interface gets in the way of selecting text from only one side, and it only works for posts that have been published to the server.
Previously:
Update (2026-03-30): Jack Wellborn:
I happen to be the one who reported that versions was broken in the first place and am delighted to see it better supported. I wish Apple did a better job surfacing and socializing automatic versioning because it feels magical and fits with a more modern paradigm that doesn’t require manual saving.
The date bug is fixed in MarsEdit 5.4.2.
Update (2026-04-08): Versions in MarsEdit are only available for drafts. Published posts do not store versions (even if you edit and republish) and do not have access to the versions of the draft from before publication.
Mac Mac App Mac OS X Versions macOS Tahoe 26 MarsEdit WordPress
fahad-sh:
I’m exploring macOS development, comparing Mac Catalyst apps vs native AppKit/SwiftUI apps.
- What are the main limitations of Catalyst today?
- In what scenarios is a native AppKit or SwiftUI app unavoidable?
Any insights are much appreciated — I’m trying to understand when Catalyst is sufficient and when going native is worth the extra effort.
Ryan Ashcraft:
Mac Catalyst seems dead to me. Five months since Tahoe’s official release and I still have crashes, ugly layouts and glitches that weren’t a problem pre-Liquid Glass.
I see no option other than build an entirely new SwiftUI-native Mac App.
[…]
I have a huge Foodnoms update that is almost ready, but I can’t ship it, because it would break syncing with the Mac app.
I could load up Sequoia and Xcode 16.4, but Apple is going to stop accepting binaries from 16.4 in April. And the UI compatibility plist option isn’t any better. It’s ugly AF.
Searching the forums, it seems like there a lot of new Catalyst bugs in Tahoe, but it does look like they are being fixed.
Jordan Hipwell:
I shipped Liquid Glass in my Catalyst app and haven’t noticed any crashes or major issues. Most issues are SwiftUI regressions where I decided not to use UIKit 🥲
Greg Pierce:
That pure SwiftUI on Mac idea scares me, too. So many weirdly different things. I think I’m sticking with sprinkling SwiftUI into AppKit where it’s useful to do so.
Previously:
Update (2026-03-20): Adam Bell:
Why are the toolbar icons smushed?
Why is the search bar the wrong colour?
Adam Bell:
Man, Catalyst has so many things busted on macOS 26 (even 26.2).
Toolbars just do not render correctly at all, even a simple SwiftUI app. Works fine in AppKit tho!
Steve Troughton-Smith:
I can’t back that up at all, Catalyst for the most part has been rock solid for all my apps for years now; UIKit has Liquid Glass bugs across all platforms (that SwiftUI will inherit anyway), and AppKit has plenty of its own, but they are all dwindling with each point update.
I am on the Mac idiom on all my Catalyst apps though; Foodnoms is an iPad-idiom app (compatibility mode) so there may be dragons there I’m unaware of, since it uses a completely different behavioral style
Kyle Howells:
I switched fully to using Catalyst for all my Mac projects and haven’t had any issues at all.
Kyle Howells:
Mac native & UIKit, no compatibility mode or SwiftUI. I consider both too buggy as is, let alone combining them.
Catalyst (Marzipan) Foodnoms Mac macOS Tahoe 26 Programming SwiftUI
Tim Hardwick:
A lawsuit brought against Apple by music streaming app Musi has been dismissed by a federal judge, after she ruled that Apple’s developer agreement gives it the right to remove any app from the App Store at any time, “with or without cause.”
[…]
Musi claimed it complied with YouTube’s terms, but Apple pulled it from the App Store in September 2024, following pressure from Sony, the International Federation of the Phonographic Industry (IFPI), and the National Music Publishers Association.
Musi subsequently sued Apple for pulling the app, alleging that its removal was based on unsubstantiated intellectual property claims from YouTube. The lawsuit went so far as to argue that Apple had violated its own Developer Program License Agreement (DPLA), and that Apple was required to conduct a review and form a “reasonable belief” that the app infringed IP rights before pulling it.
[…]
Judge Lee sanctioned law firm Winston & Strawn for alleging that Apple had “admitted” to knowingly relying on false evidence – a claim the judge found had no factual basis, even after Musi’s lawyers had spent two months reviewing Apple’s internal documents and deposing its employees.
Jon Brodkin (Hacker News):
Lee found that Apple can remove apps “with or without cause,” as stipulated in the developer agreement. Lee wrote:
The plain language of the DPLA governs because it is clear and explicit: Apple may “cease marketing, offering, and allowing download by end-users of the [Musi app] at any time, with or without cause, by providing notice of termination.” Based on this language, Apple had the right to cease offering the Musi app without cause if Apple provided notice to Musi. The complaint alleges, and Musi does not dispute, that Apple gave Musi the required notice. Therefore, Apple’s decision to remove the Musi app from the App Store did not breach the DPLA.
[…]
Musi alleged that Apple knowingly relied on a false claim from the National Music Publishers Association (NMPA) that Musi violated YouTube terms through use of the YouTube API. “Apple knew that this ‘evidence’ was false, as it has since admitted,” Musi wrote.
Musi said it does not use the YouTube API and is therefore not subject to the API terms of service. It says Apple knew this because of an email from Sony Music Entertainment. The email said that Sony “worked with YouTube to remove API access from Musi, but the app finds ways to access [Sony’s] content through technological means that are more difficult for Google to action.”
Lee wrote that the Sony email “does not state that Musi stopped using YouTube’s API” and “does not establish that Apple ‘knew’ that the evidence offered by the NMPA was false. Instead, Musi infers Apple’s knowledge based on an assumption that the Sony email was inconsistent with the detailed evidence offered by the NMPA.”
I’m not happy with either party here. I’m kind of sympathetic to Musi, because you could look at this as them building a site-specific browser with an ad blocker, and I think that’s legal and should be allowed. If they’re not using the API, I don’t see what agreement they would have been violating, though I do think it crosses a line to replace a site’s ads with your own. But with respect to their agreement with Apple, I don’t think they have a leg to stand on because the DPLA clearly says that Apple can do whatever they want whenever they want without any valid reason. The real issues are whether that sort of contract should be legal and why Apple is even inserting itself into a dispute between YouTube and Musi, but those were not the questions before the judge.
Jacob Bartlett:
Everyone is complaining about app review times, but it could be worse. Apple could be telling you “we are reviewing your app concept internally.”
This is the story of how Apple tried to kill my startup 🩸💁 ♂️🔫
Previously:
Antitrust App Store App Store Takedown Copyright iOS iOS 18 iOS App Lawsuit Legal Musi YouTube
