KINTO Tech Blog
Event

I participated in "TechBrew in Tokyo: Managing Technical Debt in Mobile Apps"

Cover Image for I participated in "TechBrew in Tokyo: Managing Technical Debt in Mobile Apps"

Introduction

Hello. I am Nakaguchi from KINTO Technologies, Mobile App Development Group.
I participated in the event TechBrew in Tokyo ~Facing Technical Debt in Mobile Apps~, held on May 23, 2024. I would like to report on the event.

The event day

The venue was at the Findy where their office was newly renovated. I had heard the rumors, but seeing the spacious and beautiful event space in person was exciting 😀 True to the name “TechBrew,” there were plenty of alcohol and snacks available, and the atmosphere was very relaxed. However, since I had an LT (Lightning Talk) presentation later, I refrained from drinking alcohol until the presentation was over👍

1st LT "Steps to evolve Bitkey's mobile app"

They shared the history of Bitkey's mobile app up to the present day. The app was originally built with React Native, but it was evolved through transitioning to native development, implementing SwiftUI, and then adopting TCA. However, they said that the SwiftUI implementation is still a work in progress and might have been a mistake. They faced challenges because the behavior of SwiftUI changes depending on different iOS versions, which was something I could relate to from my own experiences.
During the LT, the comments that really stood out to me were, "Everything we thought was good was the right choice," and "The decisions we made at that time were probably the right ones." It made me realize how true it is.
I also had the opportunity to chat with the presenter, Ara-san, during the social gathering after the LT. We talked about many things, including Swift on Windows, and I learned a lot of new information. It was a very enjoyable conversation.

2nd LT "Approaching technical debt in mobile apps as a whole company"

They discussed what technical debt is and how to tackle it.
One of the speakers highlighted the need to distinguish between:

  • Debt we are aware of, but accept it to gain returns.
  • Debt we are unaware of, or that became debt due to changes in the circumstances.
    They mentioned that the former is manageable, but the latter can become problematic if ignored for too long.
    To address technical debt, they stressed the importance of negotiating time to resolve it, even if it means pausing business tasks. They emphasized that technical debt is a shared problem, involving not just the development team but all stakeholders, which I also agree with. I feel that such negotiation skills are especially important for engineering managers and team leaders.
    They also mentioned that they use FourKeys to visualize the situation, but warned against focusing too much on numerical goals. I also feel the same that visualizing a team's development capability is challenging, and I am careful not to rely too much on frameworks like FourKeys.

3rd LT "How to deal with technical debt in Safie Viewer for iOS"

The presentation covered the challenges and strategies in developing their app that has been around for 10 years.
The app still uses many technologies from its initial release, and while there is a desire to re-architect, the current system is stable and capable of adding many new features. As a result, they were unable to justify the time-consuming refactoring, and were unable to take any action to eliminate the debt.
Currently, they are addressing the issues by doing what they can, with the following two main policies.

  • Take immediate actions if possible:
    • Updating to the latest Xcode version as soon as it is released.
    • There is code that cannot be written unless the version is upgraded, which leads to creating legacy code.
    • Implementing Danger
  • A steady approach
    • Currently using MVC/MVP
    • Asynchronous processing is closure-based
      • Re-architecting from this state is risky.
      • Test new features with modern technology.
        I thought it made sense that to actually get started, you need to draw up a specific schedule. I'm often hesitant about major refactorings, so I’ve learned the importance of setting a clear schedule and sticking to it.

4th LT "Ensuring safe mobile development with package management"

Like LT3, this talk also focused on an app with a long history of 8 years. They discussed how they addressed technical debt by focusing on commonization and separation.
A recent challenge they face is excessive commonization . For example, their Channel data has around 100 parameters (borrowing the speaker’s terms), and there are many situations where they end up with data that is not used every time.
On the other hand, they warned that excessive separation of responsibilities can also be problematic. There were instances where functions were separated even though they were only called from one place, leading to an overdone state.
The importance of "thoughtful commonization" and " thoughtful responsibility separation" left a strong impression on me, and I realized I might have separated things without much consideration.
They also explained that it is a good idea to manage these issues using Package Manager and introduced some ideas and methods for doing so.

5th LT "Tackling technical debt with GitHub Copilot"

This was my presentation. You can find the presentation content here .
I discussed the use of GitHub Copilot in Xcode. Compared to VScode, which officially supports GitHub Copilot, Xcode still has many limitations, and its usage rate is not growing as much.
However, I found that Xcode's Chat function can significantly help in addressing technical debt, so I focused on that in my presentation.
During the presentation, I demonstrated the Chat function, and I felt that the attention of the entire audience became even more concentrated. I was very happy that everyone seemed to be listening with interest.
This was my first time speaking at an event outside of our company, but everyone in the audience listened warmly, and I was able to complete my presentation without any problems.

Conclusion

After the LT sessions, there was a social gathering where I had the opportunity to exchange information with many attendees. It was a very stimulating experience, and I felt motivated to continue participating in and speaking at such external events in the future.
I also had a chance to speak with Takahashi-san, the organizer of the event. We discussed how great it would be to hold a joint event between our Mobile App Development Group and Findy. I look forward to actively pursuing such collaborations.
As a souvenir, I received an IPA made by Findy!

Facebook

関連記事 | Related Posts

We are hiring!

【iOS/Androidエンジニア】モバイルアプリ開発G/東京・大阪

モバイルアプリ開発GについてKINTOテクノロジーズにおける、モバイルアプリ開発のスペシャリストが集まっているグループです。KINTOやmy routeなどのサービスを開発・運用しているグループと協調しながら品質の高いモバイルアプリを開発し、サービスの発展に貢献する事を目標としています。

【部長・部長候補】/プラットフォーム開発部/東京

プラットフォーム開発部 について共通サービス開発GWebサービスやモバイルアプリの開発において、必要となる共通機能=会員プラットフォームや決済プラットフォームの開発を手がけるグループです。KINTOの名前が付くサービスやTFS関連のサービスをひとつのアカウントで利用できるよう、様々な共通機能を構築することを目的としています。