From a Cross-Platform Flutter Product to Native iOS
A redesign of the mobile product, design system, and Figma structure after moving iOS from Flutter to native development. Android remained on Flutter, so the challenge was not only to adapt the interface, but also to build a system that allowed both platforms to evolve in parallel as one product.
A redesign of the mobile product, design system, and Figma structure after moving iOS from Flutter to native development. Android remained on Flutter, so the challenge was not only to adapt the interface, but also to build a system that allowed both platforms to evolve in parallel as one product.
Role
Product / UI/UX Designer
Responsibilities
Product development within the design team, Native iOS adaptation, customization of the iOS design system for DIOM, restructuring master screens and flows, component architecture, Figma Slots, platform-specific states, and development handoff
Status
In Development
Platforms
Native iOS / Android Flutter / Web / Mobile Web
Diom
DIOM is a social platform that combines content and communication experiences: vertical video, a post feed, communities, channels, and messaging. Another part of the product focuses on monetization tools for creators.
The product is developed by a small design team of three. We work as peers across existing experiences, new features, and the shared interface system for mobile and web.
Originally, the mobile product was designed as a universal experience for both iOS and Android and implemented in Flutter. As the product evolved, the need for a separate native approach to iOS became increasingly clear.
Visual: key screens across feed, vertical video, communities, and messenger to introduce the scale of the product.
The product is developed by a small design team of three. We work as peers across existing experiences, new features, and the shared interface system for mobile and web.
Originally, the mobile product was designed as a universal experience for both iOS and Android and implemented in Flutter. As the product evolved, the need for a separate native approach to iOS became increasingly clear.
Visual: key screens across feed, vertical video, communities, and messenger to introduce the scale of the product.
Product Context
One Social Platform with Multiple Ways to Interact
Initially, one mobile design system served both platforms. Interfaces were designed to be as universal as possible, while iOS and Android shared the same Flutter implementation.
As the product evolved, the team decided to move iOS to native development. This made it possible to use platform capabilities more accurately and avoid some of the issues associated with the cross-platform implementation. Android remained on Flutter.
Android → Flutter
iOS → Native
The design challenge was not to create two separate products, but to preserve one coherent experience across two different implementations.
As the product evolved, the team decided to move iOS to native development. This made it possible to use platform capabilities more accurately and avoid some of the issues associated with the cross-platform implementation. Android remained on Flutter.
Android → Flutter
iOS → Native
The design challenge was not to create two separate products, but to preserve one coherent experience across two different implementations.
Why One Flutter System Was No Longer Enough
When the Technology Changed, the Design Process Had to Change with It
I became one of the designers leading the transition to Native iOS. Instead of directly reproducing the existing Flutter screens, we began using the native iOS design system as a foundation and adapting it to DIOM’s visual language.
This affected components, states, navigation, sheets, menus, system actions, forms, icons, and other interface elements. As a result, iOS retains the recognizable DIOM identity without feeling like a visual copy of the Android version.
This affected components, states, navigation, sheets, menus, system actions, forms, icons, and other interface elements. As a result, iOS retains the recognizable DIOM identity without feeling like a visual copy of the Android version.
Native iOS adaptation
Not Copying the Flutter Interface, but Rebuilding
It for iOS
It for iOS
Once the platforms were separated, a single universal mobile system evolved into two connected design systems.
DIOM Design System
The shared product principles, visual language, core scenarios, and components that continue to support Android and web interfaces.
iOS × DIOM Design System
Native iOS components and system patterns adapted to the product’s visual identity and interaction logic.
Component purpose, product logic, content hierarchy, and core user journeys remain shared. Their visual and behavioral implementation can vary depending on the platform.
DIOM Design System
The shared product principles, visual language, core scenarios, and components that continue to support Android and web interfaces.
iOS × DIOM Design System
Native iOS components and system patterns adapted to the product’s visual identity and interaction logic.
Component purpose, product logic, content hierarchy, and core user journeys remain shared. Their visual and behavioral implementation can vary depending on the platform.
Two Design Systems for One Product
Diom Design System
Human Interface Guidelines ➔ Buttons
DIOM Design System + iOS × DIOM Design System
Once iOS moved to native development, the previous file structure no longer scaled effectively.
I restructured the Figma architecture so that designers could keep both platforms synchronized while each development team received only the flows relevant to its implementation.
Mobile
Web
The web product follows the same logic:
Master screens act as the visual source of truth for the current product state, while the flow files serve as platform-specific implementation documentation.
I restructured the Figma architecture so that designers could keep both platforms synchronized while each development team received only the flows relevant to its implementation.
Mobile
- Master Screens App. The current Android and iOS screens are placed side by side and updated in parallel.
- Android Flows → Flutter Development iOS Flows → Native iOS Development
Web
The web product follows the same logic:
- Master Screens Web
- Web & Mobile Web Flows
Master screens act as the visual source of truth for the current product state, while the flow files serve as platform-specific implementation documentation.
Restructuring the Figma Architecture
One Source of Product Truth, Separate Files
for Platform-Specific Flows
for Platform-Specific Flows
The migration also became an opportunity to reconsider how the interfaces themselves were assembled.
Using a workflow I developed, master screens and related layouts were systematically rebuilt around a more flexible component architecture using Figma Slots.
Slots allowed us to keep the shared structure of a master component while replacing individual functional areas without creating large numbers of nearly identical variants.
Using a workflow I developed, master screens and related layouts were systematically rebuilt around a more flexible component architecture using Figma Slots.
Slots allowed us to keep the shared structure of a master component while replacing individual functional areas without creating large numbers of nearly identical variants.
Component Architecture and Figma Slots
Rebuilding the Layouts So Changes Could Scale Across
the Product
the Product
Moving iOS to native development required changing more than the visual implementation of the app. It required restructuring the way the product itself was designed and maintained.
The result:
Android continues on Flutter
iOS evolves as a Native application
two design systems share the same product foundation;
master screens keep both platforms synchronized;
separate flow files account for iOS and Android differences
development teams receive dedicated, structured handoff files
Slot-based components make new scenarios easier to scale
The main outcome is a system where the platforms no longer need to look artificially identical in order to feel like the same product.
The result:
Android continues on Flutter
iOS evolves as a Native application
two design systems share the same product foundation;
master screens keep both platforms synchronized;
separate flow files account for iOS and Android differences
development teams receive dedicated, structured handoff files
Slot-based components make new scenarios easier to scale
The main outcome is a system where the platforms no longer need to look artificially identical in order to feel like the same product.
Result
Two Platforms That Can Evolve in Parallel as One Product
