By Simon Wang, Engineering Manager, Mobile, MEGA
At MEGA, we’re always looking for new ways to do things, to improve the way we work. Recently, our MEGA iOS team has adopted the emerging SwiftUI and Combine technologies. Now that we’ve fully embraced them, there’s definitely no looking back.
So, why is the MEGA iOS team moving to SwiftUI? What are our thoughts behind the transition to SwiftUI and Combine technologies?
1. We’ve had a fantastic first-hand experience
In December 2021, we delivered a new photo library feature to help our 240M+ users engage with, and organise, their Camera Uploads media on iOS 14+ devices. This medium-scale project was built with SwiftUI and Combine technologies. There were some interesting challenges in this project; for instance, dynamic grid layout, large datasets and performance. To solve these challenges, we have been deep-diving into SwiftUI, pushing its boundaries, thinking outside the box, and exploring the different possibilities that new technologies such as these can offer.
This invaluable first-hand experience gave us lots of insights into the SwiftUI framework, best practices, and how we will move ahead with it.
2. SwiftUI is the future of iOS
Apple announced SwiftUI at its 2019 World Wide Developers Conference (WWDC 2019). Since then, the Apple iOS team has been focusing on improving the SwiftUI framework. Right now in 2022, if you ask any iOS engineer, they’ll tell you that SwiftUI is the future. It’s clear that the vast majority of Apple’s UI engineering resources are invested in SwiftUI. For example, at last year’s WWDC 2021, SwiftUI sessions vastly outnumbered UIKit. Every day of the event, there were 4 to 6 sessions on SwiftUI updates, and 17 SwiftUI sessions in total, compared to just 4 for UIKit.
It seems clear to us that SwiftUI is the future of iOS, and this may not come as a surprise to those following industry trends — the whole mobile world is getting reformed by the declarative paradigm. React Native and Flutter have been around for a long time, and the native Android Jetpack Compose is also evolving quickly.
There are many advantages of the declarative style of programming over the imperative style:
- engineers focus on what to build rather than how to build, allowing faster development
- simpler, easier to understand syntax and good maintainability
- better separation of UI logic and data management
- immutable UI to ensure integrity and to avoid unexpected data inconsistencies
- state driven — single source of truth principle
- intuitive — the UI is just a reflection of the underlying state
- clear data flow — a user action mutates the state, and the state updates the UI.
For MEGA, these factors played a big role in the decision to commit to SwiftUI now, and we’re already living the benefits. With Apple pushing SwiftUI to the extent that it is, we think every iOS team needs to consider whether the time is right for them to be empowered by SwiftUI and its declarative style. At MEGA, we have decided to commit to SwiftUI now, as the benefits are clear, and the cost of transitioning later could be significant.
3. It promotes innovative thinking
Innovative thinking and a passion for it opens new doors to thinking outside the box, finding ingenious solutions, seeking out the best ideas and motivating our engineers. Innovation means embracing new technology, understanding it early, and reaping the benefits.
At MEGA, we’re growing rapidly with the aim of being leaders in our business domains and technical stacks, so we’re always researching, experimenting and exploring new and interesting technologies. Our commitment to SwiftUI is the natural fruit of our labour as it demonstrates our attitude towards technical innovation.
4. It encourages engineering excellence and excitement
It’s always easy to make things work, but incredibly hard to achieve the engineering excellence that MEGA pursues. With the massive advantages we’ve been able to get from the declarative paradigm, SwiftUI moves us another step towards engineering excellence.
A crucial part of this has been the way these technologies have energised our entire team. Since we started building features in SwiftUI, our iOS engineers have been genuinely inspired and excited. It isn’t just SwiftUI itself — the shift to a new tech stack is a great opportunity to broaden one’s viewpoints, inspire new thinking, and adopt new best practices and engineering principles. We’ve been pushing our code quality to a whole new level as a result of engineering SwiftUI features.
5. It helps attract top talent
Great engineers are passionate and constant learners. They tend to keep themselves updated with the latest technologies, so they can always stay sharp and relevant in their areas. Engineers like this want to join teams at the forefront of iOS development, like MEGA, to learn new technologies. To capture and excite these great engineers, and to breed new ones internally, it’s clear that we must not stagnate. Innovation and embracing new technologies goes hand in hand with attracting top talent.
On the other hand, in this rapidly changing world, if a team doesn’t move to a new generation technology, it will eventually become extremely hard to find enthusiastic engineers to work on a stale and outdated platform.
6. Controllable risks
Despite the clear potential, before committing to build our complex photo library feature with SwiftUI and Combine, we had to examine the potential risks. The good news is that after three years of evolution, SwiftUI is becoming stable and mature. From each year’s WWDC we can see that Apple has been rewriting more and more of their own apps with SwiftUI. In fact, some of our iOS engineers already had SwiftUI and Combine experience from personal projects. With this in mind, we were confident enough to develop a large project with SwiftUI.
From a technical perspective, we have:
to easily bridge UIKit and SwiftUI.
From an architecture perspective, we’re using Clean Architecture. We’ve separated the presentation logic out of the UI logic, so in a worst case scenario, we could swap SwiftUI with UIKit. As part of the separation of the presentation logic, we tried to avoid using:
to pass and manage states inside views. Instead, for each view, we created a View Model to be responsible for state and presentation logic, by using:
A view is just an observer of a state and it is quite dumb. The less logic in UI views, the more testable and reusable our presentation View Models are.
Challenges & next steps
It would be wrong to say SwiftUI has been a perfectly smooth ride so far. As expected with such a complex photo library feature, we did find a number of challenges, such as:
- Both SwiftUI & Combine demand a complete change of programming mindset and were quite a steep learning curve for most of the engineers
- SwiftUI’s memory management is not simple. We spent a lot of time debugging and profiling in order to understand how a state updates its depending views
- SwiftUI is still in a quickly evolving stage, and we found some performance issues with large datasets. For example, LazyVGrid doesn’t appear to perform as well as UICollectionView due to the lack of reuse mechanism.
Like with any new technology, the steep learning curve and initial productivity hiccups were expected. But, we believe that as our experience with SwiftUI grows, our rough patches will be ironed out and productivity will blossom. We are already impressed with the simplicity and efficiency of SwiftUI, and we know there is more to come.
As we’ve gained lots of insights in profiling SwiftUI memory management and performance, and in working with the technology in general, we want to share our findings. We’re planning to publish a series of posts on MEGA’s journey with SwiftUI, so please watch this space.
In the meantime, if this sounds exciting to you, please don’t hesitate to apply for our open positions. We’re growing quickly and need great people to join us to create industry-leading solutions and products.