ActivityPub and Android

Once upon a time, Android was a "green field opportunity", and now is a mature technology. Perhaps ActivityPub is another area of opportunity, where Android developers can be distinctive.

About 14 years ago, I started learning Android. Shortly thereafter, I wound up as a freelance Android developer advocate. Part of what I did in the early years was try to convince developers that Android had business potential. To that end, I wrote lots of blog posts and delivered presentations outlining different opportunities in Android. My hope was that if we built the apps, there would be enough interest in Android that it would carve out a stable chunk of the mobile OS market and be a major piece of foundation technology.

That turned out well, I think.

A long-term side-effect, though, is that Android is now a mature OS with a mature ecosystem. In 2012, Android itself was still a "green field opportunity". In 2022... not so much. You can build a business around Android, but you need something more than Android. Similarly, being an Android app developer is useful but is not distinctive. There are lots of Android app developers, and you need to do something beyond that to "stand out from the crowd".

If I were a younger developer looking to be distinctive, or I were looking to start my fourth(!) business, I'd be looking into ActivityPub.

This blog is associated with, a Mastodon instance catering to Android app developers. Mastodon is gaining significant interest due to the issues surrounding Twitter. Mastodon is an app, an ecosystem, and an example of ActivityPub.

ActivityPub is a W3C specification for data exchange, focusing on social network-style apps. In particular, ActivityPub is designed around a "federated" set of servers, where the social network is not merely a network of users, but a network of sites that exchange data. The relationship between Mastodon and ActivityPub is roughly analogous to the relationship between podcasting and RSS: RSS says "this is a feed of content", while podcasting says "the content is metadata about podcasts and episodes".

ActivityPub is more than just Mastodon, though. If "Mastodon is Twitter, but using ActivityPub", then:

To me, ActivityPub has some "Android in 2010" vibes. There is a solid foundation along with early success stories, but there are few major players, none of whom are likely to completely dominate the space. While ActivityPub will lack the push of interested parties like Google and Samsung had for Android, its interoperable nature means that the success of things like Mastodon can help propel the entire ActivityPub ecosystem.

So, what could an Android app developer do who wants to get involved in ActivityPub? There are lots of possibilities, including:

  • You could contribute to Mastodon client libraries, such as mastodonk or mastodon4j. Perhaps start small and useful (test cases! documentation!) and contribute in a more serious fashion as you gain comfort and acceptance.
  • You could contribute to open source Mastodon clients, whether that is the official client or an independent one like Tusky. Again, perhaps start small and grow your involvement over time.
  • You could move up the stack a bit and contribute to open source ActivityPub clients, such as Fedilab.
  • You could create your own Mastodon or ActivityPub app from scratch, or fork an existing project and head off in your own direction.
  • You could create your own Mastodon or ActivityPub library, perhaps targeting use cases or language bindings (Kotlin/Multiplatform? Flutter? React Native?) that you feel are under-served.
  • You could write a library aimed at generic consumption of feeds, whether those are ActivityPub, RSS, Atom, GNU Social, ActivityStreams, or something else. While this library might wind up being focused purely on reading (rather than posting), it could open up possibilities for more apps to support more protocols.
  • You could create an ActivityPub client aimed at a specific form factor: app widget, wallpaper app, TV app, watch app, car app, etc.

If you feel really adventurous, you could:

  • Create a new protocol that uses ActivityPub. In other words, "my project is X, but using ActivityPub", where you come up with your own value for X. That could be tied to software development ("my project is F-Droid, but using ActivityPub", "my project is Stack Overflow, but using ActivityPub") or it could be broader in scope ("my project is Reddit, but using ActivityPub"). This likely will require some server-side development, in addition to client-side libraries and apps. On the other hand, "the sky's the limit".
  • You could leverage that "generic consumption of feeds"-style library to create the truly universal timeline app.
  • You could experiment with ActivityPub for situations where there may not be a stable Internet connection, or where Internet connections might be monitored continuously. Can you come up with an Android ActivityPub bridge that uses Bluetooth, WiFi Direct, or other communications protocol, to help conventional ActivityPub clients deal with inconsistent or inadvisable network access?
  • You could aim to become a freelance developer advocate for ActivityPub. Perhaps your hope will be that if many ActivityPub apps become popular enough, ActivityPub will become a major piece of foundation technology. Crazier things have happened.

I think that the time is ripe for some good old-fashioned business model disruption. I think that ActivityPub is in good position to help with that disruption. And I think that there will be many opportunities for Android developers with demonstrated ActivityPub expertise, where that expertise can "open doors" that might otherwise not open for you. And, the nice thing is that even if ActivityPub does not become huge, getting involved with ActivityPub can cost you nothing more than time.

I look forward to what we build!

(and if somehow your project is "overcoming hair loss, but using ActivityPub"... ping me)

Subscribe to Android Dev Social

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.