Ask HN: How different is it to make an Android app vs. an Apple app? | Hacker News Reader

Ask HN: How different is it to make an Android app vs. an Apple app?

17 pointstaurusnoises21 comments

Is there a technical reason why so many apps start out as Apple-only? I always figured it was an issue of "get it out to the most people," but as a non-dev, I'm also guessing there's a tech issue too?

View on HN

The received wisdom was that for many years it was easier to make money from Apple customers. Despite the fact that there were fewer iPhones compared to Androids the theory was that iPhone customers tended to have more money and were willing to spend to get things. The Android ecosystem was also much larger and you had to test on more phones to get confidence in the performance of your app across the customer base. So from a developer point of view, you're solving a simpler problem for more money.

In practice actually iPhone 'fragmentation' is surprisingly bad in terms of how UIs would render unexpectedly on different phones - still probably easier than Android but levels the playing field a bit more, Android market share grew and went more upmarket, cross platform frameworks improved and the whole practice has become less common.

>cross platform frameworks improved

No serious mobile application is built with a cross platform framework. It's a development strategy that relies on the product being "good enough".

Please prove me wrong. I would love to see counter-examples.

Facebook and Discord are built using React Native. Ebay is built using Flutter. These examples are easy to find on the homepages of the respective frameworks.

I agree that for the large technology companies having a team to build a native app for both platforms is worth it - you get an optimised, native feeling experience for both platforms. For smaller companies with e.g. two developers building an app as part of a larger service then the cross platform frameworks can give you a lot of bang for your buck. They're also a good starting point to get something out, and then if you wish you can begin to incrementally replace bits with native if that's beneficial.

Personally I'm also a big Flutter fan. Even leaving aside the cross platform benefits I find it a very pleasant development experience that gives very predictable results on whatever it ends up running on. I haven't yet properly used Swift UI though, which adopts a similar approach.

Minor (or major?) nitpick, but Discord on Android is a native app for performance issues encountered with React Native. On iOS, it is built with React Native.

https://blog.discord.com/using-react-native-one-year-later-9...

The latest alpha (Canary) build of Discord for Android uses React Native[0].

[0] https://www.reddit.com/r/discordapp/comments/u4kn2k/alpha_12...

This is both exciting and concerning as an Android user. Hope performance does not suffer.

React Native really only describes the UI aspect of the application. The backend code that is needed to access the native device API isn’t exactly the same, and accessing things like a camera aren’t straight forward across all devices. Although you can wrap these methods in interfaces and swap them out across devices, it usually takes an engineer with a good understanding of either android or iOS. This is the reason most people start with only Android, iOS, or Windows first, and the reason large companies have dedicated teams for each platform.

Facebook mobile is not built on React Native, pieces of Facebook functionality are. Facebook mobile is an entire spectrum of technologies including native and React Native.

Many mobile games are built on cross-platform engines (eg Unity)

I feel the reason here is more a strategic one than a technology one - at least these days. For products that rely heavily on mobile or mobile is the main platform then it makes sense to remove an extra party between you and your customers so new OS features or upstream bugs don't first need to be addressed by the React Native or Flutter teams. The fact that there's really only two platforms makes the decision process much easier. I tend to recommend this approach to clients too, if your business is all mobile - build a native app and pick whichever platform is dominant in your market first. If you're adding a mobile offering to an existing CRUDish product then it might make more sense to go cross-platform.

It's less about technical issue, more about market opportunity and what you know tech wise. There's a common idea that App Store devs make much more money than Google Play Store. The iOS app store has had much more visibility for paid apps as well.

Another way to think about it is that people spend thousands on a new iPhone, they are more likely to spend on apps. There's plenty of data to help confirm that idea such as revenue from apps in each store and even income levels.

From a personal perspective whenever I survey users about what platform they prefer to have a mobile app for with my side projects, it's like 80/20 iOS/Android. When asked if they are willing to pay, it's even more telling that Android users are more likely to not want to pay.

Speaking as someone who built a cross platform framework for a living and survived a major acquisition of that tech to a big tech company and worked in the ecosystem for many years, I believe that although Android may have more devices made and distributed in the world than iOS, it's a much harder market to make money in as a developer. As an existing business, you have to be in the market however.

Nowadays you need apps on both stores, but if you do choose one, do iOS first unless you have a background for Android. There's many cross platform frameworks that can help you do both with one codebase, but if you go native, start iOS in my opinion if you need to make money to survive.

IF a developer team his mostly iphones they will do that one first I bet. Thats how I have seen it done usually. The problem is that if most non standard use cases (like bluetooth) support are garbage in cross platform tools. So I have to make two mobile apps: one for iphone and one for android. I have an iPhone so I making that one first. If its not that popular, maybe I just dont make an android app.

Get it. Is there a general vibe in the dev world of like, "ugh, now we have to make the Android version..."

Not neccesarily? If you start with an Android app, the sentiment tends to go both ways. There's simply no good cross-platform mobile toolkits.

React Native and Flutter is fine if you want to do information app (backed by a backend for most of the work), but as soon as you want to tap into the native capabilities of the device, the difference can become too much. Those toolkits rely on being able to find a common ground between the two ecosystems, and sometimes that can be a hindrance.

Apple user spend more money, I always guessed that's the reason.

In teams I've worked on recently, it's been less of a "which is easier" and more of "what percentage of our customers would we reach".

Worldwide, Android phone significantly outnumber iPhones, but in Canada and the US, the split is pretty close to 50/50. At that point we would probably go with the platform the majority of the team is more comfortable with unless there was a specific business reason for going with a specific platform first.

I wrote down my comparison here. Hope this helps.

https://billylo.medium.com/ep-19-is-android-app-dev-easier-o...

Apple ecosystem is contained....so it's easier to just build without looking up.

but.... it's also a catch....you spend more money to develop for apple, so you need money.....hence....you bleed your customers who will 'pay more'....

trusth is.... just as many failures....

I think one reason is that there aren't that many unique Apple devices compared to unique Android devices. There are tons of different hardware combinations in Android, making it harder to create a good app, UI/UX wise.

Because Java.

Reply on news.ycombinator.com