On November 2nd 2018, it was time for part 2 of DO iOS: the conference hosted by CocoaHeadsNL in Amsterdam*. With about a dozen of talks — all related to iOS development and Swift — and free coffee and food, the place to be for developers eager to keep learning and improving their game.

I had the chance to attend the event, and will share some of the most exciting highlights with you here. Let’s dive in!

*If you’ve missed part 1 of our series on this event, catch up here.

1. Trunk-based development & delivery pipeline

The first talk that caught my attention was by ABN AMRO. With five different speakers on stage, each addressed a different topic, sharing valuable knowledge and explaining how they work. Two points piqued my interest: 

1 — The source-control branching model. The team develops using a trunk, not with a standard git-flow. They strive to have one single branch that is always stable, and releasable at any time. They usually don’t do pull requests (or only for short-lived feature branches), but rather opt for pair programming to solve technically complex problems, and for post-commit reviews. The benefits:

  • This method removes the pain of resolving merge conflicts, reviewing huge pull requests that regularly just end up stating “it looks good, merging!”
  • It forces you to push small commits where the newly introduced code is tested.
  • It encourages you to refactor your code and keep your code base clean (refactoring in a feature branch makes it difficult to review and will probably end up in terrible merge conflicts).

2 — The unbreakable delivery pipeline. To have this method running smoothly, you’ll need to put real effort into testing your code and having a solid delivery pipeline. Here’s an overview of each step needed before delivering a new product version:

ABN AMRO’s delivery pipeline

As this slide shows, the team spends time on testing, code quality, and continuous integration/delivery. What amazed me is that with this pipeline, it’s simply impossible to break the trunk due to the many safety points before your commit gets pushed to the remote.

Some of the external tools used by the team:

  • SauceLabs to run UI tests on real devices stored in a huge warehouse.
  • SonarQube to analyse code quality after each commit, telling you the amount of code duplication and code coverage. The example they showed had a 88% of code coverage, and only 3% of code duplication. Pretty nice!
  • Nexus to share archives between developers.

To me, this talk demonstrated that, and why, putting effort into continuous integration/delivery is most definitely worth the time. In other words, not testing code is not an option when you’re building high-quality products. 

We may also experiment with developing using a trunk in the near future, with its many benefits for smaller-scale teams like ours. In addition, I love the idea of pair programming to solve complex problems with two brains instead of one, resulting in a more consistent and clean code base. And the external tools mentioned above are worth a closer look.


2. App architecture & testability

Another interesting talk was by ANWB’s David Broza. David discussed ANWB’s way of programming, how they maintain a clean code base using different app architectures, and how they test their code. As with ABN AMRO, ANWB puts a lot of effort into testing their code and using well-known architectures.

David demonstrated how they inject dependencies to make code testable. ANWB uses custom assemblers, which is pretty similar to Swinject, the dependency injection framework for Swift that we use at The Mobile Company. For unit testing, they’ve created their own Swift mocking framework — similar to Cuckoo, the framework we use.

It’s clear that writing well-tested and well-architected code is a must, confirming once more that we’re on the right track in producing a well-maintained code base by teaching our developers why and how to write testable code.


3. Business model & UI/UX of a successful product

Alexander Griekspoor, an experienced app developer who has been building successful products for a long time, shared his story on how he created the Agenda app. I love hearing stories from inspired developers, and I wasn’t disappointed.

To me, hearing how he came up with the product idea, the business model for Agenda and how they’ve built their user base were likely the most valuable bits of the talk. The highlights:

  1. Agenda solves a problem Alexander himself initially had to deal with — i.e. he is acting as the actual user. This level of involvement makes it easier to build a product that brings real value.
  2. He explained that a good designer is mandatory to build a great app, showing before and after examples that really proved the point.
  3. When you download Agenda and open it for the first time, you’ll see a story written by Alexander. It made people download the app — not for the product itself, but for the funny story he added to it. That’s how the app got viral on Product Hunt and started gaining attention.

In addition, Agenda has an impressive business model. What’s the purpose of an app if it lacks a relevant business model based on the value users get from it? Agenda primarily offers a 4-month subscription, helping users unlock every newly released premium feature — forever. If you feel like your app has all the features you need, you can cancel your subscription — but you’ll get to keep your product as is, forever (as opposed to losing your premium features, as with most subscription-based apps).

Providing clients with advice on what business model they may benefit from, or how they can further develop and improve their product through innovative concepts, can add tremendous value to your service. It allows our team to create even better products, both on short and long term.


4. Siri shortcuts

Daniel Steinberg, founder of Dim Sum Thinking, gave a nice talk about Siri shortcuts, showing us how to use them in our own apps, and demonstrating that implementation is fairly easy.

Even though not everyone uses Siri (yet), there is potential there for winning ground in the near future. If Apple keeps pushing new tools for developers to develop with Siri and voice, it shows their intent to make it standard.

Integrating Siri shortcuts into apps could bring even more value to clients and their users. We’re motivated to continue mastering these technologies to provide our customers with state of the art services. Voice is the future, isn’t? (Who has never listened to a podcast?)


Bonus: Machine Learning at happn

At the end of the conference, free drinks were available for everyone who attended. Time to meet other passionate developers and have some fun! I got to chat with a Paris-based developer currently working at happn.

A bit of context: happn is a dating app helping you find people you’ve met before. When you sign up, you create a profile, pick your best pictures, write a bio and can start browsing other people’s profiles. That’s basically what the app is used for.

Why the context? As you may have guessed: with apps like happn, the photos you post should conform to strict standards. Still, that doesn’t stop some users from posting unreasonable pictures that may hurt the sensibility of others. Users can report these profiles, and eventually they will get removed — however, that process is manual. Inconvenient, right?

So, happn found a solution: training machine learning models. Configured with a wide set of pictures prohibited from the app, these models are set up to ban accounts that do not respect the rules — meaning that every time a new account is created or a new picture is posted, it’s first approved by an ML model. Pretty cool!

Machine learning is a technology with promising perspectives, and can be used for an endless array of solutions. As a development agency, integrating machine learning into our apps definitely has potential to add value to our service, and to make our customers even more happy.


What’s next?

The DO iOS 2018 conference featured a couple of very interesting talks, leaving me with lots of thoughts and ideas. The bits of knowledge fit well with our way of working at The Mobile Company and we probably will soon dive deeper into trunk-based development, as well as continue doing pair programming, investing time in continuous integration, and, of course, educating our developers on testing, app architectures and patterns to work with high-quality code bases.

Please note that this blog post only covers a selection of the event talks. Exclusive rights to selected visual footage belong to CocoaHeadsNL.