What Reverse Engineering Foretells
Many times I’ve found myself decompiling projects and apps, often for studying and tinkering purposes, out of curiosity or for work. Over the span of 10 years, apps have drastically changed; one could see how much the industry evolved and practices changed by gutting through the internals.
Goes without saying, this is a weird way to contemplate the industry, and many insights can be easily obtained and analysed in more direct ways. However, it’s always fascinating to look (at anything) through the microscope.
How it began
In 2012 I was a zealous “tweaker”, not in the narcotic sense of course, but in Software. Owning an Android phone with a sense of control over everything like in a linux box. In the golden age of rooting and flashing the living bits out of a device.
I’ve always enjoyed customising my devices and making everything to my liking. Open as it is, you can’t go further with Android without getting your hands dirty. You have to modify system apps and processes. And without much knowledge of a particular app codebase, I’d find myself reading through obfuscated assembly/ smali to make sense of things.
Getting used to particular app architectures and conventions, things tend to get easier to identify and amend. App protection techniques slowly become simple patterns and routines. App layers and 3rd party packages are almost the same at a high level. And you can know your way without much zooming in.
From binary to CSS
Apps in the past would heavily rely on native c(++) code to share and reuse logic. The Android framework wasn’t as mature as today (I know, it’s never matured). And performance was a key differentiator; a tiny memory boost resulted a thousand users more. Saving a 0.5 MB of app size would yield better listing and visibility on the App Store.
Java was a shell and almost everything else would be a shared compiled lib. The parts you could tweak were almost exclusive to the Android framework APIs.
Luckily, the OS became (slightly) better, and hardware is almost miraculous now. Everything is more powerful and smaller. And the community became more fluent (more adapted TBH) in the Android Framework. Many pieces of android logic have been written in libraries and being depended upon in almost every app.
Native Era
Many projects understood the value of native development and were willing to work on 2 codebases for Android and iOS as need be. But cost and maintainability were ever so problematic. Some teams would find a huge gap between both platforms. The Facebook app still suffers from this till this very day.
Apps were never easier to analyse and reason about. I could introduce vast changes to almost any obfuscated app and make whatever I want. And I could imagine how this translates to great readability and maintainability across engineers and teams working on this app. Products can grow at a speed never seen before—Even reverse engineers benefitted from the readability and maturity of the Framework.
Cross Platform
Like sharing static libs, teams always strived to reuse logic across platforms. Many ways and frameworks were created to solve the same issue. It became the name of the game. Apps were no longer pure encoded sources, they became this jungle of bundles and autogenerated fillings that glue things together.
Not because it made reverse engineering harder, but it seemed that things took a very complex turn to manage simplicity. Apps were no longer a function of product needs. The framework became a factor in the formula itself. Teams are developing for the framework, and slightly for the product.
The underdog
Other technologies faced drastic changes as well. The glorious web seemed like we never knew its true potential. And it is ever better in creating UIs. And the community has always wanted to make everything a website. The web (not to mention machine learning) benefited the most from hardware advancements.
Not only did they prove to be significantly more cost effective, webviews in apps also matured and these days almost all apps rely on them. And “native-shell-web-core” apps are now quite popular. In giant corporate apps, it’s almost impossible to dissect an app without finding yourself staring at a web-based feature/slice.
Commentary
“Web is the future!” is as true as it’s annoying. Their are all types of tools and solutions to solve app problems (Reusability, Simplicity, and Appeal).
But it seems if you’re looking for a compromise, the web is actually quite good. And if you want to invest more into your product, don’t sway away from native; odds are you’ll need it.
And finally, spanning 10 years, I found no great app was created with an “android/ iOS framework dev” mindset. It’s always the Software Engineering mindset that shapes apps with respect to the opinionated framework, not the opposite.
Have something to say? Use the comments below : )