Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: How are you building cross-platform (mobile and browser) apps?
158 points by aosaigh on May 21, 2018 | hide | past | favorite | 82 comments
I've been developing web apps for 5+ years and in my next project I'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've investigated writing a PWA but I'm put off by the arbritrary heuristics that Google are placing on whether or not the apps are presented as "installable".

After that, it seems the only options are Ionic, or React Native + separate web app.

What is your experience writing apps for both mobile and browser?



I use React + React Native for 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.


That looks incredibly well put together -- congratulations. I'm about to launch my first commercial React Native app (pretty simple app aimed at general aviation pilots), so let me know if you end up sharing some of the code for your project -- I'm sure there's lots to learn from it!


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.


Hehe.. turntable.fm v2.0 :-) 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!


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


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)


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


There's a desktop app available for Mac (it's an electron port of the webapp- if anyone's curious). A windows version is coming soon (ETA ~1-2 months).


I'm building my first app in React Native right now - I have a native Android background though.

Can you shed some light on what some of the performance and stability issues you faced are? What can I expect and how did you deal with them or work around them?

Nice app btw!


Sure- a couple of (oddly specific) details:

1. Long lists (>100 items) don't perform well if you have to reorder them. Initial render is a bit slow but not that noticeable but if you have to reorder or add/remove from them on the fly it can be resource intensive.

2. Animation behavior varies between Android and iOS depending on what you're animating.

3. Re-rendering is expensive so you need to be careful when you update your state if you're using redux.

4. Easily fixable but console logging is expensive so be sure to remove all JS logs from production.


Cool app! I got a little confused as to how to add songs once you're a DJ, but the whole things looks cool, and you seem to have a nice community already!


Thanks! Please join in :)

Also, thanks for the feedback I actually keep getting similar comments that it's a lot to learn all. I'm currently trying to simplify things. To add a track you just add it to your "queue" by searching and clicking the plus icon, then when it's your turn (your UN is all the way to the left) your track will play for everyone. Assuming you figured it out but just FYI


I went as far as having the track in my queue "on the deck" but couldn't see it in the global playlist or when it would be playing.

It's super fun because I tried to make a music app to make collaborative playlists on steroids but my UX is so lacking. You can check it out at http://www.niche.fm


Do you share components too? How are you doing styling? I'm using a mix of js variables for different platforms and scss files but I'm finding it kinda complicated. I would like to use styled-components somehow.


For JQBX the styling is done differently between mobile and web. I stared off using scss for web (old habits die hard) and then had to use JS styling for react-native. Not the biggest deal though since the UI is where the two apps diverge the most. Very few things use the exact same UI patterns between web and native. But if I were to do it again (and had a design laid out in advance) I would probably opt for JS-styled components across both versions- though the "CSS" syntax is a little different so you would need some way to port that. I think it still makes a bit of sense to keep styling separate between web and mobile though since you're dealing w/ a different interface... but like everything it depends on what you're building.


Looks nice! What are you using for the backend?


Thanks! BE is Node + Express. I tried to keep a lot of the logic in the clients to it's pretty slim. I'm a FE developer professionally so keeping it all within the JS ecosystem was most comfortable for me.


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.


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


Haskell on web, Android, iOS, desktop (and shared code with the server of course) with 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.


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.


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.


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


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


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.


there was a talk at RailsConf 2016 by Sam Stephenson about how Basecamp used Turbolinks to create version 3 of their, an android and ios version in 18 months.

https://www.youtube.com/watch?v=SWEts0rlezA


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


> or build your own native web view shell and load your web code manually

After a few Cordova and Electron projects I'm going to try this approach in my next project.

I need to support 5 OS (Android, Chrome OS, iOS, macOS, Windows) and having a native UI for each platform is completely out of the question.

I think a web UI is a valid approach. Not only it reduces dev time, but it also adds responsive features not available anywhere else.

This is a great example of a web iOS done right: https://medium.com/missive-app/our-dirty-little-secret-cross...


Xamarin (the code) is open source[0]. Only the bells and whistles (live code preview, integration with VS/VS4M, etc.) are closed source. I think.

[0] https://github.com/xamarin/Xamarin.Forms ; https://github.com/xamarin/xamarin-android ; https://github.com/xamarin/xamarin-macios


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


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


We launched 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.


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?


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.


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.


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/

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

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


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.


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.


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.


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


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


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.


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


How are you building the applications for the app stores?


https://docs.expo.io/versions/latest/distribution/app-stores

create-react-native-app works by leveraging Expo


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.


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://ionicframework.com/


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.


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.


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


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


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.


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

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


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


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.


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


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

(from https://blog.appfigures.com/ios-developers-ship-less-apps-fo... )


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


https://github.com/necolas/react-native-web


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.


If web app is not necessary you also have flutter.


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


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.


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


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

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


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.


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.


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.


React and React Native.

At Idea To Startup (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.


React Native. Trying out http://expo.io/


How do you like using Expo? Any serious drawbacks?


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.


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.


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


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


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


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.


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)


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

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

Happy Coding!


This should probably be a Show HN:

https://news.ycombinator.com/show


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/

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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: