Tech Lead |Software Architecture & Production Systems

What if we no longer needed to share code to develop cross-platform applications? Engineering with SwiftUI and Jetpack Compose

For years, developing an application for both iOS and Android has meant making a significant choice: should we maintain two separate native implementations, or opt for a cross-platform technology that allows us to share a single codebase?

Frameworks like Flutter or React Native, along with solutions such as Kotlin Multiplatform, have addressed a specific need: reducing the cost and time required to develop two applications that, in essence, deliver the same product.

The logic behind this is straightforward. Maintaining two separate codebases means duplicating work, and often requires specialized teams for each platform. This can lead to higher costs in terms of development, coordination, and maintenance. Conversely, by choosing a cross-platform technology, we can focus much of that effort on a single codebase, managed by a single team.

From an organizational and economic perspective, this is a perfectly reasonable decision. However, compared to native development on each platform, it often entails trade-offs—such as limited access to native APIs, differences in the “feel” of the user interface (UI), or a reliance on an intermediate abstraction layer.

While we have often accepted these trade-offs—simply because the cost of maintaining two native implementations was difficult to justify—the rise of AI agent-assisted development introduces a new variable into the equation.

The real challenge isn’t writing code twice

Just because we use AI agents to develop an application for two different platforms, it doesn’t mean we automatically solve the problem of keeping them aligned. In fact, it can even introduce new issues.

For instance, one agent might interpret a specification in one way, while another interprets it differently. A feature might be completed on iOS, while the Android version is still based on an earlier iteration. Alternatively, product decisions might emerge that no one requested, or behaviors might appear that are technically sound but don’t align with what was actually expected.

Therefore, the challenge is no longer just about implementing a feature twice; it’s about ensuring that two independent implementations evolve in the same direction. That is why, before focusing on how to generate code, I realized I needed to address several other questions:

• How can I provide the same product context to the agents?
• How can I define what a feature should do without dictating how it’s implemented?
• How can I prevent each platform from evolving independently?
• How can I objectively determine when a feature is truly complete?

The solution was to build a harness that acts as the project’s single source of truth.

Harness engineering: designing the agents’ working environment

An AI model (no matter how powerful) lacks knowledge of a project’s architectural decisions, team conventions, business rules, and quality standards.

Consequently, we must provide an environment that supplies this information and sets boundaries on the decisions the model can make. We call this environment a harness.

Think of the harness as the infrastructure surrounding the model, which makes its generative capabilities genuinely useful for our project’s development. This harness encompasses context, instructions, tools, documentation, the current state of work, constraints, and validation mechanisms. There is a significant difference between working with isolated prompts and using harness engineering. In the former, each session relies heavily on how well we can explain things to the agent. In the latter, the relevant project knowledge is structured, versioned, and persistently available.

The goal is not to make the agent more intelligent; it is to ensure it needs to improvise less.

In my case, I wanted this environment to be independent of the specific programming tool being used. The rules and project knowledge needed to reside within the repository itself, rather than in a configuration specific to OpenCode, Claude Code, or any other agent.

This way, the harness can evolve alongside the product, and different tools can operate within the same context.

Leafly: One Project, Two Native Implementations, and a Shared Harness

Leafly is an app for the care of houseplants (something I personally struggle with). The MVP includes six core features:

1. Onboarding and registering the first plant.
2. A list of plants with their watering status.
3. Details for each plant and a log of watering events.
4. Local reminders.
5. Taking photos when adding a plant.
6. A visual history of photos.

In my view, this isn’t a particularly complex product, which made it a great scenario for experimentation. I wanted to focus exclusively on the engineering process, without introducing the complications of a distributed backend or overly extensive business logic from the outset.

The architectural decision was to maintain two independent implementations:

In other words, there is no shared UI layer or common domain implementation; each platform utilizes its own technologies and conventions.

What both do share is the product’s functional definition, business rules, specifications, and acceptance criteria.

The concept is to separate two distinct aspects:

• What the application should do.
• How it should be implemented on each platform.

The former belongs to the shared contract, while the latter pertains to each individual native implementation. ### The Harness Structure

For this experiment, I organized the project into a monorepo with the following structure:

1
leafly/
2
├── AGENTS.md
3
├── feature_list.json
4
├── progress/
5
│   └── current.md
6
├── docs/
7
│   ├── architecture.md
8
│   └── design-system.md
9
├── features/
10
│   ├── onboarding.feature
11
│   ├── plant-list.feature
12
│   ├── plant-detail.feature
13
│   ├── watering.feature
14
│   └── reminders.feature
15
├── ios/
16
│   └── AGENTS.md
17
└── android/
18
└── AGENTS.md

In this setup, each element has a specific responsibility.

1
Feature: List of my plants with their watering status
2

3
Scenario: Viewing the list when plants are present
4
When the user opens the app
5
Then they should see a list of all their plants
6
And each plant displays its name
7
And each plant displays a watering status indicator

1
Read the following project files:
2
- AGENTS.md
3
- ios/AGENTS.md
4
- docs/architecture.md
5
- docs/design-system.md
6
- progress/current.md
7
- features/02-plant-list.feature
8
- feature_list.json
9

10
Current context:
11
- The `onboarding-first-plant` feature is already marked as "done" (iOS + Android).
12
- We are now working on `plant-list` (status: in_progress).
13
- We are working ONLY on iOS.
14
- Basic navigation and plant persistence (SwiftData) are already in place.
15
- The design system is already established and must be reused.
16

17
Task:
18
Implement the `plant-list` feature on iOS, following the specification.
19

20
Required behavior:
21
- If plants exist, display a list containing all of them.
22
- Each plant entry displays:
23
    - Name
24
    - A visual indicator for watering status (Up to date / Water soon / Needs water)
25
- Watering statuses (following the same logic as iOS):
26
    - 0–4 days → Up to date
27
    - 5–6 days → Water soon
28
    - 7+ days → Needs water
29
- Tapping a plant should navigate to a placeholder detail screen.
30
- There must be a clear way to add a new plant from the list.
31
- Adhere to the design system (rounded cards, natural green tones, a calm aesthetic, and ample spacing).
32

33
Technical requirements:
34
- Swift 6 + SwiftUI + @Observable
35
- Reuse the existing domain and repository layers.
36
- Calculate the watering status in a simple, clear way (you may base this on the date of the last watering).
37
- Ensure the code is clean, testable, and aligned with the current architecture.
38

39
Do not implement the Android version yet.
40
Do not mark the feature as "done."

1
Read the following project files:
2
- AGENTS.md
3
- android/AGENTS.md
4
- docs/architecture.md
5
- docs/design-system.md
6
- progress/current.md
7
- features/02-plant-list.feature
8
- feature_list.json
9

10
Current context:
11
- The `plant-list` feature is already implemented and verified on iOS.
12
- We are now implementing it on Android.
13
- We are working ONLY on Android.
14
- The following are already in place: onboarding, the Plant domain, Room, the design system, and basic routing.
15
- The plant list must behave the same way as it does on iOS, according to the spec.
16

17
Task:
18
Implement the `plant-list` feature on Android.
19

20
Required behavior:
21
- If plants exist, display a list containing all of them.
22
- Each plant entry displays:
23
    - Name
24
    - A visual indicator for watering status (Up to date / Water soon / Needs water)
25
- Watering statuses (following the same logic as iOS):
26
    - 0–4 days → Up to date
27
    - 5–6 days → Water soon
28
    - 7+ days → Needs water
29
- Tapping a plant should navigate to a placeholder detail screen.
30
- There must be a clear way to add a new plant from the list.
31
- Adhere to the design system (rounded cards, natural green tones, a calm aesthetic, and ample spacing).
32

33
Technical requirements:
34
- Kotlin + Jetpack Compose + ViewModel + StateFlow
35
- Reuse the existing Room setup and domain logic.
36
- Add `lastWateredAt` to the entity if it is not already present.
37
- Ensure clean code that aligns with the current architecture.
38

39
Do not modify the iOS codebase.
40
Do not mark the feature as "done."

My Workflow: A Development Cycle per Feature

With these components in place, the workflow is clearly defined:

1. Select the next pending feature.
2. Review and complete its specification.
3. Mark it as in_progress.
4. Implement it on iOS.
5. Verify the result and record the changes.
6. Implement the same feature on Android.
7. Validate both implementations against the specification.
8. Update the status to done.

Throughout this experiment, I followed a sequential order: iOS first, followed by Android.

Although I could have employed agents working in parallel, I chose to limit the variables and maintain more direct control over decision-making. The priority was not to maximize the number of agents running simultaneously, but rather to verify that the system could maintain consistency across two independent implementations.

I also added a small init.sh script to ensure the test harness structure was in place and to display the next recommended feature.

Finally, I documented a shared “design system” in docs/design-system.md, covering colors, typography, spacing, components, and visual direction. The intention was not to enforce a pixel-for-pixel reproduction. SwiftUI and Compose have their own conventions. The goal was to share a visual identity and let each platform manifest it natively.

What I’ve learned during the experiment

For me, beyond achieving a complete implementation on both platforms, the most interesting aspect has been observing how the development process itself changes.

Is this the future of cross-platform development?

I don’t believe this experiment proves that Flutter or React Native have become obsolete. They remain excellent solutions for many products and teams. Nor do I believe that maintaining two native implementations is always the best decision.

However, I do believe that agents are shifting some of the variables that have traditionally influenced this architectural choice. If we can reduce the cost of implementing and maintaining two native applications, perhaps we should begin evaluating our alternatives from a different perspective. Instead of asking only how much code we can share, we can ask how much knowledge we can share, which decisions should remain platform-specific, and how we can ensure that two independent implementations adhere to the same contract.

In any case, there are still questions to explore: how to scale this approach for large teams, how to coordinate agents working in parallel, how to automate functional validation, and how to accurately measure the savings in time and effort compared to a cross-platform solution.

Leafly is an experiment limited to an MVP, it is not a demonstration that this model is superior in every scenario. But it has allowed me to explore a possibility that I find compelling for mobile engineering:

For years, we have tried to address cross-platform complexity by sharing code. Perhaps now we can tackle some of that complexity by sharing specifications, context, and knowledge.

This also shifts the role of the Mobile Tech Lead. Beyond defining architectures and making technology decisions, we will need to design the environments in which these agents operate, establish the contracts they must follow, and build the mechanisms that allow us to trust their outputs.

It is not about replacing native development with agents; it is about using agents to make a different approach to building and maintaining native applications a viable reality.

I believe it is worth exploring.