
The Cost of Native Mobile App Development Is Too Damn High - prostoalex
https://hackernoon.com/the-cost-of-native-mobile-app-development-is-too-damn-high-4d258025033a
======
blizkreeg
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.

~~~
rokhayakebe
_Looking at Airbnb and Instagram ditching native_

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

~~~
FLGMwt
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).

~~~
afro88
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...](https://realm.io/news/tryswift-ryan-nystrom-refactoring-at-scale-
lessons-learned-rewriting-instagram-feed/)

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

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

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

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

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

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

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

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

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

------
fharper1961
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://flutter.io/)
[https://www.youtube.com/watch?v=Mx-
AllVZ1VY](https://www.youtube.com/watch?v=Mx-AllVZ1VY)

~~~
mambodog
React Native's ListView culls offscreen views:
[https://facebook.github.io/react-
native/docs/performance.htm...](https://facebook.github.io/react-
native/docs/performance.html#removeclippedsubviews)

~~~
fharper1961
Thanks for correcting my mistake.

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

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

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

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

~~~
hackerboos
App size:
[https://itunes.apple.com/pk/app/facebook/id284882215?mt=8](https://itunes.apple.com/pk/app/facebook/id284882215?mt=8)

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

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

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

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

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

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

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

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

~~~
dabit3
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...](https://developer.apple.com/programs/ios/information/iOS_Program_Information_4_3_15.pdf)

~~~
statictype
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)

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

~~~
htormey
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](https://appsto.re/us/P0eAgb.i)

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

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

------
xorxornop
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!

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

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

[https://getexponent.com/](https://getexponent.com/)

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

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

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

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

~~~
dabit3
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...](https://developer.apple.com/programs/ios/information/iOS_Program_Information_4_3_15.pdf)

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

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

~~~
binarynate
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://github.com/BinaryNate/nativescript-midi)

[https://www.npmjs.com/package/nativescript-
midi](https://www.npmjs.com/package/nativescript-midi)

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

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

------
msoad
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!

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

~~~
serge2k
They just moved fast and broke things.

Now they move slow with broken things.

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

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

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

