
Ask HN: App shops all telling me frameworks not worthwhile; only use native code - tempestn
I&#x27;ve been shopping around to outsource the initial development of iOS and Android apps for AutoTempest.com to a dedicated app development shop, since we don&#x27;t have any mobile app experience in house.  Haven&#x27;t decided whether to go that route yet, but wanted to get an idea of the process and costs.  I&#x27;ve been surprised to find that every shop I discuss with is adamant that straight native code (Swift for iOS and Java for Android) is the only way to go.  Opinions range from, &quot;Hybrid frameworks are useless, and will give you a noticeably inferior app,&quot; to the slightly less extreme, &quot;You might save a bit of time using a hybrid framework initially, but you&#x27;ll pay for it over time as you have difficulty adapting to changes in the platforms and adding features.&quot;<p>Coming from a web develop background, this obviously sounds a bit backwards to me.  But all of the teams I&#x27;ve talked to have great portfolios, and have build beautiful apps for major companies, so I have to think they have some idea what they&#x27;re doing.  Is it possible they <i>all</i> have this position just because of inertia?  I could see there being significant tradeoffs with a hybrid framework like PhoneGap, but what about something like React Native that (at least, as far as I understand) allows you to use native code wherever necessary?  It seems like that should save time, especially if 1) you&#x27;re developing for iOS and Android, and&#x2F;or 2) you already have a web app that uses React.  Or do they know what they&#x27;re talking about, and even RN would only be good for a quick &amp; dirty throwaway app?
======
brudgers
Consider the economics of the companies who build web apps.

1\. They have a process for producing quality work.

2\. Changing that process entails learning a new process and the risk of
producing work of lower quality.

3\. The value the firms provide is in the quality of the apps.

It seems that your argument is that using a framework should reduce the effort
a firm expends on producing an app and there is an implicit assumption that
that reduction in effort should be manifested as a lower cost to your company
rather than higher profits for the firm or higher quality in the app. That may
indicate that your company is not a good fit for the services of the firms you
have talked.

Nothing wrong with that, it's just market segmentation. Might even be a good
thing since it avoids misaligned business interests. I mean if your company is
a profitable ongoing concern without an app, then a bells and whistles app
probably isn't critcal to success and a simple wrapper on a web app might be a
reasonable first pass at implementing 'mobile app as a feature' because it is
the simplest thing that might work.

It doesn't have to be rolled out multi-platform. It doesn't have to be rolled
out to everyone right away. It does not have to be all grown up to be shown to
committed users for feedback. Later on when there's a good 0.87, it might make
sense to hire a consultant for the 1.0.

Good luck.

~~~
tempestn
> Nothing wrong with that, it's just market segmentation. Might even be a good
> thing since it avoids misaligned business interests. I mean if your company
> is a profitable ongoing concern without an app, then a bells and whistles
> app probably isn't critcal to success and a simple wrapper on a web app
> might be a reasonable first pass at implementing 'mobile app as a feature'
> because it is the simplest thing that might work.

Yes, these are the lines we're thinking along currently. I just wanted some
feedback to make sure I'm not missing something about the hybrid option, that
perhaps it truly is far worse that I had come to understand. But from the
responses I've received here and elsewhere, and my own research, it really
does seem like a logical approach, at the very least for an MVP.

------
rkho
I primarily do web dev work and I've been diving deep into React Native
recently and have worked with Ionic for a little bit. What I find with these
hybrid frameworks is that they aren't perfect.

I _love_ React Native. I think it's an incredible piece of technology and the
level of accessibility and empowerment it gives web developers to venture into
the realm of mobile development is a great thing. But at the same time, there
are so many things that React Native cannot take advantage of -- at least, not
at the Facebook-developed level (remember, Facebook's RN team is going to
focus in on the parts of the framework that they can get the most value out of
internally).

You're going to miss a lot of things that you would normally take for granted
in real native iOS and Android development such as a Camera module (yes, I
know!) and OpenGL. There are third party libraries that support these things,
but your tradeoff here is that you are going to either become dependent on the
maintainers' ability to fix bugs and introduce new features or (if your app
becomes the biggest consumer of those libraries) you will become the lead
maintainer.

RN is still _great_ for letting web developers add components to an existing
Swift/Obj-C/Java codebase and I really enjoy using it. However, I think the
maintenance and dependency costs of building a larger-scale RN-first app might
not be the best idea

Regarding Ionic/Phonegap/Other "Write once, run anywhere" frameworks: I feel
this is a large UX tradeoff and would never make it. Things don't feel smooth
when emulated. I would never use one of these types of frameworks for
production purposes.

~~~
tempestn
Thank you, this is exactly the kind of insight I was hoping for. My
understanding is that RN allows you to fall back to native code wherever
necessary. Is that not as easy in practice as in theory? It just seems like at
worst it would allow you to share many parts of your application between iOS
and Android, as well as possibly your web app, and then anything else could be
built natively as necessary. As someone with no experience using this tech,
that seems like it would simplify and save time, both in initial development
and future revisions, but avoiding duplication between code bases. I can't
help wondering if these teams tried older hybrid app frameworks like PhoneGap,
found them lacking, and have written off RN as being basically the same thing,
while it's actually considerably more powerful. It's also possible that adding
that layer adds more complexity than I'm accounting for, and really isn't
worth it for the duplication saved.

~~~
rkho
I actually haven't used RN with the intention of falling back into native code
before. I was working on contributing an RN-built component as a CocoaPod
dependency into an existing Obj-C code base but that project ended up not
getting very far for reasons beyond my control. Before it was scrapped, we
were exploring performance issues in loading up RN in each individual
component.

------
MrQuincle
We're using React Native as well, but we decided to have parts of our app in
Java/Swift:

\+ Third parties should be integrating part of our core technology in their
app. I can't force them to use a framework.

\+ We're using Bluetooth Low Energy and need to be as close to that radio as
possible.

\+ The implementation of BLE differs too much from iOS to Android to make one
library a good idea.

Apart from that if I would run an app shop, I would write dedicated for each
platform.

\+ More hours.

\+ More experienced personnel.

\+ More stable than frameworks.

~~~
tempestn
As someone buying _from_ an app shop, your second and third points would be a
plus for us as well, whereas the first would obviously be a minus. Having some
of the app built in a framework would probably be easier for a team of web
developers to take over too, although that's not a given, since it would also
add complexity.

It may be moot though if there are no shops out there using RN anyway!

------
atleta
As others have said, these companies probably have experience (and love!) with
building native apps. Now if they haven't built anything serious with the
latest non-native solutions, then their opinion will be just that: an opinion,
but not expert advice. Also worth noting that their advice (go native!) can't
be wrong technically. The native app will never be worse than the non-native
one (given, of course, that the same level of effort and knowledge goes into
them). If they don't do non-native apps, then they either take extra risks and
efforts (which will very probably eat up any theoretical savings).

I would say that you should find a company that does hybrid apps as well and
ask them too. Or, instead of a company, you could look for an expert for
advice and have him help you make a decision and pick a subcontractor based on
your detailed requirements.

Speaking about the technology: both PhoneGap and RN allows you to implement
parts in native. React Native is called that, because it renders the UI using
native components. (With PhoneGap you're running in webkit and thus your UI is
html.)

Here's my 2 cents on hybrid apps: I have build one using PhoneGap over 5(!)
years ago. Well, almost 6 now. The MVP for my first startup. It was pretty
simple, but looked nice, worked well on low end android smartphones (of the
day!) and had everyone wondering how I was able to build all that (app,
backend and a component running on a Shiva Plug) by myself. In hindsight, one
of the mistakes I made was that I gave in when we got funded and agreed to
have the app reimplemented in native for both platforms (ios+android). This
cost us quite some money and time and it turned out that the users didn't
really use our app anyway.

One of the strengths of having a cross platform app is that you can do
experiments with it a lot cheaper and quicker, for you don't have to implement
everything twice. Especially, in your case where you have in house web devs,
but no mobile devs.

I have just met one of my former employees from the above mentioned startup of
mine. He now works for an agency as a mobile developer. Back then he only did
iOS, now he does Android as well. He showed me one of their newest apps for a
big sports brand. They did that in RN. It looked pretty neat. It used OpenGL
for the graphics on at least one screen (that was implemented in native). It
was something that I would have said not to implement in JS, but the guy told
me that it was a pretty successful project for them. The agency he works for
only has 2-3 native mobile devs and a lot of web devs. I think he was the only
mobile dev on this project with 6-7 web devs doing most of the code in JS. Of
course, RN is fresh technology and can cause surprises.

Another thing to consider, if an app is barely more than the mobile version of
a website, then going 100% native might not make a lot of sense. Also, until
you have enough mobile users, you might want to try something simple. Maybe
even just a progressive web app.

------
informatimago
First I would notice that this is a problem that has remained unsolved for 34
years, since the diffusion of PUI (GUI from PARC). At the time, we had the Mac
"framework", the Atari (Gem), MS-Windows and X11 "frameworks", and already
then, people tried to design meta-frameworks allowing them to write a single
PUI application and deploy it on those multiple systems. Whole books were
written about the, describing by the minutiae the commonalities and
differences between those frameworks, and explaining how one could write a
common application, or port applications from one to another.

Needless to say, not much progress or success has been made since.

You have things like Delphi or the JVM that can let you develop applications
that can run on all those platforms, but they still always remain somehow
alien to each of the platforms where they run.

Yes, indeed, there are such tools to build Android and iOS applications from a
single source. If your application is not demanding on the user interface (ie.
if it has a simplistic user interface) and on other features of the platforms
(sensors, toolkits), then basically it will do.

However in practice, and this is why you get those responses from app dev
shops, your application will want to use specific features on each specific
platform, or will have some UI sophistication that won't be handled
satisfactorily by the meta-framework, and this is when it'll start to be a lot
more work trying to build the applications with them, instead of writing two
native UI applications.

In addition, to do it correctly with a common meta-framework, you would need a
developer who knows well both target platforms, and who is capable when
developping on the meta-platform, to think ahead how his code will run on both
platforms! This kind of developer are more expensive than two developers each
specialized on his own platform.

All is not lost however, since you should modularize your software anyways,
you will have components that are generic to your application, and components
that are specific to the user interface. Only those later components need to
be developped in two different versions, on the target platforms. The generic
core components can be developped once for all, in the form of a library that
will be used by the native applications. The only downside here is that these
generic core components will have to be written in a common programming
language, most probably C or C++, if you don't want to fight with development
environment (you could try Common Lisp, wich translators such as MoCL
[https://wukix.com/](https://wukix.com/), or Java which has a few compilers
that you could use to target iOS such as
[http://j2objc.org/](http://j2objc.org/), but in all those cases, batteries
are NOT included).

There's a caveat: iOS and Android applications are often only user interface,
they're not functional programs. Without a back-end server, in general you
cannot do anything with those applications. This is both a blessing and a
curse: blessing since this means that now your generic core components are
implemented on the server; a curse because when there's no connectivity, the
user cannot do anything.

But if those generic code components are implemented on the server, then you
see that there remains on the handheld computers only the user interfaces, and
therefore that you don't have any common code in the Android and iOS
applications.

Hence the conclusion and advice given: develop two independent native
applications by two specialized teams. This will be the cheapest and fastest
way to do it, since the two teams can work in parallel. You have in common
only the specifications, and the core components on the server, the later you
can develop yet in parallel by a third team.

