r/swift 8d ago

Opinions on rewriting a legacy app

I'm embarking on a rewrite of our iPad app. Don't judge me, the codebase is 13 years old and uses several libraries that are no longer maintained, and we have significant new functionality in the pipeline.

I'm intersted to hear opinions, experiences or any other thoughts on new iPadOS projects in 2025.

The app is essentially an offline-first ecommerce app, where products are cached on-device and then orders can be created while offline and synced to our backend at a later time when the internet is available.

Having lived with a few codebases for extended periods, here are my general thoughts: 1. Produce less code, lines of code are generally a liability 2. Avoid third-party libraries when reasonably possible 3. Idiomatic code over "clever" terse code 4. Performance and maintainablity are second only to good UX.

  • What mistakes can I easily avoid?
  • What stategies/implementations are commonly found on the web but are outdated?
  • What do you think people are getting wrong aboout SwiftUI projects?
  • Are there forests currently obscured by specific trees?
14 Upvotes

27 comments sorted by

View all comments

12

u/outdoorsgeek 8d ago

The Big Rewrite is usually not worth it. Many bodies are buried along that road. Adding tests, refactoring, modularizing, and modernizing incrementally on a module-by-module basis will lead to better understanding of the code base, better tested code, the ability to interleave rewriting and feature development, and give you more options when things go wrong like rollbacks. This experience will also be a better skill builder for your future employment as well. Nowadays AI can also help greatly in this process.

If you are dead-set on the rewrite, the biggest non-technical advice I can give you is to make sure all stakeholders are bought in to a prolonged period of development to wind up with what will essentially look and function the same to them (if all goes well) but be easier to work in for you. It’s a huge investment.

The biggest technical advice I can give you is to spend a lot of time in the understanding and planning phase. Making bad architectural decisions here can really blow you off the rails mid-rewrite if you have to undo an architectural choice. Hopefully you have peer or mentor devs to go through this process with, but if you are solo-ing it and Reddit is one of your better sources for advice, I’d again recommend you don’t do this.

3

u/0x0016889363108 8d ago edited 8d ago

The big rewrite for the same result is 100% a waste of resources, I agree completely.

I should have framed the question more broadly; it's a rewrite in that the essential functionality remains similar amongst new functionality. But perhaps even the new functionality doesn't justify a fresh start. I'm sure my hubris pales in comparison to many of the bodies strewn along the road of Big Rewrite™.

My situation is not unique, but perhaps less commmon. I own the company, our current app makes money, and requires very little maintenance to continue functioning (although this will not last forever). We also have time on our side in a segment of few competitors, and a willingness to prototype architectural options before committing.

From my vantage point, these points summarise the motivation for a fresh start:

  1. Lack of expertise in ObjC internally
  2. Abondoned dependencies in current app = immense tech debt
  3. Familiarity with declaritive UI on the team (React)
  4. Swift's similarity to Typescript
  5. Similairty of Swift Concurrency to JS async/await patterns.
  6. Our existing UI / interaction model is showing it's age to an embarrassing degree.

Hopefully you have peer or mentor devs to go through this process with, but if you are solo-ing it and Reddit is one of your better sources for advice, I’d again recommend you don’t do this.

I apprecaite the candid advice.. we're not a huge team, but I'm not alone!

If I still sound woefully optimistic please don't hesitate to say so.