How We Launched Our First MVP in the iOS App Market

Hi everyone, my name is Max Nechaev. I'm an iOS developer and a startup founder. Over the last six months I've traveled a really interesting path, which is full of complexity, uncertainty, trial, error, and fan.

We've all thought about our own business at some point. What if you don't work for someone else? What if you could try starting something of your own? Would I be able to do it? I run into these questions quite often. But what's the reasoning here? The point is that if you put your fears aside and try to answer this question as truthfully as possible, you most likely won't be able to give a clear and concise answer. This is where we run into that winged phrase "You won't know until you try".

It was after this realization that a seed settled in my mind that sprouted and gave me more and more food for thought each day and each week. Eventually, I realized that I was going to try and create my startup in the IT industry.

Market preparation and analysis

The first thing that was important to me was mental preparation. I read books on management and business. I spent a lot of time watching YouTube videos on different niches, analyzing entrepreneurs and their strategic decisions. Before starting work on any project, it is very important to be ready for it from the inside, not just "think of something and do it".

Second, analyze the market. You can't just take and make any application, because the market is big, there are prevalent trends, there are leaders and outsiders, there are money niches, and there are niches where there is no money in general, no matter how much marketing budgets you pour into it. There are plenty of niche analytics sites out there, at first I used SensorTower. It helps us in finding apps in different niches in different countries. Moreover, you can see who is earning how much (the only issue I have is that it doesn't show how much someone spends on marketing, so you won't see the real net profit).

In this article, I would like to share the steps we have taken, not a specific case study, so I will not go into the details of the research. We are not a million-dollar company yet, so there are no working cases yet, but those who are interested in this topic will find a lot of useful tips here.

So I will say this. We've settled on a niche of apps that help content creators and SMM specialists.

Team building

"One man can't fight alone." I keep bombarding you with catchphrases. But in the 21st century, this is the purest truth. I am not used to hearing "success stories" about how some programmer from the village did something and became a millionaire. Because even if there are such cases, it is rather an exception to the rule. It is very important not to fall into the "survivor's syndrome". Don't get me wrong, every good developer can write his first MVP alone. But only if we are talking about real commercial success, multiple financial growth, and high productivity, we are talking about a team.

In the first stages, we don't need a big office and several development departments. We need to cover several areas: frontend, backend, design, marketing.

You don't necessarily need 4 people, because, often, many mobile apps don't need a backend, plus one person can fulfill multiple roles.

I'm lucky here, I have a background as a marketer. I understand how metrics work, ad rooms, what creatives are, what they should look like, and what it takes to get the whole thing up and running. I'm not saying I'm the best at it, but this level is enough for the first stages of a startup's life. So I've been doing iOS development and marketing for the project.

Going through a cool school from Y Combinator I realized that a co-founder is needed. A person who will share my values and move in the same direction as me. Startups with co-founders are many times more likely to succeed than those with a single founder. This is shown by the statistics that the folks at Y Combinator have compiled. If you're interested in specific numbers, I encourage everyone to go to their school.

My co-founder (surprise surprise) is a backend developer. This means in addition to some business decisions, he'll be able to take on that role as well. This will greatly simplify iOS development (because most of the logic will be put on the backend). And of course, it will increase our speed a lot. We are both senior developers, which means that we will be able to think through everything competently and do it optimally with minimal financial and time investments.

There is one last role left uncovered. UX/UI Designer. Because of where I am in the IT industry, I have a lot of talented people around me. So to be honest, I found the designer even earlier than the co-founder. She will also get a share of ownership of the startup and the head designer position when the staff grows.

So together we are covering all the initial needs. With a team like this, we can make neither one nor two apps.

Maybe we will expand our team and take new people. For now, we plan to take only some temporary outsourcing for adequate money (if necessary).

From the start, we build in processes. Set goals and objectives. We make development boards, put up milestones, and spread everything out by dates. We calculate the economics of projects, plan investments, how much, and at what stages. In general, operational activities are also starting to go full speed.

Design development

At this stage, we have started on the application’s UI. Our goal is style, usability, and beauty from the user's point of view. We have thoroughly analyzed the competitors and identified the weaknesses of each. After that, by improving their apps we create our own.

As part of the design, I also laid out a set of objectives. The designer has deadlines for working out each screen. She has a description of the functionality. The goals of the app and the problem it solves.

We average 4-5 days of work (not full-time) per screen. Again, some people will find it too long, and some will find it too fast, but at this stage, it works and we are satisfied with it. We work out the entire design in Figma. All task descriptions, boards, and project descriptions are in Notion.

Our application allows users to create and generate text content for social networks. That's why we developed the most simple and understandable design, which will completely cover the problem with writing posts, scripts, their organization, etc.

Application Architecture

Now I'm not talking about the architecture of the iOS part, but mostly about the architecture in general. I'll be honest, initially, the app was made only for the iOS platform and stores everything locally. I didn't intend to add a backend, but later on, I reconsidered my decision. For this purpose, I had to rewrite parts of the functionality. At the same time, it was an important note not to break the existing one.

So, it turns out that we are making a full-fledged client-server application, so everything becomes clearer with the architecture.

We have a "service" that is responsible for user registration and authorization, it simplifies the work of the iOS application because you just need to send a couple of requests to the backend and the "magic" begins. For the next step, we needed to pull up the database. That's where we will store users, their IDs, data, and content.

Separate from that, we need to create a service for working with the database. Because the application should synchronize well with it every time the user opens the application.

Yes, yes, you heard right. For now, we are running with somewhat limited functionality of full synchronization, as we don't need it that much. The main point of creating a backend and pulling user-generated content there is to preserve progress. No one wants to delete an app or change phones and lose all their data and all their content. So at this stage, it's still the goal to preserve, not to make seamless instant synchronization for cross-platforming.

This is where I'd like to bring up the topic of "optimality". Often, aspiring startups (like us) make a huge mistake of trying to make the perfect product. They spend a huge amount of time (and some even financial resources) to make an ideal product to beat everyone else in the market. But the truth is, it's likely that they'll never make it to release. With limited resources, the word "perfect" is inapplicable. Even the first versions of Facebook were pretty ridiculous (not to mention Amazon). I, on the other hand, am a stickler for the word "optimality". It's much more important and more succinct. Instead of making the perfect product, the perfect design, the perfect architecture, and the perfect servers that can handle colossal loads, I will make an optimal solution. It will work fine. NORMAL. And no more. I can refine everything else gradually, as long as the optimal solution generates some cash for me.

The iOS architecture

Now for the most interesting part.

Since I'm an iOS developer, I'd like to write more technical "stuff" here. What we used, why, and what problems we encountered.

SwiftUI

Oh, yeah. We gave up on UIKit. It's even more accurate to say that "I gave up". I decided that since I'm starting to write something from scratch, let it be new and promising technologies. Moreover, SwiftUI is quite easy to layout, screens are made fast. Animations are also easy to implement. Moreover, SwiftUI is reactive, we are working with the Combine framework and it works quite well, no matter what anyone says.

Moreover for future hiring, I believe this will be a big plus. There are a huge number of talented developers who already really want to move to 100% SwiftUI but are not yet able to do so. The overwhelming number of apps are still on UIKit. Rewriting them to a new framework is long and expensive, and businesses don't like those words.

Did I regret choosing SwiftUI?

To be honest, despite all the pluses of the new framework, there are some outright minuses. For example, navigation. Yes, most developers have problems with it. It's not obvious enough how to take the routing logic into a separate entity, encapsulate it there, and take this responsibility away from the UI (like we're used to in UIKit). With iOS 16 this has gotten a lot easier and clearer, but the problem is that we're still supporting iOS 15 after all. Some guys write their extensions and somehow find a way to bring out the logic of routing through several levels of abstraction, we didn't have the resources for that. That's why we got the classic SwiftUI routing.

We also encountered problems with the custom TabBar, which did not want to work correctly. Spent about 4 days doing everything competently.

Is reactivity a pain? For many developers, creating reactive applications is a challenge. Especially for those who have never worked with this paradigm. I had a pretty good experience working with RxSwift, so in general, the approach was familiar. I just needed to understand how it all worked inside SwiftUI and how to build the architecture.

At the dawn of SwiftUI's launch, everyone was talking about how MVVM was the perfect design pattern for it. Over the last six months, I've been hearing the opposite viewpoint, that MVVM is not suitable for SwiftUI, but that MVI is already laying down quite interestingly. I took the classic approach that Apple recommends. I had several managers that were needed in many places in the application, created one instance, and passed it throughout the UI hierarchy as an Environment variable. Admittedly, I made separate ViewModels for screens a couple of times, as I didn't see the point of making the class an observable manager.

Conclusions

So, I would like to summarize the above and the results of the first launch.

Would I choose SwiftUI for my next application? Most likely yes. But while writing the application, I will be more careful in writing code, create more reusable UI components, and adhere to MVI architecture more strictly.

Is a team really necessary? Yes, when you are not alone, you feel more confident, and you feel responsible not only for your destiny but also for your guys. It is always more interesting and precise to think through business or technical architecture together. Plus the saying "one head is good, but two are better" works perfectly here. Now the desire is only to increase the company's staff.

What about the finances? It would be foolish to expect big income at the start of the project, so I consider only investments, investments, and once again investments. Of course, a small income begins to appear, and people buy subscriptions, but it is not comparable to the amount of money that comes from investments. I understand these risks and take them into account.

Building your own business is a long-term game, full of risks and costs. Emotionally, I am ready for it. It is not an easy path, but I think it is quite realistic for me. Would I advise all developers to follow this path? Of course not. There are dozens of talented developers around me, they are happy, and they earn a lot of money with rather low responsibility. They have a lot of free time. They travel and spend money on whatever they want. Do they need to throw money into the bonfire of a business that could go out at any moment? Probably not. Everyone chooses their own way. I, for example, can't live without it all, and for some people, it's a real hell. I do not condemn either of them, and I am very glad that each person chooses his own way.

Thanks for your time, for any questions you can contact me by mail or on Telegram (@maxnech) (or LinkedIn).