Modular Channel Management in Super App

Ceyda Karabulut
Trendyol Tech
Published in
4 min readJun 30, 2022

Hello everyone, I am Ceyda!

I am working as a mobile developer for 3 years. I am at Trendyol mobile iOS team for the last 1 year of this journey.

https://www.fegno.com/wp-content/uploads/2022/03/mobile-app-development-company.gif

As our users know, Trendyol has wide variety of service channels like grocery, meal, Dolap (as second hand trading) and these continue to increase day by day. So we need to manage this on mobile projects and it should be scalable.

Applications that provide more than one service that a user may need are called as super app.

While developing a super app structure you may be faced with some challenges. Because if you are developing multiple channels in one app, you need to maintain a stable view to create integrity. Users should see familiar structures on each channel and should not rediscover all similar processes for each channel to increase usability. Also, you may have to use the same structures for technical reasons, for example, if you have some extensions for a view component, you should access it from all channels to avoid code duplication and differentiation.

In the Trendyol app, we manage super app challenges by modularity.

Channels are being developed modularly, like separate apps in one project. But in this case, we need to handle common structures across channels. Let me first mention our module mentality. We have two types for naming;

  • Kit: Has util functions, extensions, helpers, builders, managers, events, loggers, etc.
  • Module: Has specific screen flows and classes that are just related to this module. We are separating modules by business domains. For example, orders, which has an order list and detail screen, is a module because these are linked main screens for the domain of the orders.

We are naming modules according to this point of view, but all these kits and modules are located as separate projects in the workspace and able to move or reuse.

For a channel developer, first of all, you need to decide the kit or module that is suitable for the specific task. To make this decision, you have to answer some of the questions like the following chart.

The Decision Chart
The Decision Chart
Through this structure, we are able to build and run our channels as a separate applications.

Let’s create a case to handle it on a project structure like that;

You have ChannelA and ChannelB in your project, and you need to show a bottom popup in the same view, in both.

It would not make sense to do it inside one of them because you shouldn’t be allowed access from one to the other, in the best case. And of course, it will not be the right approach to have the same code in both.

Then you can build a structure like that;

Folder Structure

The channels group contains a folder for each channel and you can locate kits and modules that are specific to this channel in its group (ChannelA, ChannelB..).

The common group contains kits or modules that can be accessed from multiple channels like our example. You can create a kit for the common bottom popup and you can import and use it from channels.

Usage Example

It is important that kits and modules in common should be developed in a really common way. If a developer builds the common view or something with a channel’s rules, it would not makes sense to be located in common and it is useless for the other channels. To avoid this, we are injecting all properties that can be changed from channel to channel, using protocols and delegates for actions that can act differently, and developing its logic on the channel that implements. By means of this, we do not have any channel-specific logic codes on common kits/modules.

As a result of this, the super app needs to build a smart structure to manage dependencies effectively. Also, you should always think ahead, otherwise, when you get a new channel on your app or a comprehensive change, you will have to make major changes and these and unforeseen rapid changes will most likely fail.

After a suitable structure has been established, and the team met at the common point channels are growing efficiently and rapidly.

  • We are using to maintain our project by Tuist, you can check the presentation about Tuist and our structure by team members.
  • Also, testing is one of the most important parts of our project, you can read about UI Testing from here, one of our various testing methods.

Thanks for reading, feel free to contact me if you have any question! :)

--

--