Trendyol iOS Application’s Navigation Redesign and Implementation

Changing navigation style of an application is a heavy task that requires detail-oriented teamwork. When we first decided to change Trendyol’s navigation, we really tried to think all possible obstacles on the road. After weeks of planning, programming, and testing, we proudly introduce Trendyol iOS App V3.

In this blog post we are going to discuss why we’ve decided this transition, types of problems we faced, what we did good and bad, and lastly outcome of this project. While some of the cases are specific to Trendyol, others can be considered as general design and programming issues can be experienced by any developer.


Previously, we were using side menu navigation at Trendyol’s iOS app. The user could open side menu by swiping left to right at the edge of the screen or by tapping the menu button at the top left corner of our homepage. Side menu contained several items to navigate the user to the desired point of application. Simple as that. No hidden navigations like 3D touch or any type of gestures. If it was that simple and our users already got used to interacting it, why we took a risk and changed it.  Here are the reasons behind our decision:

  • As iPhones get bigger it becomes harder to reach the top of the screen for most of the users.
  • We needed to enhance the use of Favorites and Search screens since we have a new feature called ‘basket consolidation’.(We need users to see more products from different boutiques more easily)

With these requirements in our minds, bottom tab bar is selected as Trendyol’s new navigation style. Some reasons why we think bottom tab bar is a better fit for Trendyol are following:

  • It successfully solves the unreachability problem of top left menu button by moving its content to the bottom of the screen.
  • Favorites and Search menu items become more accessible when they moved to the bottom of the screen.
  • World standard is shifting to bottom navigation. Users are already familiar with how to use tab bar navigation. Well-known applications like Twitter, Instagram, Spotify and many others use this approach.

Here is the V3 of Trendyol iOS application homepage with bottom tab bar:

Tab Bar Navigation Homepage

Tab Bar Navigation



The navigation migration project was already on the iOS app product roadmap, so we’ve been separating the whole app to different storyboards for 2-3 sprints. The whole app was in only one storyboard at the time. To increase the speed of the implementation process, we’ve thought about using the storyboard references which have been around since iOS 9 and unfortunately, our app was supporting minimum iOS 8 at that time. After the negotiation with the product team, they looked at the data and decided to drop the support for iOS 8. Hello storyboard references, hello happy developers 🙂

We ended up having references for the 5 main view controllers which are embedded in their own navigation controllers:

iOS - Tab Bar Navigation Storyboard


Before implementing this new way of navigation to our app, all of the A/B testing values were generating after the initial view controller of the app is visible to the user. Since this navigation changes take place from the beginning of the app we also had to move our A/B testing process to another view controller which is called “FakeSplashViewController”. You get the point here, right? 🙂 We are showing a fake splash after the real one to initiate our a/b testing values so the app can decide whether the user should see the tab navigation or the older navigation flow.



Product team knew what might be the outcome of disturbing users’ comfort zone by changing whole navigation. Loss of conversion rates is what we expect for some time after release so product managers decided to use A/B testing for tab and side navigation to see how well or bad tab bar doing.

At Trendyol, we frequently use A/B tests to be sure our applications meet our users’ expectations. A/B testing is an excellent tool for deciding final form of a new feature or screen. Generally speaking, implementing a new A/B test into a project is a desirable and fun task for a developer. While migrating our iOS app to tab bar navigation, we realized that some of the existing tests can be designed in a more efficient way. Here are some cases that lead us to think we should more carefully design our tests:

  1. Designing app’s whole navigation with A/B test is a lot trickier than it looks with lots of screens that are not implemented for this kind of transition.
  2. One main problem is screens should give some if its content area to bottom tab bar. Some screens need to be redesigned and re-implemented because of the existence of tab bar.
  3.  Another problem is we needed to carefully fix some broken screen transition animations. Small pixel differences in transition animation can be looked extremely ugly to the user. So we reviewed our animation system to work with both side menu navigation and tab bar navigation.
  4.  Having ‘nested A/B tests’ can cause lots of different screen states and redundant code. You can see what we mean by nested A/B test in below graph. This also makes it harder and more time-consuming to test new and existing features of the application.


We can use a real example for this case. While navigation project is in progress Trendyol has an A/B test on its product screen also. The main idea behind ‘the product screen A/B test’ is to make content (photo, price, sale, variant) look great on both small and big iPhone screens. But here is the problem; we have one ProductDetailViewController and all the UI decisions (What to show, ratios, margins, constraints) are made in that view controller in separate ‘if statements’. This approach worked for a while but when we decide to use another A/B test for the navigation system, we came to a point almost lose control over this huge view controller with doubled conditional statements.

What we learned from this experience as a developer is if we have a massive A/B test, probably writing a separate class for what we testing is a much cleaner idea. Keeping A and B cases in different classes makes it easier to work on a specific one, makes the whole code more readable and deleting the feature that loses test become an incredibly small task. Of course, this idea comes with a time burden. It is clear that this approach takes more time to implement. Also, it should strictly be used for fairly big A/B tests, not for button color decision tests.

A-B test sample diagram (2)

Homepage -> Search -> Product Detail flow gets complicated when we put an A/B test at the beginning of the flow.


We are using 4 different deep link schemes to navigate our users directly to the proper point of application. It means we had to deal with 4 x 2(app states) x 2(from an ad or from push notification) = 16 different types of landings. After navigation A/B, now we have to cover all 2(different navigations and screen stacks) x 16 = 32 different types of landings because finalizing the A/B test of the navigation is going to take some time.


We are still improving tab navigation experience with each release. Any feedback from customers is extremely valuable for us to understand their needs about the new version of Trendyol. We are more careful about implementing A/B tests properly and thinking several steps further while coding. After all, it was a fun and instructive experience for everyone in Trendyol.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: