Manton Reece

I’m as tired of debating the App Store as anyone. I’ve been making essentially the same arguments for 10 years, on this blog and on the podcast. But the news from South Korea adds a new wrinkle that is worth highlighting.

The spirit of any law forcing Apple to allow external payments for apps is clearly twofold: give developers more control over interacting with customers, and let developers avoid paying the 15% or 30% on transactions by handling payments outside the store. Apple and Google are trying to follow the letter of the law while missing the larger point completely:

Apple said it plans to provide an alternative payment system at a reduced service charge compared with the current 30 percent charge, as the tech giant turned in its compliance plans to the Korea Communications Commission (KCC).

Ignore for the moment whether this response is legal or fair. Let’s think through how this would work in practice. Apple is developing APIs so that when using an external payment, Apple is still notified about the external transaction so they can collect their “reduced” service charge.

But iOS developers are used to paying Apple $99/year, and then getting a check from Apple once a month with 70% of the sales through the App Store. The 30% (or 15%) is taken out automatically, just like 3% is taken out for Stripe transactions. Developers don’t have to think about it.

In this new world Apple imagines, developers will be collecting all of the sales into their own bank account, and then paying Apple the 11% or whatever Apple ends up demanding. There is a huge psychological difference between these approaches, just as there’s a difference between getting taxes taken out of your paycheck automatically and having to write a big check to the government.

If this goes through, it will only underscore how ridiculous the App Store tax is. Why do developers have to pay Apple a platform fee when we’ve never had to do that for macOS? What is the point of the $99/year program?

Apple wants iOS, the App Store, and their App Review team to be inseparable as a single platform. That’s not a technical reality. If they keep pushing this approach, they’ll only run up against more regulation and more distrust from the developer community.

Last June, I was traveling with my family for a vacation to Washington DC. We had all gotten vaccinated, the Delta variant of COVID hadn’t hit the US yet, and we were feeling pretty great about moving beyond the pandemic. Maybe too optimistic, but that’s another story. For Micro.blog, what happened leading up to that trip and while in DC is that I spent some time thinking about the future of the platform and the team.

Maybe it was the stress of travel. I felt a kind of urgent need to get help with Micro.blog, ideally from someone who knew Ruby, had seen some of my code before, and had experience with mobile apps and APIs, so they could hit the ground running. I emailed Vincent Ritter right before leaving town and asked if he was interested.

Vincent had developed the third-party Micro.blog app Gluon, which runs on iOS and Android. He’s an active blogger and codes with Ruby, which we also use on the Micro.blog backend. He and I have discussed several improvements to the Micro.blog API through his work on Gluon, so I was pretty sure we had a similar approach to development and could work well together.

Vincent has been working part-time on various improvements to Micro.blog since shortly after I reached out to him over the summer. Bug fixes, backend architecture brainstorming, and new features like dark mode on the web. But he’s also been working on something big: Micro.blog for Android.

We rolled out the Android version last week as a public beta on Google Play to get early feedback. It won’t match the features of the iOS version exactly, just like the macOS and iOS versions are different from each other in their own way. The Android version has all the basics: the Micro.blog timeline, posting, replies, Discover. The design borrows from the iOS version but also tries some new things, like a tab bar.

Five years since the Kickstarter for Micro.blog, I remain as excited as ever about the potential for Micro.blog. Finally filling in this missing piece for Android users is a huge step forward.

Thinking back to last summer through to this winter, it’s easy to let bad news happening in the world dominate our thinking. I’m really proud that behind the scenes with Micro.blog we keep moving forward. I probably say something like this every January, but… 2022 is going to be great.

Today we’re releasing the first public beta of Micro.blog for Android. You can download it here on Google Play.

Vincent Ritter led the development on this and there’s a ton in it for a first beta. Some of the features in this initial version:

• Timeline, Mentions, Bookmarks, and Discover.
• Creating new posts and replying.
• Uploading photos.
• Viewing conversations.
• Emoji picker in Discover.
• Multiple blogs and multiple Micro.blog accounts.
• Choose categories when posting.
• Viewing profiles and following new users.

We have a few more things to wrap up before we officially call it 1.0. For example, push notifications will make the final release but they aren’t in this beta. There will be bug fixes, UI tweaks, and other improvements based on feedback.

Enjoy! Let us know what you think.

Reacting to Daniel Jalkut’s follow-up on his 2010 post about native apps vs. web apps, Michael Tsai has a great summary of how much Apple has lost the plot. His blog post collects many of the problems in one place:

Since then, Apple has slowed the pace of improvements to the frameworks for writing native Mac apps. It added technical (sandboxing, TCC, SIP, kernel extension restrictions) and policy (App Review) roadblocks that make it harder to develop apps that go beyond what can be done with Web technologies.

I’ve been doing a lot with AppKit this week, updating Micro.blog for Mac. I can’t believe I’m saying this in 2022, but AppKit is still the best way to develop Mac apps. Apple’s framework strategy is so muddled.

If you’re supporting iOS, Android, and macOS, you might choose an Apple framework like Catalyst or SwiftUI to cover iOS and macOS, then something different for Android. But lately I’ve been thinking the best way to support all 3 platforms is to have cross-platform code on mobile, and AppKit on macOS. iOS and Android are a lot more similar than either one is to the Mac.