[mad_tortoise]

I'm not sure I see the point, other than this being aimed at first world (see US/EU) businesses who solely have iOS application's and want to convert those to Android. So if you only have Swift developers and didn't have the forethought to want an Android version of the app going forward then this is a product for you. I would recommend, going pure native android or starting again with Flutter.

Whereas the rest of the world is Android dominant, and there is no real reason to do this when there's multiple better frameworks for cross platform development. Flutter, React Native and Kotlin MP are and always will be miles ahead. Let alone those framework's being free whereas here there is a cost for professional development.

As someone that has written various projects in Kotlin (including multiplatform), Swift, Dart/Flutter for over a decade I don't see the point. And I would be exactly the target market for this kind of product. The transpiling is the big issue for me, you will have to tap into every single Android API, write code to transpile those and then maintain across every Android version going forward.

Let alone the denigrating of cross platform frameworks and promotion of yours due to "animations, accessibility, and future-proof evolution alongside OS updates" doesn't sound like much of a win, when the quality of these in cross platform is already at a very high level. Secondly "And there's a GitHub ecosystem of open-source modules supporting popular frameworks, including SQLite, Firebase, Lottie, and many other common building blocks of modern apps." all of which exist in cross platform and kotlin multi platform.

I'm sorry to the developers and team to knock it, but just my 2 cents coming from a more third world perspective.

[anakaine]

I thoroughly disagree with your positions about foresight, multiple specialists, a lack of need in this space, etc.

There is space in the market for something like this, and it would suit small teams who may be lean, single devs who are starting out, and those who would like to use native code with few if any dependencies.

You may not see the point because you are deeply experienced with the existing tools. I see the point as someone who has struggled to get deep with the existing tools.

[isodev]

> it would suit small teams who may be lean, single devs who are starting out, and those who would like to use native code with few if any dependencies

I think that's already covered by Kotlin Multiplatform, Flutter, React Native and others. It's extremely easy to get started and they all have a vibrant and thriving ecosystem.

I'm not blind to your use of "native" here, but again that's a descriptor typical for the iOS/macOS dev bubble to imply "build with Apple tooling" vs. "build with a 3rdparty/cross-platform framework". It was mentioned in another reply - the years when that was noticeable in any meaningful way are long gone.

[mad_tortoise]

In terms of forethought, I can't imagine anyone outside of the US/EU developing an app solely for an iOS user base other than creating an MVP. And then even still, once you have proof it can work why build something that intentionally shuts off the majority of your userbase, or provides a lower quality product to the user base? If you are lean and starting out, don't put all your eggs in a Swift/iOS basket and then hope for a tool like this to sort out your problems. It may be an easy quickfix for a basic app, but once you go even a little bit deeper than surface level you're going to run into problems, have to backtrack and start over with either native Android code, or a cross platform framework.

That said the cost is also something that is odd, when you have free alternatives that provide far more mature ecosystem.

In terms of getting deep with existing tools, what is the difference here when using XCode as to Android Studio or VSCode? The tools aren't difficult to use, at least any more so than XCode. If you're not a developer then sure, but if you are then AS or VSCode should be a breeze. We're far removed from the days of Eclipse and Notepad++ where you didn't have the tooling, online resources or automatic fixes that these tools come with today.

So yeah maybe my experience doesn't see the need for this, which is exactly the issue here. Who is making the majority of the apps we use today? Who is paying to use tools that speed up development? Engineers like myself.

[cvwright]

The problem with this perspective is that iOS is where the money is. Almost ALL the money.

So if western B2C companies have to pick just one platform to start with, it will almost always be iOS. This lets them then port that initial app to Android once they are established with western audiences, so they can also serve the (much larger, much less profitable) rest of the world.

[mad_tortoise]

My problem with this is that it show's almost no forethought by those creating the app. If your goal is first an iOS app that you will develop into an Android app. Then why go this route? It doesn't solve any of the bigger cross platform problems, is a far less mature ecosystem, and will seemingly only paper over the basic needs - but in-depth development will become an issue. But if you're only porting an "initial app" and expecting the next iteration to be either native or cross platform, then start like that rather than waste 6-12 months on transposing the code to a different language.

To me this presents as something a business person with very little knowledge of app development will be drawn to. But the long term drawbacks of this approach far outweigh the short term gains from trying to quickly port an existing iOS app to Android.

Sure there's more money in the Western app ecosystem for iOS apps, but that doesn't mean your app should inherently cater for iOS first. In fact that's a very first world and reductive approach, when there's billion's of people that don't interact in the same way.

[MrDresden]

This only applies to those applications whose role is to generate revenue directly (B2C), and in a specific market segment or region (high income and/or US/EU).

For other types of applications the need to service a wider audience can often trump this.

Think banking applications that are without any kinds of in-app purchasing or upfront cost of use.

Or state healthcare sponsored medical/health tech applications.

Or industrial applications that need to run on rugged devices.

[isodev]

> iOS is where the money is. Almost ALL* the money.

* All the money made through an app store.

For everyone and everything else, apps are utility helpers for physical goods and services paid for externally. You setup your router, the app for your door lock, the app to hold your Carrefour discount codes, the app setup your printer etc.

[abewhite]

Being able to share any parts of your business logic and UI that you want between iOS and Android versions is a huge win for companies of any size. Traditionally this has been a PITA, has added significant performance overhead and bloat (JS runtime, added garbage collector, etc depending on the framework), and on the UI side, has often given you non-native UIs. Skip solves all of these problems, and because it uses your code as-is on iOS and generates native code on Android, you can trivially and directly mix in platform-specific code wherever you need to, without any bridging.

[mad_tortoise]

Edit: I see you work for Skip, which I think you should state upfront. But I do understand your bias or blinders in assessing the tool.

I get the benefit of being able to share business logic. That's not the issue at stake here. If it was, this wouldn't be a company in the first place as there's multiple frameworks that enable this and do this better - at zero cost.

I don't believe performance issues is a relevant metric anymore, having dealt with them on RN, KMP, Flutter. Non-native UI, is also quite irrelevant these days. Perhaps if we were having this conversation 2-3 years ago I would agree with you. But with how RN/Flutter UI's are now, and the native aspect of KMP it's a non-issue.

> Skip solves all of these problems, and because it uses your code as-is on iOS and generates native code on Android, you can trivially and directly mix in platform-specific code wherever you need to, without any bridging.

I will believe it when I see it. You say "Skip solves all of these problems", when Kotlin multi-platform was essentially doing the same thing in reverse, but with far larger backing and it took years before it was production ready. It is not trivial to keep up with ever changing Android ecosystem, multiple API levels that need to be catered for, differing UX interactions, different native API's e.g databases, push notifications, permissions etc. Again you say trivial, not sure what is trivial about this.

I feel like you've either never tried cross platform work on a (large) production project? This is solving an aspect of mobile development that personally I don't see a need for. But if it's for you go for it, in my experience across languages and platforms, I would recommend against this option unless you solely only have iOS Engineers, no ability to cater for a native Android experience and hadn't thought of having an Android app before starting development. Then sure, use it. Any project I plan would be both platforms and wouldn't require this level of abstraction.

[BodyCulture]

Your criticism is very interesting, but instead of just presenting some abstract ideas of potential problems it would give much more impact to your argument to present some hard evidence that your way of thinking is better.

Can you show an example of an app that will generate more problems for developers with this approach than with other platforms?

BTW do not forget to add some possibilities to pay you for your work with such a publication, I would certainly be willing to pay for a good in-depth analysis.