
Ask HN: How are you building cross-platform (mobile and browser) apps? - aosaigh
I&#x27;ve been developing web apps for 5+ years and in my next project I&#x27;ve been tasked with building a mobile (iOS and Android) app that we can also run as a web app. I would obviously like to try keep a single code base for simplicity as we have limited resources. I&#x27;ve investigated writing a PWA but I&#x27;m put off by the arbritrary heuristics that Google  are placing on whether or not the apps are presented as &quot;installable&quot;.<p>After that, it seems the only options are Ionic, or React Native + separate web app.<p>What is your experience writing apps for both mobile and browser?
======
jqbx_jason
I use React + React Native for [https://www.jqbx.fm](https://www.jqbx.fm). As
a 1 man project it seemed like the only sensible way to build mobile
(android/iOS) and browser versions. I can share almost all of the code (where
applicable) so one can move a lot faster and have a lot less mental overhead.

That being said React Native has stability and performance issues that are
tricky and can hold up your app for a non-trivial amount of time. Also staying
on top of updates requires diligence and can be a pain. But if you're looking
for the quickest path to market I would say look no further.

~~~
gubsz
Wow that app is exactly what me & my friends have been looking for. They even
started hacking together an Android version of this. Looks really well done!

One question: Do you plan on writing a native desktop solution? I'm not a fan
of having to keep my browser open just to run a single app.

~~~
kovacs
Hehe.. turntable.fm v2.0 :-)
[https://en.wikipedia.org/wiki/Turntable.fm](https://en.wikipedia.org/wiki/Turntable.fm)

Just checked it out. This is really well executed! Definitely doesn't look
like a one man operation. Congrats!

~~~
jqbx_jason
Thanks! And yeah heavily inspired by tt.fm (RIP). Hopefully the community
keeps growing and can bring some of that 2011 internet magic back.

~~~
kovacs
Yeah and this is smart because this time around the licensing falls on Spotify
where as back then TT had to negotiate licensing if I'm not mistaken. I'm not
a lawyer but if that's true this seems much more viable using Spotify's APIs
with the caveat that your entire business relies on them if that's your
aspiration. Regardless, wish I'd thought of this :-P Seems like it would be
such a fun app to work on :-) Best of luck to you!

(BTW it just pinned a Google chrome helper on my machine so I had to kill it.
Not sure if you know anything about perf. with your app yet. Just FYI)

~~~
jqbx_jason
Yeah it's fun- and you're right about the licensing and reliance on Spotify.
Hopefully it all works out but who knows :)

Sorry about the perf- it's a known issue and I'm working on it, I only
recently got it (somewhat) feature complete so It's next on the list...

------
d0m
It's the third time I have to build the whole stack (web+ios+android).

For the first time, I used a webapp and was hoping that the ios/android
experience would be good enough. Unfortunately, It wasn't and it was a big
mistake. I'd only recommend this for quick mvp knowing that it'll need to be
rewritten or if your audience really understand what it means to have a mobile
webapp compared to a native app. I.e. if there's an IT department in place
that can install it on the devices and understand the limitations.

For the second time, we went with ionic/phonegap. It was a huge improvement,
but we hit too many limitations and scenarios where we wanted native tweaking
for animations or handling the keyboard hiding fields or the topbar acting
weird, etc. You don't see those issues at first.. but they start appearing as
you start doing QA on more devices and with real users. And at that point,
you've invested so much in trying to make it work that you can't just go back,
so you start piling weird hacks on top of weird hacks.

For the third time, we went with react-native. Overall it was a great
experience and unlike ionic, it's a real native app, not just a webview. We
could reuse a big part of the code between web, ios and android. The issues we
faced were often related to weird edge cases that are buggy within react-
native itself such as input fields not working correctly when dictating or a
"pull-to-refresh" supposed to be stateless but in practice being stateful and
buggy if you call "refresh" on it twice within 30ms. However, it's a good
feeling to know that when we'll have the time, we have the flexibility to
either fix the library itself or re-write it (compared to ionic where we
couldn't do much and web apps where the solution to most our problems would be
to "wait a few years until the browsers decide to improve it".)

If I had to do it another time (a fourth time), I'd go with react-native again
but I would make sure to stress test the libraries with real data on all the
devices we'd want to support. Also, it's popular in the javascript ecosystem
to have libraries that depend of another library that depends of another
library that wraps another library.. in most cases, it's just better to write
a quick wrapper for your app and only include the inner-most library that does
most of the work anyway. Otherwise you're depending on too many authors and
libraries quickly go out-of-sync and you're stuck with old versions that
aren't compatible with new ones.

------
sdcooke
We use React Native for our apps and React for desktop - I'd say about 95% of
the Android/iOS code is shared and we're able to share a lot of business logic
between mobile and web. Having all of the code together in one repo has worked
really well for us and some of the most complicated stuff is shared between
all platforms.

If you want to share UI across platforms you could potentially use something
like [https://github.com/lelandrichardson/react-
primitives](https://github.com/lelandrichardson/react-primitives) to do that,
but we don't and I'm not sure we'd want to because we don't want to use the
same design on all platforms.

------
kenmicklas
Haskell on web, Android, iOS, desktop (and shared code with the server of
course) with [https://github.com/reflex-frp/reflex-
platform](https://github.com/reflex-frp/reflex-platform)

It's pretty hard to beat the productivity of one codebase for every platform
with a powerful type system catching errors across every part of system.

------
soulnothing
I've been using Kotlin for the past few years. The multi platform support is
getting really nice. Ios is the lagging participant, but with the upcoming
conference alot of the niggling bugs should be addressed. Right now JVM,
android, and js are all stable.

Writing a graphql endpoint emitting a data class. Then have react directly
cast to that same data class. With proper type safety is great.

There are bugs but they feel like fringe cases. I spent half a day cleaning up
my bindings to react material ui. An hour or two fighting serializaiton bugs.
Those are the biggest time sinks that come to mind. It's still marked as
experimental but it's something to keep an eye on.

------
SCdF
We've built an offline first webapp that is basically a PWA (it's one manifest
file away from being one IIRC), but instead of relying on Google to have
something installable[1] we also create an Android app which is just[1] a web
view hardcoded to the correct URL.

I'm not convinced this is what we'd do if we were starting fresh, I imagine
we'd look at React / React Native. However, this definitely works for us for
now.

[1] We also deploy to very old / basic phones, so we use this opportunity to
bundle our own version of the web view so we can target higher chrome
versions.

------
dangoor
At Khan Academy, our award-winning[1] mobile apps are a combination of native
+ React Native + web view. The React Native part is relatively new, but it's
definitely helping us to move a lot faster in developing our apps.

A few years ago, I worked on a project in Xamarin with some success. The
iteration cycle with React Native is far faster, though.

[1] [https://blog.google/products/google-
play/winners-2018-google...](https://blog.google/products/google-
play/winners-2018-google-play-awards-are/)

------
tsmall
Depending on your needs, using something like Turbolinks [1] may be a great
fit. There are iOS and Android libraries that can make your web app talk to
your native app so it can do things like trigger screen transitions, populate
native menu or tab controls, etc. We're using a similar idea at my company and
so far it's been very successful for us.

[1]:
[https://github.com/turbolinks/turbolinks/#readme](https://github.com/turbolinks/turbolinks/#readme)

~~~
deedubaya
I use Turbolinks over at HOALife.com. Mobile clients take advantage of native
geolocation, camera, and photo library upload.

The web, iOS, and Android devices utilize all of the same server generated
HTML + JS google maps et al. 0 to completed for both Android and iOS in maybe
30 hours because of the native API stuff I had to learn. If you don't need
those native API's or know Swift/Java better, that time could be trimmed down
considerably.

------
gldalmaso
You should consider your target audience and your own resources. For consumer
facing apps, I'm not sure an hybrid (cordova / ionic / webview shell) approach
is really up to par, as the UX is really challenging to make right and
performance will be lacking. That said, a native approach requires twice the
codebase and twice the resources (man hours) roughly, so the challenge becomes
maintaining feature parity and team expenses.

Apps targeted for B2B users are considerably more flexible in terms of UX, the
goal is mainly to help users get stuff done, so hybrid is more viable here.
Which is what we usually do with cordova. Some considerations to bear: using
cordova, the team doesn't really get much expertise with the proper platform,
so problems are sometimes harder to debug because of lack of developer
maturity in the platform. You need to design with an eye to light performance
requirements, which usually means facilitating inputs and maybe have a
separate web interface for complex UI like dashboard and management.

If you absolutely have to share code between apps, your options are:

\- hybrid approaches like cordova, or build your own native web view shell and
load your web code manually

\- react native, which is not v1 yet, and looking at it recently I'm
personally not sold on it yet, many unkown unknowns to actually double down
and build on it. But that's just my opinion.

\- Black box compatibility frameworks like Xamarim, Nativescript and the like.
They work by giving a common platform middleware that builds to multiple
target platforms. There are a lot of trade offs here, specially the lack of
control. If a feature is buggy or not supported there is little recourse.

\- I have read some big companies share code via C++ bindings used natively on
each platform (loaded in Java and Objective C). I imagine this technically
"solves" the problem, as you can share code and build natively, though I have
no idea what tooling there is to help with this, and imagine the developer
experience gets the short end of the stick.

edit: typos

~~~
nailer
Instagram is pretty popular, has a good UX and is built on a webview (ocne a
year on a shitty connection the CSS doesn't load and you see it).

~~~
slow_donkey
Wow I wasn't aware but looks like they did start with webviews and migrated to
native + react native

------
osrec
We launched [https://usebx.com](https://usebx.com) as a PWA, and have
successfully managed to keep a single code base across pretty much all
devices. The install process isn't much of a problem either, as a user can
always "install" your app by adding it to the home screen. I would definitely
recommend a PWA, unless you need some hard core native features that aren't
available in browsers yet.

~~~
olijka
Do you have any requirements for offline data storage for your PWA? If yes,
how do you manage it? From what I've heard the amount of space available for
data varies wildly between devices. In that case what does your offline data
storage strategy look like?

~~~
osrec
We use indexeddb, which is generally okay, but you're right, the DB size can
vary across browsers (I think some limit to 10mb, and others to half the HDD).
For our use case, it was good enough. Our strategy is to try and cache things
offline, but if indexeddb fails to store the data, we attempt to fetch from
the server. As the saying goes, cache invalidation is hard, but that's true
regardless of the platform.

------
andrewstellman
Consider taking a look at the Visual Studio tools, which have really matured
over the last few years: [https://www.visualstudio.com/vs/features/modern-web-
tooling/](https://www.visualstudio.com/vs/features/modern-web-tooling/)

Specifically, tools for Apache Cordova:
[https://www.visualstudio.com/vs/features/cordova/](https://www.visualstudio.com/vs/features/cordova/)

(disclaimer: I haven't used them, but I've heard very positive feedback)

~~~
WhitneyLand
1) The Microsoft development product line is great at some things, but not for
directly enabling cross web/mobile solutions. However do use VS Code as the
environment for other solutions mentioned here.

2) If you are a non-MS person, make sure you don’t miss out on the greatness
of Visual Studio Code by dismissing it as yet another Windows centric product.
VS Code is world class performant, has a great plugin arch/ecosystem, and
somehow combines a hardcore developer first mindset with carefully thought out
UX at the same time.

Also to be clear for those not much in the MS world, the “Visual Studio“
product line you’ve heard of for decades is not the same thing. It’s confusing
naming but Visual Studio Code is relatively new and very different.

~~~
megamark16
They should have just called it (Microsoft) Code. If they can use Word,
Access, and Excel as product names, surely they could get away with just
calling their world-class editor "Code".

I second your recommendation, I'm a sucker for a sleek editor with a great
plugin architecture.

------
kreck
We're running all our apps based on Ionic which works absolutely brilliant &
allows for the deployment as PWA today or at any point in the future. That
being said we primarily build b2b applications. Minor drawbacks to native in
terms of UX performance exist, but tbh, if you know how to optimize rendering
performance in a browser you'll get 99% of native performance by putting in
the effort.

For us the ability to run on literally any(!) device (this includes for
example also smart TVs) completely outweighs the potential (minor) performance
drawbacks.

------
mychael
Create React Native App (CRNA) with Expo. It doesn't get any better than this
from a developer experience perspective.

~~~
weka
How does it handle Electron apps? I thought playing with EXPO was a limited
venture?

~~~
sodafountan
I'm currently developing with Expo with plans to expand to Electron (though I
haven't written anything for Electron yet, just the React-Native and Expo
portion) but my theory is that once you have the core React functionality down
(The API endpoints, Reducers and Actions (if using redux), and general
component structure) then porting to Electron will be fairly trivial.

React-Native has a lot of cross-over with React for the web. So I'm hoping
when the time comes my port will go smoothly.

~~~
raarts
Expo/create-react-native-app experimentally support the web now, so you can
build both from one codebase. My PR to that effect was recently accepted. See
my blogpost[1] about it.

[1] [https://medium.com/@ron.arts/web-support-for-create-react-
na...](https://medium.com/@ron.arts/web-support-for-create-react-native-
app-80b16f930326)

------
tabtab
Advice: get OUT of the UI/UX business, it's an ever-changing grinder. Unless
you enjoy relearning 50 Shades of the Wheel every 3 years, bail fast and
quick. It's getting worse over time, not better. An alternative may smaller
internal applications where they care less about latest-and-greatest UI's. It
still changes, but not as fast.

------
yesimahuman
This is exactly the vision we have for Ionic and where we are taking it. One
app that works great in the app stores _and_ when deployed on the web (or even
electron), built entirely on standard browser technologies. If you are put off
by Angular, our v4 release (alpha right now but quickly heading into beta and
then production ready) was rebuilt on top of web components and is framework
agnostic.

It also happens to be creating some of fastest PWAs right now based on
benchmarks. We built a lot of web component tech to make sure we were sending
the least amount of code to the client and things like SSR and lazy loading
with minimal configuration on your part (see our web component compiler
Stencil we built in order to build our v4 components:
[http://stenciljs.com/](http://stenciljs.com/)).

[http://ionicframework.com/](http://ionicframework.com/)

~~~
sntran
Not sure about the speed benchmark, but Stencil's build process could be
improved. It takes more than 1s to build on file changes. Definitely not ideal
for development.

Vue.js PWA, on the other hand, rebuild quite fast.

With that said, I really like Ionic PWA and the component approach. Will wait
for the stable release.

~~~
yesimahuman
I was referring to runtime performance. Our build process will probably be
slower than vue because we're using typescript, but we do have plans to speed
it up. I've been using it for a large app and barely notice rebuilds, so I
think we're almost there.

------
komuW
I'm using flutter [1] which uses the dart programming language. I'm loving the
static typing of dart, hot reload of flutter, very good debugging tools. Also
the fact that layout/ui and logic are all laid out in code and not in a
separate markup lang

1\. [https://flutter.io](https://flutter.io)

~~~
jsntrmn
Would you care to comment on runtime performance of the finished product? I've
played around with Flutter a bit and get the impression that it's still a
little too heavily skewed toward Android in terms of optimization. I guess I
can't fault a Google-built framework for that, but I could never sell Flutter
to upper management if I have to say, "well... it's a little janky on iOS."

------
tones411
Ionic can get you the most code sharing. Ionic uses a web view to render the
UI so it will never get you the same as a native UI, but it is actually really
good. Expect a few delays here and there, though. Make sure to try it out on
the oldest phone you plan on supporting to see if you’re okay with the
performance before moving forward. Ionic will get you the most code sharing.

React Native is a great for cross platform iOS and Android native. If you want
code sharing across native app and web app, look into ReactXP, or come up with
your own code sharing technique, which apparently @sdcookie’s team did.

Titanium from Appcelerator also supposedly targets Native and Web.

Also consider focusing your efforts on native and not doing a web app.
RobinHood stock trading app went a long ways without having a web app. Just
throwing that out there.

------
arca_vorago
Pure html+css with as little js as possible...

eg: websites/single page webapps over native ios/android apps

~~~
gtycomb
Wow. Among all conversations, haven't heard this simple truth mentioned any
more. Would love to hear more discussion along these lines.

~~~
CryoLogic
Before hybrid apps where a thing I would build HTML/CSS/JS web apps and put
them in an android web-view with no controls. Easy peasy.

You can use local storage to cache for offline use. TBH I don't think most
apps really need the overhead of these new libraries. Half of the apps on the
app store just display and update data from a DB.

------
ianjsikes
Just wanted to mention that React Native + React Native Web _is_ a viable
solution (at least for me it was). I was able to convert a mobile React Native
project into a usable mobile website with Next.js and `react-native-web`.

I had to use a lot of platform-specific imports (eg:
`index.ios.tsx`/`index.web.tsx`) to replace anything mobile-specific, and
there are some cases where you need platform-specific UI components as well to
make everything look nice on larger screens.

My only complaint is it gets a bit messy having all these different entry
points and platform-specific modules and whatnot. Overall, it's probably the
best you can hope for to write an app for mobile + web with ~80-90% _actual_
code sharing.

------
zerr
Interestingly, Flash/Air seems most-popular cross-platform mobile toolkit for
app dev (far ahead React Native):

[https://blog.appfigures.com/wp-
content/uploads/2018/03/11-No...](https://blog.appfigures.com/wp-
content/uploads/2018/03/11-Non-Native-SDKs@2x-1.png)

(from [https://blog.appfigures.com/ios-developers-ship-less-apps-
fo...](https://blog.appfigures.com/ios-developers-ship-less-apps-for-first-
time/) )

~~~
dangoor
A lot of games have been made in Flash. I'm guessing that a lot of those apps
cited are games (which is true for a few other frameworks on that list).

------
davman
[https://github.com/necolas/react-native-
web](https://github.com/necolas/react-native-web)

------
tunaoftheland
My take on this is that React Native works fine for content-dominant (media,
text) apps but maybe not for UI interaction-dominant (arcade games, heavy
animations, gestures) ones. You share a very similar API (React) and possibly
the business logic between web and mobile. Your project could get bogged down
by many little details and idiosyncrasies of React Native so a clear scope and
discipline is important.

One example is a Bluetooth-enabled iOS/Android app that I made (but did not
publish to app stores). I was able to use a RN library for Bluetooth
communication and interact with another device (a bathroom scale) in
JavaScript. It was one of those "Wow, this is cool!" and "Man, this is pain!"
moments. Note that I did not use create-react-native-app/Expo for this.

Another app, also iOS and Android, simply renders the content of my wife's
Etsy store, including the pictures (published to both Apple and Google Play
stores). It was done using create-react-native-app/Expo. I didn't like the
dependence on the Expo site for building app packages. It's free and there for
now but I'll have to "eject" the app in the future if the something were to
happen to the site. I used an open-source RN components library which does a
good job selecting default typefaces and sizes. There were still fiddly bits I
had to poke at to make it look decent, but it was alright for something that I
whipped up as quickly as I could. The documentation for the component library
was not keeping up with the continuous changes React / React Native / the
library itself so that was a pain.

Note that it can get a bit confusing keeping track of what you can and cannot
do with create-react-native-app/Expo. You might have to scope the app
appropriately until you feel ready to "eject" it from Expo and access the more
lower-level RN APIs.

On the web side, I find that I can grok the React API more easily than most
other SPA libs. So there's natural affinity for me to keep the API complexity
down in the projects that I choose to do by preferring the React-* APIs in
general.

I agree with @jqbx_jason's comment and RN was the only sensible (sane?) choice
in my case for the 1-man projects. Some background: I have professional
experience in Java, C#, C, JavaScript/ES6/TypeScript and few others, but no
experience doing fully-native iOS and Android apps.

FWIW, Pinterest seems to be liking RN for their mobile apps:
[https://medium.com/@Pinterest_Engineering/supporting-
react-n...](https://medium.com/@Pinterest_Engineering/supporting-react-native-
at-pinterest-f8c2233f90e6)

------
philippz
We (STOMT) use Cordova/Phonegap and AngularJS for our desktop/mobile apps.
Ionic is considered to be faster but it's difficult to implement custom UI.
Ionic might be interesting for casual apps, for us it would mean to do a
complete rewrite.

------
gede
If web app is not necessary you also have flutter.

~~~
maremmano
you can also do web app in DART (the language on which flutter is created) you
can do mobile, web and server cli apps in DART

[https://www.dartlang.org](https://www.dartlang.org)

------
ben_jones
Tweak the question, instead of "is there a framework that makes this difficult
task simple" ask "is this a difficult task that can be simplified without
significant investment or overhead?".

Personally I don't think RN, Ionic, Electron, or any other tools completely
solve all cross-platform development issues. Like all things its a tradeoff
and personally I am not convinced that what we have out there is sufficient
for most applications - particularly for small teams. Small apps maybe, but
the second you have to go off the beaten path you will be losing weeks not
hours of development time.

~~~
chrisco255
Yeah but the alternative is to write native applications for every platform,
which would easily cost you months, not weeks of development time.

------
troycarlson
I made a React web app and then had an iOS "container" built with some minimal
native iOS functionality to make everything feel more native. Here's an
overview of how the iOS app was made:
[https://www.vsanthanam.com/writing/2018/5/9/web-app-
containe...](https://www.vsanthanam.com/writing/2018/5/9/web-app-containers-
in-ios)

It works great for my simple web app. Obviously, your mileage may vary.

------
aerodog
Decided to give a go at React XP. Based on their claims, they're good because:

\- React Native Web and React Native (iOS/Android) are handled in one go

\- Windows Support

\- Stripped down so nothing from within will work on iOS but not Android, for
example, as is the case with React Native...

\- Lots of components from Material UI (just launched v.1) can work right on
top without too much of a hitch

Caveat: we're just getting started, so I don't want to oversell this. But
faced with a similar problem, this route seemed optimal at this time.

------
akulbe
Is .Net Core something you can use for both mobile and browser? I'm curious
how much traction that's getting for cross-platform stuff.

------
patwolf
Ionic uses Cordova, which you can use directly without having to use the rest
of Ionic. You're then free to write the app in React or whatever web framework
you prefer.

The only downside is if you do want a native look and feel, you'll need to
find a UI library to provide that, but that's no different than if you were
writing a PWA.

------
nikhildaga
React and React Native.

At Idea To Startup ([https://ideatostartup.org/](https://ideatostartup.org/)),
we have developed a ui framework "One-Ui" which helps us write code that works
on all platforms (Web, Android and iOS).

It has helped us immensely in reducing the time to develop apps.

------
daurnimator
React Native. Trying out [http://expo.io/](http://expo.io/)

~~~
bernardino
How do you like using Expo? Any serious drawbacks?

------
teo4oro
At my company, we're building our mobile applications using React + Cordova. I
loved the idea of React Native, but after some reading I wasn't convinced
given how difficult it seemed to be to get the app built for the App Store and
Play Store.

------
WA
I use Ionic + PouchDB/CouchDB.

One code base plus auto-syncing of user data.

Works pretty great.

Ionic is pretty close to a native feeling. I think most people wouldn’t be
able to tell the difference.

------
curyous
You can share JzvaScript code without having to use a framework. Both iOS and
Android let you run JavaScript within a native app.

------
segmondy
A bit off topic, but if you are using ionic, how are you testing?

------
mandebi
I were looking at Vue NativeScript. Anybody on why should I not?

~~~
pragueexpat
Also curious if someone has anything to say about Vue/Nativescript. That would
be my choice as well. I'm constantly wondering why React Native gets all the
attention when Nativescript seems to have so much going for it.

~~~
slow_donkey
Imo it's hard to justify betting a product on significantly smaller
communities like nativescript/weex. Also when other companies have
successfully used rn in prod like fb, insta, airbnb, the stress testing has
already been done for you whereas I know of exactly 0 large scale deployments
on those frameworks (even flutter had the Hamilton app)

------
AppPile
Hello all! My name is Michael Arnold and I've recently launched a new product
App Pile ( www.apppile.com ) , which is currently under a private beta
release. App Pile converts Axure designs into native Android & React Native
projects complete with source code. Not just source code, but readable,
editable, expected code. As mentioned, it is a beta release which means the
native Android offering has a stable build while the React offering is nearly
complete and should be done in the next week or so. (But is still included
with every download) Axure is a design program similar to
Invision/Sketch/Marvel and recently created a plug in which lets you import
Sketch projects, so defacto App Pile works for Sketch as well. Please check
out my latest post which explains the product in a little more detail.
[https://www.linkedin.com/pulse/app-pile-take-away-work-
from-...](https://www.linkedin.com/pulse/app-pile-take-away-work-from-
existing-software-companies-arnold/)

If you have any questions or would like a free trial code, please email me
directly at michael@apppile.com

Happy Coding!

~~~
tomhoward
This should probably be a Show HN:

[https://news.ycombinator.com/show](https://news.ycombinator.com/show)

------
adley
DronaHQ has a container product that runs on all mobile and desktop platforms
as well as a web app.
[http://www.dronahq.com/platform/uec/](http://www.dronahq.com/platform/uec/)

Edit: [Disclaimer] I work with them. To clarify, the container is already
built, you can build hybrid or native apps on top of that.

~~~
Gys
Please add a disclaimer if you have some kind of relationship. DronaHQ is
obviously an enterprise solution: price info only on request and it seems the
goal is to build the app for you.

