EventBus Went From Android Standard to Pariah — and It's Not the Library's Fault

A library that was once in nearly every Android project is now being systematically removed. The shift isn't about bugs — it's about architecture maturity: implicit event buses trade short-term wiring speed for long-term maintenance debt, and the modern Android stack now offers state-observation patterns that give you the same decoupling without the untraceable side effects.

greenrobot's EventBus once dominated Android development because it replaced layers of callbacks, broadcasts, and manual context-casting with a single post-and-subscribe pattern. A `post(new LoginSuccessEvent())` and a handful of `@Subscribe` methods were all it took to wire up a dozen pages. That simplicity was revolutionary when the alternative was deep interface chains and LocalBroadcastManager boilerplate.

The same qualities that made it popular turned toxic at scale. Implicit dependencies mean a `post()` call reveals nothing about what will execute — you must grep the entire codebase for every subscriber. Call chains break at the event boundary, so debugging a login-triggered UI stall requires manually hunting through every listener. On Android specifically, EventBus ignores component lifecycles; forgetting an `unregister` leaks Activities and causes crashes when destroyed pages try to update UI. Thread-mode annotations scatter execution across POSTING, MAIN, BACKGROUND, and ASYNC threads with no visibility into which subscriber runs where.

Modern Android architecture — ViewModel, StateFlow, Lifecycle — replaces the broadcast mindset with a state mindset. A `MutableStateFlow<UserState>` observed by UI layers makes dependencies explicit, call chains traceable, and lifecycle handling automatic. EventBus still fits genuinely global broadcasts like forced logout or theme switching, but for ordinary state-driven UI updates it has become a liability that teams are actively ripping out.