Hacker News Reader

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.

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.

> 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?

I can see a simple reason for solely targeting the iOS user base, wherever one comes from: on average they earn more and spend more, making them better targets for both advertising and in-app purchases business models.

Apple’s AppStore represents 65% of global app stores consumer spend, and ~7% of iOS users spend some amount of money on apps, while on Android it’s ~4.5%.

On top of that, the hardware is much less diverse, making it easier have a consistent experience across devices. I still remember a client building an internal bar-code scanning app for their warehouse, then complain it didn’t work well enough, only to realise they had equipped their staff with the cheapest crap they could find, which had a terrible camera.

Back on topic, perhaps yhis kind of tool can be useful for teams who didn’t intend to or couldn’t afford to invest any effort into making an Android app.

> On top of that, the hardware is much less diverse, making it easier have a consistent experience across device

Which is why iOS is usually not the platform you need to worry about when doing cross platform projects. So it doesn't feel like a benefit to start on the least diverse platform and then move on from there.

> Back on topic, perhaps yhis kind of tool can be useful for teams who didn’t intend to or couldn’t afford to invest any effort into making an Android app.

But they were however able to invest in both iOS developers, the required hardware and this tool?

> So it doesn't feel like a benefit to start on the least diverse platform and then move on from there.

On the contrary. What are you trying to validate? That enough people are interested in your product. Anything that gets in the way of that is just another distraction, and there already will be more than enough of those.

> But they were however able to invest in both iOS developers, the required hardware and this tool?

Developer cost is the same. The difference in hardware costs, if there is any, is negligible.

The tool? It starts quite literally at 0$, and the first paid tier is 29$ / month.

There are two cases where I can see how it would make sense to focus on Android.

First, the WhatsApp example: you are making an app that, by its very nature, entirely relies on massive network effects, and somehow can afford to focus on growth without monetising.

Second, a product that targets people with average to low incomes.

Other than that, if you have to pick between the two, I don’t see the point in starting with Android.

This is such an ignorant First World perspective - for reasons I've stated in other comments. It's mind-boggling there are people like yourself who see's the world in such a narrow vision. As if the Third World doesn't exist and people who develop apps are only in the First World.

Really funny, that you probably consider yourself highly educated, and yet have zero ability to see why iOS is actually not the primary choice for engineers in the global south. Your two cases are beyond laughable.

I'm really sorry I'm being rude, but I highly doubt you have ever built a mobile app yourself if these are your hot takes.

I wanna expand by saying that is not even a full First-World perspective, but purely an US one.

In Europe iOS has a big market share, but Android is still the most used.

I’m not from the US.

And while Android has the largest market share in Europe, it still doesn’t change the fact that the iOS app store captures most of the global app store revenue.

Including in Europe.

Again, it exists.

It’s not where the advertising money is.

It’s not where most in-app purchases income can be found.

Don’t believe me? Have a look at Meta’s ARPU on a per country basis. Over $50 in the US, around 15$ in Europe, $5 in Asia-Pacific, less than $5 in the rest of the world.

Don’t like those numbers? Look at Genshin Impact’s.

Don’t like those numbers? Look at how much people spend on the AppStore vs the Play Store. The AppStore represents 66% of global app stores revenue, and 76% of global app stores subscriptions revenue.

Sure, since Meta and Google don’t operate there, those numbers aren’t accounting for a big factor: China.

Now, if you’re building Grab in Indonesia, sure, Android makes perfect sense as a first choice.

Making a utility or marketplace app for a specific country or region? Sure, adapt to your target. You’d have to be a fool not to.

We come back to "targeting people with average to low income". Because wether we like it or not, that’s most of the world compared to Switzerland, the US, Japan, Australia, and the like [0].

You can be rude all you like, it won’t change the numbers.

[0]: https://datatopics.worldbank.org/world-development-indicator...

> 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.

Seems absurd to include Kotlin Multiplatform with Flutter and RN, given KMM is far less user-friendly.

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.

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.

> 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

That's exactly what it means. When I was at Twitter, the Android app generated 1/10th the revenue of iOS. If you care about building a business that generates revenue, you should definitely cater to iOS first.

> If you care about building a business that generates revenue

You missed the end of that sentence "... in the first world". The ignorance or arrogance to assume all businesses that are started are aiming for first world markets. You think entrepreneurs in Africa, South and Central America, Asia are all aiming to expand into Europe and the US? That Third World business problems don't exist and solely cater for Third World needs?

It never fails to amaze me at the absolute arrogance of these assumptions, as if the Global South isn't relevant in technology or entrepreneurship. Truly astounding.

> 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.

Nonsense. Google Play revenue 2023 34.30 billion. Additionally, Google Play isn't available in China, unlike the Apple App Store so if you're going to compare both stores keep that in mind because it isn't an apples-to-apples comparison.

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.

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.

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.

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.