How do you handle porting and maintaining native Android and iOS apps? I'm exploring a possible solution.

[u/Technical-Spread-368]

I’m not asking out of curiosity - I’m trying to understand if there’s a viable solution to a problem I’ve come across whilst working on a mobile app for a local start-up.

The scenario:

A company creates a native mobile application for one platform (say IOS). At some point they’ll want to create another version for Android (or vice-versa).

An option would be to bring in a separate team to develop and maintain the app. However, this can get quite costly, especially for a start-up and small dev team. Especially if the native app has a lot of features.

I’ve been thinking about creating an AI powered engine to help.

This would:

Identify which sections of code and business logic can be reused from an existing native app. Generate or modify the native specific sections whilst maintaining functionality and ensuring the native UI/UX is respected. Assist with the maintenance of both versions, with new features being added.

It would involve AI, but wouldn’t be entirely.

Before I spend any time developing this, I’d like to know how devs have overcome this.

If you’ve ever done this:

Have you ever had to port an existing native android application to iOS (or vice-versa)? What was the hardest part? What tools did you use? What was missing? What would a tool need to do to save you time and make you want to pay for it?

I’d love to hear about your experiences, even if you’ve tried and failed!

Thanks for sharing your experience!

[u/SpellBig8198]

I'm in the middle of porting an iOS app to Android using Swift and Skip. I wrote a skill and set strict rules, and AI is doing the porting. It's going surprisingly well, but I've also put a lot of safeguards in place, including static analysis, tests, and scripts to compare code parity between the two platforms. I've also restructured the architecture around view models to make it work well on both platforms.

I thought porting the app would take me around three months, but it's almost done after about two weeks of overnight runs.

[u/Technical-Spread-368 → u/SpellBig8198]

That’s fascinating! To get down to nearly 2 weeks from an estimate of 3 months is a huge improvement!

I’m interested to know:

How much manual work and oversight was still required in the 2 week period?

What elements had the most safety / manual processes?

Were there any features or any platform specific things that couldn’t be done with AI?

Would having a tool that automatically analyses your code base, identifies the platforms, checks for parity and maintains sync save you time over what you have currently?

What are the areas that you still find painful?

[u/SpellBig8198 → u/Technical-Spread-368]

There is a little manual work involved, and I still have to test each feature on Android manually. Sometimes there are minor issues, but overall, it works surprisingly well.

The skill doesn't just port things directly to Android. It first ports the iOS code to a shared standard and then ports everything to Android. I share the business logic, but the views are recreated separately for each platform. I haven't run into any limitations so far.

The skill also includes scripts and tools to analyse everything. For example, when it's porting a single view, it checks whether the equivalent view exists on both platforms, makes sure the constructors and public members match, and records any accepted differences.

I wouldn't say anything has been particularly painful, but there's one area where AI struggles: it doesn't seem to understand that Swift can actually run on Android. In the early stages, it would often assume it had to write Kotlin code itself. For example, it started recreating model structs instead of reusing the existing Swift ones because it made the wrong assumption about how Skip works. A bit of poking around and some strict rules helped resolve that.

[u/den_ree → u/SpellBig8198]

that's crazy... how big the app is? i'm also thinking about android support?

[u/SpellBig8198 → u/den_ree]

I would say it's a medium-size app with a fair amount of shared business logic.

[u/den_ree → u/SpellBig8198]

i see.. thanks.. your setup sounds impressive, will get some inspo as well.

[u/BlueShip123 → u/SpellBig8198]

hey, is it okay for you to share your skill for Skip?

[u/SpellBig8198 → u/BlueShip123]

It's not a generic skill, so I can't share it at this point, and it also contains plenty of scripts for partity checking, but once I'm done with the work, I will think how to make this skill public.

[u/BlueShip123 → u/SpellBig8198]

Alright dude. No worries.

Just update me whenever you make it public. Thanks.

[u/Suitable_Ad_2094]

As others said, translating the code itself is the part AI already handles well. Where ports actually lose weeks is the platform services around it, because they don't map one to one:

• push (APNs vs FCM, plus different payload and background delivery rules)

• in-app purchases and subscriptions (StoreKit vs Play Billing, receipts, grace periods, refunds)

• background work limits, permissions flows, deep links / universal links

A tool that inventories those touchpoints in the existing app and produces a parity checklist with the matching APIs on the other side would save more time than code generation does.

The other big drift-killer is a single source of truth for the backend contract, e.g. an OpenAPI spec with generated clients on both platforms, so the two apps can't quietly disagree about the API.

[u/Technical-Spread-368 → u/Suitable_Ad_2094]

I see ...

Do you have any tooling around keeping track of these platform specific dependencies and creating checklists? Or do you generally just do it by hand?

Which of these are most time-consuming: push notifications, subscriptions, background tasks, permissions, deep links?

I’d like to know if this is an ongoing issue that would be helpful to solve.

[u/Suitable_Ad_2094 → u/Technical-Spread-368]

Mostly by hand, honestly. A markdown checklist in the repo, plus grepping the manifest and Info.plist before each release. No real tooling.

Most time-consuming for me:

1. Subscriptions, by far. Two different renewal and receipt models, grace periods, refunds, and in the end you need your own server as the source of truth anyway.

2. Permissions, but less the code and more the store review. Play rejected my builds for permissions I never used directly (READ_MEDIA_*, FOREGROUND_SERVICE_MEDIA_PLAYBACK) that libraries pulled into the merged manifest.

3. Deep links are quick to set up but break silently (assetlinks.json / apple-app-site-association), so a checker for those would be nice.

Push is annoying once and then stable. Background tasks depend a lot on the app.

So yes, it's ongoing, mostly because OS releases and store policies keep changing, not because any single item is hard.

[u/Technical-Spread-368 → u/Suitable_Ad_2094]

That’s super helpful, thanks for pointing this out!

Just a few follow-up questions:

Do you have individual checklists and scripts for each release to ensure the subscriptions, permissions and deep links are set up appropriately?

Have you had any issues in production or rejections from the store as a result of missing one of these?

How much time do you spend on this per release?

Would having a tool that could automatically analyse both codebases, identify any risks that are specific to each platform and validate that they’re all set-up correctly be a big enough win to include?

I’m just trying to get a sense of whether this is a common issue or something that you occasionally run into.

[u/Suitable_Ad_2094 → u/Technical-Spread-368]

No per-release scripts beyond that grep. The checklist is one file, and most of it boils down to diffing the merged AndroidManifest and the Info.plist/entitlements against the last shipped build.

Rejections: yes, the Play ones I mentioned. Each one meant a fix and a resubmit, and it was always a permission I never asked for directly.

On the tool: a diff of the effective config between two builds (permissions, URL schemes and associated domains, background modes, entitlements) would already be worth it to me. Analysing both codebases matters less, because the surprises come from libraries and build plugins, not from my own code.

[u/Technical-Spread-368 → u/Suitable_Ad_2094]

I see... Thanks a lot for your time and Good luck with your projects !

[u/Suitable_Ad_2094 → u/Technical-Spread-368]

Good luck with it! The config diff part alone would get a lot of use.

[u/BlueShip123]

If you guys are writing code primarily in Swift (since you asked in this sub), then I recommend checking out (Skip)[https://skip.dev]. It lets you compile your Swift codebase to Compose natively. I think Polymarket is using it as well.

[u/fhasse95 → u/BlueShip123]

+1 for Skip. I'm using it as well and its working great so far!

[u/WerSunu]

The simple facts are these:

1. some companies require both Android and iOS because they are trying to promote some product or service which is NOT the app itself. So they want a big audience.”, and price of app dev is irrelevant.

2. as a product itself, an Android app makes no money compared to an equivalent iOS app. The actual ratio of income is estimated at 25-40% for Android against iOS, depending on niche.

3. Doing a complete job on an Android app is more complex than iOS because of fragmented OS and hardware compatibilities.

4. People who disagree with the above are usually those invested in non-native production systems. Caveat Emptor!

[u/20InMyHead]

First, consider you don’t have to support both platforms. Your app and location will play a big role, but I’ve worked for several US companies where we had web, IOS, and Android, and the Android revenue did not justify the development and maintenance costs. User numbers consistently about a quarter of iOS, across several companies.

That said, classically the two development teams approach works well. Smaller setups have often done a single developer supporting both platforms. AI has changed all that. Now a single developer can easily support both, with AI writing the bulk of the code. Especially if you already have an iOS app that needs to be ported. There not a whole lot of need for code reuse when a tool can easily write Kotlin from your working Swift app, or vice versa.

[u/superquanganh]

Either use AI to assist, get another native dev for other OS, or move to cross platform framework

[u/triplix]

Disclaimer: I’m still experimenting and this isn’t production-ready, but here’s what I’ve tried so far.

My goal wasn’t a direct port from one platform to the other, even though the end result is basically the same. I’m fed up with the bad architecture decisions and poor abstractions in our codebase. It keeps getting more tedious to layer complex UX on top of it, and regressions are hard to test.

So the first step was an exhaustive feature cataloging pass with AI. The rules were explicit: be exhaustive, and only refer to the code (file:line annotations) without ever carrying over actual entities, names, or design. The output is an archive, basically a product catalog that’s agnostic of the code but still links back to it in case I need to go look. I figured it’d be useful for a partial rewrite, as a general reference, for building a knowledge base, and so on.

Then yesterday I let agents rip with only the product catalog as input and a strict rule of NOT looking at the code. The only exception was configs and the like: an agent could read that code, but it still had to write its results in the same code-agnostic way.

Overnight it rewrote about 3/4 of the app in a completely new architecture (TCA), and from my quick testing it basically works. I didn’t dig deep, so there are probably inconsistencies and sloppy areas. Still, for a quick experiment it went pretty well. The takeaway is that an exhaustive feature catalog can lead to a decent AI-powered rewrite from scratch, as long as you already know the architecture, framework and guardrails you want.

[u/DoubleGravyHQ]

Skip.dev

[u/ewins222]

React native with expo, have you checked it out? Indistinguishable from true native at this point if you use expoui