The Cost of Native Mobile App Development Is Too Damn High | Hacker News Reader

The Cost of Native Mobile App Development Is Too Damn High

hackernoon.com

127 pointsprostoalex95 comments

I 1000th this. Native mobile dev pretty much doesn't make sense for most early stage startups anymore. I sunk in thousands in launching an MVP for my product with the help of an outsourced team, only to run into slow(er) and costlier dev cycles, maintaining 2 code bases, designing for 2 platforms, app store rejections, users not applying the latest updates, Android users recycling apps when they run out of memory, device fragmentation (on Android) issues, and an overall lack of agility in making updates to the app. If you want to iterate fast, fuhgedaboutit. Granted some of the problems I've outlined are not about the path chosen for app development, but you should be aware (and scared) of these if you're looking to build an app.

I've literally taken to replacing some tabs in the app with web views and serving light, responsive HTML5 through them.

Unless your app is a game, or you already have found product/market fit AND have a large eng team and the resources (aka $$$) at your disposal, probably makes no sense to develop native any more. Looking at Airbnb and Instagram ditching native dev too, I'm not even sure of the latter case.

I'm not sure its fair to say that they are "ditching" native dev. React native works well for some flows, but is still lacking when it comes to a lot of more complex animations, non-standard views and basically most things that make you really go "wow." Those companies are using it where appropriate, but large portions of the apps are still native.

Fair enough (pun intended). But for the majority of startups, I'd still wager they don't need those premature 'wow' effects.

I would argue that in some cases (certainly not all), a little bit of strategically placed "wow" may be vital for some startups to grow - small things that make users love a product and show others. The vast majority of users will not sympathize with the reasons a developer would choose to use something like a web view in a native app.

I was going to focus on ReactNative my the more I read about the more I realized I am better off native, at least for now. Exactly because I do a lot of animations and I am all about interaction. If your product looks bad or "dated" it's not going to connect with users, not in the aread I am focusing on. If your product is about that extra pop, then I think Native might be best.

I'm a long term native developer who's been doing react native contacting for the past 6 months. One big issue that you run into is if you need to do long running background tasks (network polling, bluetooth, music, etc) you basically need to write native code to handle it. Complex animations and non standard view's aren't that bad to implement.

Just about to implement react native app with network polling. Do you have any links/tips to share re best practices?

If you are just doing polling when your app is in the foreground, you should not have to write any native code. All of the polling can be handled in your actions.

If you need to poll in the background when the phones screen is locked, then you will need to write native code. Writing native code to do this isn't that hard (react native docs are good), it's just annoying that you will have duplicate business logic for Android/iOS.

Looking at Airbnb and Instagram ditching native

Any sources for this? I would like to read up on it.

I think the quoted might be referring to Instagram's use of React Native and Airbnb's hint of exploring it (can't determine what they do). So perhaps this is clarified as native app development for native app (as opposed to a cross-platform framework/shim).

Didn't Instagram just do a big refactor of their iOS app, and release an iOS OSS framework with their new feed code?

https://realm.io/news/tryswift-ryan-nystrom-refactoring-at-s...

I spoke to a few people at Airbnb about this. Supposedly about 10-20% of the app is React native. I really doubt that Instagram have ditched all of their Native code for React native.

The airbnb ios app is awful and getting worse. I am constantly running into inconsistent state issues. No problems on Android so far though.

We don't have much written up about yet, but 90% of our recent Trips functionality was built in RN [1] and there are some bits in this talk as well [2].

1: https://twitter.com/spikebrehm/status/799338174979842050

2: https://www.youtube.com/watch?v=npwa3ZmG9VQ

There is a huge difference between using react-native and ditching native. My observation at Airbnb is we are the former, not the later.

This is why technical cofounders that can build a native mobile MVP make sense.

I am technical, it's just that native dev is not my forte. But that's besides the point. It is less about the money, more about the huge overhead of building one.

Netflix is running React native across all devices.

Not true. Our Android and iOS apps are native. We are however looking into React Native.

Source - I'm an engineer at Netflix.

Sorry. I was under the impression after watching this video Netflix was using React across all devices. [0]

[0] https://youtu.be/eNC0mRYGWgc?t=23m50s

React is not the same as React Native... there's enough similarities to share a name. React is the base (afaik) for all web-based client interactions, which also includes a lot of TV/Webtop interfaces, but not necessarily Android and iOS.

Given the shift towards Flux and Falcore, React Native may make sense for the iOS/Android, and potentially in Windows/Ubuntu as well (speculating).

Disclaimer, I don't work there, but did go through the interview process last year, I wasn't enthusiastic about moving to California at the time.

No worries! Tracker1 is correct that all browser based UI is built using React. Other platforms may be doing their own explorations into React but I can't speak to that since those are outside of my domain of expertise. I can say that my team loves React so we're definitely looking into React Native.

Are you guys hiring? ;)

Absolutely!

https://jobs.netflix.com/

I can verify that it's an amazing place to work :)

This article could be: "All signs point to huge growth in the technology I offer consulting services for."

The table of app development costs seems very handy, except it is missing the disclaimer: your results will vary.

My biggest issue with the cost breakdown is the omission of:

"Cost of redeveloping entire app natively when a cross-platform framework limitation is hit."

This is common for non-native development.

Most often limitations can be worked around with platform specific plugins.

I'm not sure his example of Facebook's app is a good one, considering how terrible it was in design. Wasn't it essentially their JS stuff transpiled (with some extras) that turned into an 18000 class, ~100MB bloated monster of an APP? That isn't a problem with "native". That is a problem where developers fucked up the engineering.

Facebook's apps are the not the first place I would look for model example of "how things should be done" in (native) apps.

It feels like the UI is changed quite frequently, which when you combine with the bugs and various anti-patterns (out of order content, making basically any activity appear in the "globe" notification, messenger opening another app, unable to find old posts, etc, etc..), it's a super-irritating experience at all times.

What's the practical problem with Facebook's native mobile app? It's fast and reliable on my two-generations-obsolete cell phone, and as a user I don't care how they made the sausage.

I'm speaking in the context of development time and cost. Their app was very expensive to develop, but it wasn't because it was "native."

They, like most companies would, decided that getting it out to market quickly was more important than delaying a half or full year to "get the engineering right". But that's some kind of logical fallacy, because engineering doesn't mean "designing beautiful things", engineering means understanding both the theory and the practice, and making tradeoffs so that you get something that meets a variety of needs.

That's what I see technical debt as. A lot of people think "technical debt" is just bad decisions that accrue over time, but you can also get into debt by taking out a loan -- with interest. I got into debt when I bought my house. Your city probably used debt to build new schools. Governments use debt to fund, well, the whole country. Facebook took out debt to move faster. And then they had to pay it back with interest, just like my mortgage and those municipal bonds that funded the schools and the treasury notes that trade our foreign debt. Fortunately they paid it back by further developing react native, and they're still pushing.

I think the Facebook engineering team is good -- they simply wouldn't survive if they weren't, and they're doing fine. I don't think they fucked anything up. I think they were conscious of the loan they were taking out, and had a repayment plan in place. So in that sense they did the responsible thing, and took out a loan for the right reasons. It worked out well for them.

I'm very interested to see where react native goes. I think Microsoft will see an opportunity to push against Apple, because people are falling out of love with Macs and are starting to like the Surface. And if the Surface starts selling, the Phone would too... except that MS has an ecosystem problem. There aren't many developers targeting Windows Mobile, and there's not a ton of expertise there as compared to Android or iOS. By backing React Native, they can get developers onto Windows platforms faster, which means the ecosystem can keep pace with the market if they can keep showing quality hardware especially for power users and professionals. So we may see some MS+FB friendship in the near future.

Well, they (MS) have Xamarin, which is free, and targets Android, iOS, and WP. You could likely share a lot of the codebase with a UWP app also, since it's all .NET natively or supported (UWP supports other languages, eg. JS, C++ etc). It's a pretty compelling option, and works well in my experience.

I am one of those people who like Xamarin, especially now that it is open source. But needing a Mac for iOS is a pain. I understand it is hard to not work like that but it is annoying. That said, I do like Xamarin and currently work fast in it.

I have tried hybrid/cross-platfrom development route many times. It's not as rosy as it seems on paper. In terms of maturity there only 3-4 options out there and each of them have their own set of problems and gotchas.

Out the 3-4 mainstream ones, I am quite familiar with

Cordova / PhoneGap

Xamarin

The main problem that I see, is the lack of ecosystem support for both of these. For example, you want to use latest features of a third party SDK, you find out that they only have native libraries available. Then it falls on your plate to create the JS or C# wrappers for these native libraries. This calls for a specialist who has experience in writing these wrappers. There are not that many people who have experience with this. So it also ends up being expensive.

Another problem is that the "idea" / "visionary" people don't understand the limitations of the cross platform development. They keep coming up with user experience demands which don't really fit well in the cross platform sense. When you the programmer tell them that it's very time consuming to do it in the chosen technology, they refuse to understand and argue a lot citing examples from other popular apps. Most of these popular apps are from companies who are very well funded and have access to extraordinary programming talent. They undertake creation of custom components/frameworks as part of their app development. This is really not possible for small agencies / small startups.

In the end the cross platform approach always ends up making up some compromises. If the senior management of the product understands the compromises and is wiling to live with it only then it works out. Still from time to time, there are discussions about whether "right" technology was chosen when you find a limitation of the chosen approach which makes a new "groundbreaking" feature very expensive to implement.

I started coding in BASIC with a Sony MSX in the 80s, and professionally since the late 90s on all sorts of things (web, desktop, video games, etc). Mobile is BY FAR the most frustrating experience I've ever had.

This could be easily solved if HTML5 apps were first class citizens in Android and iOS like they are in Chrome OS.

Relying on third party solutions like Cordova, Crosswalk, is frustrating.

Solutions like ReactNative and NativeScript are also unsatisfying and both iOS and Android should offer a similar solution (native engine + scripting behaviour) without relying on third parties. This is common practice in the video game industry and prevents 15 or more minutes of compile times.

From what I've heard React Native doesn't yet handle lists containing many views without rendering the entire list.

I'm looking into Flutter/Dart from Google for building iOS/Android apps from the same codebase.

The SDK is still alpha so there are still rough edges, but I've created a POC app and have been able to run it on both platforms. I'm very pleased with the results so far.

https://flutter.io/ https://www.youtube.com/watch?v=Mx-AllVZ1VY

React Native's ListView culls offscreen views: https://facebook.github.io/react-native/docs/performance.htm...

Thanks for correcting my mistake.

Those numbers aren't that high... $32k for an MVP is entirely appropriate. But if I use an experimental, flavour-of-the-month technology, I can save $10k? No thanks, too risky. There is a wealth of talent and knowledge around native app development for businesses to use, good luck trying to find react-native developers (not the same as javascript/web developers).

It really depends on what you're making... and what kind of funding you have... are you paying for this on a small business loan, or even on credit cards to get started? $10k can be the difference of being able to run the servers an extra couple months, or not having an app at all.

Also, any good developer in a tangient field should be able to get up to speed quickly. There are a few issues, most "JavaScript/Web" developers aren't that good as developers or with JS to begin with. Developers from other disciplines aren't good, and often don't even try to become good with JS. And beyond any of that, few developers have sufficient UX skill to create an app as a single dev.

Of course, it really depends on your needs... I'd frankly be happy if it meant apps would render fonts at a size I can read... I'm far sighted and rarely need glasses for anything at a distance, but the few feet from my face, primarily my phone is often irritating, and FB was always the worst offender at not following the accessibility settings on my phone.

Facebook's problems != your problems.

Re 15 minute build times, Facebook iOS is 301MB! Makes me seriously wonder which is larger, FB iOS or facebook.com

Is that the code size or the app size? I'm not familiar with objective c, but that sounds unreasonable for a build time for a small app, are the not doing any sort of incremental builds?

App size: https://itunes.apple.com/pk/app/facebook/id284882215?mt=8

Just...How? Correct me if I'm wrong, but there is nothing to remotely justify an app of that size is there? This is up there with the 300MB printer driver rubbish, but you'd expect facebook engineers to be more capable.

You don't get attention for re-using an existing framework but everyone will love you for reinventing a slightly better wheel. Every team does its own thing so there are many implementations of what amount to the same concepts.

Actually I wouldn't expect that at all. These companies don't (seem to) hire engineers. They hire folks with academic CS backgrounds and put them in engineering roles, and generally they aim for younger such developers.

This is like hiring undergrad and fresh graduate mathematicians to build a space shuttle. It's not a matter of competence or intelligence. It's a matter of ego and inexperience (engineering is an easily learned skill; all that matters is selecting the right data structures and algorithms from my CS [1-4]xx classes, etc.).

Get a hold of the .ipa (?) file and have a look - I wonder how much is custom frameworks and other stuff. For my uses, m.facebook.com in Chrome is adequate. I just wish they didn't force me to use Messenger for chat.

I encourage everyone to believe this article; it leaves room for those of us who care deeply about the user experience (and the user's battery life).

I think it really depends on the application... A simple crud app may as well go for biggest bang/buck, as opposed to full native on multiple platforms.

Also, the last time I really tracked battery usage, it was the more intrusive social apps (all native) that ate the most battery.. and the screen uses more than any app.

For a simple crud app, does it need to be an app at all?

Absolutely not, but thankfully for me many clients demand it even if I advise against it.

Probably not, but you'd be surprised how many will prefer an app over the website, even if it's exactly the same interface.

I was under the impression that React Native apps were pretty close to native on both counts. Is that not true?

This means that you can push updates, features, and bug fixes instantly to your users, bypassing the labor of bundling, submitting, and having your app accepted to the App and Google play store

This is the real killer feature to me but it also seems like the sort of thing Apple will quickly shut down if it gets popular. Even though allowing remote JavaScript to be downloaded and run is explicitly allowed right now I feel like they were thinking about web pages and not native js code.

Are there apps right now that push out new features with JavaScript bypassing the App Store? Is Apple ok with this?

By shutting it down, Apple would make a huge mistake and literally walk back into the past. I can't imagine that happening. As it is, it's becoming difficult for app developers to get noticed and grow and as chat-based interfaces become more powerful, I in fact don't see a bright future for "downloaded" apps - the way installed software was upended by the web for most use cases.

From my point of view web versions of applications generally offer a worse experience compared to the native desktop versions that have to be installed.

I suppose the closer the browser gets to just being an operating system running in a pseudo-virtual-machine the less crappy the non-desktop-experience will become. On the other hand we're already approaching absurd levels of JS required as a download for some web sites. I could easily envision, in some dystopian future, a scenario where hundreds of MB (compressed) of JavaScript or more are required for an especially loathesome resource eating web "app".

Is it really better to have to download 10s or 100s of MB of JS every time (yes, yes, caching helps) you want to use an application instead of a one-time install of a couple of GB?

Edit for clarity: I'm responding to the part of your comment about web apps "eating" the install-based model of desktop apps, specifically, not to the broader topic of mobile apps (as clearly there's a difference in the model, packaging of applications, etc. there).

Except it's not a one time download - every damn update has you downloading the whole mobile app again, which is a devastating multiplier.

JS isn't nearly as offensive as those exaggerated numbers by comparison

Not a fair comparison. Those updates can happen in the background (when in another app, when you're asleep, etc.), and most apps will continue to operate without being updated.

Nothing more irritating then being forced to update / download content when you need to go and quickly do something in an app.

the few apps I care about (banking, for example), always force a full update, and generally right when I need to use the app. Old version doesn't work anymore, and I have to reinstall a new one. And... I've never seen mobile apps update in the background or while I'm asleep. I have to explicitly authorize (generally with the clunky password input box) the new update. Every. Single. Time.

I don't seem to have this trouble. My apps update maybe once a week on average. The notifications always seem to pop up over night while I sleep. When I wake up I simply accept the updates and make my breakfast or shower while the updates occur. I haven't spent time waiting on an update when I needed the app right then in so long I can't remember the last time it was.

With JS they have to download a new version too (now that we're compiling javascript), and not in the background but when they want to run the app.

> I suppose the closer the browser gets to just being an operating system running in a pseudo-virtual-machine the less crappy the non-desktop-experience will become.

No- the crappier your computing experience will become, which is already happening.

Well in general I'd agree. I'm unconvinced that having to download tons of javascript regularly because everything is in-browser (and provides a generally inferior experience, in my view) is a superior model to having to download once and update occasionally a desktop/mobile install.

However there is significant effort being made in making these browsers better, so perhaps something will improve.

> This is the real killer feature to me but it also seems like the sort of thing Apple will quickly shut down if it gets popular.

It also means they can add, change and remove features whenever they want, that isn't consumer friendly.

It is popular, and has been used by many apps for years at this point (Ionic supports it as part of the framework). The key thing is not to change the app radically with an update that bypasses the App store. Of course Apple will never say anything since they like to leave their ToS vague enough where they can do whatever they like.

They already shut it down ... afaik this has always been forbidden by App Store guidelines

I have a good relationship with the Microsoft team behind Code Push. After speaking with them about this exact topic multiple times, they are sure that not only are JavaScript updates allowed, but they will continue to be allowed, as it is stated in the Apple Developer Agreement [1].

There is also a growing ecosystem of open source projects and companies offering services that offer and facilitate over the air updates.

[1] https://developer.apple.com/programs/ios/information/iOS_Pro...

Thanks for clarifying. I'm guessing Microsoft has directly talked to Apple about this before spending time building their infrastructure.

I'm thinking many people at Apple are happy to encourage OTA updates and even side loading apps. The original guidelines were dictated by you-know-who and so that's what they rolled with, but are willing to look the other way now (even though this type of code push directly violates the spirit of the App Store as a closed and controlled environment)

When I investigated last year, the TOS had a pretty clear paragraph that only allowed JS that was run by the Safari Browser to be downloaded. It specifically disallowed web views.

However, about 2 months ago, the mobile team at my current workplace announced a new product built with several React Native components. They specifically mentioned that they had gotten clearance from Apple on downloading JS bundle updates outside of full app releases. I haven't personally reviewed the TOS to see if there is a change to the language, YMMV, IANAL, etc.

In theory so is A/B testing yet pretty much every major app (Facebook/Pinterest/Airbnb/Google) has been doing it for years. It's very unlikely you would get in trouble unless you abuse it terribly. Also the app store changed its rules recently to allow over the air updating with JS.

I find the example where 90.000 must be spent for just one native app or 100.000 for both platforms with React very amusing yet I'm afraid somewhere some pointy haired boss is assuming it's really true.

If you can do both for 150.000 and get something that works perfectly on both you're lucky.

I literally just did this for one of my clients (react native app, Android/iOS). The figures he sites are within the right ballpark. You can check the app out here: https://appsto.re/us/P0eAgb.i

Any particular reason to block people from outside the US from downloading it?

It's a medical marijuana delivery service which currently only operates in California.

No love for Xamarin?

Being able to target Android/iOS[/WP, relevancy aside] (and UWP in part, with a shared logic codebase), is pretty nice. I rather suspect it will get full UWP support in due course, also.

In my experience, it's fast at runtime, very easy to debug, very customisable UX, easy to code for in a pleasant, highly productive language with amazing tooling (best in VS, but Xamarin Studio on Mac or Linux isn't bad, especially compared to the competition), allows you to share often the vast majority of the codebase across platforms, has very good, but optional, Azure integrations should you want them - and free. Pretty compelling offering, I'd have thought!

God no, Xamarin is the perfect example of something being 'too good to be true'. :)

Also check out Exponent (YC S16), which is built on top of React Native.

https://getexponent.com/

I still have to use Android native I have a lot of c++ parts that require jni. But I'm doing a lot of heavy digital signal processing. Not every app is a database crud app. I don't support iOS however my product is android only.

What is your project? DSP sounds rather interesting for a phone app.

I'm still not convinced that React Native is a great solution for anything beyond the most simple apps.

The iOS/Android SDKs are already complex enough to deal with when you're writing native apps. When you introduce a third-party framework that wraps the native SDKs, you now have to worry about bugs in that framework, plus bugs in the bindings to the system SDKs, on top of bugs in the system SDKs themselves. (Of which anyone experienced in iOS/Android development knows there are already plenty.)

React is very trendy right now and I think that's why React Native is getting a lot of attention, but I think there's a good reason similar cross-platform frameworks like Xamarin and Titanium have only reached niche status, and most mobile-first apps are still developed natively.

Firstly, this page is so well built for mobile I couldn't comment...

Secondly

> This means that you can push updates, features, and bug fixes instantly to your users, bypassing the labor of bundling, submitting, and having your app accepted to the App and Google play stores

... and violate the Ts&Cs of both!?!?!

Author here, Apple actually allows performing over-the-air updates of JavaScript and assets [1].

[1] https://developer.apple.com/programs/ios/information/iOS_Pro...

Also, how is this any different from A/B testing which has been industry standard for a long time. Unless you really abuse pushing over the air you are not going to get in trouble. Also, as the author notes, over the air updates for JS are allowed by the apple app store Ts&C's.

Our first project was Phonegap which then became Cordova. However, after running into many issues including the fact that we did not like someone could right-clicking and save our html/javascrip code, we transitioned to native apps. We have and continue to work in Objective C, Android Java and more recently Swift.

Ultimately, the problem-solution should determine which platform is used including what you use for backend programming. I find that it is equally difficult to find good qualified people in React and React Native as it is with Objective C, Android Java or Swift. So it is 6 to 1/2 doz.

I was waiting for my NativeScript app to build when I came across this article!

I'm a web developer by day (Ember / Node) and believe that the web platform will ultimately come out on top due to its inherent cross-platform support, "install-less" use, and open design. For the time being, though, browsers still lack support for many hardware APIs, which still make native apps necessary for many interesting use cases.

The use cases I'm tackling with my current app require MIDI and Bluetooth Low Energy support. There is interesting work underway to draft web standards for such APIs (there is a working draft for web MIDI that is implemented in Chrome and an unofficial web bluetooth API that can be turned on in Chrome), but general support is far off.

Luckily, I learned about NativeScript on the Hanselminutes podcast and started working with it in September. Overall, I have been really impressed with the completeness and functionality of the NativeScript runtime, its CLI, and the design for code sharing. Unlike React Native, NativeScript aims to allow you to share both your application and UI code across iOS and Android. You write your application in JavaScript (I use ES 6 with the babel plugin), your UI in XAML-like XML, and your styles in a subset of CSS.

For the application code, NativeScript provides common APIs that share the same interface on iOS and Android. There are still gaps in APIs that have been implemented out-of-the-box, but one of NativeScript's biggest strengths is that you can also access the native OS's frameworks within the JavaScript runtime, enabling developers to create plugins with a common interface for the APIs they need. For example, I'm developing a MIDI plugin to provide a common interface for MIDI on iOS and Android, which I'll open-source on GitHub / NPM once it's mature. The native frameworks are converted to JavaScript at compile time, so whatever native code you include (e.g. Objective-C classes, C libraries) are usable from within your app's JavaScript.

In my case, my app communicates with an embedded Bluetooth SoC in a product I'm developing, and I'm able to reuse C libraries I originally wrote for the embedded platform in my mobile apps. So, I'm sharing my mobile app code across and iOS and Android (huge win) and sharing some core messaging code across iOS, Android, and my embedded platform (bonus win).

Since my MIDI plugin is ready to use for iOS, I decided to go ahead and put it up on GitHub.

https://github.com/BinaryNate/nativescript-midi

https://www.npmjs.com/package/nativescript-midi

My experience - I was a bit overwhelmed and decided to outsource one of my project. A company from India contacted me, said they have a branch here in NJ and have many clients in USA, just finished a mobile app for Walgreens.

My requirement was simple. I needed an app which will allow the end user to enter their zip code and it will fetch a list of our retailers within x miles radius. You highlight the store and get the address and phone number. That's it!

The first phone call turned to two, three, four...being introduced to several team members/project managers etc. I had to provid detail requirements.

They storyboard the shit out of this and came back with 30k for a native iOS app. No shit!

After back and forth they offered to do it for 15k.

It took one evening and I did it in hybrid for multiple OS.

EDIT - I kept the quote on my desk. Showed the boss the following week. He said, that's why you make the big bucks! Earn your keep.

Pretty much what you should expect from going 3rd party.

3rd party companies are going to make more money the larger, and more complicated the project. If there's little chance of return work, then they also make more money the buggier the project.

Their incentives are not your incentives.

From what I heard React Native didn't scale for Messenger team at Facebook and they put a lot of custom ObjC code in the codebase to make things work. Games for examples uses little React Native.

Abstraction kills!

LoL if Facebook's app takes 15 minutes to compile a minor change, it is because facebook has some n00bs writing that shit.

They just moved fast and broke things.

Now they move slow with broken things.

"It has become increasingly difficult for new startups without substantial funding to create native apps, MVPs and prototypes."

yeah this is true, but it's not a relevant priority to google or apple.

This is why chat bots are so much more useful for applications they are appropriate for. No more high app dev costs, UI development, long product release cycles. Just design your interactions and code the bot. I think it's the future.

Chat bots are great for some niche purposes but they have a horrible UX for the vast majority of use cases. It takes a lot longer to type a message for a bot then to just tap a few buttons in a native mobile app.

Reply on news.ycombinator.com