Micro.blog has always had per-blog pricing. Hosting one blog was $5, two blogs was $10, three blogs was $15, and so on. On top of that, Micro.blog Premium added additional features either to a specific blog (like podcast hosting, video, and email newsletters) or across the platform (like our new notes feature).

The reason this pricing appealed to me is that by charging for each blog, we could keep the standard plan as low as possible for most people who only have one blog. If you needed multiple blogs, upgrading added on to the subscription in a way that seemed fair to us and customers.

Over the years we’ve had problems with this pricing, though. It was confusing to keep track of. There have even been billing mistakes because the code for subscriptions was too complicated. Instead of obvious tiers on your account, each blog was effectively its own tier, with tricky scenarios when trials and yearly pricing are mixed in.

Today that’s changing. We are getting rid of the per-blog pricing. Instead, there will be three simple plans, and Micro.blog Premium will now include multiple blogs.

• $5: one blog with all the basic features
• $10: Micro.blog Premium, all the advanced features and up to 5 blogs included
• $15: Micro.blog Family, same as Premium but up to 5 users can post to any of your blogs

Additionally, there will continue to be no charge for hosting extra single-page web sites and test blogs. The new “up to 5 blogs” count is for normal, full blogs.

Most people only have one blog. If you do already have multiple blogs, this pricing change may mean you’ll be paying less. By the time you read this, your subscription should have been updated to reflect the change.

For example, if you had two blogs, one standard blog and one using Micro.blog Premium, previously that would have been $5 + $10 = $15. Now, having two blogs is covered in Micro.blog Premium, so your cost goes down to $10. Or if you had two $5 blogs already, you’ve been upgraded to Micro.blog Premium automatically because it’s the same price you were paying before.

Micro.blog has been updated throughout to reflect this pricing change, including a redesigned Plans page to upgrade or downgrade your account. Creating new blogs is simpler too.

I’m biased, but I think Micro.blog hosting is one of the best values on the web. Nothing else comes close to the depth of features. Hope you like Micro.blog as much as we like building it.

I don’t want my whole life to be writing blog posts and podcasting about Apple’s changes for the EU’s Digital Markets Act, but this latest developer update from Apple feels like an insult to developers, playing us for fools.

Let’s start with how Apple keeps mentioning all the new APIs that are part of this rollout:

To comply with the Digital Markets Act, Apple has done an enormous amount of engineering work to add new functionality and capabilities for developers and users in the European Union — including more than 600 new APIs and a wide range of developer tools.

They said the same thing in the initial news announcement:

The changes include more than 600 new APIs, expanded app analytics, functionality for alternative browser engines, and options for processing app payments and distributing iOS apps.

Apple repeatedly talks about these “600 new APIs” as if it is a favor to developers, but it was Apple’s choice to handle it this way. For example, to comply with the DMA’s requirements on sideloading or marketplaces, Apple could’ve chosen a system similar to installing apps from TestFlight. This would require zero new APIs for developers, just as TestFlight itself has no new APIs when building a beta version of your app.

Apple created the new APIs — a significant number in MarketplaceKit alone — so that they would have control over distribution. By both reviewing marketplaces and requiring that marketplaces use new APIs to install apps, Apple can track app install numbers, allowing them to invoice developers the new €0.50 Core Technology Fee. The new APIs help Apple, not developers.

Moving on to the web browser update, there is going to be universal concern from web developers about Apple disabling PWAs in the EU. On letting web apps use browser engines other than WebKit, Apple writes:

Without this type of isolation and enforcement, malicious web apps could read data from other web apps and recapture their permissions to gain access to a user’s camera, microphone or location without a user’s consent. Browsers also could install web apps on the system without a user’s awareness and consent.

Was this statement from Apple written by a hallucinating AI? All mainstream web browsers have a strict security model for JavaScript. Cookies and local storage cannot be accessed across web apps. It’s even difficult or impossible to make certain web requests from JavaScript because of cross-site scripting and CORS limitations. The only way this could be circumvented is with a rogue web browser engine that did away with these standard constraints, but Apple already has this scenario covered because they approve every browser engine:

To help keep users safe online, Apple will only authorize developers to implement alternative browser engines after meeting specific criteria and committing to a number of ongoing privacy and security requirements, including timely security updates to address emerging threats and vulnerabilities.

Users want to run Firefox and Chrome, popular browsers that are trusted by users. The DMA was created to allow this kind of choice. No one is asking Apple to blindly let browser engine malware take over home screens.

Some have argued that the DMA is poorly written, or at least too vague and open to interpretation. It actually gives gatekeepers like Apple significant leeway when it comes to security. Quoting from section 6.4:

The gatekeeper shall not be prevented from taking, to the extent that they are strictly necessary and proportionate, measures to ensure that third-party software applications or software application stores do not endanger the integrity of the hardware or operating system provided by the gatekeeper, provided that such measures are duly justified by the gatekeeper.

Apple has clearly jumped on this to give themselves an out, ignoring the spirit of the law. When it benefits Apple, they take the DMA requirements much further than intended. When it doesn’t benefit them, they lean back on the “integrity” of iOS and barely comply at all.

Wrapping up, Apple writes:

EU users will be able to continue accessing websites directly from their Home Screen through a bookmark with minimal impact to their functionality. We expect this change to affect a small number of users. Still, we regret any impact this change — that was made as part of the work to comply with the DMA — may have on developers of Home Screen web apps and our users.

It is hard to take this seriously after Apple’s bad-faith effort to comply with the DMA. I’m sure WebKit engineers regret this change, but Apple leadership doesn’t. By limiting PWAs just as PWAs are starting to be competitive with native apps, Apple ensures that native apps have no real competition on iOS, strengthening Apple’s hold on app distribution.