React Native for OS X
github.com
github.com
A React Native app isn't horrible or bad (nothing like Java Swing) but it also isn't delightful to use. Technically you have animations and things like the cross-platform navigator. In reality, you have a lot of performance issues and strange incompatibilities due to attempting to execute animation keyframes on the JS thread (or replace the system-provided navigation bar in the case of Navigator). It isn't terribly easy on battery life either.
I'd rather write my sync and offline storage system in JS and share that across platforms while leaving the entire view layer as native code. That stuff is far harder to get right for non-trivial apps, it just isn't sexy and most web devs ignore it completely because hey - the web browser is always online!
I'm biased though. Our customers download 5-10 GB projects with millions of objects in them because when you're building a hospital the MRI room is a literal faraday cage. No such thing as internet access in there and telling the user they can't pull up plans or engineering specs because they're offline is a non-starter.
If people want to use reactive programming for their view layer on iOS or OS X then ReactiveCocoa is probably a nicer fit.
EDIT:
I mentioned "reactive programming" because React is typically used in conjunction with reactive programming. Mentioning something related to something else is pretty standard communication.
To elaborate on why I made my initial comment...
Reactive programming is a paradigm, it has advantages (and disadvantages). Paradigms are higher level than implementations (libraries), or even a programming languages. When people start a new project they come up with requirements; continuous integration, easily testable etc. These requirements are mostly satisfied by a paradigm, not a implementation, nor even a programming language.
If you've decided you like React, you probably like it for various reasons, most of which are probably because you're following the reactive programming paradigm - and perhaps because you like JavaScript. Nonetheless, when you start a new project (e.g. you've decided you want a native Mac app) it's your job as a competent software developer to determine the best fit for the project. This means you should really do your best to make a well rounded assessment of the situation - that means being educated about the subject matter. My comment merely agreed with the parent comment's description of the disadvantages of a (near) pure JS solution, and proposed ReactiveCocoa as an alternative that provides many of the advantages and familiarities of React, minus the disadvantages the parent post pointed out. Of course, you can't use JS to write your app - that may well be deemed by your team as a sufficient enough disadvantage to avoid ReactiveCocoa as a solution.
The real dataflow in reactive programming which could be considered the 'state', is not managed by React at all. You could use Redux for that, but having a datastore with reducers which modify state, and actions which trigger reducers is not something I would consider reactive.
So I think RN is a reasonable option for some kind of business that needs a decent, usable app on both iOS and Android. But if your business is mobile-first then I would still recommend you take the time to do a real native implementation.
I've gotten my RN app to run at the same performance level (as far as the user is concerned) as my native app and there are definitely some non-trivial animations and gesture responders for the RN version.
It did take some tuning and I had to add a couple artificial delays to wait for animations to finish, but nothing crazy.
No opinion on Android yet, but RN for iOS is definitely not negatively impacting the user experience in my case.
It's not in the store yet, but to give you an idea of the UI complexity level - see Slack and Google Chrome's UI and gestures.
It's possible that the OPs ran into certain issues with specific cases or weren't able to figure out a workaround even though solutions exist, but the result of their comments unintentionally create FUD.
I'll give an example. One of the most popular libraries for messenger apps to use in RN is GiftedMessenger, but it's actually doing the keyboard wrong, so people may get the misconception that ReactNative doesn't support smooth keyboard animations, which is not true. There are a lot of examples like this, not meaning to pick on anything specific.
I will say that the library ecosystem around RN doesn't feel mature yet, kind of like Node.js in the early days, but React-Native itself is not the issue.
No, the user always feels. Even the grandmas and grandpas, that are far away from technology as possible, feel it in the back of their mind. They know something is "off".
Also, adding "artificial delays" to wait for animation end is a sign of a terrible terrible animation system.
It's hard to describe without showing you in person and asking you to tell me which app is a RN app vs native, but it's actually the case... There's pretty granular control over the easing functions and the default ones do match the iOS curves.
I was a designer before being an engineer, and I was immersed in Obj-C for 4 years before trying React Native. On the well-implemented React Native apps, it really truly is indistinguishable.
It does help to read obj-c code in the RN repo to see what's possible and how things work so you use the right javascript parameters, but you don't normally have to do additional obj-c coding most of the time.
You're saying that that it is easy to use RN to build an app that is indistinguishable from an app written in obj-c
I'm offering the possibility that your 4 years of obj-c experience trained you to make intuitive judgements about how things should be done and that this intuition is mostly correct. Also that a person without that experience wouldn't make those same judgements and might default to doing things in a lower-fidelity way.
This suggestion is offered without experience using either react native, obj-c, or swift. So coming from ignorance, I might be entirely wrong.
If it's below a certain ms (milliseconds) threshold the user does not "feel". There's nothing more or less to it besides simple physiology.
It drains more battery, it leaves less CPU for other operations, etc.
Additionally I like the React lifecycle better than Android's finite state machine where you always have to know where in the cycle you are, what's next and what's before, etc.
If the wrapper doesn't do what you want, you can still write that portion in native or write your own wrapper with an underlying implementation that does exactly what you want.
The point is to create the equivalent experience of a native app with a delightful development and organizational experience.
- Instead of having separate teams develop your iOS, Android, and now OS X apps, one product team can make all three and share the majority of the code.
- Instead of a slow frustrating compile cycle you get live reloading.
Whether or not the experience is great isn't a deal-breaker, it's a factor in the decision making process. For plenty of companies out there, having a less-than-perfect application that they can deploy to many platforms in a month or two with a single or couple of developers is a choice that might get made, when the alternatives are either much longer timetables or many more dollars.
Any management person will throw in a "you've done X on this platform, why don't you try to reuse most of your stuff on this other platform ?", just in case it's actually doable.
Edit: Just to clarify, there may be instances where a mgmt type has asked if X on platform Y can be reused on platform Z easily. I've never seen it go beyond the ask.
Besides Facebook's Ad Manager (which barely cuts it) I haven't seen any React Native app on Android that didn't feel horrible (and not like an Android app).
There are people in this world that think Olive Garden is great Italian food. There are people in this world that think React "Native' is a good user experience.
Why does Facebook absolutely insist on avoiding writing actual native apps? As in Swift for example. It seems like they are almost allergic to actual native and instead focus on this inferior cross platform stuff.
In 'most cases' users won't know the difference? sure they will; they'll notice that the app they're using sucks more than other apps on their phone. They'll tolerate the glichiness, the occasional blank data screen during a load because they care about the content more than the terrible experience. All because a developer or the CTO somehow thinks "it works well enough" is the same as "let's really give our users the best possible experience." I am amazed that Facebook has thousands of employees but can't be bothered to write a single line of code in Swift. They've been insisting on this stubborn course of action since the beginning of their mobile experience. Does Zuckerberg just hate Obj C or Swift? Why are they making the mobile experience into the lowest common denominator? Why does their Facebook app feel like some cheap PhoneGap experiment? My Facebook app on iOS performs exactly the same as it does on a years-old Android phone.. And that's ridiculous. I have superior hardware and yet I get to run an inferior app because JavaScript? It's like socialism for apps: make everyone equally miserable.
The simple fact is this: I hate cross platform systems because they end up averaging the quantity of the mobile experience with capabilities being reduced to support the lowest common denominator. If I want my apps to run as terrible as many do on Android, I will use an Android. It's lazy development. It's a means for the JavaScript crowd to avoid leaning Swift (or Java) so they can provide middling to bad mobile apps rather than actually building the absolute highest quality product they could build.
Even Facebook does it! I feel like the React Native ecosystem is doing more to reduce the quality of the mobile app experience than anything else. Apps are being turned into these average pieces of crap with only the UI being slightly different. Does anyone have any performance benchmarks on a React "Native" compared to Swift? Any data at all? Or are we just so excited to write apps in React that we fail to care? If we care about 'cross platform' development -- we can already do that; it's called 'the web.' Let stop foisting inferior mobile apps on people just because we can.
(I'm not going to dispute that cross-platform toolkits can have less native fidelity than compared to coding to the native toolkit can. I just don't like the Objective-C vs. JavaScript performance myth.)
Here's a link showing Objective-C beating JavaScript handily: https://medium.com/@harrycheung/mobile-app-performance-redux...
But is this even a debate? Wouldn't you expect a compiled, manual memory managed, language to be faster than an interpreted language with garbage collection?
> But is this even a debate? Wouldn't you expect a compiled, manual memory managed, language to be faster than an interpreted language with garbage collection?
Objective-C is not compiled in terms of method dispatch, nor it is manually memory managed. Instead, all method dispatch happens through essentially interned string lookup at runtime, backed by a cache. Objective-C also has a slow garbage collector--atomic reference counting for all objects. (Hans Boehm has some well-known numbers showing how slow this is compared to any tracing GC, much less a good generational tracing GC like all non-Safari browsers have.)
The method lookup issue has massive consequences for optimization. Because JavaScript has a JIT, polymorphic inline caching is feasible, whereas in Objective-C it is not. It's been well known in Smalltalk research since the '80s that inline caching is essentially the only way to make dynamic method lookup acceptably fast. Moreover, JavaScript has the advantage of speculative optimization: when a particular method target has been observed, the JIT can perform speculative inlining and recompile the function. Inlining is key to all sorts of optimizations, because it converts intraprocedural optimizations to interprocedural optimizations. It can easily make 2x-10x of a difference or more in performance. This route is completely closed off to Objective-C (unless the programmer manually does imp caching or whatnot), because the compiler cannot see through method lookups.
Apple engineers know this, which is why Swift backed off to a more C++-like model for vtable dispatch and has aggressive devirtualization optimizations built on top of this model implemented in swiftc. This effort effectively makes iOS's native language catch up to what JavaScript JITs can already do through speculation.
1. Objective-C's compile time memory management is actually slower than JavaScript's garbage collection.
2. The performance consequences of Objective-C message sending are greater than JavaScript's JIT compilation. And furthermore, that JIT compilation is actually an advantage due to the other optimization techniques it enables.
I'd like to see a more direct comparison with benchmarks, but I can see where you're coming from.
I realized another issue, too: I don't think it's possible to perform scalar replacement of aggregates on Objective-C objects at all, whereas JavaScript engines are now starting to be able to escape analyze and SROA JS values. SROA is another critical optimization because it converts memory into SSA values, where instcombine and other optimizations can work on them. Again, Swift fixes this with SIL-level SROA.
Sometimes I feel like using JavaScript too much transports people to some kind of imaginary JavaScript fairy land full of rainbows and unicorns. I read the craziest things about JavaScript development even though I can't comprehend why so many people believe it has any redeeming positive qualities over other languages, besides ubiquity.
I'm aware of the dynamic dispatch overhead of Objective-C, but first of all it's my understanding that Apple's Objective-C runtime & compiler perform all kinds of smart tricks to reduce the overhead to a minimum (caching selector lookups and such), and second, because Objective-C does not require you to use dynamic dispatch if performance is a concern. No one is preventing you from doing plain-old C-style functions for performance criticial sections.
I also don't buy the 'ARC is slower than GC' argument. ARC reference counting on 64 bit iOS, as implemented using tagged pointers, has almost zero overhead for typical workloads. Only if you would write some kind of computational kernel that operates on NSValue or whatever (which is a dumb idea in any scenario, about as dumb as writing such a thing in JavaScript) you would ever even see the difference between not having any memory management at all. Just like your other performance claims: without data, there is nothing that backs up your statement that ARC is slower than GC for typical workloads. Hans Bohm is not the most objective source for such benchmarks by the way.
Apart from that you seem to spend an awful lot of effort explaining the things that would make Objective-C slower than JIT'ed JavaScript, while completely disregarding the overhead all this JIT'ting, dynamic typing, etc has, and the fact that in JavaScript you basically have no way to optimize your code for cache friendliness or whatnot.
You may be a compiler developer, but based on your comments I'm highly doubtful you are aware of how much optimization already went into Apple's compilers, which greatly reduce the overhead of dynamic dispatch and ARC.
That's just writing C, not Objective-C. But if we're going to go there, then neither does JavaScript. You can even use a C compiler if you like (Web Assembly/asm.js).
> ARC reference counting on 64 bit iOS, as implemented using tagged pointers, has almost zero overhead for typical workloads.
No, it doesn't. I can guarantee it. The throughput is small in relative terms, I'm sure, but the throughput would be smaller if Objective-C used a good generational tracing GC.
(This is not to say Apple is wrong to use reference counting. Latency matters too.)
> Just like your other performance claims: without data, there is nothing that backs up your statement that ARC is slower than GC for typical workloads. Hans Boehm is not the most objective source for such benchmarks by the way.
There's not much I can say if you're determined to discount real numbers solely because Hans Boehm provided them. But here you go ("ARC" is "thread safe"): http://www.hboehm.info/gc/nonmoving/html/slide_11.html
Anyway, just to name one of the most famous of dozens of academic papers, here's "Down for the Count" backing up these claims: https://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-... Figure 9: "Our optimized reference counting very closely matches mark-sweep, while standard reference counting performs 30% worse." (Apple's reference counting does none of the optimizations in "Down for the Count".)
Here's the Ulterior Reference Counting paper, showing in table 3 that reference counting loses to mark and sweep in total time: http://www.cs.utexas.edu/users/mckinley/papers/urc-oopsla-20...
memorymanagement.org (an excellent resource for this stuff, by the way) says "Reference counting is often used because it can be implemented without any support from the language or compiler...However, it would normally be more efficient to use a tracing garbage collector instead." http://www.memorymanagement.org/glossary/r.html#term-referen...
This has been measured again and again and reference counting always loses in throughput.
> You may be a compiler developer, but based on your comments I'm highly doubtful you are aware of how much optimization already went into Apple's compilers, which greatly reduce the overhead of dynamic dispatch and ARC.
I've worked with Apple's compiler technology (clang and LLVM) for years. The method caching in Objective-C is implemented with a hash table lookup. It's like 10 instructions [1] compared to 1 or 2 in C++, which is a 3x-4x difference right there. But the real problem isn't the method caching: it's the lack of devirtualization and inlining, which allows all sorts of other optimizations to kick in.
Apple did things differently in Swift for a reason, you know.
One thing I do want to make a last comment about is your dismissal of using C/C++ inside Objective-C programs as some kind of bait-and-switch argument. Using C/C++ for performance critical sections is IMO not the same as calling out to native code from something like JavaScript, or writing asm.js or whatever other crutch you could use to escape the performance limitations of a language. As a superset of C, mixing C/C++ with Objective-C is so ingrained in the language you have to consider it a language feature, not a 'breakout feature'. Nobody who cares about performance writes tight loops using NSValue or NSArray, or dispatches millions of messages from code on the critical path of the applications performance (which usually covers less than 10% of your codebase). As an example, I'm currently writing particle systems in Objective-C, but it wouldn't even cross my mind to use anything but straight-C arrays and for loops that operate directly on the data to store and manipulate particles. This is nothing like 'escaping from Objective-C', as all of this is still architecturally embedded transparently inside the rest of the Objective-C code, just using different data types (float * instead of NSArray) and calling conventions (direct data access instead of encapsulation). It's more like using hand-tuned data structures vs STL in C++, than like calling native code or writing ASM.js from Javascript.
[1] http://quellish.tumblr.com/post/126712999812/how-on-earth-th... [2] http://componentkit.org/
[1] https://facebook.github.io/react-native/showcase.html [2] https://www.facebook.com/notes/facebook-engineering/under-th...
But back then internal adoption of React Native was definitely accelerating rapidly and it was solving very real organizational and developer experience problems. The original motivation of the project internally was to solve developer experience pains, just like React but for mobile.
- With such a large app (Facebook), the compile cycle was becoming quite slow. RN has no compile cycle.
- You've got 3 teams (web, iOS, Android) per product (eg. Events, Groups, etc) and they don't really communicate or share any product code despite building effectively the same thing.
Take the Mobile Ads Manager app: Now one team (of web engineers) can ship an app on iOS and Android, while sharing 83% of the code between each app, in half the time the project had budgeted for just the iOS pure native app. Not to mention the team constantly loved their jobs because they didn't have to wait 5 minutes for the damn thing to compile every time they made a change.
All by manager's and client's decision. It was a horrible experience overall.
Poor user experience doesn't mean much if you are not on the market soon enough.
Which should be obvious on HN, and it's a point PG himself has iterated several times...
90% of the time this doesn't apply. The "need it done last week" attitude is mostly undeserved.
[Edited to clarify that of course I can't blame my mental health problems on a UI framework... but I keep the formulation for the sake of sympathy with anyone else who may feel less than "delightful."]
It was pretty cool at first, after a couple of months of trying to get the thing working decently without crashing, lagging, or just sucking, I gave up on the whole project.
I don't doubt that many people use React Native with delight. But there are aspects of it that are likely to cause frustration. It's a mashup of two incommensurable platforms, and in the gap between them there is horror.
What expectation do you have when deciding to use a framework which hasn't even released it's 1.0 yet.
Did we forget the customer somewhere? What ever happened to trying to wow your customers rather than simply tolerating them?
This attitude makes me crazy angry. That one comment just revealed everything that's wrong with many product companies: just give the user a 'good enough' experience. If you aren't striving to create a delightful user experience than you're disrespecting your users. Laziness.
If Steve Jobs had heard you say that, he would have fired you in an instant -- and for good reason. We owe our users a delightful experience, giving them anything less is just unacceptable.
Which part of "equivalent" did you miss?
You're entirely missing the point. This isn't about product experiences whatsoever. You can ship equivalently delightful experiences in React Native as you can in pure native apps. The point of React Native isn't to make your app more delightful.
The point is to develop it faster, in a more enjoyable manner, and enable one product team to develop for multiple platforms. This is an incredible win organizationally and for developer experience.
> Steve Jobs would have me fired
Check your ego.
And unlike Firebase, Parse et al it is based on posting messages to streams that people join, rather than diffing objects. This way you can have a history of changes, and just focus on implementing the front end handlers for the changes.
Do you feel the same way about Xamarin? I'm just curious as I've been considering moving to it. My company has been developing on Ionic the past year or so and it's become quite cumbersome as a platform. Basic apps look alright in Ionic, but is plagued by web view problems, making a non believer in the platform. Xamarin seems to compile better and avoid the web view. I guess I'm just looking for opinions.
That was a long time the case for Xamarin, but if you look at their customer forums, reddit, stackoverflow etc you will find the negatives too nowadays.
I am not interested in .NET, so I would not personally use Xamarin anyway, but I know that with Qt for instance you have to be careful with mobile UIs - it's best used for custom stuff and not native-looking apps.
Although Android is going to give you most headaches of those three, as the NDK is pretty anemic and JNI is not that friendly, but with help of JUCE and Djinni the pain isn't that hard.
The advantage is that you get to write a portable application without extra third party layers and have full support of the available SDK tooling for debugging issues.
You only know when you notice something is wrong.
Slack is the second-worst offender. It feels less native than many websites do.
The other is Rubymine, which on Mac now includes its own embedded Java runtime. It's significantly worse, but they are neighbors on the spectrum. Slack suffers less because it's mostly just chat, which can be done even in a Terminal window (e.g., IRC) without suffering that badly. But when you try to do anything in Slack other than just chat, the non-native kludge factor quickly becomes obvious and irritating.
That's a bad example. There are apps where you absolutely not know. It's not even a "subjective issue".
As long as you have either
a) wrapped native widgets with the same look and behavior as native (or a fully skinned app vs a fully skinned native app)
b) response times below some objective, determined by human physiology, threshold
Then it doesn't matter if it's a higher level framework doing some wrapping, you don't know it at all.
Once you have a a hammer (javascript), it doesnt mean you should apply it everywhere.
It's not clear from your comment whether you're familiar with React Native architecture or not. A React Native app works by using JS/React as the "brains" of the app (http services, state, smart components) and runs this in a separate thread to a 100% native portion of the app that uses uses platform specific native ui controls. Animation performance is pretty good because of this multithreaded approach. So in this way your JS app brain can be portable across platforms, while the nitty gritty view layer may shift to accommodate the capabilities of the native components you work with on each platform.
Of course, who wouldn't? The problem is resources. The alternative to not horrible/bad (React Native) for many devs is either horrible/bad (Ionic etc) or nothing.
We have now Facebook, a major actor on the web, who is developping a cross-platform toolkit for application development, using OS native widgets. XUL, I miss you :) And now others try support different OS.
Mozilla created everything and they just failed to "market" it. It s at the same time a pain and a joice to see real JS applications, shadow dom, custom components, CSS based styling being the core of a toolkit while we saw XUL/XBL/CSS/native calls from Mozilla be killed a few months ago. It had its flaws, but it s a serious (but really difficult) way to go : Qt did it, Gnome did it, Microsoft did it, even Adobe tried to do. Mozilla and people involved in previous ideas and implementations deserve a special mention for their work.
We really need such technologies, and that Mozilla killed theirs was a really sad choice for me. Creating software with "simple" markup, "simple" styling rules, "simple" event/user interaction handling should be a concrete goal of decades of languages/compilers/interpreters researches.
It has a price : performance, sometimes native look&feel not perfectly accurate, supported platform must have similarities. We may hopefully reach a level where a <button> tag will cost 1% of overhead against a native call and this will be a great day. I hope these new implementations will succeed, and that the actual overcomplexity in the web developpement will not land in though.
Also known as XAML and QML.
It is a pleasure not having to deal with HTML + CSS + JavScript tricks to bend the DOM to fake UI widgets.
Disclaimer: I didn't feel the user experience you described. (and have a lot more experience with XUL than QML)
What I experienced is that actual performances of crossplatform "runtimed" toolkits are enough for desktops and acceptable for mobile devices, but the global overhead (compared to a binary using native OS widgets) exists, beginning with startup cost, memory consumption, i/o latency. In fact, the same constraints that VM-based languages have. And even more : the underlying GUI toolkit may be used in an unexpected way, strange GPU driver behaviours may pop up, how not to be bothered by OS fragmentation. And then an application may run flawlessly on a device with a given OS while on another it performs not that good.
While I think it's correct to say that VM-based languages does not have to blush in front of compiled programs when talking about raw computing performance, my experience (as an ex XUL-lover, I may be biased) make me think that this is still not true when UI is involved. Java has maybe the oldest (and most optimized ?) runtimed UI, and it does not convince me. OK, this may be a bad example : Java UIs are "runtimed" at a different layer. but seeing the length of the QML performance wiki page is a bit scary :)
Maybe the "1% overhead" is an unreachable dream, and maybe the native apps will become deprecated, but I think there are a place for improvements. How many attempts of crossplatform UI runtime exists ? Not that much. With hardware improvements, the overhead will be more and more acceptable. It s a huge work, and previous errors should be looked at (rant time : Mozilla: you should not have stopped to use native widgets - Adobe: Flex - QML: mimicking web dev like XUL did is nice !).
Though, I am really impressed by Qt and .Net SDKs and I would really love to see more free software and linux surprises from Microsoft with the Xamarin acquisition.
And, let's be utopic, the future is maybe about a standard API à-la POSIX for end-user applications, where OS vendors will agree on an app, and natively implement their own <button>, their own <menu>, their own <video>. They do if for the browser, for the "webassembly", why not for the OS ? Or the browser will be deeply integrated in OS and the "web" apps will replace all native applications. Or they'll still coexist for years.
OK, anything but embedding a webview would please me :)
XAML engine is native C++ code, no VM. Since Windows 8 there isn't also a VM as such on the .NET side, given the AOT compilation support.
Similarly QML is only interpreted in the free version. Commercial Qt compiles QML into native code.
This is what makes the whole idea a complete non-starter. Users want apps without perceptible latency for their interactions, that look and (more importantly) work like the other apps they are used to. Hard to come up with more important criteria for a successful end user application than these.
W3C made it possible for web.
W3C provided what might be akin to C compiler standards which are only partly followed by implementors.
The rest is handled by libraries/frameworks/polyfills that get you 80% of the way there.
A part of me sees react-native adding another option here - "write once, tailor anywhere"
While it's always been possible to have common core logic and then tweak your frontend for each platform as a separate project to get a slightly closer to actual native experience, react-native makes it significantly easier to do so and I think it's that one+ standard deviation away ease that makes all the difference.
I don't think we'll see a lot of successful react-native cross platform that goes for the one-size-fits-all approach but rather, with the same (probably even less) effort, we'll see react-native apps that target the UX of a platform rather than just the UI elements.
https://talks.golang.org/2015/gophercon-go-on-mobile.slide#1
Fast enough to be used by the Windows Shell, Office, Edge, HoloLens, and Xbox.
http://www.joelonsoftware.com/articles/StrategyLetterV.html
Facebook is an application / services company, so it wants its competitors to be non-existent or expensive (luckily, so far, it's more the first than the second), and its complements to be free / cheap and ubiquitous. Hardware / software / networks are its complements so it tries to make them free (give away internet access, build open source servers and routers, make cross-platform libraries, and so on).
Google is in much the same boat, and does much the same kinds of thing.
Apple is the reverse, so it wants its platform to be anything but a commodity, but apps to be free / cheap and ubiquitous (hence the App Store). Similarly, insofar as it creates differentiating development tools, it would prefer they be platform exclusive. (Swift isn't a positive differentiator; it mostly addresses a platform disadvantage, so it's free and open source.)
Sure, this would all need to be reasoned about carefully to avoid visual security loopholes, but it's not like we didn't live through Flash and Java.
Some reservations to choose RN: RN is possible due to the JavaScriptCore framework build by Apple. It is the bridge between JavaScript code and Cocoa API. Apple designed this so that you can use JavaScript as scripting language for Cocoa. The popular Sketch for OS X is using the precise JavaScriptCore to power its plug-in scripting feature. I guess Apple never have thought JavaScriptCore could be used the way RN does. Choosing RN means your app is relying on Apple's decision on JavaScriptCore API. Someone please enlighten me if RN is still possible or not if Apple remove JavaScriptCore.
JavaScriptCore opens up the Cocoa API, but does not give you a JavaScript ready API. So RN has to implement the bridge internally. So when iOS 10 is released, you will have some lag waiting for new features or changes to be supported by RN. I guess this is common problem to all cross-platform framework.
In order to implement RN for Android, Facebook implements its own JavaScripCore for Android. I have no Android experience, but what I read is RN app for Android is not performing as natively as its iOS counterpart.
If your business rely on all Apple's platform, then choosing RN does not help as there is no RN for watchOS and tvOS.
React Native will make app manager and web-dev team happy, but not those who treasure the last mile UX experiences. But is could also be useful for those startups creating their first MVP. Get app release fast and then change to native codes when you got the traction. Is this good or bad startup advice?
It will be a different ballgame if Facebook announce they are moving to use 100% React Native for Facebook for iOS app.
Just because the tool isn't the right tool for your job means nothing about how good it is. graph databases aren't the best at searching large singular tables, but that doesn't make them useless.
Edit: It looks like the iOS version is built using React Native, but the Android one is not. I can't comment on the iOS version as I've never used it.
Because, in my experience, React Native is the first framework that actually feels native, and often results in apps that behave identically to their native counterparts. One of the big reasons for this is that it actually is using native components in most places.
Facebook's philosophy isn't that you should write platform-agnostic components and use them everywhere. They actually encourage using platform features wherever possible, but at the same time the way you write the components doesn't change across platforms -- "learn once, write anywhere."
Your customers are probably downloading GBs of data in advance because their reception/speeds outside the MRI room aren't sufficient.
Yes, the problem is that connectivity is often absent, poor, or slow combined with the fact that the app is useless without the entire dataset available. And you're collaborating with a team, so you have 10s-1000s of disconnected clients.
No such thing as Wifi, sure, but why can't the hospital run ethernet into the room?
I've been using React Native on iOS in production since last November for http://townske.com/app,
Over that period, I did hit some performance issues, but the vast majority of those were implementation flaws (i.e. my fault), not framework flaws. Real user feedback has been overwhelmingly positive, including being featured in the app store multiple times.
I just launched another app for iOS and Android last weekend (https://curbitapp.com) that was built with React Native in a few weeks, and shares about 80% of the codebase. I haven't spent any time optimising these apps for performance, other than following standard react best practices and see sufficient performance on both iOS and Android.
For someone who has a web background, React Native is a no brainer. 60fps native UI is generally attainable, you can use the exact same tooling (good dev tools, hot reloading), and you have the ability to pick up a large chunk of your code and put it on Android, or web, or now potentially OSX.
After downloading Townske I get hit by three modal dialogs one after the other:
* notifications
* location access
* query about installing an update, even though I've just downloaded the app. If I select install, nothing happens, no progress bar or anything.
Developing for a platform is more than having native-looking widgets, it also means taking conventions and user expectations into consideration.
I am referring to things like the tab bar which has a back button, having a next button and also page swiping in the intro, not throwing popus at the customer, etc.
As well as devs following good practice with modal dialogues.
I used Titanium to build a cross-platform app, and once I understood what it is writing with my JS, I could ensure native/performant UI elements and animations were being rendered.
Really excited to see how this pans out :`)
The two permissions modals are required by iOS to access those features, and RN definitely has the ability to defer when those are shown.
The update prompt is actually from http://microsoft.github.io/code-push/ which allows us to push minor updates directly to the app without going via the app store. Say goodbye to 2 week time cycles. A newer release of Code Push actually doesn't prompt the user at all, and can download an update during use and load it when the app goes inactive.
I especially enjoyed the subtle transitions and animations. I also saw a prompt to update immediately after downloading the app, which was strange. If you're updating the layout and such directly, then that's actually pretty cool. Is that the case?
I especially like that it gave me the option to register later (also the reason why I didn't get past Curbit intro since registration was mandatory). I was able to dive right in.
It sounds like an IP issue waiting to happen if you are admitting here to sharing 80% of the codebase from Townske (employer) into your Curbit (your personal app).
I can't agree enough. Apps built with cross platform frameworks like Cordova and React Native will obviously be slower than their native counterparts, but I've seen the framework blamed for bad implementations many times. Once, we tracked down a horribly slow Cordova app down to too many localStorage accesses (solution: indexedDB or SQLite).
Note: I really don't mean this in an inflammatory way; it just feels like people are rediscovering the cool stuff about Qt and reimplementing it but worse.
I'd love to see React and Qt talking to each other.
But at the very least this is not React-specific.
I have my fair share of Haskell experience so I get the benefits of statelessness. But I don't necessarily think it's a silver bullet for UI.
And is easier to bring web devs onto desktop app development.
And is faster to prototype.
And is probably a better way to develop desktop apps.
</kool-aid>
See eg https://en.wikipedia.org/wiki/Declarative_programming#Functi...
But it's a strict subset: config files are declarative without being functional. Raw data is declarative without being functional. One could argue that imperative functions are declarative too: "This C code is the declaration of what steps to execute in what order". So the definition of declarative can be a little fuzzy around the edges, but pure functions are most certainly declarative.
Anyway, QML is most certainly declarative, however it's still not functional because there's no functions.
With React you don't have a template. Every change generates a new virtual-HTML page, and then a diffing algorithm figures out the cheapest way to update your existing HTML with the changes. That makes things far simpler--your renderers are just HTML-generating functions, not some magical view-view_model thing that has its own syntax and workarounds for its limitations. UI is more testable because you can verify the actual HTML output, not just view_model state.
Would love to see something similar to React on other GUI platforms as well.
In QML one has QML components, which are JSON syntaxed files that can include other components and Javascript code. A component can be anything from a UI widget to a a camera object that can be used to take pictures, etc. QML encourages model-view programming which is a proven pattern used in the best UI frameworks on pretty much every platform. Nothing magical or limiting about it.
At least on the iOS and Mac, I don't really want to give up on Swift in favor of Javascript.
I like React on the web. In my view, conceptually it's the most interesting framework out there and that's saying a lot, given the jungle of JS frameworks populating the web.
But I also like UIKit and the other native frameworks, now that I've spent so much time learning to use them right.
I'll give it a try anyway, I'm sure there's something to like about it and probably something to learn too..
I'm not scared of Swift or Java, But I am frigthened of their ux. Even big apps like eclipse put me off, due to their bloat.
Also frameworks like QT don't offer the same ease of development.
Remember React-Native is currently on version 0.22, and over a year old. IMO it currently offers much better ux than TK/Swing/Qt/...
The day it offers something like Expression Blend, Qt Creator, Netbeans Matisse, Scene Builder, Storyboards ... I will believe it.
When a product needs to go mobile for the first time on two platforms you have to make a business decision:
1) You can grow the team to tackle both platforms in parallel. 2) You can have the team do it one platform at a time. 3) You can have the team do it one time.
Every option has big trade offs in either cost, time or user experience. There's somewhat of a gradient there as well in terms of code reuse giving the options avaiable right now.
React Native sits somewhere between 2 and 3.
It's really a matter of context for the business. How much time you have? Resources? What does your target user expect?
For a lot of B2B companies, there's just not enough value added to choose between 1 and 2 since you either take more cost or more time to market and your user just needs the feature not the best possible experience.
For a lot of B2C, your product may already be born mobile and you need the best possible experience to compete.
Applying that to native desktop application development has me so excited its not even funny!
Also, have you noticed any slowdowns at all vis-a-vis fully native apps?
Thanks.
The biggest difference is that for real cross-platform support you need to be careful which APIs you choose to use; some have cross platform equivalents, but not all. In addition, we didn't want to just render the iOS UI on Android, so we replaced some of the components, about 10% or so to get a more native Android feel. Because the iOS version is more mature, we started with it and migrated it to Android a few weeks ago.
The biggest thing, and this is not even React Native specific, is to ensure that the components are implemented with flexbox correctly and the layout adapts properly between screen sizes. Because Android has such a disparate set of screen sizes and devices (and iOS lets you "cheat" a bit because the set is so much smaller, letting you hardcode sizes/layout that you shouldn't), some discipline is needed.
Lastly, your top-level container component will likely use padding on iOS to not overlap the status bar, don't forget to remove that on Android, because it renders it the way you'd expect: below the status bar, not underneath!
EDIT: See below, this is no longer the case as of the latest versions?
Edited to add:
We're running v0.21.0 here, and I know there were still issues with certain libraries causing conflicts even running up to v0.20.0 -- we've not had any issues since upgrading mind you.
We've been working on a banking app, and most of the rough edges we run into are not dealbreaking (limited transition types, weak animation support, etc) and can be worked around either with native patches or are expected to be solved as the platform matures
Android: Not as mature, but with some careful choice of libraries (effectively eschewing native libraries and sticking to Javascript implementations where possible) we had basically no issues.
Tooling for Android isn't as nice as iOS in my opinion (specifically the simulator even with Intel's fancy extensions sucked compare to the iOS simulator), but because we lived mainly in Javascript-land this was rarely an issue. Debugged and tested on real Android devices (this is one thing that worked really nicely with little effort).
This is a real production app for a software-as-a-service product, though it's getting a small controlled rollout to begin with. I'll be writing up a blog post or two on our experience, so keep an eye out on my website over the next few weeks/month or two -- I'm not expecting any issues though, as our beta testing has gone brilliantly :)
I hope it's extended to Windows eventually.
This... does not. The screenshots look like webapps that try hard to look native, despite actually being native.
The text in the top-left textbox in the first and second screenshots looks weird, because its baseline is too high. The box around it in the second screenshot has weird corners, etc.
Now, I'm not an OSX user, but with all the talk about OSX having the most polished interface, I highly doubt weird things like this are common.
Update. Filled the issue https://github.com/ptmt/react-native-desktop/issues/52
This is a selling point. CSS can make an app look beautiful, native look-and-feel is always atrocious, everywhere.
If I use 5 applications and they all look entirely different, it will not look beautiful, and each time I swap to a different application I have to re-familiarize with whatever the UI designer thought was a good idea for that application.
I'm working on the code editor right now, so I'd like to build something small (few megabytes), performant, but allows me to use the whole js ecosystem.
https://github.com/facebook/react-native/graphs/contributors
https://github.com/ptmt/react-native-desktop/graphs/contribu...
so very few of the 5.5k commits came from the OS X port
"No it's not like Java this time!" "It's not like Carbon!" "It's not Flash!" "Don't worry, it's no X11!"
If you care about the platform, go native. Learn the rules and look and feel. If you don't care that much? Maybe you should reconsider the port. You can't "click this checkbox for OS X", it doesn't feel right.
It's just a way to use the underlying native UI. It's not a bunch of emulated components with a pluggable "look and feel". They're the real thing, just wrapped in a JS API.
I've tried few plugins and there's no production support yet.
Let me know if you guys know of one
I have a sense that there should be more versatile components for desktop, I guess once it takes off, there will be those.
Thank you.
[0] - E.g., PhoneGap apps on iOS & Slack app on OSX
For OS X though if I were to get into a project I'd go the Electron route.
For a recent example, having gotten used to Transmission (BitTorrent client on Mac), I was absolutely floored at how absurdly complicated and ad-ridden Windows alternatives are.
There are very few applications that I miss from Windows. Most big cross-platform applications like Photoshop (or even SourceTree) are almost identical, but the majority of Mac-only apps that I try are fantastic.
Reeder (RSS client), Fantastical 2 (calendar), Tower (git client), iTerm 2, 1Password, Transmit (FTP/SCP client) and TextWrangler/BBEdit are just a couple of examples of apps I use every day that I think really show off what Mac developers can do.
[1] https://www.transmissionbt.com/images/screenshots/Mac-Large....
Unlike many cross-platform applications, Transmission integrates seamlessly with your operating system.
The Mac OS X interface is written in Objective-C and uses Growl notifications and dock badging to keep you informed.
https://www.transmissionbt.com/about/
There are many apps that are miles ahead of Linux or Windows equivalents: OmniGraffle, OmniFocus, Acorn, Pixelmator, 1Password, iTerm, Alfred, (Git) Tower, etc.
Where? I vastly prefer native OS X applications to both Windows apps and most Linux GUI apps.
Compared to what? I like native OS X desktop applications better than native Windows, Linux, iOS, Android, or Windows Phone applications, and I like them MUCH better than web apps.
The main reason OS X desktop apps tend to be so nice is (a) Apple’s first party software in the 2000–2010 timeframe was mostly quite good, setting a high standard; (b) GUI conventions are reasonably standardized and developers tend to follow them better than on other platforms, in particular using native widgets which handle edge cases better than various ad-hoc custom (i.e. buggy) widgets on other platforms; (c) the Mac app economy has been pretty good for independent developers, and there’s a cultural expectation of paying for software which is much less present on other platforms, so as a result developers can afford to invest the time necessary to add polish.