Hacker News Reader

It depends on what your goals are.

If you are looking to develop for iOS (or any single environment) only, then all the points you make are great, and you should absolutely stick to native development for that environment.

However, if you are looking to target multiple platforms (and by that I don't just mean mobile, but potentially also web, desktop, and more), then some of these frameworks start looking a lot more interesting.

React Native has split the UI from the rendering, and as such now has render targets for much more than just iOS and Android.

And while you can't share 100% of your code, you can develop a shared component library that can all feed into various native shells as needed. That shell can handle your environment-specific bindings and integrations, while your shared components provide your application's UI and interactions.

Of course it all depends on what you are building, and not all apps would be a fit for this approach.

The advantage is that you can access ~100% of the mobile market with a single codebase for about 10% extra work compared to native on a single platform.

Performance is roughly the same and you have access to most of the platform features that most apps need.

That's the obvious value proposition but There's a reason why sporks did not make spoons and forks obsolete.

I messed around with a few cross platform tools a bit and my impression is that if you want to make something that is better than a WebApp you actually have to learn a lot more tools and frameworks and everything feels like falling apart and you are depended on multiple vendors to upkeep the tooling.

The moment you say that your app is more than an UI to access a database, native on multiple platforms is actually easier.

I like that analogy!

I work on React Native projects for a living and what you're saying is true. You need to use both Xcode with ObjC/Swift and Android Studio with Java to get the most out of React Native. That comes with the additional complexity of also needing to learn how Xcode builds projects and how Gradle works.

That's a lot of extra complexity, but it's also no less than if you had built two native apps. You're now just expecting a single team to manage it.

My background is in "real" native development (both Android and iOS) so I get on fairly well with this, however, for people coming to React Native from the web side of things, it's a lot to take in.

Overall, I still recommend to 90% of my clients that React Native is a good way to go if they have limited time and budget. For larger companies, they might have the budget to build and maintain two apps.

Also, most apps really are just UIs on top of a REST API. And even if you do want to make something more custom, you can always create a native component or module yourself for each platform and wrap it to use it with the rest of your React Native app. That way the "boring bits" like the account management, data handling, etc can all still be shared.

It's a trade off, but just about works out for me.

10%? Try at least 50%. If you wanna do anything complicated you have to drop down to native, which is made more confusing because of the layers of abstraction.

RN, never again.

Would you mind sharing more about your experience? I'm curious what you were trying to build that was too much for RN.

At my work, my team is pioneering React Native development so I've got a couple of thoughts.

The main benefits for us come down to the fact that we have a large existing JS web application that would take a lot of energy to port to both native platforms (we know from experience, we tried it before). Using React Native, we can share a significant amount of the data and controller layers between web and native. This also means that when a feature gets written for the web, most of the work is already done on mobile (if it was written correctly).

The other key difference is the sheer numbers of each different type of devs we have. At work we have ~400 JS devs and ~30 each of iOS and Android devs. It's just not reasonable to expect the native engineers to be able to keep up. Exploring React Native lets us distribute the load of app development off of the native engineers and put it into some of the web developers. Arguably, an alternate solution would have been to just hire more native devs and I gave that suggestion to management, but that wasn't the direction they wanted to take.

I'm curious what this means:

"...my team is pioneering React Native development..."

React Native has been around for 5 or so years.

but GP's team has just recently started using it

Presumably pioneering it for their specific organisation.

Ah. I've never heard it put like that.

React Native Web (https://github.com/necolas/react-native-web) is a nice solution for better cross-compatibility between React Native and React DOM.

React DOM is very coupled with DOM elements, so React Native Web abstracts away web-specific things, so that code is more sharable.

I would imagine that on the Android side of things are also not that different.

The simple fact that there even _is_ an iOS side and an Android side is a large part of what makes cross-platform development appealing.

>but I think it's a fair question and I would like to know if I am missing out on something.

You asked why you would want to go cross-platform, and then listed a bunch of things you like about iOS development.

The fact that you aren't even sure what the Android tooling looks like answers your question, doesn't it?

I haven't asked why I would want a cross platform development. I asked how it looks compared to developing natively on the platforms you want to support.

I know very well why I would want cross platform development, it doesn't take a genius to figure it out.

The benefit is simple, write once run it everywhere. Oh wait, is that trademarked by Java? Or is their slogan Write Once, Debug Everywhere?

Cross platform is the obvious one. I think react native is "good enough" in app quality and tooling. I agree with most of your points. Developing a iOS only app is smoother sailing. The 10-50% more effort it takes to make a good RN app can easily be offset by a) getting 2+ plattforms b) if you have >10-50% more experience with JS and factor that into dev time/quality. The downsides and cross platform are covered, here‘s some other benefits:

- if you think swiftUI is better than AppKit you can use a mature framework in the same style and could have been doing so for years

- live feedback: SwiftUI previews and fast recompiles are garbage compared to React Fast Refresh which instantly updates the running app, on device, even preserving UI state half the time

- you can update the app outside of the app store, it may be against the rules or not but people do it all the time

- there are more medium quality but ready to go UI components out there. I was pretty shocked by that the last time I did iOS dev.

- Swift is a good language but Typescript is way more chill while still being a pretty good language

- personal opinion: simple animations in react native are not exactly perfect but coding custom CoreAnimation is way harder (for me)

- going from a random design that does not take iOS UI conventions or guidelines into account to an app that looks exactly the same is faster/easier. Is that good? Idk but it‘s something agencies need to do all the time.

> I would imagine that on the Android side of things are also not that different.

You would indeed imagine that, but the reality is less rosy.

1) Android is stuck on an off-brand Java stack that makes desktop Java seem pleasant by comparison. They are finally starting to make headway on replacing this with Kotlin, but most shops are still heavily invested in Java.

2) Android's UI framework is a weird hybrid of legacy and modern controls, and it only fairly recently that it has been capable of accomplishing things like a long scrolling list without memory/performance headaches. Before that everyone had to use 3rd party controls for complex or performance critical apps.

4) A lot of time spent setting up toolchains, SDKs, etc. God forbid your project incorporates C++ dependencies.

6) Google may provide Android itself, but each chip vendor then layers on their own special sauce, and finally each handset vendor layers on ever more special sauce. Add to that the historically abysmal adoption rate of new versions of android (and many vendors not providing upgraded OS versions for their older hardware), and the odds of being able to use a newly-released Google feaure/API are... not good.

As other people say, something like 10% more effort to reach 2 platforms rather than a single one.

But _also_ (and that's no small deal), these cross platform framework often benefit from a huge skill transferability from web development, eg React Native or Vue Native. This is a massive deal, it means you can get a web dev to be productive on a mobile app pretty much immediately (and potentially you use the same technology as for your web app, which itself is also a big deal)

In theory just just write code once and have the app ran on both platforms. In practice it's much more complicated, and whenever you need to do more than the framework offers your situation is much more complicated than in the case of native development. Also some features are implemented in different ways on both platforms and you need to get into details anyway. So being familiar with native APIs is a great advantage even if you use the cross-platform approach.

Depending on what the app does, developing a single native app is probably faster, more performant and easier than going with something like Xamarin, React Native, or a browser-based application wrapped in a native app.

That said, browser based apps make a lot of sense when your app is client-server application and don't need a lot of device-level functionality. This is especially true if your app needs to be a web app, mobile app and desktop app.

Swift has the slowest compiler I have ever had the misfortune of using. The dev iteration cycle was unbearable for me in a Swift project the I inherited.

SwiftUI and Previews sort-of address this now but it's not really ready yet, Swift compiler is still slow as molasses though and SwiftUI itself seems to bring the compiler to it's knees sometimes (on a brand new M1 Mini). It will flat out stop type checking anything that it deems to complex so you end changing code to appeal the compiler sometimes.

I like not having to learn Swift or dust off my 15-years-ago Java.

I can build stuff the same way on a Thursday for mobile that I do on a Tuesday for web.

> 5) Despite its bugs, Xcode is a good IDE that natively understand all the tooling I use. Autocomplete might break down sometimes but it can handle project creation, asset management, project configurations and the distribution.

This seems like you have very low standards for what is good.

Please educate me, what is good? What I am missing out on?

I'm no stranger to Web tech, including JS on the browser and on the server side. It's hell compared to native App development using the native technologies.

I mean, it's so bad that the tutorials explaining the project setup phase can be hours long to follow. Scripts running in the background just to keep you in check and let you write more readable code that is no where as good as Swift(linter, transcompilers, packers oh god >:( ).

When Xcode misbehaves, I would clean the build folder or restart it and everything is back to normal.

It has been a few years since I did something for the web but please let me know if you have a magical IDE or a script or something that lets you do work on you actual code with no janitorial work. Did JS world become considerably better in the last years? Did npm swamp dried out?

> Please educate me, what is good? What I am missing out on?

For me, it's that you're talking about the flaws which means they're considerable.

Considerable? I don’t know, every few days I would need to restart Xcode. No big deal, really. It’s two clicks to close the app, one to launch it again but it’s annoying nevertheless.

> Considerable? I don’t know, every few days I would need to restart Xcode. No big deal, really. It’s two clicks to close the app, one to launch it again but it’s annoying nevertheless.

You literally considered it while writing your list. Therefore literally considerable.

>I'm no stranger to Web tech, including JS on the browser and on the server side. It's hell compared to native App development using the native technologies.

As a front-end developer, it's clear to me that you only think that because you are familiar with it, same for me with js - all you need to start developing is npx create-react-app appname or npx create-next-app appname. I toyed around with react native too, and expo is godsend. On the other hand when I tried to use swift/xcode I quickly discovered that official docs are just trash for people unfamiliar with it and community is so much smaller (I was only looking at swiftui FWIW). You have to configure things like dependencies with xcode ui while in js it's all code. Needless to say I didn't go through with it and will go react native next time without a second thought.

> What are the trade offs/Adventages to use cross platform tools for app development in 2021?

I use Xamarin for some projects and it's serviceable. Xamarin Forms is a decent toolkit for cross platform internal business apps. Personally I enjoy native iOS dev quite a bit more than cross-platform Xamarin dev, but depending on your use-case, Xamarin might be a better idea than writing separate native iOS and Android apps. Again, I believe for internal business apps that needs to be multi-platform and don't have to look very beautiful, in those cases Xamarin is an excellent choice.

So with that out of the way I want to compare each of your points with the Xamarin situation, from my point of view.

> 1) Swift is very pleasant to use and it is fast.

C# is very pleasant to use as well. It's quite modern and feature wise is pretty close with Swift. On iOS it's probably a little bit slower, but still good enough for most use-cases. I prefer Swift over C#, but C# is almost as nice to use in my opinion.

>2) The UI libraries that I need to learn: UIKit and SwiftUI. SwiftUI is also very pleasant to use and it is getting there.

UIKit and SwiftUI are available for Xamarin, however when developing with Xamarin Forms you will likely try to avoid using these libraries, since Xamarin Forms is meant to cover both iOS and Android UIs.

>3) No hoops to jump for integrating API that makes an App do things that WebApp cannot do.

Again, pretty much all native APIs are available from C# in Xamarin.

>4) Work environment setup is very easy, no scripts to run no tooling that breaks down. It's as simple as creating an new Word document and start doing actual work, not janitorial tasks.

Generally the same for Xamarin, though I guess there's some extra layer of tooling (from what I understand Xamarin translates the C# code to native code, probably Objective-C, maybe Swift).

>5) Despite its bugs, Xcode is a good IDE that natively understand all the tooling I use. Autocomplete might break down sometimes but it can handle project creation, asset management, project configurations and the distribution.

Xcode is leagues above Xamarin Studio. My main issue with Xamarin Studio is that the app just becomes dog-slow after some time. Interaction between Xamarin Studio and iOS Simulator is sometimes also a bit finicky.

>6) The only vendor that I rely on is Apple, as soon as they make something interesting it is available to me. The latest API is there right away.

In Xamarin usually new APIs are available pretty much as soon as Apple releases a new SDK. From what I understand Xamarin uses some automated tooling to generate the C# SDK based on Apple's header. Same stuff you can use to wrap third party libraries in a C# project (Objective Sharpie [0]). Objective Sharpie isn't trivial to use, but quite powerful.

>7) The apps look in place by default, you actually have to work to make UI unconventional and weird.

Xamarin uses the native UI components, regardless if you use Xamarin iOS, Xamarin Android or Xamarin Forms. However, Xamarin Forms is meant to encompass both iOS and Android and therefore is a bit less flexible.

---

[0]: https://docs.microsoft.com/en-us/xamarin/cross-platform/maci...