Meet our iOS team

We’re growing

According to Financial Times, Appunite is 586th fastest-growing company in Europe. Our native iOS team is no exception to this company trend. At the moment of writing this, there are 18 of us, iOS devs, and we’ve 3 open positions. We work across 6 different product teams and there’s a seventh one coming.

Let’s dive into challenges we’re facing and how we plan to approach them. This will give a sneak peek on what to expect after joining us.

How we work here

How does our iOS team blend within the company structure?

As you may imagine, we primarily work on our clients’ products and the product team is the one that you’ll be spending most of your time with. Platform teams are orthogonal to those and the iOS team is one of them.

We face different challenges and learn various things throughout the products development process. We see it as an opportunity that can help us grow faster and make each individual’s skill sets more complete and versatile.

It wasn’t always all that great though. We went through a rough patch as an organisation when we had moved our focus to products. The pandemic didn’t help either. We went through a period of isolation among teams, whereas before we had had a quite spontaneous flow of knowledge because of more regular migrations of people between product teams as well as better interaction between us.

However, this wasn’t all that great either due to the fact that it takes time to form a team. People need to get to know each other, find out their expectations and fill in others' weaknesses.

All this brought us to a place where we are now. Although we’re still learning a lot as we go, we know much more about creating better product teams and act more consciously on creating stronger platform teams.

Who do we work with?

We have very different clients from all around the world: Asia, Africa, United States and Europe. We aim to become partners with those people and form long-time relationships. But what does it mean for us as developers?

Firstly, we have an opportunity to be part of a group of people who understand each other well, have time to build trust, have well-established means of communication and can focus on doing their best work.

Secondly, and this one is really cool for us as software engineers - all the challenges that we would be facing at the product company, related to long-term maintenance of the codebase and scaling it up are here. Modularisation and architecture in general, build time optimisations, migrations, long-term dependency management are some of the things we face in our daily work.

So I believe we’re getting the best of both worlds. We encounter and solve problems both related to different markets and industries, as well as different product cycles.

Now that you have a better context, let me tell you a bit more about our objectives, as well as the values that we stick to in the process.

Let’s become a team

To become one we need to know who we’re working with and what we can expect from each other. It’s not as easy as in a product team since we don’t work together on a daily basis. In order to keep this team vibe flowing, we have bi-weekly water-cooler meetings. We meet in randomly selected groups of 3. This way we keep everybody engaged in getting to know colleagues and exchanging experiences.

Let’s work as a team

What’s next? We want to use different experiences that each of us has as a factor in strengthening our learning efforts. Across the entire iOS team, we want to use the best practices, use the best tools for the job and avoid making the same mistakes. More importantly, we want each and every team member to understand why they make those choices.

We know that each product is different and may be in another phase encountering various conditions in its respective environment. For example product in an MVP phase, may need to do some shortcuts, but there needs to be a plan on how to pay such technical debt off (by the way, if you’d like to know how we perceive technical debt, this article may interest you). Because of that, we want our iOS developers working in separate product teams to have autonomy over the decisions they make. We don’t want to impose a single best way to do something. In some areas, we may have strong opinions, in others propose sensible default, heuristics to help you find the answer, and sometimes you’d be the pathfinder yourself. The most important thing is for those decisions to be made consciously. We would also like for them to be documented, so we can verify them from a time perspective and learn from them.

In order to achieve that we’ve started the iOS Guidebook initiative. It’s ought to be a set of opinions we have and heuristics we use as a team along with the reasons we have to proceed the way we do.

Let’s get specific - tech stack glimpse

CI/CD

We use Fastlane for building automation in all of our projects. As for the CI service provider - it’s a decision made on the product team/client axis, but currently, you’re most likely to land with Github Actions.

Testing

As a platform team, we are committed to automated testing. We love seeing the column of green checkmarks and we believe it helps us react much better to unavoidable changes. Some of us use Quick/Nimble, some of us old good XCTest, but you can be sure that working with tests will be your daily routine at AppUnite.

Reactive programming

All of our teams use a reactive approach in some form. Recently, when we’re able to choose we go for Combine. In other projects, due to legacy reasons, you’ll probably find RxSwift.

Tooling

If we can avoid mistakes or save ourselves some time (or both) thanks to great tooling, we do that. Because of that, in our projects, you’ll find such tools as Swiftgen, Swiftlint, Swiftformat, Sourcery, and Xcodegen. I think I won’t be the only one if I say that I especially love the last one. It helps us with merging xcodeproj files, but most importantly, thanks to it, changes we do in project configuration are easily trackable and don’t go unnoticed.

Team players

We believe in collective ownership over the code we create. We care for constructive code reviews and pair programming, and we encourage all team members to take part in those. Are you interested in what other values drive us? Check here.

Developer experience

We care about maintaining a great developer experience as we believe it helps us stay focused and effectively be more proud of the work we do.

One of the examples of things that we do to achieve that is maintaining iOS projects, with such tools as carefully planned modularisation and conscious dependency choice and management, in a way, so that builds are fast and tests run quickly.

Shiny new stuff

We know that every one of us likes to work with shiny new frameworks, language features, and tools. So what’s our approach here? Again, this is each team’s own call. This is another thing that we need to balance out. On one hand, we need to be aware that if we neglect adopting new stuff it will be harder and harder for us to maintain a good pace and our work will become less enjoyable. On the other hand, we need to keep in mind our client’s business priorities to decide when is the right moment to do the transition. We want to make sure we’re working with the best people, and that includes people that treat their work responsibly and are able to make such calls.

So, when will you join us?

We believe we create a great growth environment and that we have our radar calibrated pretty well for challenges that we’re facing. We need great people on board. Become one of them!

Tech