Introduction

Hey there! I’m Viacheslav Vorona, an iOS engineer. In August this year, I had the opportunity to participate in iOSDC Japan 2024, a conference for iOS developers held in Tokyo.

It was my first time attending a conference where the sessions were conducted (almost) entirely in Japanese, so I was a bit nervous. However, it turned out to be easier than I expected. Thankfully, when looking at code snippets or listening to topics I’m at least partially familiar with, even if I didn’t catch every single word, I found it wasn’t too hard to follow the presenters. Special thanks to those who included English translations on their slides! That was as helpful as it gets ❤️

Now, I have attended several sessions. There were a couple of talks about curious hobby projects their authors are passionate about, like this session by ta.inoue about the principles behind GPS and demonstrated data sniffing of transmitted signals using an iOS device. It always fascinated me how the GPS system is so simple in principle yet tremendously complex in how it is actually built, so I decided to check this session out and wasn't disappointed.

There was also the impressive deep dive into the history and purpose of various UIKit ViewControllers by haseken. Even though we encounter ViewControllers all the time in our job, UIKit is so extensive and some view controllers are so niche that it’s possible you haven’t even heard of some of them (there certainly were quite a few unfamiliar ones for me), so that session was really interesting as well.

Today, however, I'd like to talk about a couple of things that I thought were worth keeping in the back of my mind for the future, as they might be useful in practice someday. Let’s take a look, shall we?

Practical Use of Hidden APIs

Every developer, every now and then, finds themselves in a situation where they need to take a closer look at some third-party code they are utilizing in their projects. We do this to figure out whether a library or framework satisfies the needs of our new project, to better understand the tools we are already using, and sometimes even to track down and report bugs in third-party code.

There is, however, a special category of frameworks that we all use daily but are still some of the most obscure: the iOS frameworks, such as SwiftUI and UIKit. Along with the well-documented and recommended APIs, these frameworks have a lot of capabilities we aren’t aware of. Finding and using those capabilities can not only be an interesting exercise but also benefit iOS developers in niche situations. This was the focus of the session titled iOSの隠されたAPIを解明し、開発効率を向上させる方法 (How to unlock hidden iOS APIs and improve development efficiency) by noppe.

noppe split his presentation into three parts:

• Perform:
  This part was a short introduction on how one could expose hidden methods both in ObjC (by replacing the .h files of the classes we are interested in) and in Swift (by fiddling with .tbd or .swiftinterface files).
• Use Case:
  In this part, probably the longest, noppe listed scenarios where hidden APIs could potentially be used:
  • Prototyping: useful and safe, as you can cut corners in non-critical code without impacting functionality, even if those APIs change.
  • Testing: useful and relatively safe, as you can more easily cover some testing scenarios, but it is better to cover the undocumented APIs with tests as well to quickly detect any potential changes.
  • Production: obviously unsafe, not only because the APIs are not guaranteed to perform the same way in the future, but also because your app might get rejected from the App Store.
• Find:
  The last part was dedicated to finding hidden APIs primarily through checking .h, .tbd, and .swiftinterface files, analyzing stack traces, and engaging with the community to see what others have found.

In his presentation, noppe also provided several examples of situations where hidden APIs might be useful. Let’s take a look at them:

For the prototyping stage, one memorable example was related to UITextView. As you may know, although having a placeholder in a text view is a common feature, Apple doesn't provide an accessible API for setting a placeholder. This usually means having to create custom solutions, such as adding label subviews. However, it turns out that UITextView has an unexposed method, setAttributedPlaceholder, that does exactly that. Even though it’s not allowed in production, you can still use it during prototyping or proof of concept stages to save time.

An example related to testing involved UIDebuggingInformationOverlay, a tool that was easily accessible prior to iOS 11 but now requires some fiddling to access. It is still possible to enable it by utilizing hidden, low-level features of UIKit.

UIDebuggingInformationOverlay

Learning about undocumented APIs can offer developers a deeper understanding of the tools they use daily. While using these APIs in production is not recommended, knowing they exist expands the possibilities in situations where unconventional solutions are needed. Additionally, understanding how they work is a great way to improve your own API design skills.

Overall, it was a really practical and inspiring session, which I’m glad I attended.

Server-driven UI

As developers, we are usually striving to keep up with the latest trends in the industry, either to be the first ones to dive into a promising framework or technology or simply to avoid being left behind by our more grasping colleagues. At iOSDC this year, however, I stumbled upon a session about a design paradigm I knew little about, even though it has been around for some time. The session was Server-Driven UI入門: 画面のStateを直接受け取るアプローチ (Introduction to Server-Driven UI: An approach to directly receive the screen state) by Nade. Server-driven UI appears somewhat niche, but I feel that keeping an eye on it and at least knowing that it exists is worth the effort.

Server-driven UI involves receiving the UI state directly from the backend. It enables changes to the client-side UI without releasing a new version of the app and aims to reduce the amount of client-side business logic. This is achieved by implementing a set of predefined UI components within the client application, which should be simple and easily reusable across different parts of the app. Server responses then dictate which of these reusable UI components should be displayed on each screen, in what order, and what content they should include.

In the case of iOS, the approach is even more natural when using SwiftUI, as views can adopt the Codable protocol and essentially mirror the server responses. Nade clearly demonstrated this in his presentation.

Of course, adopting such a paradigm leads to certain trade-offs compared to traditional implementations. Let’s take a quick look at them:

Server-driven UI Pros:

• Faster release cycles for new features, as you don’t need to release new app versions, and changes can be made on the backend.
• All business logic is shared between platforms, resulting in DRYer code, with changes propagated immediately across all clients.
• With minimal (ideally no) business logic on the client side, developers can focus on aspects like polishing the UI/UX to provide a smoother experience.

Server-driven UI Cons:

• The need to define and build a large set of generic UI elements beforehand, which can be overwhelming for small teams.
• Testing all possible combinations of these generic UI elements can be costly.
• Server-side architecture becomes more complex with additional "Backend for Frontend" layers.

As you can see, Server-driven UI is a solution most suitable for larger teams capable of managing the added backend complexities and infrastructure. However, it can offer significant benefits in terms of client flexibility and delivery speed.

In the End

iOSDC Japan 2024 was both an entertaining and valuable experience for me. Among the sessions I attended, the two I’ve shared today stood out as the most useful in practice. I hope you find them interesting as well, especially now that the iOSDC organizers have published the session recordings.

Thank you, and until next time!