How we built the iDB app – part 2: from design to code

By , Aug 4, 2016

iDB app cards

This is a guest post by Giulio Michelon, proud designer and CEO of Belka, the Italian studio that designed and developed the iDB app. We’ve asked Giulio to come here and share his experience developing the app, from the initial concept to the final product. Part 1 was published last week, and part 3 will be published next week.

In the previous part, we talked about the lo-fi design, which mostly iterates on the basic ideas and concepts. In this part I will talk about the high-fidelity design and the actual implementation of the product.

From low-fi to pixel perfect

After talking with Sebastien about how the app was supposed to work, we had to make it visually attractive. We love nice and clean design, which is why we iterated on different proposals and decided for the best one.

low fi iterations

Can you spot the winning iteration? Probably not, because it’s not here!

As you can see, the high-level design is very demanding: we had a couple of different choices. The main differences between the pixel perfect design and the low-level design are:

  • In the low-level design, the problem to tackle is usability,  which is usually already defined by the majority of other apps.
  • In the high-level design, there’s taste involved, and that’s why it is usually harder. To tackle the problem we started with a broad range of choices.

After tweaking and discussing with Sebastien about colors, other apps styles, and much more, we came up with a polished and well-defined version of the Card layout.

almost final version

The almost final version

The Card layout has been tweaked again during the development from this version, but it’s mostly in his final form.

We followed the same path for the Article view, in order to get a visually pleasant and highly readable result.

From design to working code

Once the design part is done, it is time to open Xcode, a tab with StackOverflow and put the developer hat on.

The main issue in this app has been the swiping gesture. It looks nice and simple, but in reality that single feature represents 40% of the entire development. Animations on iOS are very hard, and Sebastien expected nothing less than the perfection from us.

We didn’t design the swiping gesture before the implementation. Instead, we decided to use the Tinder card animation as the expected result. Below you can see the final result.


The other feature that needs to be highlighted is the connection with WordPress. is built on WordPress, and we had to link the existing database, in order to let the authors of the website write and post their articles from the same interface. We made sure to make it convenient for them by not altering the WordPress dashboard at all.

I don’t want to bore you with the details of the implementation since probably most of you aren’t developers, so instead, I’ll give you some random trivia about the app:

  • The app has 98 implemented features. Does this sound a lot? It’s interesting to consider that this is a relatively simple app.
  • The iDB app contains a whopping 8,020 lines of code.
  • The most consumed food by Luca (our lead iOS engineer) during the development was Canederli. This helps his brain produce high quality code. Look at the next point to know how good it works.
  • The app has been 99.6% crash-free in the first three weeks. Canederli is amazing. We’re sorry for the 0,4% of users who’ve experienced crashes. We are working for you right now.
  • The app is entirely hand-crafted in Italy, like Ferraris.

That’s all for this post about how we build the iDB app. In the next (and last) act, we will cover the Apple Watch app and some secrets. Stay tuned!

If you have any question about the high-level interface design or about the development, feel free to ask.

  • Share:
  • Follow:
  • Noohar

    “The app is entirely hand-crafted in Italy, like Ferraris.”…lol…I liked

  • Ilja.

    I really like the visuals of the application, but I am not sure about the technical implementation. IMHO you may implement a bit more caching. Polling every time the authors full information when loading the article overview – even if it’s the same author… I attached a sample screenshot.

    Also: why do you track the usage three times? Via fabric (Answes), onesignal and Google Play(?!). I can’t find any privacy policy linked, which would allow this.

    • Giulio Michelon

      Hey, thanks for your hints! The first point is interesting, maybe we will implement it in the future.

      Regarding the tracking we are using different services to ensure the best experience: analytics (Google), crash reports (Fabric), and push notifications (OneSignal) so that’s already the best we could offer in terms of requests.

      • Ilja.

        Glad I could provide a little improvement-idea.

        Alright, thanks for the information. Not quite sure about the american law, but having a privacy-policy link providing all the information you just told me, would be great. 🙂

  • Endriu Andrei

    Could you show parts of code ? I am a beginner trying to learn coding

    • Giulio Michelon

      I’m sorry Endriu but there is no plan of releasing parts of the app right now.

      • Endriu Andrei

        No problem , thanks for your reply

      • iKhalil

        Hello, I’m very impressed about the animations; can you share some courses or tutorials where to master or at lest begin to learn a little of iOS animations?

      • Giulio Michelon

        We don’t have any tutorial about that now, but we will release it in the future. It’s been quite challenging for us as well!

      • iKhalil

        Well, thanks, I’ll be expecting how you guys go

  • Black Dynamite

    Were you presented with some “data” about the preferences of the general public with regards to the UI? It’s one thing to design for one’s own personal preferences, but what if that clashes with the rest of the users? I’m curious because I’m always battling my own idea of what is visually pleasing with that of others.


    • Giulio Michelon

      We didn’t A/B test this UI style, so I can’t really answer this question. The choice has been made considering the mobile apps use case, and designing consequently.
      I agree with you that defending a design choice sometimes is hard, but A/B testing those kind of decisions is very expensive and the budget didn’t allow that. Therefore we followed the decision and helped with all the insights we could provide based from our previous projects.