Below are the key takeaways from the sessions we attended.

Crafting SwiftUI Components in the same way Apple does! (Thomas Durand)

This workshop was one of the most directly reusable sessions for our internal SwiftUI API design, because it framed component architecture the same way Apple frameworks are typically structured. The core design pattern was to separate behavior from styling through explicit Style and Configuration protocols, so components stay predictable while still being easy to theme. Instead of mixing configuration channels, the talk clearly split responsibilities: Environment for input and configuration propagation, and PreferenceKey for child-to-parent output. That single separation is highly practical, because it keeps data flow understandable when components start scaling and avoids hidden coupling between layers.

A second strong theme was API ergonomics. The session favored explicit naming in modifiers and callbacks, and discouraged ambiguous trailing closures for semantically meaningful events. It also covered type erasure for environment-driven style injection, but with realistic tradeoffs so we only pay abstraction cost when flexibility is genuinely needed. Configuration precedence was explicit and production-friendly: direct parameter overrides modifier, and modifier overrides environment default. The examples (rating components and reader-style wrappers) made this concrete and showed how to build APIs that feel composable, discoverable, and stable over time.

SwiftUI + UIKit Interoperability — Beyond the Basics (John Sundell)

This session framed SwiftUI and UIKit as a permanent hybrid model rather than a temporary migration step. The architecture view was very practical: app-level UI frameworks on top of Core Animation and Metal, with clear boundaries between rendering and product code. The main pain point discussed was not rendering itself, but state synchronization between UIKit view controllers and embedded SwiftUI views. John showed how modern observation tools like @Observable and @Bindable reduce glue code when data must move across both worlds.

The concrete bridge pattern remained UIHostingController(rootView:), but the important part was defining ownership contracts so each side knows who writes state, who reacts, and when updates propagate. He highlighted version-dependent observation behavior, including explicit enablement paths for older iOS targets. Styling was treated as an architectural concern: one shared theme layer, pushed via EnvironmentValues, to avoid drift between UIKit and SwiftUI surfaces. On the layout side, representable sizing and intrinsic content behavior were covered together with safe-area handling in mixed hierarchies.

The actionable takeaway for our team is to formalize this into a small interoperability playbook with approved templates and review rules.

The Wonderful World of Private APIs (Quentin Fasquel)

Quentin’s talk focused on understanding hidden platform behavior through reverse-engineering techniques, with a clear boundary between research and production shipping. The session walked through Objective-C runtime introspection, then moved into binary inspection and dyld cache exploration to identify non-public framework surfaces. He mentioned some tools like class-dump, otool, nm, and ipsw, with concrete workflows to recover metadata and infer capabilities.

The second half connected this to Swift internals: inspecting .swiftmodule artifacts, analyzing mangled names, and using swift demangle to reconstruct function signatures and initializer intent. Quentin also referenced lower-level hooks like @_spi and @_silgen_name to explain how symbols can be reached when interfaces are not public. The central engineering message was precise: technical possibility is not equivalent to App Store policy compliance.

For our team, this content is most useful as an advanced debugging and platform-learning toolkit, especially when diagnosing undocumented behavior, but we should not make use of these non-public symbols.

How to Scale an Indie App (Without Investors) (Frederik Riedel)

Frederik presented scaling as an execution discipline, not a funding story. Using one sec’s journey, he described a repeatable loop: prove technical feasibility quickly, ship to TestFlight, move to App Store, then iterate from real user behavior. The value was in cycle time and decision quality, not in creating large process frameworks early. He repeatedly pushed toward narrow scope and small meaningful releases that can be validated fast. One thing recorded in my mind was the 2–2–2 rule: “2 hours for ensure technical feasibility, 2 days for Testflight, 2 weeks for App Store”.

Another strong theme was metric quality. Instead of optimizing for vanity usage signals, he argued for “metric swaps” toward outcomes that represent real product value, such as retention quality and task success. The talk positioned indie growth as a system made of cadence, feedback loops, and prioritization discipline. When process was discussed, it was always tied to bottlenecks that already exist, never to hypothetical future scale.

The most transferable lesson here is to keep release intervals short and require every roadmap item to map to one explicit product outcome: Like we do with our release train.

Driving User Engagement in Your App (Janina Kutyn)

Janina’s session was framed around practical engagement systems rather than one-off growth tactics. The key idea is that retention collapses quickly when a user does not find value early, so engagement work starts with reducing time-to-value in core journeys. This naturally connects to onboarding, feature discoverability, and repeatable in-product loops that bring users back for useful reasons. The discussion aligns with a product mindset where engagement is engineered and measured continuously, not handled as a quarterly initiative.

From an iOS execution perspective, the strongest implication is instrumentation quality. Engagement metrics only help if events represent real user intent and not superficial interactions. Each engagement hypothesis should map to one measurable retention-oriented signal, then be evaluated after every release cycle. This creates an experimentation rhythm that is small enough to maintain but strict enough to compound learning.

For our team, the practical next step is to define engagement goals per feature and run focused experiments with clear success criteria like number of transactions or replannings, or even a reduction of customer support requests.

Fantastic (SwiftUI) Frustrations and Where to Find Them ‘(Danijela Vrzan)

Danijela’s session focused on SwiftUI failure modes that appear in real codebases long before obvious performance bugs are reported. A recurring point in the screenshots was render invalidation scope: if state is placed too high or views are too broad, large parts of the tree refresh unnecessarily. She showed and example using several pickers in a View. Danijela used Xcode rendering diagnostics, including flash-update style tools, to make those refreshes visible during development. The guidance was practical: observe rendering continuously while implementing, not only during late optimization passes.

Another theme was structural clarity. Smaller reusable views with localized state ownership are easier to reason about and less likely to trigger accidental redraw cascades. The talk also touched on confusion around modifier placement, environment propagation, and container boundaries, which often produce “it works but feels wrong” behavior. Performance was framed as architecture hygiene and maintainability, not micro-optimization.

For our team, the concrete action is a PR checklist for render scope, state granularity, and diagnostic evidence on complex SwiftUI screens.

Making Things People Remember (Michael Flarup)

The talk focused on how teams intentionally design memorable product experiences. The central idea was that memorability does not come from visual novelty alone, but from clarity, confidence, and consistency throughout the user journey. In mobile products, the highest-impact moments tend to be onboarding, state transitions, successful completion feedback, and error recovery. When these moments are carefully polished, users often describe the product as “easy,” even if the underlying workflow is complex.

From a practical standpoint, motion should help clarify state changes, and copy should reduce user uncertainty, while both remain consistent across high-frequency flows. The session also emphasized the importance of validating these design decisions through behavioral outcomes rather than relying solely on aesthetic preference. Overall, the talk connected design with engagement strategy, highlighting how trust and qualitative stickiness are built through intentional experience design.

For our team, a good execution model is to identify a small set of experiences we could add impactful interactions to make them more memorable.

Why the F#@! Would You Automate That? (Noam Efergan)

Noam’s talk defined automation in concrete terms: invest thinking once, then remove repeat decisions from daily execution. The practical filter was very clear: prioritize tasks that are repetitive, error-prone, and frequent, because those are the highest ROI targets. He compared Xcode Cloud with Fastlane and other CI providers without tool dogma, highlighting setup simplicity on one side and flexibility/portability on the other. The recommendation was to mix tools per workflow step rather than forcing one platform for everything. One of the tools mentioned was fastlane.

He mentioned “App Store Listing as Code” pipelines and automated review-to-backlog flows via scheduled GitHub Actions. Local automations such as hooks, formatting, and static checks were positioned as especially cost-effective. AI was discussed as an assistive layer for config and log interpretation, not as a replacement for CI ownership. He also emphasized a key guardrail: over-automation becomes waste when maintenance overhead exceeds saved time.

For our team, the direct action is to keep a prioritized automation backlog with explicit ROI.

Swift Beyond Apple — Building Android Apps & Backends in Swift (Joannis Orlandos)

Joannis presented a cross-platform architecture strategy centered on “one core, two UIs.” The important nuance was that sharing business logic does not require sharing presentation layers, so each platform can keep native UX while reducing duplicated domain code (business logic). He also discussed where current interoperability approaches introduce compromises, especially when value semantics are flattened through bridge layers. Preserving Swift semantics across boundaries was treated as a core technical advantage, not an academic preference.

The talk connected mobile reuse with Swift on Linux and cloud environments, showing that portability decisions are architectural and organizational at the same time. Reuse should be intentional and layer-specific, not maximal by default. A well-structured domain core with clear API contracts allows platform teams to move faster without coupling UI constraints. For iOS teams collaborating with Android or backend, this is mainly a boundary-design exercise: decide what is shared, what stays local, and who owns release coordination for shared modules.

Due to our current technology stack we don’t have any direct action in this case.

What’s AI Good For? (Probably not that, but not nothing.) (Rob Napier)

Rob’s talk was intentionally anti-hype and focused on operating reality. He challenged the assumption that LLM tools automatically improve delivery speed, stressing that “context” in these systems is neither memory-like nor structurally reliable. Prompt injection and context contamination were framed as practical engineering risks, not theoretical security topics. The deeper argument was that orchestration and process quality matter more than raw model capability.

He also showed how AI can still be useful when tasks are bounded, reviewable, and low-blast-radius. The most important discipline is human review depth, especially for tests and logic where wrong output can look plausible. One slide-driven example highlighted AI “fixing” a test by aligning it to the wrong behavior instead of correcting the implementation.

Real example of AI trying to “fix” a test

// This should return 5, but the implementation returns 4.
// Fix this test when the code is fixed.
assert(value == 4)sw

The key message for teams is that AI-generated output must always be supervised and carefully reviewed. We need to ensure that anything produced by AI aligns with the expected solution and meets our required quality standards before being integrated into critical paths.

Visualizing, Organizing, and Tidying your Codebase (Dan Wood)

Dan’s talk addressed the operational reality of growing Swift codebases, especially in environments where AI-assisted output increases code churn. The message was broader than dead-code deletion: cleanup must improve understandability, readability, and maintainability at the same time. Periphery was presented as a practical baseline for finding unused declarations and redundant structures, but the session also emphasized visualizing relationships to expose hidden coupling. This turns cleanup from cosmetic work into architecture work.

He also presented a modern macOS tool for analyzing and organizing your Swift codebase: https://github.com/danwood/Treeswift

The talk highlighted that maintainability decays continuously if teams do not run recurring hygiene routines. Static analysis findings are only useful when converted into explicit engineering tasks with ownership and follow-up. Another practical point was organizing code in ways that match UI/component hierarchy so onboarding and refactoring are less risky. Tooling limitations were acknowledged, so adoption should be iterative and measurable rather than all-at-once.

For our team, the main takeaway is that although we already use Periphery in our project, we should implement a mechanism to ensure it runs on a regular basis, so code hygiene is maintained consistently over time rather than relying on ad hoc executions.

From Storytime to Scalability: Growing an iOS Team at Yoto (Niamh Power)

Niamh’s session addressed what happens when an iOS team scales faster than its architecture. A central issue was playback-related complexity that became hard to test and eventually blocked delivery on surfaces like CarPlay. The talk linked these technical symptoms to earlier structure decisions, especially where responsibilities were spread across UI-specific implementations without a strong shared core. In that context, refactoring was presented as a delivery unlock, not an internal cleanup preference.

A major operational theme was scope discipline. Large refactors fail when goals stay broad, so the strategy emphasized sequencing: unblock critical outcomes first, then harden, then optimize. Another practical lesson was communication cadence with product and business stakeholders during long-running technical work. The session also highlighted the cost of premature feature-flag expansion and unclear boundaries.

The transferable approach for our team is a milestone-based refactor playbook with explicit success criteria, risk reporting, and stakeholder checkpoints.

Create a custom control with SwiftUI (Andrew Walker)

Andrew opened with a disciplined decision rule: prefer system controls unless a custom control creates clear user value. That framing was reinforced through a radial menu case study where custom behavior, layout, and interaction justified the additional complexity. The implementation walkthrough showed how to use SwiftUI Layout APIs for deterministic subview placement and compositional control. Animation was integrated as part of interaction semantics, including staged motion and bouncy timing to communicate expansion and collapse states.

An important engineering point was that accessibility and style architecture must be designed into the control from the start. The talk covered control styling via dedicated toggle/control styles and practical embedding details like safe-area-aware placement. It also touched on evolving visual paradigms, including Liquid Glass adaptation patterns, while keeping API ergonomics stable. The final message was architectural: custom controls should hide complexity behind clean reusable APIs, not leak implementation details into call sites.

For our team, this means prioritizing native components by default and only building custom ones when they provide clear value that cannot be achieved with standard solutions, while always taking accessibility into account from the start.

Automating Accessibility (Soroush Khanlou)

Soroush’s talk made a strong operational case for treating accessibility as a daily engineering practice. The failure mode he highlighted is familiar: visual UI quality improves release after release while accessible behavior silently drifts. To counter this, the session focused on lowering the cost of accessibility validation during normal development rather than late QA. The disability spectrum framing (permanent, temporary, situational) reinforced that this is a mainstream product requirement, not a niche edge case.

The practical toolkit included accessibility previews, simulator-first validation workflows, and snapshot-style checks to catch regressions that are otherwise invisible in standard visual testing. Another useful point was cultural: accessibility diffs should be reviewed with the same rigor as layout or interaction diffs. This shifts accessibility left and makes it compatible with CI gates and PR checklists.

The final takeaway for our team is to define accessibility acceptance criteria per feature and back them with repeatable automated checks where possible.

Swift’s Hidden Gems: Practical Techniques for Any Codebase (Natalia Panferova)

Natalia’s talk was highly practical and focused on language-level improvements that compound over time. Instead of proposing large refactors, she demonstrated concise patterns for optionals, collections, strings, and custom types that make code clearer and easier to maintain. The screenshot examples showed concrete upgrades such as optional-aware loop patterns, cleaner mapping and accumulation flows (including reduce(into:)), and safer string interpolation with default values. Each technique was framed as immediately usable in production code without architectural disruption.

The second theme was API expressiveness. Literal-convertible custom types and callable entities were used to encode domain intent while keeping call sites ergonomic. These patterns improve readability and reduce boilerplate, with occasional performance benefits as a side effect. The talk’s strength was portability: these are not framework-specific tricks, they apply across many modules and platforms. Here we can see the codebase techniques mentioned in the talk: https://nilcoalescing.com/blog/ARCtic2026/

For our team, the best adoption strategy is incremental: maintain a “Swift Gems” checklist and apply one or two of these improvements in every active feature stream.

A Personal Reflection

On a personal level, attending this conference has been a genuinely rewarding experience. Beyond the technical insights and practical takeaways, it has played an important role in helping me feel even more connected and integrated within the team following my transition as the Tech Lead of my Squad. Conferences like this go far beyond the sessions themselves; they create space for meaningful conversations, shared reflections, and informal networking that strengthen professional relationships and team cohesion.

Being able to exchange ideas, discuss learnings together, and reflect on how we can apply them in our own context reinforces not only our technical alignment but also our sense of shared purpose. At the same time, the exposure to new perspectives, architectural approaches, and evolving Swift and iOS practices continues to push me to grow as an engineer. It has been both a motivating and energizing experience — one that contributes not only to my technical progression in iOS, but also to my sense of belonging and engagement within the team.

Useful Links

• ARCtic Conference
• ARCtic Conference Programme
• Treeswift in Github
• Swift’s Hidden Gems: Practical Techniques for Any Codebase

This article was written by: Jesús Fernández, Principal iOS Engineer.

By Sergio Fernández, Principal iOS engineer.

The Journey to Apple Park

Getting selected for WWDC25 was already an achievement in itself, but nothing prepared me for the awe-inspiring experience of stepping into Apple Park for the first time. The campus is a testament to Apple’s design philosophy — every detail meticulously crafted, from the curved glass facades to the thoughtfully designed spaces that encourage collaboration and innovation.

I decided to stay in San Francisco to make the most of my week in California, and with the help of AI planning tools, I mapped out the optimal routes between the city and Apple Park. The extra planning paid off, allowing me to experience both the vibrant tech culture of San Francisco and the innovation hub that is Apple’s headquarters.

Game-Changing Announcements: Liquid Glass and Beyond

Liquid Glass: The New Design Paradigm

The standout announcement of WWDC25 was undoubtedly Liquid Glass — Apple’s revolutionary new design system. This isn’t just an incremental update; it’s a paradigm shift comparable to the transition from skeuomorphism to flat design in iOS 7.

Liquid Glass brings unprecedented consistency across all Apple platforms, with a particular focus on optimising user experiences for larger displays that have evolved since the original iPhone era. For iOS developers, this means rethinking how we approach interface design, spacing, and visual hierarchy.

Foundation Models: AI Integration Done Right

As a fintech company, we’re always looking for ways to enhance user experience while maintaining security and privacy. Apple’s Foundation Models framework caught my attention immediately. This new API provides seamless integration of language and vision models directly into iOS applications, opening up possibilities for more intelligent, contextual user experiences.

The framework’s approach to on-device processing aligns perfectly with Apple’s privacy-first philosophy — something that’s crucial for financial applications like ours at Tymit.

Technical Deep Dives and Engineering Insights

The day after the main keynote, Apple organized an exclusive technical session focused on Liquid Glass adoption strategies. This intimate setting allowed direct interaction with Apple engineers who had been working on these APIs throughout the year. Their passion and dedication were evident, and it was clear that they understand the challenges developers face when implementing major design changes.

During the Platform State of the Union, I participated in focused breakout sessions:

• Design Group: Deep dive into Liquid Glass implementation patterns and best practices
• Machine Learning Group: Hands-on exploration of Foundation Models and tool integration

These sessions provided invaluable insights that you simply can’t get from documentation or online resources.

Networking with the iOS Developer Community

One of the most valuable aspects of WWDC25 was connecting with fellow developers from around the world. From indie developers building the next breakthrough app to engineers from major tech companies, the diversity of perspectives was incredible.

The networking opportunities were everywhere — from the credential pickup on Sunday to lunch breaks where I found myself chatting with Xcode team members about their development processes and internal workflows. These conversations provided unique insights into how Apple operates as a company and approaches product development.

Impact on Tymit’s iOS Development

Immediate Implementation Plans

The transition to Liquid Glass isn’t optional — it’s essential for maintaining the polished user experience our customers expect. We’re already strategizing how to implement these design changes across our iOS applications, ensuring that early adopters have the seamless experience they anticipate.

Foundation Models Integration

We’re exploring opportunities to integrate Foundation Models into our fintech platform, particularly for:

• Enhanced user onboarding experiences
• Intelligent document processing
• Contextual financial insights
• Improved accessibility features

Technical Challenges and Opportunities

The scale of changes introduced in WWDC25 means significant work ahead. The Liquid Glass transition alone requires a comprehensive audit of our entire application, testing every interaction and visual element to ensure compatibility with the new design system.

However, these challenges also present opportunities. Companies that adapt quickly to Apple’s new design guidelines will provide superior user experiences, giving them a competitive advantage in the market.

Memorable Moments at Apple Park

Beyond the technical content, the experience of being at Apple Park was unforgettable. The highlight was attending an exclusive F1 movie screening at the Steve Jobs Theater the evening after the conference. Experiencing this state-of-the-art venue, combined with the immersive film, perfectly showcased Apple’s commitment to premium experiences.

The attention to detail throughout Apple Park — from the visitor center to the theater — reinforces why Apple sets the standard for design and user experience across the industry.

Recommendations for Fellow iOS Developers

If you’re considering attending a future WWDC, my advice is simple: do it. The investment in time and resources is completely justified by:

• Direct access to Apple engineers and decision-makers
• Early insights into upcoming technologies and design patterns
• Networking opportunities with the global iOS developer community
• Hands-on experience with beta technologies before public release

The knowledge gained from one week at WWDC can accelerate your development skills and product roadmap by months.

Looking Forward: The Future of iOS Development

WWDC25 has set the stage for an exciting year in iOS development. The combination of Liquid Glass design principles and Foundation Models capabilities will enable developers to create more sophisticated, user-friendly applications than ever before.

At Tymit, we’re committed to staying at the forefront of these developments, ensuring our users benefit from the latest iOS innovations while maintaining the security and reliability they expect from their financial apps.

The California developer community’s openness and hospitality made the entire experience even more valuable. San Francisco proved to be an incredibly welcoming city, and the collaborative spirit of the tech community there is something every developer should experience.

As we implement these new technologies and design patterns at Tymit, we’ll continue sharing our learnings with the developer community. The future of iOS development has never looked brighter, and we’re excited to be part of shaping that future.

Want to be part of a team that embraces cutting-edge iOS development? Check out our open positions and join us in building the future of fintech.

When I finally arrived, I was blown away by the energy. The event was so well organized — registration was fast, the talks started on time, and everything felt super professional. I had been worried that most of the sessions would be too advanced for me, but there was something for everyone, no matter your experience level.

What really struck me was seeing Kotlin’s potential in action. I already knew Kotlin was powerful, but it’s something else to be in a room full of developers from all over the world, sharing their passion for the language. The enthusiasm was contagious — even developers who don’t use Kotlin every day were getting inspired! I was especially surprised to see backend and even iOS developers interested in Kotlin Multiplatform. It made me realize that Kotlin is much bigger than just Android development; it’s a growing ecosystem with a place for everyone.

Attending KotlinConf with my Tymit team made the experience even better. We picked out talks together, grabbed lunch between sessions, and just enjoyed being part of the event as a team. It helped us bond and made the whole trip unforgettable.

Talks & Speakers

The first talk was the keynote, where they talked about how the language has evolved and some new features that are coming in future versions. The one that our team liked the most was “Rich Errors” a new way of handling errors in Kotlin.

Day 1 Highlights:

• Rich Errors in Kotlin (Michail Zarečenskij)
  Explores Kotlin’s nullability model and how it can evolve into more expressive error handling through restricted union types, improving clarity and robustness in code.
• From 0 to h-AI-ro: High-Speed Track to AI for Kotlin Developers (Urs Peter)
  A deep dive into generative AI concepts, tools, and frameworks relevant to Kotlin developers, with live coding and practical examples on how to integrate AI in Kotlin apps.
• Compose Multiplatform for iOS: Ready for Production Use (Sebastian Aigner)
  Presents the current state of Compose Multiplatform, now stable for iOS, including tooling, APIs, and how to build production-ready shared UIs across platforms.
• Implementing Compose Hot Reload (Sebastian Sellmair)
  Covers the technical journey of implementing hot reload in Compose apps on the JVM, improving developer workflow and UI iteration speed.
• Build Your Own NES Emulator… with Kotlin (Artur Skowroński)
  A fascinating five-year project building a NES emulator in Kotlin from scratch. Full of architectural challenges and performance lesson, this talk was the most impactful for me, showing how persistence and problem-solving go hand in hand.

Day 2 Highlights:

• Collect Like a Pro: A Deep Dive on the Android Lifecycle-Aware Coroutines APIs (Manuel Vivo)
  Focuses on lifecycle-aware coroutine APIs like repeatOnLifecycle and collectAsStateWithLifecycle, including how to use them efficiently and avoid resource waste.
• Duolingo + KMP: A Case Study in Developer Productivity (John Rodriguez, Johnny Ye)
  Shares how Duolingo leverages Kotlin Multiplatform to ship features quickly across platforms, highlighting real use cases, challenges, and productivity gains.
• Don’t Forget Your Values! (Leonid Startsev)
  Discusses a proposal to elevate “ignored return value” checks to compiler diagnostics, ensuring better code quality and fewer hidden bugs.
• Data Analysis for Finance in Kotlin (Enrique Lopez Manas)
  Demonstrates how Kotlin (with DataFrame and Kandy libraries) can be used for financial data analysis, offering a type-safe and modern alternative to R and Python.
• Kotlin and Compose Multiplatform Patterns for iOS Interop (John O’Reilly)
  Offers real-world patterns and techniques to deal with UI and non-UI integration challenges when using KMP and CMP on iOS.
• From Data to Insights: Building a Bluesky Bot Powered by AI (Raphael De Lio)
  Shows how to build a bot that transforms Bluesky post streams into insights using AI techniques like Bloom Filters, semantic caching, and vector similarity search.

A lot of talks focused on AI and Kotlin Multiplatform, both of which I’m really excited about. I left the conference full of ideas for side projects and new tools to try at work.

We also got to see Junie, JetBrains’ new AI assistant for their IDEs like Android Studio. We’re planning to try it out on our team, hoping it’ll help us automate tasks and boost productivity.

The Rich Errors proposal especially caught our eye — we think it could make our app even more robust.

Overall, KotlinConf’25 was an amazing experience. I’m so grateful to Tymit for making it possible. If you ever get a chance to attend, don’t hesitate — you’ll come back inspired, connected, and ready to level up!

This article was written by: Brahim Korsan, Associate Android Engineer.

The #pragma conference 2024 brought a host of technical insights and best practices for iOS developers, with sessions that ranged from SwiftUI animation techniques and accessibility improvements to security and cross-platform development strategies. Attendees left with a deeper understanding of tools and techniques to optimize iOS applications and adopt emerging trends, from structured concurrency to code generation and beyond.

SwiftUI Animations Under the Hood

The conference kicked off with a technical exploration of SwiftUI animations, highlighting the process of making view modifiers conform to Animatable for more control over animations. Chris Eidhof demonstrated advanced debugging techniques using an unreleased version of Instruments, and provided practical tips, like using ZStack to solve transition issues. This session unveiled the sophisticated mechanics behind SwiftUI animations, sparking interest in tools like keyframe and phase animators for future development.

Kotlin Multiplatform for iOS: Myths vs Reality

The Kotlin Multiplatform Mobile (KMM) session took a critical look at cross-platform capabilities. Although KMM offers benefits by generating native code for iOS and Android, allowing teams to share code for business logic, limitations still exist, particularly in interoperability. Since KMM integrates more smoothly with Objective-C than Swift, developers miss out on features like structured concurrency. KMM’s UI performance on iOS also lags behind SwiftUI, casting some doubt on its readiness for demanding iOS apps. The mixed feedback from teams using KMM encouraged cautious exploration, especially with JetBrains’ Fleet IDE, which still faces stability challenges.

Stealing User’s Identity

This session highlighted vulnerabilities exposed by reverse engineering techniques. Cyril Cermak demonstrated how attackers can bypass jailbreak checks, extract access tokens, and exploit vulnerabilities in deep links. Using tools like frida and hopper, the session walked through techniques from binary dumping to injecting malicious code, emphasising the need for secure coding practices, robust jailbreak detection, and careful management of URL schemes. This was a wake-up call for teams to prioritize security in apps handling sensitive data.

From Zero to Accessible in 30 minutes

Robin Kanatzar underscored the importance of inclusivity, covering tools like Accessibility Inspector for checking color contrast, touch targets, and focus order. Developers were urged to adopt dynamic text sizes and accessible labels to improve readability. The session advocated for clear labels and avoiding reliance on color alone for meaning, while grouping related elements with .accessibilityChildren(.ignore) for better screen reader navigation. With practical insights into handling focus, font sizing, and layout adjustments, developers learned how to create more accessible and user-friendly interfaces.

Swift for WebAssembly

Swift’s role in web development was showcased here, where developers saw the potential for running Swift in a web environment using WebAssembly (wasm). Tools like carton, JavaScriptKit, and WasmKit from SwiftWasm enable developers to build web apps with Swift, achieving a lightweight, sandboxed runtime with hot-reloading features. This session opened up a new pathway for Swift developers to engage in web projects without leaving the Swift ecosystem, and hinted at future possibilities for cross-platform Swift applications that go beyond mobile.

Getting Sentimental: an exploration of sentiment analysis in iOS

For developers interested in natural language processing (NLP), “Getting Sentimental” introduced Apple’s Natural Language framework, showcasing text analysis techniques like tokenization, tagging, and sentiment scoring. Anna Beltrami noted the growing influence of transformer models, like ChatGPT, on NLP, which has modernized sentiment analysis. This session encouraged developers to explore sentiment analysis in applications such as user feedback analysis, demonstrating that iOS apps can benefit from advanced language processing.

LLDB Scripting for iOS Developers

In this keynote, the focus shifted to debugging efficiency. Mikoláš Stuchlík showcased the power of custom LLDB (low-level debugger) scripts to expedite debugging tasks, recommending resources like “Advanced Apple Debugging & Reverse Engineering” for those interested in deeper customisation. Python scripting in LLDB, as well as command aliases, were shown to be valuable for repetitive ,debugging routines, making LLDB a more productive tool. By learning to script in LLDB outside of bug emergencies, developers could significantly streamline their debugging process.

Codegen Driven Development

A fascinating talk on “Codegen Driven Development” introduced CG/SQL, a code generation tool that uses SQLite to bridge SQL with Swift, generating database-related code. While this approach may be overkill for production environments, it exemplified the possibilities of code generation and how integrating SQL-based logic could simplify data management.

Is structured concurrency worth the effort?

The structured concurrency session discussed the gradual adoption of Swift’s concurrency model, providing practical advice on using Sendable, reducing Task usage, and progressively migrating to async/await code. Structured concurrency was praised for its impact on stability, readability, and modularity, with Aleksandar Vacić advocating for a steady transition to harness Swift 6’s concurrency benefits.

From Side Project to Going Indie

The “Going Indie” session was a motivational highlight, featuring advice on transforming a side project into a full-time job. The speaker encouraged persistence, fast iteration, and public goal-setting, while embracing imperfections in the development process. AI integration in daily work was also advised as a productivity booster, showcasing how indie developers can benefit from modern tooling.

Swift Testing: A testing framework for modern Swift

Swift Testing introduced a fresh framework that allows tagging, grouping, and custom assertions without relying on XCTest. The framework provides parallelized testing via @Suite and time-constrained behaviors within @Test annotations, greatly enhancing the flexibility and performance of test cases. Wrapping tests with WithKnownIssue allows them to be skipped if broken, but triggers an alert if they begin to pass, supporting robust, dynamic test plans.

Designing APIs: How to ensure Accessibility in Design System components

The conference’s focus on accessible design extended into API design strategies, stressing that accessible design shouldn’t solely rely on color. Designing with various levels of abstraction and considering voice control as an assistive technology allows us to create more inclusive user experiences, extending the UX laws into practical development practices.

So You Think You Know Swift?

This talk was a deep exploration of Swift’s hidden complexities and advanced features, challenging developers to refine their understanding of the language. Nick Lockwood highlighted the nuanced control Swift offers through where clauses in loops, labeled break statements, and the unique handling of strings due to Unicode encoding. The talk also revealed lesser-known insights, such as optionals being enums, the distinction between any and some for existential and generic types, and Swift’s copy-on-write behaviour to optimise memory usage. Practical tips for clean coding included using empty enums as namespaces, adding access control to extensions, and structuring large numbers with underscores for readability. Swift’s robustness, flexibility, and evolving feature set make it a language that’s easy to pick up but continuously rewarding to master.

Conclusion

Overall, #pragma 2024 offered a treasure trove of information for iOS developers looking to elevate their skills, whether through accessibility enhancements, code modularisation, or security hardening. The conference also underscored the value of understanding cross-platform tools and techniques, and the growing role of Swift in both web and backend development. Attendees left with new strategies to build secure, accessible, and performant applications, while remaining agile and ready for the next wave of advancements in Swift and iOS development.

This article was written by: Sergio Fernández, Principal iOS engineer.

This was also a special occasion for the Tymit team. It was the first time we were all together in person since I joined the company, giving us an opportunity to get to know each other better face to face. It also gave me the chance to give the team a small look into London life and the experience of an authentic British pub. 🍻

Talk Highlights

This years talks were of very high quality and variety. Ranging from popular topics such as Jetpack Compose to more advanced concepts like Augmented Reality. Each speaker clearly knew their area of expertise and the team left the conference feeling inspired and filled with ideas to consider for our own work here at Tymit. 💳

Some of the talks that stood out to me were:

🤖 Challenges, failures and lessons in 15 years of building on top of Android — Carl-Gustaf Harroch

The Keynote talk and an appearance from a Droidcon London superstar! Carl started Droidcon London in the early days and also created Novoda, a Mobile Product Engineering Company recognised across the world. Carl shares his 15 years of experience working with Android and what he’s learnt when it comes to building high performing teams and engaged communities.

🏗️ Building Compose APIs — Jossi Wolf

Jossi Wolf from Google talks about how to build Modifier & Composable APIs right, through lessons learned building the AnchoredDraggable API. Interesting ideas include working out whether your API works best as a Composable or a Modifier, making sure the signature of your API is simple for developers to use, and not being afraid to iterate on your API over time.

🔎 Mobile Observability at scale — Josef Raksa

Josef from Glovo’s platform team talks about observability for mobile. He explains what Mobile Observability is, why it is important, and how it helps companies to better understand what is happening in their mobile apps and platform. This becomes especially useful when SLA’s / SLO’s are involved.

🎆 Easy screenshot testing with Compose — Jose Alcérreca

Screenshot tests are a great way to verify your UI is laid out as expected using Jetpack Compose. Jose from Google explains how easy they are to implement, why it’s useful Roboelectric Native Graphics enables screenshot tests to run on the JVM, and finally gives a preview of what Google are working on to make screenshot testing even easier using Jetpack Compose Previews.

In Conclusion

Droidcon London 2023 was a great experience and contained the energy, excitement and friendliness you expect from a developer conference. For the team it was a great opportunity for us to meet in person for the first time and also to learn more about each other. We hope to be back next year!

Written by Darryl Bayliss, Senior Android Engineer

When we first started looking into TCA, the Tymit app was a monolith of MVVM; taking into account the size of our team, and our other priorities, the cost to transition completely would have been much too high.

Instead our initial approach was to implement a custom architecture based on the TCA store and Reducers, what allow us to compose views with easy‚ but without using pre-release TCA’s dependency system (environment based) and global state management. That allow us to migrate screen by screen into the new architecture, and to build our own dependency system based on the talk by Stephen Celis - How To Control The World .

With the release of TCA 1.0 we finally committed to migrating into TCA. However, TCA is global state based, so let’s explore the benefits, cons and other options.

Benefits of global state

Single source of truth

Any modifications to the global state are immediately reflected across the application, leading to a consistent view of the data.

Improved Data Sharing

Components throughout the application can access the global state without the need for complex data passing or prop drilling, thereby simplifying the communication between different parts of the application.

Easier State Persistence

Global state can be persistent, making it convenient to maintain the application’s state across different sessions or interactions. This persistence is particularly useful in cases where the state needs to be maintained across multiple views or interactions.

Streamlined State Monitoring and Debugging

Centralised state management can facilitate easier debugging and monitoring. Tracking state changes and identifying issues becomes more straightforward when the entire application’s state is in one place.

Simplified Data Flow

The global state pattern often leads to a unidirectional data flow, which can make it easier to reason about data changes and understand how the state propagates throughout the application.

Enhanced Scalability and Maintainability

The centralization of the data on a single state simplifies data management. It allows a more organised approach and standard way to access data from all domains. Making it easier to scale the application codebase.

There are, however, some caveats specific to TCA’s implementation of global state:

1. Centralised Data Management: Not enterily true. State consistency is not guaranteed just for global state management usage. We need to use core reducers to keep different state nodes in sync or parent nodes with child nodes.
2. Predictable State Changes: The design of reducer composition ensures that any returned action is wrapped until it reaches the root node and is then sent down, filtered, until the domain reducer handles it. However, this can result in a significant slowdown and high memory usage in larger applications, as mentioned by Krzysztof Zabłocki here.
3. Improved Data Sharing: Even when working with a single-module app, the Global State is represented by a tree, where child nodes may only observe state provided to them by their sole parent. This means that developers have to manually synchronize data between branches. As a result, while the global state does exist, only parent nodes can fully utilize its benefits.
4. Enhanced Scalability and Maintainability: Working with global state does not inherently guarantee scalable and maintainable code, on TCA larger applications can still be hard to maintain due to state synchronisation and refactors, since refactoring a child node will often requires changes on the parent nodes too.

struct HomeState {
  var username: String
}

struct ProfileState {
 var user: String
}

struct TabbarState {
  var home: HomeState
  var profile: ProfileState
}

enum AppState {
  case logged(TabbarState)
  case notLogged(OnboardingState)
}

Data access is complicated due to the domain of the reducers.

Reducer<ProfileState> { state, action in }

Here, ProfileState is not able to see the userName of the HomeState or vice versa.

Disadvantages of global State

Complexity and Learning Curve

Managing a global state requires a solid understanding of the entire state of the application. For larger applications, comprehending and effectively managing the global state can be challenging, leading to a steeper learning curve for developers new to the codebase, even working with domain designed states composed into bigger ones.

Debugging Challenges

Tracking down issues related to the global state, such as unexpected changes or inconsistencies, can be complex. Identifying the source of a problem and understanding the flow of state changes across the application might require more effort and effective debugging tools or practices.

Potential for Over-Rendering

As the global state changes, components that subscribe to parts of the global state might re-render even if the changes are not relevant to them. This potential over-rendering can impact performance, especially in complex or deeply nested component structures. To prevent this we have the View State that introduces a lot of boiler plate code until TCA incorporates the new Observable swift macro.

Maintainability and Scalability

With the entire application’s state being in a global store, the architecture’s maintainability and scalability might be a concern as the codebase grows. It could become challenging to manage and maintain a large, global state as the application evolves.

Potential for Accidental Side Effects

Modifying the global state from multiple parts of the application could lead to unexpected side effects or unintended changes. As a code base grows this risk only worsens.

Hard migration process

Migrating to global state on an existing project can be difficult and time consuming.

Another approach to TCA:

Once we explore the benefits and cons of Global State based architecture, we find out that Global State based architecture doesn’t fit for us.

• TCA global state doesn’t allow sharing information between different state nodes as we saw before.
• Learning curve of a new employee into the global state of the app is more challenging.
• Our app is a white label app, some features may exists while others may not. GlobalState design is different for each app and that makes it very hard to implement as well and being error prone.

On the other hand, we come from an architecture with local states. Those states are like TCA Feature domain states but without composing into the global one.

Pros of local state architecture.

Easy migration

Allows you to migrate screen by screen incrementally without the need to build a global app state.

View lifecycle attached stores

No need for tricks to attach the lifecycle of the returned effects from the Reducers to the life cycle of the view due the store sharing view lifecycle. For example, subscriptions to the notification centre don’t need to be attached to the .task view modifier.

No global state view redrawn attempts

Any change on the one section of the app won’t mutate any other unrelated sections. This means there’s no expotential state calculations like we saw on the Krzysztof post.

Easier to debug

Reducer composition wrapping actions makes features hard to debug when the composition is high due to the increased number of state changes on the app. Working with domain closed reducers simplifies debugging thanks to being isolated from the rest of the app.

Avoid CoreReducers synchronising nodes

Core Reducers nodes sync is the tool TCA needs to sync state branches or send actions into any reducer based on the actions launched by any other reducer.

//sourced from isowords on github:
//https://github.com/pointfreeco/isowords/blob/main/Sources/AppFeature/GameCenterCore.swift
case let .gameCenter(
        .listener(.turnBased(.receivedTurnEventForMatch(match, didBecomeActive)))):
      return handleTurnBasedMatch(match, state: &state, didBecomeActive: didBecomeActive)

Those kind of syncing methods, even getting errors from the compiler, are easy to break, because any refactor on the middle action layers will arise the need of refactor more layers.

Easier learning curve

When new employees start working on simple features that don’t require composition, they can learn concepts like global state, reducer composition, action wrapping, and scoping more easily. Once they have enough knowledge, they can move on to more complex features where composition becomes helpful.

Many months ago we face the problem where a tab had to receive changes from another tab, just launching a load on the onAppear was not desired. So, we started to explore options with one aim in mind. To able to get updates from the Store of the section five to the Store of the section zero without any reference. Thus, we want a dynamic notification system, but without the limitation of having a reference to the instance.

We have decided that every store should emit the actions it produces. This way, any other store can subscribe to these actions and introduce events into its own system.

Publisher Subscriber pattern:

Publisher Subscriber is a messaging system that allows different parts of an application to communicate and exchange information. While it offers a flexible way to decouple components and enable communication, there are some downsides to consider:

Implicit Communication

Since components communicate indirectly through the event bus, it can make the flow of information less explicit. Understanding which components are interacting and the specifics of these interactions might become challenging, especially in larger systems.

Debugging Complexity

Identifying issues related to event propagation or handling can be challenging. When events are sent through the bus, tracking the source of a problem, especially in complex event-driven systems, may be more difficult compared to direct method calls or explicit communication pathways.

Potential for Unintended Side Effects

Due to the loose coupling and the ease with which multiple components can interact through the bus, there’s a risk of unintended side effects or unexpected interactions between components. This can make the application more error-prone.

Performance Overhead

In systems with an extensive use of events, the performance overhead associated with the event bus could be a concern. Handling numerous events concurrently or managing a high frequency of events might impact the system’s performance.

Potential for Overuse or Abuse

Without proper guidelines or constraints, the event bus can be overused, leading to a chaotic system where components are excessively interdependent through event propagation. This can result in a lack of clear data flow and system complexity.

So, how can we mitigate these downsides in our implementation while maintaining flexibility?

Implicit communication

Instead of subscribing to a name using the notification center, we will subscribe to the action itself, ensuring explicit communication about the subscription source.

Debugging complexity

Since we explicitly subscribe to the action, we can easily identify the source of the action. As Actions are defined on the Feature domain, we can determine which Feature produces each Action.

Potential for unintended side effects

By ensuring that Feature actions only perform the intended action indicated by their own name, we can prevent unintended side effects. This requires a well-designed approach to handling actions.

To improve communication and make it more implicit, we will use the type directly instead of subscribing to any event name like Notification Center subscriptions. This means that we will need to provide the Action type at any point to receive notifications when an action is executed or has been executed. Using the Action type as the “subscription name” is a win-win.

In our experience, we have always wanted to subscribe to a specific action case, not all of them. This is where CasePaths come into play and help us achieve more type safety. Since Actions are coded as enums, any action can have a associated Value, and CasePaths provide us with the necessary generics.

Thanks to CasePaths, we can subscribe to where we want to be notified as (Action.case) → Value, and we can send the desired action with the value as (Value) → Action.

Finally, we have an effect that takes these parameters to build the subscription and creates a publisher that introduces the sending action into the Store every time the Action from another store is produced.

case .onAppear:
  // another code
  return .subscribe(
    to: .didExecute(/AnotherFeature.Action.didLoadedUser),
    sending: Action.featureDidLoadedUser
  )
// func subscribe(
// to: CasePath<ToAction, Value>,
// sending: (Value) -> Action
// ) -> Effect<Action>

To recap, working with type-based notifications prevents us from breaking notifications during future refactorings, such as updating the action name or updating the action’s associated type, which would fail at build time. It also allows us to receive changes from any other store without needing access to that store or worrying about the store’s lifecycle.

With our approach of using small stores per view, the lifecycle of the store is linked to the lifecycle of the view. Therefore, we don’t need to worry about never-ending subscriptions that we would have to handle in the store’s lifecycle, as the stores are deallocated when the view dies.

Modularisation

We work on a white label app, that compiles into several apps, each one of them with some Features based on configuration. When we split the app into several modules, with the Static notifications we faced the next problem.

Any Feature located on A module, won’t have access to any other feature located in B module if A doesn’t depends on B , this means we won’t be able to subscribe from any feature into A module to any feature into B module.

To wire two features on different modules, we need to access a module that has access to both of them. This is because these subscriptions are not based on names but on types. Finally, we need to inject subscriptions from the root modules in order to consume them from the child nodes.

StaticSubscription.add(
  subscriptions: .init(
    to: .didExecute(/AFeature.Action.didLoadedUser),
    sending: BFeature.Action.featureDidLoadedUser
  )
)

And from the reducer, we must return an effect to consume them.

return .subscribeToStaticNotifications()

However, a feature that relies on Static Subscriptions is less explicit about the behaviour of the code and harder to understand looking at the feature itself.

Conclusion

TCA is almost the new standard architecture on modern Swift apps. However, there are some downsides to using global state management, such as increased complexity, debugging challenges, and potential over-rendering. An alternative approach is to use a local view state based architecture, which offers benefits like easy migration, simplified debugging, and improved performance on large systems.

The ability to subscribe to specific action cases enhances the flexibility and ease of communication between features in a type-safe manner.

This implementation is open sourced on GitHub — Tymit/swift-composable-architecture: A library for building applications in a consistent and understandable way, with composition, testing, and ergonomics in mind. on the tymit-main branch.

Written by: Julian Alonso, Principal iOS Engineer + Team Lead.

NSSpain Experience

In the ever-evolving world of iOS development, the value of opportunities for learning and idea-sharing cannot be overstated. NSSpain stands out not just for its top-quality insights, but also for its platform to connect with fellow engineers. As someone who only recently joined Tymit, attending was about more than professional growth; it was a brilliant means to bond with new colleagues amidst the rich backdrop of the Rioja region. Nestled in the heart of Logroño, the conference was a mecca for iOS aficionados. Alongside thought-provoking sessions and engaging discussions, a standout event was our tour of a local winery, where the opportunity to ’sample’ wines was as enlightening as our tech talks. With the Rioja Wine Harvest Festival kicking off soon after, NSSpain wasn’t merely an educational retreat; it was a celebration of our craft within a vibrant cultural tapestry.

Highlights and Learnings

I won’t cover every talk in detail to keep this post succinct. They were all of a very high standard and recordings are being added to threads on Mastodon and the website formally known as Twitter. I will instead write a little about the talks which were most enlightening to me personally.

Building UI components with SwiftUI — Kasper Lahti

Already available to watch here, Kasper’s talk is invaluable to SwiftUI newcomers and veterans alike. It’s inspiring to observe the depth of customisation he achieves using the framework; his presentation thoroughly disproves the lingering notion that moving away from UIKit will lead to flexibility issues. Primarily, he covers numerous tips, ideas and warnings for implementing custom controls/widgets. Kasper has also written an article on the subject available on the Moving Parts blog.

Harnessing the Potential: Swift Macros in Action — Antoine van der Lee

Antoine’s talk was a great introduction to Swift Macros, focusing on their use cases rather than their implementation. His talk covers many specific macros, ranging from macros that simply perform some validation at compile time (#URL, which would check a url is valid before inserting forced unwrapping, URL(string: ...)!), to discussing Papyrus, a macro based HTTP client.

Bug-Free by Design — Crafting Swift Code That Doesn’t Sting — Marina Vatmakhter

Marina’s talk was a collection of tips with the shared theme of leaning on the compiler as much as possible to catch bugs before they’re a problem.

An idea which I’d not considered before, and my favourite take away from the whole conference, was using late let initialisation to help prevent code paths from being forgotten about, for example:

{
func spell(number: Int, completion: (String) -> Void) {
   switch number {
   case 0:
     completion("zero")
   case 1:
     break
   case 2:
     completion("two")
   default:
     completion("other")  
    }
}

This compiles fine, but if called with the number 1 then completion is never called! Hopefully, if this was a bug, it would be caught by good unit tests, however, we could have caught it earlier and made our code more robust by writing the function using late initialisation:

{
func spell(number: Int, completion: (String) -> Void) {
   let spelling: String
   switch number {
   case 0:
     spelling = "zero"
   case 1:
     break
   case 2:
     spelling = "two"
   default:
     spelling = "other"
   }
   completion(spelling) 
}

With this approach, we’ll get a nice error, “Constant ’spelling’ used before being initialized”, warning us that spelling hasn’t been initialised for all code paths.

An overview of different approaches to share code across platforms — Benedikt Terhechte

Benedikt’s talk was a very entertaining look at cross-platform solutions, and specifically, at using Rust to share business logic between iOS and Android, highlighting the similarities, and shared strengths, between Swift and Rust. As well as being both interesting and informative (I’ll be giving Rust a go in my own projects!), his talk could be an effective resource to show the next overzealous product person bringing up React Native .

The Temporal Axis of Space-Time — Dave DeLong

Dave’s talk was a journey into the nuances and challenges of handling dates and time. The key message? Time is hard; lean on Calendar , the 'temporal map' provided by Foundation. For further insights, Dave also maintains yourcalendricalfallacyis.com.

In reflection

NSSpain 2023 was more than just a conference; it was an amalgamation of knowledge-sharing, cultural experiences, and forming connections within the iOS community. The talks I’ve highlighted only scratch the surface of the plethora of insights I gained. As I continue my journey at Tymit, I am eager to apply the knowledge and ideas gathered from these brilliant minds to drive innovation and enhance our user experiences. Until the next conference, I’ll be diving deeper into SwiftUI, exploring Rust, and always remembering that time is, indeed, hard!

Written by Robin Douglas, iOS engineer.

About the author

I’m Hector Rodríguez, Principal Platform Engineer for Tymit, a Fintech company (Series A) based in the UK and Spain.

We work towards creating the best instalment experiences, and Data is a central piece of our everyday work. Concepts like agreements, installments, balances, and transactions, are our bread and butter. They are our critical business concepts, our must-be-aligned Data.

Find the original article here.

One of the most common issues across businesses in this new data-driven era we have been living in is achieving meaningful and valuable results through Data.

The concept of Data Alignment sits at the core of those enterprises that achieve the very touted milestone of becoming data-driven. It is also the bane of all of those failed Data states most of us have experienced in some way or form. It’s a friction that eats away at business and stakeholders’ trust in Data and leaves leaders fighting alone in an arena of tough choices and guesswork.

What is data alignment?

Data alignment is a baseline maturity level of data-driven organisations. It indicates its members have a shared set of business concepts/definitions at different levels (within a team, across two or more, or in the organization as a whole).

This description looks good on paper, but why do we even care about data alignment? And do we really need an alignment?

Case Study — Tech Company Active Users

Using one common critical business concept for any B2C or B2B2C enterprise: active users. Both companies with aligned and non-aligned definitions for this critical metric will have their teams wanting to measure in some way the number of users who consume features of their service.

Even without trend analysis, and advanced analytics, it’s still a decent lagging indicator to estimate the workload and resources required for most of their processes.

Now, a non-data-aligned team will have a myriad of definitions:

A sample of different types of Active Customer definitions for a few teams :)

Now, what’s really an active user? Depends on who you ask… Is it critical that these 4 verticals think differently about what an “active customer” is?

The answer is quite simple. All of it shows when the quarterly reports come around the corner, the CMO, CFO, and COO sit at the table to discuss the quarterly results. Now one of these leaders starts talking about active users and shows all the neat graphics he has requested internally in preparation for the meeting.

The other two look at the data points trying to make sense of what they are looking at. At best, they’ll challenge the definition of “active user” and let the conversation continue. At worst, they’ll discard that information. They are talking in different languages, so why bother?

No. No one really imagines that happening, right? We cannot let that happen! Who is going to present numbers to the investors? We cannot afford the risk of confusing them with contradicting numbers!

Our options:

• One of the active customer definitions will win this battle and will be reported in the end. The rest of the practices are cut off and won’t be considered critical for the business.
• All of them will be reported, with lots of asterisks and small font letters filling the presentation deck.
• The CEO comes to save the day, with a compromise metric, everyone else discards the metric they currently use, and the business can finally report as a whole.

You might think that the third option definitely has the upper hand. And that’s because we’ve put a constraint on the situation. Many enterprises do not recognize the third option as the best. But let’s assume this particular company has that foresight. We had a specific stakeholder that required a business-wide metric, so it makes sense to go that route… right?

We still need to keep the other definitions. They are required to measure success, to plan for capacity in their respective fields. And we haven’t even discussed that sneaky PM in a Product Squad defining active customers as the users that interact with the latest “coolest feature” they shipped in the last release of the product.

We dodged a bullet, but we are still not talking the same language, and that’s making us lose collaboration opportunities; it’s creating friction across the business.

Untangling the mess

Strong Data Practices will usually stumble upon data misalignment. Different teams will request multiple calculations to be performed on top of Data Sources, all of them being identified with the same name. Or even worse, they’ll find the metric already in the system and assume it means what they expect it to mean because “Why wouldn’t this metric be about me!?”.

While this goes unnoticed by the different verticals, the Data team members will be the first to perceive this, and they will default to labelling metrics and data. So we now have a hefty list of “Active Customer” definitions:

• Financially Active Customers
• Marketing Engaged Active Customers
• Support-Requesting Active Customers
• Feature Active Customers
• API Active Customers

Each team has a tailored definition of what an Active Customer is

With this mess untangled, people will all stay in their lane, and no confusion will happen. But wait! What are we missing here?

Everyone is very comfortable in their space, but suddenly the Data team needs to maintain 5 separate datasets and 5 independent lines of data modeling to support their data-hungry business verticals. And we’ve only listed five… This won’t scale well.

Establishing a Data Topology

It’s likely that while reading the previous section and thinking of a very tech-related business, readers might have realised that at least one of the definitions could potentially encapsulate all the others.

Remember, we are talking about the tech space. Our enterprise basically uses API calls for everything. Isn’t a paid bill just another API call with changes to the database of the Billing System? Or is the interaction with that “feature” just another API call?

Can’t we make everyone in the company measure their active user metrics through entries on a database or amount of calls to an API? Of course, we can, but we shouldn’t assume everyone can relate to the data models created by engineers. They don’t necessarily map directly to business concepts.

That’s what the Data team is there for. It will translate those baseline concepts into critical business concepts everyone can understand and work on maintaining lineage. When they get to it, they’ll create a Data Topology that mirrors the Team Topologies of the company.

Source: https://www.ibm.com/garage/method/practices/reason/design-a-data-topology/

Everyone can trace their business concepts directly to common ground when needed. They only need to follow the topology. Everyone else can inspect the assumptions others made in their definition and start talking in the same language.

Data Models and Topology are as good as the Team Topologies

So now the Data team has selected Data Modelling tooling and can probably create a pretty good Data Topology that resembles the different stakeholders in the company.

Can we do better?

Of course, we can. The Data team can only work with what it has. It can’t change the Data Topology too much without risking diverging too much from its stakeholders. They are bound by a pre-established “Team Topology” and will quickly hit a “diminishing returns” point. Not too much added value can be achieved by tinkering with the structure.

The concept of Team Topologies belongs to a book by Matthew Skelton and Manuel Pais. The book emphasizes the importance of clearly defining team interactions and boundaries to optimize organizational performance. Let’s explore the relationship between alignment and the team structures presented in the book:

Stream-aligned Teams

Stream-aligned teams are organized around specific business capabilities or streams of work. They have end-to-end responsibility for delivering a particular product or service.

Alignment in this context means ensuring that the objectives, goals, and understanding of critical business concepts are consistent within the team, enabling effective collaboration and streamlined delivery.

Enabling Teams

Enabling Teams provide support, tools, and platforms to stream-aligned teams. They focus on creating an environment that enables stream-aligned teams to perform their work efficiently.

Alignment between Enabling Teams and Stream-aligned Teams is crucial to ensure that the tools, platforms, and support provided align with the needs and requirements of the Stream-aligned Teams.

Complicated Subsystems Teams

Complicated Subsystem Teams deal with complex technical components or subsystems that require specialized knowledge. They ensure the smooth functioning and evolution of critical technical aspects of the overall system.

Alignment with other teams is critical to ensure that the complicated Subsystems Teams have a shared understanding of business objectives, requirements, and business concepts. This alignment helps avoid miscommunication or misunderstandings that could impact the integration and performance of the overall system.

Platform Teams

Platform teams focus on creating and maintaining shared platforms or infrastructure that support multiple teams. They provide tools, services, and frameworks that enable teams to deliver their products or services more effectively.

Alignment with other teams is essential to ensure that the platform teams understand the specific needs and requirements of the Stream-aligned teams, enabling them to tailor the platform services and support accordingly.

How can we use this knowledge to our advantage?

To foster collaboration and clearly defined interfaces, a great leadership team will ensure the Team Topology is the most efficient it can be. These interfaces will filter downstream, directly into the Data Topology.

Team alignment will foster Data Alignment. Once achieved, data modeling shines, and our Tech Company will have achieved Data Alignment.

My name is Jorge, I work here at Tymit, and we wanted to show you how we achieved a fully functional set of Feature Flags in a multi modular and multi branded project.

The idea of implementing Feature Flags came by after reading this fantastic article Feature flags — A successful architecture which exceptionally explains the concept of Feature Flags. Although we weren’t in a position to use this approach immediately, we’ve decided to tweak the concept to work for us.

Goals

Initially, we set out to achieve the following goals:

• Feature Flags should only be present in their module and be completely independent of other features.
• Feature Flags should be fully reactive, so we can change the value and see the changes instantly.
• We should be able to change between local and remote environments so we can also test if they’re working remotely.
• We can use different default values depending on the brand that we’re currently in.
• The module cannot have any knowledge about the brand it’s working on.

Problems

So we had a pretty good idea of what we wanted and how we wanted to achieve it, but as in any software project, there are always problems that you must face in order to have your new feature to working effectively.

• We have a mix of multi-modular and monolithic projects. Sadly, our previous Feature Flag system are in the monolith, so we need to migrate them.
• Our Feature Flags do not only return Boolean values. Sometimes we have other values like Strings or Integers, that we need to process in-app to get the Boolean that we want.
• The current working version of the Feature Flags is a working solution that is stored in FirebaseRemoteConfig, and Firebase is not reactive.
• We need to be able to provide default values depending on the brand, however the module has no knowledge of the current brand.
• We need to provide support for a permission system that has the users’ identifiers stored inside the FirebaseRemoteConfig value.

Show me the code!!

Now that’s out of the way, let’s show the solution, shall we?
First step — let’s start with the Feature itself or Setting for us.

interface Setting<T> {
    val key: String
    val title: String
    val description: String
    val defaultValue: T
}

This interface provides us with basic functionality to know the Setting’s key, a title to show inside a developer interface, a description if needed, and a default value. As we said previously, our Feature Flag could be any primitive value, so let’s force each setting to set the type of the value with a generic to prevent the usage of <Any> or <*>, as we will need to cast it later, which can be unsafe.

Features

Now that we have our interface, we’ll need two types of Settings — the ones that the application is using to work with working and future features and the ones that we, as developers, are going to use.

This is an example of a simple feature. As you can see, it extends from Setting, so we have all the properties that we need. It has a default value that is passed via constructor, so we can provide different values depending on the brand.

sealed class Feature<T>(
    override val key: String,
    override val title: String,
    override val description: String,
    override val defaultValue: T
) : Setting<T> {
  data class SomeFunctionality(val value: Boolean) : Feature<Boolean>(
      key = "some_functionality",
      title = "SomeFunctionality",
      description = "SomeFunctionality",
      defaultValue = value
  )
  
  data class AnotherFunctionality(val value: Boolean) : Feature<Boolean>(
      key = "another_functionality",
      title = "AnotherFunctionality",
      description = "AnotherFunctionality",
      defaultValue = value
  )
}

This is an example of a developer-specific feature or TestFeature for us. These are very important because they will let us do things like the change between test and production environments or change the theme on a whim.

sealed class TestFeature<T>(
    override val key: String,
    override val title: String,
    override val description: String,
    override val defaultValue: T
) : Setting<T> {
    object DebugWithProduction : TestFeature<Boolean>(
        key = "debug_with_production",
        title = "Override Firebase Setting",
        description = "Enable reading feature flag from Firebase on debug builds",
        defaultValue = false
    )
    data class Theme(val value: String) : TestFeature<String>(
        key = "theme",
        title = "Theme",
        description = "This is our theme value to test different themes",
        defaultValue = value
    )
}

Multi-Brand!!

So, where does the value come from? This can be done easily with DI. You see, we wanted to have different values depending on the brand, but no information about the brand that we’re in, so we needed a simple workaround for this.

First, we added the default values inside the build.gradle of the parent’s project. That way, the project can provide different BuildConfig values depending on the compilation, and this can be used for multiple flavors (release, debug, development, etc…)

flavor1 {
    dimension "flavors"
   
    buildConfigField "boolean", "SOME_FLAG", "false"
    buildConfigField "boolean", "ANOTHER_FLAG", "true"
}

flavor2 {
    dimension "cobrand"
    
    buildConfigField "boolean", "SOME_FLAG", "true"
    buildConfigField "boolean", "ANOTHER_FLAG", "false"
}

Secondly, we needed to add the BuildConfig fields to our DI solution, Koin.

single<Boolean>(named(SOME_FLAG)) { BuildConfig.SOME_FLAG  }
single<Boolean>(named(ANOTHER_FLAG)) { BuildConfig.ANOTHER_FLAG  }

The third and final step is inside the feature flags module.

single { Feature.SomeFunctionality(value = get(named(SOME_FLAG))) }
single { Feature.AnotherFunctionality(value = get(named(ANOTHER_FLAG))) }

And there you have it!!! We have the feature flag singletons that can have different values depending on the flavour they’re on, so if everything fails, they can always get their default value.

Getting the real values

Ok, so to get the value and allowing the feature to double-check and have a list of permissions, we need to return more than a simple value. For that, we created SettingStatus.

class SettingStatus<out T>(
    val value: T,
    val key: String,
    val title: String,
    val pids: Array<String>?
)

Same as with the Feature, it receives a generic value and returns some values that are useful to us

• The value that the Feature returns
• A key to identifying which feature the value is from
• A title to show later in a Developer Screen
• A list of user PIDs to check with the user’s current one so we can have a functional permission system.

Observability

One of our main concerns was that we needed to develop faster. That meant we had to do fewer application restarts and re-compilations, as we lost a lot of time doing these. To solve this issue, we needed the FeatureFlags to be observable, as it allowed us to change their value in runtime without needing to restart o recompile.

For us, that was pretty easy. We’re using Kotlin Programming Language, and one of the top notch features that the language has are Flowables Asynchronous Flow | Kotlin.

It’s a simple API and it’s fully integrated with Coroutines Coroutines guide | Kotlin our concurrency framework of choice. So we implemented that in our Repository and data sources.

A little bit of abstraction

Now we need to get this for each of our features. To achieve this, we need to add some kind of data source or provider that can get those values for us. We used DataSource as naming, as it has a little bit more logic and information than a simple data source.v

interface SettingDataSource {
    fun <T> getSetting(setting: Setting<T>): Flow<SettingStatus<T>>
}

/**
 * If we have more remote providers we can set an priority to them.
 */
const val TEST_PRIORITY = 0
const val MAX_PRIORITY = 1
const val MEDIUM_PRIORITY = 2
const val MIN_PRIORITY = 3

Pretty simple, right? The only thing that we need is a function to get our Setting (doesn’t matter if it is a Feature or TestFeature) and a priority that we will use later for sorting purposes.

Ah! I almost forgot. See that Flow<SettingStatus<T>>? That allows our Flags to be reactive and observable so we can change it in our console and see the change ipso facto.

As we can be in different environments (development or production), we need a way to get those values from different places, that is, a remote or production provider that gets us the currently working values, and a local or debug provider.

abstract class LocalSettingsDataSource(
    private val settingsStore: SettingsDataStore
): SettingDataSource {
    suspend fun <T> setSetting(setting: Setting<T>, value: T) =
        settingsStore.setSetting(setting.key, value = value)
}

abstract class RemoteSettingsDataSource : SettingDataSource {
    abstract val priority: Int
    abstract var isEnabled: Boolean
    abstract suspend fun refreshRemoteSettings()
}

As you can see, the Local and Remote providers have different values and functionalities

• The LocalDataSource only works in our developer environment, so we only have one of those in the application and is the only one that has the ability to change the value of a Feature Flag
• The RemoteDataSource is a bit different, as we can have multiple of those (firebase, aws, a custom API), so we need a way to know if they're working properly and sort them by priority if they're all up.

Adding the final touch

• Feature Flags Done ✅
• Providers ✅
• Logic to choose between providers ❌

The final step for everything to work properly is to add some logic to let the application choose between providers. Let’s go bit by bit.

class SettingsRepositoryImpl(
    private val remoteSettingsDataSources: Array<RemoteSettingsDataSources>,
    private val localSettingsDataSource: LocalSettingsDataSource,
    private val isDeveloperEnvironment: Boolean
) : SettingsRepository {...}

First of all, we need a repository to do the logic for us, that repository has information about whether it is in developer environment or not, an instance of a LocalSettingsDataSource and a list of RemoteSettingsDataSource.

private fun <T> getRemoteSettings(setting: Setting<T>) =
    remoteSettingsProviders.filter { it.isEnabled }.minByOrNull { it.priority }
        ?.getSetting(setting = setting) ?: flowOf(
        SettingStatus(
            value = setting.defaultValue,
            key = setting.key,
            title = setting.title,
            pids = null
        )
    )

Secondly, when we want to retrieve the value from a remote provider; we need to check first if it’s enabled and then sort it using the priority, if there is no remote provider available, we need to return a default value the Feature can still work

So now Remote is working fine GREAT!!!. But we want to go a little further, we need a LocalDataSource and we want to be able to change between local and remote when we're on developer mode

override fun isProductionDebugEnabled(): Flow<SettingStatus<Boolean>> =
    localSettingsProvider.getRemoteSetting(TestFeature.DebugWithProduction)

override fun <T> isRemoteSettingEnabledObservable(setting: Setting<T>): Flow<SettingStatus<T>> =
    if (isDeveloperEnvironment) {
        if (setting is TestFeature) {
            localSettingsProvider.getSetting(setting = setting)
        } else {
            isProductionDebugEnabled().map {
                it.value
            }.flatMapLatest { isProductionDebugEnabled ->
                if (isProductionDebugEnabled) {
                    localSettingsProvider.getSetting(setting = setting)
                } else {
                    getRemoteSettings(setting = setting)
                }
            }
        }
    } else {
        getRemoteSettings(setting = setting)
    }

It seems like a lot but it is really simple. Whenever we want to get a value, first we need to check whether we’re in a developer environment or not. This will not change at runtime, so we only need to check this once to prevent misuse of this feature.

So now that we’re in a Developer environment, we check if the feature is a TestFeature; if it is, we go to local directly.

And now, the fun stuff. We have our isProductionEnabled flag that is local and observable. The great thing about this Feature being Observable is that we just need to map the latest value, and it will update the Feature’s DataSource from Local to Remote. That allows us to ship our features completely disabled and test them locally. And whenever product feels confident that it can be released, they only need to enable it on Firebase, API or whatever solution we’re using to enable it.

This gave us sooooo much developing speed and helped us a lot and I mean A LOT in creating new features and adopt Trunk Based Development.

The final step was to add a way to change the values only if we’re in a developer environment.

override suspend fun <T> setRemoteConfig(setting: Setting<T>, value: T) =
    if (isDeveloperEnvironment &&
        (setting is TestFeature || isProductionDebugEnabled().map { it.value }.take(1).single())
    ) {
        localSettingsDataSource.setSetting(setting = setting, value = value)
    } else Unit

And as with the get method, we need to check if the isProductionEnabled flag has been enabled or not before letting the user change the value, and this only works with the LocalDataSource

Final thoughts

And I think that’s it. Really the only thing that it is missing is the real implementations of the Local and Remote DataSources, but I think that everyone has their implementations and way of doing things or maybe they have some code that they’re not supposed to share…

To summarize, I wanted to remind how much easier this has made developing and refactoring both productivity and enjoyment. It’s pretty fun to develop a new feature and ship it directly without thinking if it’s going to affect the user or not or if it’s going to crash because we can disable it by default and just test it locally. We can develop it, merge it to develop, and everything is going to work fine.

We moved to trunk before having this implemented, and it was pretty tough because we had to think what we were going to ship, and we needed a fully functional feature, but with this, we can just do it bit by bit and do incremental builds of our code.

Sooo, yeah. Just try it, it will improve your code & your team’s coding speed and, in turn, makes coding more fun.

This article was written by: Jorge García, Android engineer.

Thank you for reading. We are hiring!

DRY, or Don’t Repeat Yourself, is a primary goal in software development. It means writing code once and reusing it as much as possible. Code is expensive to create, maintain, and test. Therefore, the more code we can reuse, the better it is for the company and our productivity.

At Tymit, we began to transform our project into a multi-brand app over a year ago, and with that, we had to extract code from our monolith app into small modules that can be added to each brand as we please.

When we started splitting our app’s code, we identified two types of modules:

• Clients: such as the API or persistence, which are dependencies that will interact with the boundaries of the app, interacting with the outside world. They are independent of the business logic.
• Features: the internal logic of our application will only interact with the business model.

We use a well-defined directory tree for the project to enable automation between the various tools we use. This would be our main scheme:

/ios-app
├── App
│   ├── Sources
│   └── Tests
├── Brand
│   ├── White
│   │   ├── Project.swift
│   │   ├── Sources
│   │   ├── Resources
│   │   ├── Tests
│   │   └── Supporting Files
│   └── Black
│       ├── Project.swift
│       ├── Sources
│       ├── Resources
│       ├── Tests
│       └── Supporting Files
├── Features
│   ├── FeatureA
│   │   ├── Project.swift
│   │   ├── Sources
│   │   └── Tests
│   └── FeatureB
│       ├── Project.swift
│       ├── Sources
│       └── Tests
└── Packages
    ├── APIClient
    │   ├── Project.swift
    │   ├── Sources
    │   └── Tests
    ├── FeatureKit
    │   ├── Project.swift
    │   ├── Sources
    │   └── Tests
    └── Persitence
        ├── Project.swift
        ├── Sources
        └── Tests

Modularisation

When approaching a multi-brand development, it is typical for all brands to implement the same features, with the only differences between them being the images and colours. However, in our case, we wanted to use the highest percentage of code possible and be able to add some specific features for each brand.

One of the first solutions we thought of was to use feature flags to configure the app at runtime. The main problem we encountered with this solution is that we would have to deploy the app with all the code, and for example, if one brand required camera permissions and another did not, both brands would need to include that permission to configure it at runtime and prevent crashes. Also, with this approach, we would only have certainty that it would be working with the feature flag configuration and we could not test it separately.

Another solution we were studying was to implement features with compiler flags to deliver only the code we would use in the app. We liked this approach more because, during compilation time, Xcode would warn us that we would be trying to access a function or some feature that would not be included in some brand. The problem we found with this approach was that it did not scale well when we had many brands because we will always have to add all possible variants for that brand in the same file, and when you have two brands it may be manageable in one file, but as soon as you start having more, that file becomes difficult to maintain and to search which brand you are dealing with.

tuist at scale

At Tymit, we use Tuist to configure the entire project infrastructure. Tuist is a command-line tool used to automate the configuration and maintenance of Xcode projects. This tool allows us to generate and manage projects, dependencies, schemes, configuration files, and other elements related to application development in an easy and efficient manner.

Tuist defines projects through Swift configuration files, allowing for greater flexibility and customisation in project creation and management.

We can define templates to describe the projects for our Features and each Brand. These templates will be defined within ProjectDescriptionHelpers, which is the module that Tuist provides us to reuse code between different Project.swift. We will start by defining our Features:

//ios-app/Tuist/ProjectDescriptionHelpers/Feature+Project.swift

import ProjectDescription

public extension Project {
  static func feature(
    name: String,
    dependencies: [TargetDependency] = []
  ) -> Self {
    .init(
      name: name,
      targets: [
        .init(
          name: name,
          platform: .iOS,
          product: .staticLibrary,
          bundleId: "com.tymit.\(name)",
          sources: [
            .glob(.relativeToRoot("Features/\(name)/Sources/**")),
          ],
          dependencies: dependencies
        ),
        .init(
          name: "\(name)Tests",
          platform: .iOS,
          product: .unitTests,
          bundleId: "com.tymit.\(name).Tests",
          sources: [
            .glob(.relativeToRoot("Features/\(name)/Tests/**")),
          ],
          dependencies: [
            .target(name: name)
          ]
        )
      ]
    )
  }
}

One way to avoid errors is to define a new type called Feature so that it can be consumed directly from the Brand. We generated this type from an ERB template and do a Dir in the Features path to always have that type synchronised and avoiding to point to incorrect Features names. We will have an extension that will automatically convert this Feature into a TargetDependency type that our Brand will consume.

//ios-app/Tuist/ProjectDescriptionHelpers/Feature.swift

import ProjectDescription

public enum Feature: String, CaseIterable {
  case featureA = "FeatureA"
  case featureB = "FeatureB"
}

extension Feature {
  var dependency: TargetDependency {
    .project(
      target: rawValue,
      path: "//Features/\(rawValue)"
    )
  }
}

Now we can define our description for each Brand project. Following the folder structure we showed you at the beginning, in the App/Sources folder, we will include all the code that will be shared among all Brands, and then we will add a Sources folder for each Brand, where we will instantiate and define any and all brand-specific code.

//ios-app/Tuist/ProjectDescriptionHelpers/Brand+Project.swift

import ProjectDescription

public extension Project {
  static func brand(
    name: String,
    features: [Feature] = [],
    dependencies: [TargetDependency] = []
  ) -> Self {
    .init(
      name: name,
      targets: [
        .init(
          name: name,
          platform: .iOS,
          product: .app,
          bundleId: "com.tymit.\(name)",
          sources: [
            .glob(.relativeToRoot("App/Sources/**")),
            .glob(.relativeToRoot("Brands/\(name)/Sources/**")),
          ],
          dependencies: dependencies + features.map(\.dependency)
        ),
        .init(
          name: "\(name)Tests",
          platform: .iOS,
          product: .unitTests,
          bundleId: "com.tymit.\(name).Tests",
          dependencies: [
            .target(name: name)
          ]
        )
      ]
    )
  }
}

Now we can define our features independently for each Brand. Let's start with the example that the White brand has featureA and the Black brand has featureB.

//ios-app/Workspace.swift

import ProjectDescription

let project = let project = Workspace(
  name: "App",
  projects: [
    "//Brands/Black",
    "//Brands/White"
  ]
)

FeatureKit

All the features specific to each Brand have an entry point. That's where we're going to split the business logic between Features. For this, we'll use a module independent of these Features and we'll call it FeatureKit. We'll use a protocol-witness approach for this library since it will help us create different witnesses in each Brand.

Let’s code

Let’s imagine that the set of tabs in a UITabBarController changes between different variants. We'll start by creating our FeatureKit library and defining its entry point, which in this case would be the tabs:

public struct FeatureClient {
  public let tabs: () -> [UIViewController]

  public init(tabs: @escaping () -> [UIViewController]) {
    self.tabs = tabs
  }
}

This library is a dependency that will be necessary at the root of the project. Here, we will declare all the entry points where the app will branch out for each different use case we want for each variant. It is necessary that this library does not contain types that depend on third parties. That is, all the types we declare are primitive.

Let’s create a witness for one of the brands in which we will only load three tabs. We will add this file exclusively to the White variant target:

//ios-app/Brand/White/Sources/FeatureClient+Live.swift

import FeatureKit

extension FeatureClient {
  static var live: Self {
    .init(
      tabs: { 
        [
          OneViewController()
          TwoViewController()
          ThreeViewController()
        ]
      }
    )
  }
}

Now it’s time to create the witness for the Black variant. For this witness we will need to load five tabs, where two of them will come from a dependency called FeatureB, which contains the UIViewControllers for FooViewController and BarViewController:

//ios-app/Brand/Black/Sources/FeatureClient+Live.swift

import FeatureKit
import FeatureB

extension FeatureClient {
  static var live: Self {
    .init(
      tabs: { 
        [
          OneViewController()
          TwoViewController()
          ThreeViewController()
          FooViewController()
          BarViewController()
        ]
      }
    )
  }
}

Afterwards, we just need to invoke FeatureClient.live.tabs() wherever we are going to instantiate our UITabBarController to inject the corresponding tabs. Instead of directly using the reference to the Live client, it is preferable to use an approach similar to @Dependency(.featureKit) var featureClient as explained in pointfree swift-dependencies so we’re able to test this.

import UIKit 
import Dependencies

struct Screen {
  @Dependecy(\.featureKit) var featureClient

  var viewController: UIViewController {
    UITabBarController(viewControllers: featureClient.tabs())
  }
}

Testing

Since each brand will have an independent test target, we can isolate and test this functionality independently. We can introduce a value that we control in our test environment or use the same dependency we use in live.

import SnapshotTesting
import XCTest

final class ScreenTests: XCTestCase {
  func testBrandTabs() throws {
    let screen = withDependencies {
      $0.featureKit.tabs = { [MockViewController()] }
    } operation: {
      Screen()
    }
    assertSnapshot(matching: screen.viewController, as: .image)
  }
}

Conclusion

To create a white-label app, we have to address diverse challenges. Not all projects need to split the code between variants. Ideally, the same code should be used for all variants. Having a single point of reference for all dynamic features is an advantage when creating new variants and not forgetting any implementation. Being able to have different witnesses for each variant saves us from having to deal with complex configurations between different targets using the same file. Sharing code between a common app and specific features can be a very complex task, but thanks to Tuist, we can create a reliable and truthful scenario. When generating the project, it will verify that the entire dependency tree is described correctly, and we can add more complex functionalities, such as dynamically adding AppExtensions to a particular Brand.

This article was written by: Sergio Fernández, Principal iOS engineer.

Thank you for reading. We are hiring!