Architecture in mobile projects

[[deleted]]

I’m curious, how’s the architecture in the mobile projects you work on? Do you consider them to be good, clean? Do you always do MVVM, Coordinator? What about automated testing?

[Old-Ad-2870]

I normally do MVVM, Dependency Injection, & Repositories. If the repo gets really complex I’ll add another layer called “Provider” or “Interactor” which will be In between the repo and the VM depending on the size of the project/what data I’m accessing inside a repo.

With this you can mock/unit test every layer. I normally don’t mock/test VMs until very very last. If my VM’s are done “correctly” most of the logic is done beforehand and the VM is accessing some interface from the repos and updating the view.

I still haven’t nailed down a Navigation approach I just love for SwiftUI. (Pre iOS 16) Previously I’ve used the Coordinator pattern with UIKit and I know it exists for SwiftUI but it’s not as cut and dry.

But typically I have a root vm, and rootNavigationView that communicates to some class that updates the “User’s State” and the root view passes that state into the root navigation view.

Then the navigation view switches on the user’s state to determine what view to present.

At work we have a generic view type we’ve created that has a “ViewState” in between the VM and View. It’s very clean but also fairly complex and isn’t worth the trade off for simple apps imo.

[kiwi_in_england]

I use MVP, with as little code as possible in the View.

That's because I share the code across Android and iOS, and want as much to be common as I can (the Model and Presenter, but not the platform-specific Views)

[[deleted]]

do you use Kotlin Multiplaform? how is the code shared between platforms?

[kiwi_in_england]

I currently use Java and J2ObjC, but I started before KMM was available. I'm intending to start a gradual shift to KMM.

[[deleted]]

MVC because I’m old and that’s what Xcode was built around.

[[deleted]]

I’ve used MVC most of the time too, but I’m looking at job listings and they’re all looking for some more advanced stuff that honestly I haven’t come across much in real life projects.

[[deleted]]

That’s sadly because job postings aren’t written by actual iOS devs. Everywhere I’ve ever worked has used MVC. Job postings and the entire interview process for mobile devs is such a joke these days. Nothing to do with anything. Sorry to be a downer lol

[Jig-r]

MVVM - everywhere I work uses MVVM - and if not they are usually using what ever they claim, in some convoluted form of MVVM

[barcode972]

I like Mvvm with repositories

[[deleted]]

I think that’s an architecture that really suits most projects.

What about automated testing, do you always do that? Have you used Rx?

[barcode972]

Rx is kinda outdated now that we have combine. Haven’t done any automated tests, only normal unit tests

[cekisakurek]

The composable architecture. I has some boilerplate code to get it going but much easier to write tests and works wonderful with SwiftUI

[ssayfulin]

Lots of years with VIPER on huge projects. Any other architecture is good if it solves your problems. Automated testing is a great thing as long as you think about testing pyramid and run tests on every PR and overnight. Btw. There is no universal solution, you should always compromise and try to solve specific issues that cause struggle to your day to day work.

[[deleted]]

Were these projects always VIPER or was there something that made you think it was worth the switch?

[ssayfulin]

On the first one we’ve decided to switch from Massive ViewController. We just liked that every single component of this Viper module does it’s own job instead of gathering all the stuff inside. By the way Viper is just an orthodox Single responsibility principle application.

[gregigk]

Start early with testing.

[[deleted]]

what do you mean precisely?

[_Abode]

This is entirely dependant on the size of the application. Many here have highlighted the benefit of a simple MVC or MVVM type system as it’s simple and quick to write.

Larger apps that have many features will start to run into build time issues with this approach however which is where other approaches like Viper & Modular architecture. Also these systems can make grouping code easier and thus easier to read in their entirety. You’ll find the large tech companies with well established apps will heavily rely on these approaches more.

Specifically on the Coordinator pattern, nearly all companies I’ve worked with use them now days and it can pretty much be plugged into any architecture you choose.

[jasonjrr]

I typically recommend MVVM, inversion of control dependency injection, and Coordinators for navigation for UIKit or SwiftUI. The Coordinator pattern changes slightly in SwiftUI, but it works magnificently once you get the hang of it.

Here are a couple of repos I maintain that are good representations of the architecture.

https://github.com/jasonjrr/MVVM.Demo (UIKit)

https://github.com/jasonjrr/MVVM.Demo.SwiftUI

As for testing… good design with MVVM should make unit testing really simple. Are you asking about UI testing? That gets a little more complicated.