A year-long rewrite: speed is a feature
Rather than updating it, X rebuilt its Android app from the ground up and released it globally on July 20, 2026. Work on the new app, built with Kotlin and Jetpack Compose, began in August 2025. The company promises improvements in loading times, scrolling, notification handling and overall reliability. This issue covers the July 20 agenda and was published on July 25, 2026 to complete the archive.
Not an update, a rebuild
X shipped its Android app by rewriting it from the foundations rather than improving the existing code base. The company's engineering team says the new version is faster, smoother and more reliable than the old one in every way. Head of product Nikita Bier describes the work as one of the largest engineering projects in the company's history and says the new structure will let features be built far more quickly. The app became globally available on July 20; existing Android users can update through Google Play.
One year, one team, and what is still missing
The project started with an Android team assembled in August 2025 and ran for nearly a year. The new app was built on Kotlin and Jetpack Compose, a choice aimed at faster interface development through reusable components. The company openly acknowledges that the Android version had lagged well behind its iOS counterpart.
The released version is not finished work. Bier notes that performance tuning for older Android devices, Spaces support, video editor features and react-with-video are still missing and due soon. In other words, the company chose to ship the foundation and build on top of it rather than wait for completeness.
Technical debt slows the product down
A slow app is not only a user experience problem; it decides how quickly a company can try new things. X's stated reasoning covers both sides: fluency for users and speed for developers. Adding features on top of old code gets more expensive over time, and every addition raises the risk. Spending a year renewing infrastructure without shipping visible features is hard to market in the short run and cheaper overall in the long run. The choice shows that technical debt gets paid back with interest at some point.
What it means for businesses in Türkiye
Mobile usage runs high in Türkiye, and a large share of users browse on mid-range devices over connections of varying speed. In that environment a heavy site or app gets abandoned no matter how beautiful the design. The practical lesson from X's decision is that performance is part of product strategy, not a maintenance chore. Three concrete questions follow. Measurement: do you know how long your page takes to open on real user devices? Budget: every new feature adds weight, so is there an upper limit on that weight? Timing: infrastructure renewal usually gets postponed because it has no visible output, yet the cost grows the longer it waits. A rewrite is not always the right answer, but adding features without measuring the cause of the slowness is definitely the wrong one.
The UNALSOFT take
Our reading is clear: speed is not decoration for design, it carries it. On a page that loads heavily, even the best creative gets closed before it is seen. That is why in our web design work we treat performance not as an optimization pass done later but as a limit set on day one: image weight, font load and script count get discussed at the start of the project. Rescuing something afterwards always costs more than building it right.
Sources
TechCrunch, "X relaunches a rebuilt Android app after year-long effort"
How fast is your site on real devices?
Let's measure performance and see together where you are losing people.