How do you organize code for iOS and Android mobile apps?

Make sure to do spell checks and add apt documentation when writing the code rather than at the end of the development. Add pragma methods if you want to re visit some code.

Remember that consistency doesn't mean nothing changes once the coding style is decided. As a team you need to remain vigilant for when style rules agreed in the past no longer make sense, especially if no one remembers the reason behind the rule in the first place! Not only does this keep you open to new ideas and ways of working, it also ensures you're communicating with your team to understand what each other is thinking.

A consistent coding style not only makes it easier for you to work on your code but also facilitates collaboration with other developers. Here's a sample coding style that you can adopt as an iOS developer: 1-Naming Conventions: Use descriptive and meaningful names for variables, functions, classes, and methods. 2-Indentation and Formatting: Use 4 spaces for indentation, not tabs. Place opening braces on the same line as the declaration (K&R style). 3-Function and Method Declarations: Start with access control (e.g., private, internal, public). Use descriptive parameter names to make function signatures clear. 4-Comments: Use comments to explain complex or non-obvious code. 5-Imports: Organize imports alphabetically.

Choosing a consistent coding style is the bedrock of well-organized code for iOS and Android apps. It fosters readability, teamwork, and efficient development. Use tools like SwiftLint and ktlint to enforce these standards effortlessly.

Organising mobile app code is one of the most important decisions when building a mobile app. There are already established architecture and design patterns which in my opinion are solving this problem. Exploring and applying these architectural and design patterns will help organise your iOS and Android apps as best as possible. Let's discuss one - The clean architecture. Clean architecture requires app to be organised into layers with separation of concerns and clean lines of dependencies established. The layers are: 1. App layer : Serves as the entry point to the application. 2. Presentation: This is where all UI related code lives 3. Data: All data source (API/Database) an repositories live here 4. Domain: Business logic only

Using Clean Architecture modular architecture proved to be the best for me - having data, domain and presentation modules helps to keep the codebase organazied and separate all the important logic inside domain module. With this modularization you don't have to worry that your core logic is incorrect - the only issues that might come are in either data layer or presentation layer. Together with MVVM pattern it helps to minimize bugs and debugging significantly.

Architecture is not just down to modularisation, there are other areas such as design library that can contribute to the architecture and structure of the application. As well as this, working with an agnostic approach at the UI level and defining UI modules mean that you can create decoupled UI elements and also define set structures that the front end wants. This also helps to make sure that any changes from a back end perspective won't have any major knock on effects.

In React Native, you can divide your mobile app on many separate UI-components, as well as many custom Hooks which can do business logic of the mobile application. Following the separation of concerns principle, you can build a flexible mobile app with React Native, using many small pieces of UI and small pieces of business logic, decoupled from the UI via React's mechanism of Hooks. Also, it's possible to create an app as a bunch of micro-frontends, for example with the help of Re:Pack package.

I've found that utilizing a modular architecture is a game-changer in our development efforts. It's the backbone of efficient collaboration among team members, helping us maintain a clean and organized codebase. This approach makes onboarding new members smoother, and when faced with tight schedules and the need for fixes or updates, in our team the modular architecture allows us to swiftly adapt and expand while minimizing disruptions. The code becomes more reusable, testing and debugging are simplified, and scalability is a natural progression. In the fast-paced world of software engineering, a modular architecture is like a trusty tool in your kit, ensuring your projects stay agile and code stays robust.

Speaking as an Android developer - MVC isn't really applicable in the Android world, and MVP is arguably outdated by now. I see MVVM as the default recommended approach (backed by the standard libraries). MVI, to me, is more of a further refinement of the concept, or possibly orthogonal to it, than an alternative to MVVM. MVI can still revolve around ViewModels; you're just adding state reducers to the mix.

This is the real answer. My tips; 1. Don’t use inheritance 99% of the time. Use composition. Inheritance is just another way to strongly couple solutions. 2. Split your functions but one purpose actually means to one actor. Thats all. That’s the intent of SRP. This means SRP is also encouraging duplication. If you think about it, having one reason to change is a loose definition. 3. The most egregiously disregarded (and shouldn’t be) in my opinion is the interface segregation principle. How many apps just store api details into state management ?

The "single responsibility" is the easiest to understand. We all start to code everything in just one MainiActivity. And then we see that it doesn't work, even the one who made the code can't read and use it. And so it's the time to start learning SOLID from the first letter. However one shouldn't stop learning. Because later we learn about architecture and Repository pattern. And one often can make the same mistake again, making the OldGodFatherRepository which will work through the whole application. So, we should separate it again for a few different repositories with their own "single responsibility".

No matter which architectural approach you are using, whether it's MVC, MVP, MVVM, or VIPER, it can become clunky and bloated over time. SOLID principles will guide you on how to write object-oriented code properly and keep your codebase clean and precise.

Follow the SOLID principle so the people who use your code won't be overwhelm when they have to work on it .Specifically the Single responsibility principle

Certainly! Following SOLID principles means: 1. Each part of your code does one thing well. 2. You can add new features without changing old code. 3. You can use one part in place of another. 4. Only use what you need. 5. Use abstract ideas instead of specific ones for flexibility and easier changes. This makes your code better, easier to work with, and more adaptable.

DI should be considered before starting any project, it's a big part of any project and allows you to create clean code. Consider all DI platforms, Dagger is a big one for android but can get a bit confusing depending on your level of knowledge with DI. I would always consider starting with Koin as it gives you a great insight into DI and what it is capable of.

On mobile platforms like Android and iOS, dependency injection frameworks like Dagger and Swinject can be used. These frameworks handle dependency graph creation and provisioning of objects/services where needed. With dependency injection, classes don't need to worry about service acquisition and lifecycles. In summary, dependency injection externally provides class dependencies rather than tightly coupling to internal creations. This reduces coupling and improves testability and modularity. Mobile apps can leverage frameworks to implement dependency injection and service provisioning.

The DI is so helpful, your code is cleaner, you have fewer memory leak problems, etc. However, the libraries are very different and one should be cautious when changing them. One time at work I had an interesting problem with that. I usually work with Hilt, but I have Dagger in one of my applications right now. And I got used to make "value classes" for my useCases. And it always worked perfectly, but once. However, it doesn't work with Dagger so straightforward. The Dagger tried to provide the inlined code to the Provider function and it caused a conflict of classes.

Use dependency injection . I use dagger-hilt in all the new projects I start . Its easier to use and more easy to understand .Saves you a lot of trouble injecting dependencies manually which makes it easier to test .

Whilst Dependency Injection frameworks help simplify adopting the technique, they can sometimes add unneeded boilerplate depending on your needs. If your app is small for example, you may find it easier to create your own dependency injection classes and inject the classes directly into the necessary dependencies. The decision to use an existing solution or create your own depends on the context of your app. Take into account the size and skill of your team, the business context, and the pros and cons of each.

Code refactor is key when it comes to any programmers world. We have to work on the basis that something we did 6 months ago (or less) might/will have a better solution now.

Code refactoring not only benefits the codebase by preventing accumulation of technical debt, but also makes the developer's work more enjoyable, efficient, and productive.

Today, you are better than yesterday. So should your code. Regular refactoring is important: - Code Quality: Refactoring enhances code clarity and readability, improving overall quality. - Bug Prevention: It helps catch and fix issues before they become serious bugs. - Scalability: Well-refactored code is more adaptable to new features and changes. - Team Collaboration: Clean code fosters smoother collaboration among team members. - Maintainability and Longevity: It ensures your software remains relevant and can be extended over time.

Refactoring and therefore cleaning and improving your code is a crucial part of being a developer. You can do it on your own, but I would recommend using tools like linters to find issues in your coding style. Most linters can also be adopted to your own coding guidelines. Another helpful tool can be SonarQube which can do linting of your code, but can also do code coverage, vulnerability checks and much more. - Why a tool is so helpful? During your daily business you won't be able to keep up with the latest trends, improvements and vulnerabilities, but a up-to-date tool like SonarQube can point you in the right direction on a case by case basis.

In recent times, I have been dealing with a lot of code that is considered legacy and they are almost a decade old. The issues that i have faced is mostly poorly written code, no use of architectures and bad variable naming conventions. Companies tend to overlook this because their mindset is as long as nothing breaks, its better to leave it as it is. Over time, when other developers take up the project, it becomes very difficult to modify or scale the application. Also, if there is a heavy dependency on an outdated/ deprecated library or libraries, one fine day the entire application will come to a grinding halt. Therefore it is recommended to have a sprint or two to purely focus on refactoring so that the application growth is smooth.

Before creating new project make sure to do some research on trending technologies, especially, if they are recognised or developed by google. This means it will get regularly updated and fits most of the projects perfectly.

I like the talk from high level architectural design, but since it’s about a very specific topic, I don’t think linters and formatters should be ignored. It’s authors choice to decide whether certain tools should be recommended, for example swiftlint swiftformat KT lint and so on, but this article can get some help from mentioning tools that can be run both locally or on CI.

Before starting a project, it is recommended to have a team-level discussion on tools, tech stack, coding style, and architecture to be followed and document it to be accessible for everyone. As mentioned by others, following clean architecture guidelines is beneficial for the maintainability and testability of the project. Some points to consider: - What is the current team experience in X (architecture/framework/etc) - How easy is it to onboard a new team member? - If building for multiple platforms, can business logic be shared while keeping UI native by using KMM? Does Flutter/RN fit the requirement? - Check support and community pulse around tools/framework. - Be open to change and evolve as per teams need. Don't set rules in stone.

Before starting project, building the team and then addressing the code organization is a reasonable one. Establishing a strong team foundation is crucial before diving into the technical aspects of code organization and architecture. It allows for better collaboration, communication, and a shared understanding of goals and responsibilities among team members.

Consider the realities and business context behind the app. If you are a one person team working in a startup it may actually be counter productive for you to follow every best practice. Keep yourself flexible and when the right time comes adapt the app to work with the next best practice that's appropriate. Let the need lead, as they say.