You have completed a course, watched a series of videos on YouTube, or read a series of articles about iOS development, and now you feel ready to write your first pet project.

Firstly, well done! That’s awesome. You’re cool! 💪

Secondly, a pet project is a fantastic boost to your skills. When you start doing something on your own, not following instructions — you have to spend a ton of time and effort, Google a lot, read heaps of new information, and try to filter and fit it precisely into your case. In short, it’s already a real task that will boost you five times.

However, most beginners ignore key things (not out of their initiative, but without understanding their importance). Over the past six months, I have been actively mentoring and helping newcomers with their questions and problems, including pet projects.

I have identified the top 3 points that you, as a beginner, should incorporate into your must-have list, master, understand, and use.

Access Level

At first, almost no one pays attention to the private modifier. Meanwhile, everyone can instantly explain SOLID if you wake them up in the middle of the night. Having read various smart articles, people try to create a bunch of classes according to the idea of S (single responsibility).

And then, with a clear conscience, they change the property of class A from class B and vice versa.

class A {
    
    var someAValue: Int?

}

class B {

    let a = A()

    func foo() {
        a.someAValue = 1
    }

}

In general, if it’s still unclear, here’s the plan: always write private everywhere, and when the compiler complains — think, is it okay to access this property or function from the outside? And if it is — remove private.

When you think, guide yourself with real-world comparisons. For example, if your class is a store, then the goods property should obviously be accessible to the external customer. But the moneyInCashRegister can clearly only be changed by an internal store employee.

After all, a customer shouldn’t have access to the cash register, even with put, let alone fetch.

One might argue, “I understand perfectly well which property can be touched and which cannot even without a private modifier”. However, writing access level modifiers is part of the design. I am sure you wouldn’t create a blueprint for a house with a door on the third floor leading outside.

And then, just remember not to open it. After all, it’s likely that others will use your code too.

By the way, a similar situation exists with var and let. Again, always use let unless you’re immediately sure you’ll change the value.

Architecture Simplicity

I’ve noticed a tendency where beginners try to plan everything in advance. While this is commendable, developers often make mistakes due to their lack of experience. They pre-prepare overly complex managers (usually copied from StackOverflow) with many complicated methods, which they eventually never use. As a result, the amount and complexity of the code grows.

Instead of what seemed like a convenient, ready-made service, our programmer ended up with only problems and misunderstandings. The same goes for architecture.

Let me briefly journey you through the history of programming to convey my point. By the end of the 1960s, as the popularity of programming began to grow, the sizes of programs also increased. As you can understand, a larger program size means more lines of code, leading to increased complexity and difficulty in understanding the program.

To address this issue, structured programming emerged — functions and procedures that allowed programs to be divided into smaller, manageable parts. The code became modular, reusable, and more understandable.

The advent of structuring led to further growth in programs until they again reached their size and complexity limits. Therefore, by the late 1970s and early 1980s, the object-oriented programming approach was formed. This solution enabled the creation of flexible and scalable systems, addressing increasingly complex tasks.

In the next decade, we witnessed the boom of computer games. The reaction to user actions (clicks, presses) turned out to be critical, leading to the emergence of Event-Driven Programming.

And for organizing code in web and desktop applications — when the same data needed to be rearranged from different perspectives — the MVC pattern (i.e., separating the model from its visual representation) emerged.

You’ve grasped the main idea: a problem arises, -> a solution emerges. Problem -> Solution.

So why do beginner programmers now start applying solutions (architectures) at a time when the problems have yet to arise? Tutorials immediately suggest choosing at least an MVP. Test tasks for one/two screens always specify NOT to use MVC.

During interviews, a person who has written a couple of pet projects with the same one/two screens is asked about VIPER problems. How could he know about the problems if he has not yet encountered them?

People often talk about the convenience of testability in the context of architecture, but they haven’t ever written tests. And if they have, it was based solely on some tutorial, focusing only on unit tests without tying them to an actual application.

They can explain the MVP scheme in simple terms, but they often get confused when it comes to protocols with similar names, like ViewInput and ViewOutput. Deep down, they already see all of this as some overhead 🙄🤯

Conclusion: Don’t create problems for yourself. Don’t be ashamed of MVC. When your controller grows too large, or you encounter inconveniences, you’ll understand it’s time to look for new approaches.

UI Simplicity

Front-end development is a dopamine paradise for beginners. You write code and immediately see the result on the screen — receiving your reward 🍭. It’s undeniably motivating. However, there’s a flip side to this coin. Beginners often strive to create overly complex UI right away.

Moreover, complex features tend to follow complex UI. Even though SwiftUI simplifies the task today, one can still spend much time adding bells and whistles without making real progress.

I learned iOS development in a course where we formed teams and worked on a single project. In my team, a guy suggested starting our app development by choosing fonts and colors for the dark mode.

Overall, he spent the entire course on it, and it’s worth noting that the fonts and colors turned out fabulous. However, the guy wrote approximately zero lines of actual code during all that time.

Undoubtedly, the beauty and functionality of your application are crucial. Eventually, you’ll have to spend time on this aspect. It’s just better to start with something simpler. Develop an MVP (minimum viable product), focus on the most critical features, and launch from there.

The 80–20 rule applies here — create the fundament of the application, and then add the extras. The opposite approach will lead to grappling with complex nuances and constantly dealing with a main functionality that keeps breaking.

For newcomers in mobile development, there’s a risk of adopting complex solutions prematurely. While the visual rewards of front-end development can be enticing, starting with a simple MVP is often wiser.

Historical trends suggest that solutions should evolve in response to genuine challenges.

Understanding foundational principles and addressing real-world problems as they arise is critical to effective development.

Also published here