Are "native" apps resilient?

In that talk about Rails 8, DHH talked in depth about taking back control of our apps - removing hidden complexities from both the build pipeline and hosting. It made me think about resiliency and, specifically, resiliency of apps. Native apps.

The Rails talk was focusing on bloated web frameworks - how complex they are and how you can't really run them, or update them if they were made "more than 5 minutes ago" he says.

He is not wrong. In fact, I've experienced this first-hand on multiple occasions. A recent example was one of our own internal products called CIBUS. The web app was created way back in 2017 using Vue and a framework called Nuxt. Attempting to update the app later on, revealed multiple issues and incompatibilities that had to be resolved before we can make further changes (Vue had moved on to Vue 3, Nuxt along with it, many dependencies were updated or dramatically changed, the SCSS compiler itself wouldn't run anymore etc).

There are just too many moving parts.

It occurs to me that it's not just web apps that are suffering from this affliction - "native" apps have it too.

Yes, you read that correctly - our beloved "native" apps have exactly the same problem as bloated web frameworks: You can't really run/update them if they were made more than 5 minutes ago.

Be it a SwiftUI update, Xcode update, Swift language mode update, Swift tooling version update, macOS update, or something with permissions or a new manifest that needs to be added, chances are, reopening an app a year after it was made likely means you can't "just" publish it again.

Does your app contain a widget, a Siri intent, alt-key shortcut on desktop? These have changed so many times in just the last couple of years.

You may recall that time Apple was sending out emails to people who haven't updated their apps in more than 3 years. So perhaps, the fleeting or rather consumable nature of apps is no accident at all, it is by design.

The introduction of Apple Silicon only compounded the problem, as developers had to recompile for the new architecture. This wasn’t the first time a change in Apple's ecosystem caused disruption - remember bitcode?

For a time, Apple required binaries to contain precise bitcode data to run. It was quite a challenge, even using first-party tools. A very good example of how even small changes in tooling can break existing apps.

You may be thinking this happened a long time ago, but how about the transition away from Cocoapods. A process that will probably continue for several more years. At the time of writing, Xcode 16 (the current version of Xcode), doesn't support the current version of Cocoapods - imagine folks having apps depending on cocoapods, or Flutter or Kotlin Multiplatform experiencing tiny paper cuts when they're attempting to make changes to their (already working) apps.

I can keep going with examples, but I think the idea is clear. Resiliency is not an aspect of native iOS and macOS apps. So yes, DHH was right, only the browser is forever.

But these are just stuff of life, right? Frameworks and tools are evolving, and you're right - there is nothing wrong with iterations and adding new features.

It's just that there seems to be more releasing of things and less refinement. It's not enough to solve a complex technical problem, it's also important for the solution to be accessible and easy to adopt.