Developing Our First iOS App with React Native | Hacker News Reader

Developing Our First iOS App with React Native

code.hireart.com

219 pointstomtang2131 comments

Truthfully, the language barriers are nothing next to the API barriers dealing with your platform of choice. I am probably giving away my age here, but there's very little that's new under the sun after you've tussled with... say one each of the big three language families. These being: Nasty old C (not going anywhere, ever. Deal with it.), modern scripting languages (Ruby, Python, et al) and the real deal functional languages (lisp, ml, haskell, etc). It just turns into "Oh, this is how they handle an array. Do I have any functional plumbing? Ok, great. How do I dispatch a thread? Ok, let's go." It's just not that interesting after a while.

Objective-c is quirkier than most, swift is nice but still baking, but it really all boils down to the platform APIs. And you're gonna have to get wet at a platform level if you want to provide functionality beyond a mobile web page. (Albeit one with improved load times since it's coming from disk, at the cost of dynamic updates since it's coming from the app store.)

Yep this is what I'm realizing after a few years of programming. I can pick up a language easily, however learning it's APIs is almost as hard as learning the syntax for the language itself.

Like how do I open a file? Ok cool. How do I close it? Do I need to explicitly close it? Ok.

Also, learning APIs for other peoples codebases/software is task of learning that isn't trivial too

This is why language oriented programming is a better alternative to everything else.

I agree. Keeping up with the giant, buggy, constantly changing, platform API, as well as the whole ecosystem, from build tools to the app distribution and analytics, is by far the hardest part.

These abstractions on top of the platform might make it easier for quick prototypes if you don't have time to learn the language. But you'll lose some flexibility, power, visibility and community. After a while the initial speed benefits wear off since the language is a small part of the things you have to stay on top of, especially if the app takes off.

Those are the extremes, so once you know those you can handle most things. Some modern languages seem to have a foot in each camp, like Rust for example.

We should graph every programming language on a radar chart using those axes.

Syntax is easy, semantics are hard, cultural norms take time.

Yeah, I find the learning experience of any language to be like that, once you have a few under your belt.

Except Haskell. I can do the trivial stuff, but anything non-trivial is a chore to learn. It is not as if it has a learning curve, it has a learning brick wall that hits you very early on.

That is one way to write the code, but if you do it that way you will never get the benefits of each language. Haskell and Lisp are both functional, but they way they are intended to be used are very different (example: if you don't use macros with lisp you are probably missing something. If you don't take advantage of lazy evaluation in Haskell you are also missing something).

Uhhh, I never suggested writing lisp in a C style, or ruby in a functional style (well, more so than it encourages at least). That would be crazy. My point is that there aren't that many ideas under the sun. Lazy evaluation, super. Monads, ok. Real-deal, no playing memory allocation and management? Where's that union stashing variables again? Are you sure? Uhhh, fine I guess. (Although I'd rather take the monads.)

Lazy evaluation is no longer exclusive to Haskell and other functional languages.

C# has had Linq for lazy evaluation of data collections for many years.

Javascript supports observables now and ot's only a matter of time before they're included in the official spec.

Reactive Extensions has been extended to many different languages now.

Lisp macros are essentially higher order function definitions. They can be trivially applied using decorators in Python and closures in Javascript (JS decorators will be supported in ES7).

> Lisp macros are essentially higher order function definitions.

Definitely not. Lisp already has higher order functions. Macros are something entirely different.

> They can be trivially applied using decorators in Python and closures in Javascript (JS decorators will be supported in ES7).

Of course not. Decorators and closures are in no way related to Lisp macros.

There is enough literature about Lisp macros... For example a certain Paul Graham wrote a book explaining them in detail:

http://www.paulgraham.com/onlisp.html

> Lazy evaluation is no longer exclusive to Haskell and other functional languages.

> C# has had Linq for lazy evaluation of data collections for many years.

> Javascript supports observables now and ot's only a matter of time before they're included in the official spec.

> Reactive Extensions has been extended to many different languages now.

These things are quite different from having pervasive laziness, though.

React-Native isn't just a JS-wrapper, you're trading away language safety features (e.g Swift) with features to help with transient state (React).

Of course you can mitigate that with RxSwift, but it only goes so far.

Concurrency is a real bear on mobile, and it isn't something that can be ignored (a la the web) when you're that close to the metal. I'm an explicit js chauvinist, so maybe they've gotten something together on that front, I wouldn't know, but that's a very serious concern of mine with js-outside-its-proper-place-within-the-DOM.

i agree with you, although i think you are forgetting to add (and maybe it is implied here and i missed it) that learning mobile development requires you to not only learn new language APIs in objC/swift, but you also have to learn some new design patterns (delegation, etc.) and most importantly the SDKs (CocoaTouch)

if you can use react native and avoid learning a lot of this it is a big win - I havnt used it yet, and I have a hard time believing it a mobile only company would use it to build their mobile app, but i am excited where it is going.

>learning mobile development requires you to not only learn new language APIs in objC/swift, but you also have to learn some new design patterns (delegation, etc.)

Delegation has been a standard feature of desktop APIs for decades. Not just on things like Smalltalk and ObjC -- it has been the standard .NET model for UI events since C# 1.0.

sure but the majority of developers writing code write webapps. Some there are some desktop apps out there but not a lot.

Going to need a source on that 'majority' of which you speak of as if its a fact. Sure, web development is popular, but there are a _lot_ of developers working on other things (which potentially include delegation). Also, I'm sure you'll many web frameworks that use the delegation pattern.

I'd say the majority of developers write enterprise code, whether web or not.

So here's the real bear of it, and the crux of my argument.

The delegate thing is an iOS thing. Android uses a totally different pattern. I mean, there are delegates, to be sure, but android loves their anonymous inner classes in many of those cases. (Which is closer to idiomatic js IMHO.)

So on a language level sure, easy peasy, you could delegate in javascript all day long (and you do). But on a platform level, nuh-uh. One is going left and the other is going right. How do you meet in the middle? What fine line gets scrubbed in between?

React-Native pattern with delegates is passing down functionHandlers to childComponents that would trigger them.

Except Objective-C (and Swift) had protocol conformance. Though come to think of it TypeScript allows you define an interface for a Component, one of those attributes could be a function.

Not really getting away from it. ;-)

Isn't delegation just a slight variation on callbacks?

Basically yeah. An object can have one delegate object, which implements a set of required and optional methods defined in a protocol. So the delegate can add customized behavior to an object without subclassing.

I found this true in my case too. The API/Framework was the thing I had to learn.

As far as React Native, I can't see it being used seriously. I think teams are going to have to know native iOS and/or Android programming anyway.

But seeing the mass of apps that never live beyond a year, maybe React Native is just the thing.

No one is doubting that you'll need people who know iOS and Android ecosystem. But React isn't just a wrapper over native views. It's a fundamentally different way to write up applications compared to the way you work your way around states and UI.

While I agree with you, I also think that it's easier to overcome one of those hurdles first, rather than to overcome both at once.

I guess I see it as a form of technical debt-- you move faster, but past a certain level of performance it's all gotta go native. There are a lot of places it would be a decisive win. There are a lot of mobile websites that are great. But there's a ceiling, and once you hit it, all that javascript is gonna get rewritten.

Where does C# fall among these 3 families?

The C category.

A 4th category is probably needed for statically compiled, garbage collected, OOP languages.

The reality is, most/all of the most popular languages blur the lines.

Javascript is getting official support for OOP as well as better support for functional programming.

C# has good support for dynamic typing as well as many functional characteristics.

High performance Python has always had the ability to delegate to C extensions.

Etc

Agree 110% on the blurring, and maybe a 5th category too - 4GL, for SQL and its ilk.

Obj-C, Obj-C++, C++, and C can all co-exist in the same codebase and be complied into 1 output (if you are insane enough to try), similar to CUDA or Fortran with C/C++. That's not really possible with JVM or CLR languages, but not impossible either. Which makes them more like 3GL/OOP while sharing more similarities with smalltalk than 2GL/C.

Py, Lua, GLSL/HLSL, and many others can "mix" or be called by C/C++ similar to CUDA, and Lua is definitely in the interpreted "script stuff" bucket, not statically compiled like Java, C#.

The shader languages like GLSL/HLSL are really confusing to categorize, especially when used with C#, because they can exhibit characteristics of 1GL thru 4GL.

Can't forget the declarative regular and context-free languages.

XLST and other template syntaxes are another interesting case. They look mysteriously like a declarative context-free language but have imperative characteristics of a turing complete syntax.

JVM may not be able to be combined with compiled languages but there are a number of languages that, at a bytecode level are compatible with Java. For example IronPython, Rhino, etc. The same can be said for the .NET environment and languages like VB.NET, managed C++, C#, F#, etc.

Don't even get me started on languages that can output output Javascript. Last I heard, there's over 100 of them now and the list keeps growing.

I'm not sure about GLSL/HLSL because I haven't used them but they sound like they're declarative DSLs (Domain Specific Languages).

Maybe it's about time somebody created an update to the Chomsky hierarchy. Instead of the traditional subset-superset classifications, some other system is used to compose the characteristics of languages.

In the bigger picture of things, it's all very incestuous. Like every language is trying to be like every other language. The winners of the pack are those that everything else compiles/transpiles down to.

I've been out of the ecosystem for a while but isn't it closer to type inference than dynamic typing?

C# has both. "var" for type inference, "dynamic" for dynamic typing.

I feel like C# (and C++, and Java) would all be basically in the C camp. C# and Java could be arguably somewhere on a spectrum between C and the scripty stuff.

React Native is pretty awesome - especially if you've got a web version of your app. At work, we use React Native for our iOS application - and are able to share pretty much all the store & action creators logic for our web (and desktop) app. It's been pretty huge as all our iOS engineer (we only have one!) really has to do is do the view specific stuff for iOS, the rest being shared with the web/desktop version. Also, our engineers that work on the web application can contribute to the iOS app with ease too.

Our general product iteration strategy involves building it on the web version and then porting it to iOS fairly quickly. For a chat application, our stores handle a lot of data, so it's been awesome to have that code shared.

React Native's bridge is also alright. We bridge with Component Kit for the chat messages view & WebRTC for the voice side of things fairly easy from JS.

Also, being able to update the bundle w/o doing an App Store update is pretty big too.

Here's the app if anyone wants to try it: https://itunes.apple.com/us/app/discord-chat-for-gamers/id98...

Just wanted to say Discord is awesome!

I didn't play on-line for years, last time I did regularly, the standard for voice communication was Ventrilo/Teamspeak. When I first used Discord a couple of months ago, I was just shocked. It has a decent webapp. I can create my own server for free. It takes less than a minute to get going. It just works.

Truly amazing work, keep up

On a more technical note - I'm exploring React Native (having significant experience shipping native iOS Apps) and while on the face of it React Native looks amazing, as I go deeper into building something production quality, I've hit roadblocks with doing simple (natively) things like scrolling a scroll view to focus on a text field that's partially visible and changing the offsets of a scroll view to prevent the keyboard from masking the focused text field in a way that doesn't appear glitchy.

Did you encounter any such problems?

What are you hoping to get out of using react native?

This write once, use everywhere is such a strange desire.

If you're a serious company, develop on iOS/Android first, then hire a dev or two to make an exact copy for the remaining platform. It's really not that hard.

The hard part is doing something the first time and iterating. Copying is not rocket science - look at the Russian facebook clone - it's actually better because of copyright laws, you can do more on their version.

There are two fundamental issues with the mobile first approach.

Duplicate effort does incur a real cost in terms of time to delivery. Duplication is a clear sign of inefficiency. A platform that provides native support for multiple platforms reduces such duplication.

The maintainance cost of providing multiple platform-specific implementations compounds over time. For every feature added there's a chance that subtle differences will be introduced. In a perfect world one platform developer will have an equal level of skill and understanding as a developer for another platform. In practice, there's no guarantees that both versions will be kept in sync. The differences and abstraction leaks become technical debt and accumulate as the platform grows/changes over time.

Now, lets say you want to provide a web, iOS, Android, and Desktop interface for a platform. Would you choose to do 4 independent implementations in 4 different languages. Or 1 in a single language with platform-soecific differences?

Platform duplication is a violation of DRY at the system level and incurs the same problems of diplicating code, at a much larger scale.

The Russian Facebook is basically a independent fork. It's not required to remain feature-complete and in sync with the official Facebook platform.

I understand the theoretical upsides to one platform/language to rule them all, absolutely.

I am saying that trying to re-write the layout engine, data layer and all the rest to make it work the same on both platforms is not only a massive undertaking - it is ignoring the reason the platforms diverge to begin with.

iOS has features Android doesn't and vice versa. Something that works on both platforms is always going to be a second-class citizen - it's the lowest common denominator.

I don't want the lowest common denominator because it's 'easier for developers'. I want the best stuff.

The theoretical technical debt due to writing on different platforms is why we have software architects and senior developers.

Really, I've been part of a dev shop that does ios/android - the biggest hurdle is people problems, not code. People who don't know what a good app is or have any taste so they say first show me, then I will start asking for changes at random while insisting on a tight deadline.

As for web/ios/android/desktop - this is a rare bird, if you need to support that many platforms, you can afford an architect and some smart people.

The application layer is decoupled from the rendering layer specifically for reuse across multiple platforms. That means the data layer that handles data fetching and change propagation works everywhere.

The view rendering layer is the part that is specific to each platform and the React community provides web components that work natively on each platform making the development process between mobile/web more consistent. Mobile provides an escape hatch to write platform specific code in the native language.

"As for web/ios/android/desktop - this is a rare bird"

Targeting all, will remain very unlikely. Targeting more than one is pretty common. React and Angular2 are pushing hard to enter the mobile development ecosystem. Microsoft has been pushing for Typescript usage on the desktop and just picked up Xamarin so we'll likely see desktop or web or mobile hybrid applications at some point in the future.

If the barrier-of-entry to support another platform is low enough, it'll make sense to do so. In the current ecosystem, supporting even 2 platforms is a massive undertaking.

I just spent 5 minutes looking at React Native and my first and final impression is that this is a complete waste of time.

I am so flabbergasted that I took the idea seriously, looking at what it actually is, it is so clear to me that this is not going anywhere.

For starters - using Javascript when you could be using Swift/Objective-C is laughable. That's a non-starter. Then, there is no real data layer at all! You have to interface with Objective-C!

So what is the point of using this at all? To have shared view layer logic? Facepalms

> I am so flabbergasted that I took the idea seriously, looking at what it actually is, it is so clear to me that this is not going anywhere.

Facebook is using RN in production. So I doubt it.

> Then, there is no real data layer at all! You have to interface with Objective-C!

I don't get what you mean. You don't have to interface with any native code if you don't have a very specific need to use a platform specific feature which is not available in RN.

> I just spent 5 minutes looking at React Native and my first and final impression is that this is a complete waste of time.

If you spent just 5 minutes, it clearly means that you don't have enough experience with React Native, and I don't think you should give opinion on anything without at least being familiar with it. I've been working with React Native for months, and yeah, there are technical hurdles. But I'd say the same for Android, or web (I don't have any experience with iOS dev).

There are parts of React Native that suck. But there parts which are amazing. Amazing enough that I'll choose React Native over Java/Obj-C any day. The development speed with React Native is much faster than native Android dev. The DX is getting better day by day.

I get to share code isn't the primary reason why I love React Native, but it's an important thing for companies which want to support multiple platforms.

I'd say let's focus on fixing the parts that suck in React Native, rather than discarding a new tech without even trying it.

Ok hold on, you've been working with it for months? To what end?

Please tell me you're not using a library that's at 0.20 for production.

So you're using ReactNative for pet projects right?

As soon as you get to writing a real app that's beyond a to-do list, you'll be in a world of pain. Just start with having no support for a sqlite/database or an orm layer on top of it, only a key-value store as your first massive and insurmountable stumbling block.

> Please tell me you're not using a library that's at 0.20 for production.

I'm using it in production. And so is Facebook.

No, it's not a pet project, and much more than a TODO list app.

I've implemented one solution to this in FB's Groups App. Try that experience out and let me know what you think. Also, Nick Lockwood should comment here.

We should hopefully be able to open source a cleaned up version of the solution that Jordan alluded to, but we have a long list of components we'd like to work on, and only a finite in-house development resource.

I think it's important to understand that React Native is not an attempt to replicate the entire iOS native framework - it's a set of UI components that aim to provide a better developer experience for the common app development challenges we face at FB, combined with a framework for building new components.

When we encounter an uncommon challenge (i.e. something that we haven't already had to solve and build a reusable JS component for), we simply drop down to the layer underneath and create a new native component.

That's why I struggle to understand the argument that "React Native doesn't do this one thing I need, so I can't use it" - we put a lot of thought into the plugin architecture of RN, and making native plugins is trivial for anyone familiar with iOS or Android development.

If there is something you already know how to do natively, you can leverage that knowledge to build an RN plugin and then get the best of both worlds. If you don't already know how to do it natively, there's a good chance that someone else already made a plugin that will do what you want.

Is the solution something you can share on a general level? Would love to see how you approached it.

It's not incredibly advanced: It mostly just consists of measuring where exactly the current text box is in the scroll view, how high the text box is, and then having the scroll view scroll to that location, followed by fading in a docked text input right on top of the underlying one. It's pretty slick, but I'd encourage the community to recreate it in a reusable component and open source it.

> Learn once, write anywhere

What's most amazing to me about React Native was how quickly we were able to go from idea to product (~3 months working only part-time) using our existing knowledge as web developers. We did have to write a few lines of Objective-C here and there, but for the most part all of the views and interactions fell together the same way a webapp would.

As someone who is about to embark on a similar route, that's interesting and exciting to hear. Was it both Android and iOS? If so, how much of the codebase/time was spent on shared code versus needing to write platform-specific portions?

I've seen the Facebook post about developing Ads Manager (though it glosses over some details), but it would be interesting to hear other people's experiences.

https://code.facebook.com/posts/1189117404435352/react-nativ...

We built it for iOS, but I expect Android would have been a similar experience (albeit with much more cross-device testing required).

Hard to say how much of it was platform-specific, since we only targeted 1 platform (for now). But the large majority of the code we wrote exists in React components or in related JS files, so porting it over to Android should be a matter of decoupling the parts of the code that rely on native features (i.e. camera, navigation, etc).

A lot of that work is already happening in the React Native community so I expect the cross-platform support will keep getting easier.

After a while apps are just apps, and the languages all feel the same.

What I'm curious to know is, outside of the arguments about React being the superior pattern for developing UI's, how is this fundamentally better than or different from other hybrid libraries like Appcellerator Titanium or Xamarin?

In my experience they all fall short when you try to get the last 20% of your app written. Because you're not writing in the native language, directly accessing native API's, you're always going to be limited to the abstractions that the hybrid framework has (or hasn't) defined.

I much prefer either going full native or full HTML5 because I never hit a wall when I try to do something that hasn't been covered well by the hybrid framework yet.

React Native doesn't use embedded webviews and provides an escape hatch to write native code when Reactive Native's capabilities fall short.

That's no different than appcellerator or xamarin though. And in the case where you are just using embedded webviews you can easily write native code alongside them. Cordova is written in objective-c and is easy to understand.

You're right, I was thinking of platforms more like Cordova.

I did a little reading and it appears that React Native, Appcelerator, and Xamarin are pretty close to feature parity.

I'm sure this observation was probably made tens of thousands of times before, but- is the React Native and frameworks like it the beginning of the end of the "native vs. mobile web" debate? A synthesis of both approaches?

What I'm betting on is the mobile web browser. I know going HTML5 on mobile has failed in the past, but the future can still come. On desktops, desktop apps ruled until web apps became super powerful. I'm betting on the same fate for mobile web apps.

On my mobile I absolutely use and prefer native applications. I only use my mobile web browser for web browsing tasks. On my desktop, I only use my web browser for web browsing (searches, news, content, etc) and I hardly use any web applications.

I don't feel like I'm unique in this.

I think this "synthesis of both approaches" has merits.

There are times when the native app is great, but all the permissions that you have to give up have me fallback to the web version. There is a native phone app for a popular online course that has recently started asking for access to 'Phone Id/what not' on Android. Why? Just show me the videos of the courses I paid for. I refused to update and these days I just log in via Chrome and play the video on there. Not the best UX but that is what I will associate with that product going forward.

I wish Android would make something granular (and understandable) or at least let me disable permissions after the fact.

You can, starting form android 6.0. Adoption of the latest Android versions is as slow as ever, though.

But native applications use webviews more than you might expect. I've heard that the conversation view in the Messages app is a webview, and I know from first-hand experience (CSS not loading) the Instagram feed is one too.

I think that webviews get a bad rap because you only notice then when they're done badly.

Messages is definitely not a web view.

Searches and news are web applications. Not to mention Hacker News.

"The general distinction between an interactive web site of any kind and a 'web application' is unclear. Web sites most likely to be referred to as 'web applications' are those which have similar functionality to a desktop software application, or to a mobile app."

https://en.wikipedia.org/wiki/Web_application

An easy distinction I use is: can the user alter the content? If so, it's an application. If not, it's a website.

I'm the opposite of you. I'd much prefer to do everything in a browser. I hate downloading new apps for every little link. I was really hoping the Firefox OS worked out.

I don't even have a lot of apps, though. And using an web application is just as much work: logging in, bookmarking, etc.

Now that Chrome supports notifications (on Android) I was able to uninstall the native Facebook app and rely exclusively on the web version (which actually loads faster for my anyway).

Still have the icon on my homescreen, still get the same notifications -- the main difference is how much better my battery life is now!

Not to mention you don't have to store a 100MB app.

So you download it each time?

I think so. Reducing the language/framework barrier to mobile development definitely makes makes arguments for mobile web weaker. If you have a lot of mobile users and you want them to have a really good experience, going the React Native route makes a lot of sense.

I don't think so. I've participated in enough native / mobile web flamewars to last a lifetime, but the main argument this doesn't resolve in any way is the question of freedom. A react native app is still subject to Apple's App Review, or can be removed on a whim by Google (remember the ad blockers recently?). Some people have a real problem with that.

I am particularly interested in hearing about view transitions. I know JavaScript, Android, and iOS development and found that, while I could easily make a React Native app work on iOS and Android, it was lacking the polish that modular view transitions could provide.

>Java? Objective-C? Swift?? I don't have time to learn things!!! Now let's start coding XDDDDDD

Every cross platform mobile framework in a nutshell.

Its not the language thats hard, its the framework. Solution? Create a new framework?

Something is broken

> Not knowing Objective C or Swift

I think this is a key phrase here. I'm writing a RN Android app without knowing much about Java.

You can write a CRUD like app without any hardware/native code required. However, even when you do need that code - for example I'm building an app that records and plays audio - react native still gives you an advantage in the sense that you only need to expose a hardware API but all the logic still stays in javascript. I've managed to write just enough Objective C and Java to expose some APIs I need, and no more.

There is also a lot of react-native npm packages that abstract away the hardware issues, quality & completeness varies however.

Have you run into any gotchas? I am thinking of doing the same thing for a simple app.

There were definitely some head scratchers along the way, I think I address a few of them in this post but I plan to write a few more posts that show how we tackled some issues in more detail so keep an eye out for that.

This article is pretty meaningless without any link to the app so we can see for ourselves. I couldn't find it in the Apple store, did anyone?

Why is this on the top of HN ? Honestly, this is a bad thing, not a thing to show off.

To quote the author: "We're web developers, not iOS developers." EXACTLY, don't bring your web tech into native platforms, learn to do it the right way or just hire someone who knows how to do it.

Seeing things like that creeping into becoming a norm makes me cringe

This is on the top of HN because people, like me, are interested in it. You say learn to do it the "right way", by that logic we should have stuck to making desktop only apps instead of browser based web apps. I'm not saying this is better or worse. But I certainly think it's an approach worth considering.

It's a great piece of tech, I'm not saying anything against that, I'm saying that it shouldn't be used as a replacement for native programming because you don't want to learn a new language. react will come with huge limitations and deps that you don't want to even think about, it's never easy as "code once, deploy everywhere", this is usually a bad decision any company makes, engineering wise.. same reason as adobe air never took off, it's a bad idea, the only reason this is taking off is because people already know JS and don't want to learn something else.

By the "right way" I mean use every language for its intended purpose, you can't build desktop apps in browsers, that's why we have Javascript. and i'm saying we should keep it that way

React Native doesn't claim "code once, deploy everywhere", and in fact embraces native APIs where appropriate. As a reference, their slogan is "learn once, write anywhere". In other words, learn React Native, and write native apps wherever you want. Indeed one of the opening talks about React Native at React Conf specifically mentions that React Native is a leaky abstraction, and embraces that by allowing multiple escape hatches so that the native APIs are always available.

Railing against React Native seems like railing against Unity3d, or saying that abstracting the common parts of mobile development (while leaving the non-common parts 100% available) is a bad thing.

By the "right way" I mean use every language for its intended purpose, you can't build desktop apps in browsers

You can build desktop apps in browsers (ie emscripten). Additionally, can you explain why a "language" (as compared to platform specific APIs) has any relevance to what can or can't be built for a mobile device? For JavaScript specifically, if Apple didn't think that it was a language for building applications on iOS, then why would they ever have release JavascriptCore (which is what React Native uses)?

React is native. It's a JS interpreter on a separate queue rendering native UILabels and UIViews. I'd say the concept is far more superior to UIKit which disgusts me, and I've worked with for almost seven years now. I honestly think React is the future, but for now we can try to stick with MVVM and RxSwift ;-).

I think you're fundamentally not understanding how React (not just React-native) works.

This is mainly taking off because native developers want a fast build-run loop, hot code reloading, the ability to update code on the device without pushing a new App Store release, and a shared technology and mental model for writing apps across web, iOS and Android.

This is happening.

No, it is not. "I don't know what I am doing" mentality already hurts the web, where hordes of developers without understanding of the strengths and limitations of the platform are making angular monstrosities, now the same is being pushed to mobile. Luckily it does not have much chances there.

Regardless of your opinions on this, it's still worth examining and discussing.

It is on the top of HN because people find it interesting. People are interested in bringing different tech into native platforms to decrease how much it will cost them to develop the product and I for one don't really care if it is not how you are supposed to do "proper development". Once upon a time you weren't supposed to build servers out of commodity components, but it worked alright for google.

> learn to do it the right way

What is the right way? Native only?

There are many apps in the appstore that uses html5 and users of the app don't care how is it build.

I got flamed for my rant.

This is literally just a paid ad for React on the front page. Gross.

Is the app live in the App Store? Would love to check it out!

We just submitted it to be approved, hopefully will be live soon.

Great, good luck!

The biggest barrier to high fidelity ECMAScript apps on native platform is simple economics. Apple is guaranteed a $99 bounty when you push something on the appstore. Making Safari or WebView compatible with their native APIs and performance is a risk for AppStore.

Having built 3 non-trivial iOS apps using phonegap and JavaScript. I have come to the conclusion that I'm never going to build native apps using web stack. I have struggled with API support, DOM limitations and performance.

Disclaimer: I have not tried react native.

I think it'll fail for mission critical and non-trivial apps. If you just want an AppStore presence for your browser app or your app is trivial like one in the post. You are probably going to be fine.

You also appear to not know how it works. React Native doesn't use a web view at all. It uses JavaScriptCore to process UI updates to native views.

Good luck sir getting web stack to work with native that's at par with Swift/Obj-C perf. Also, do share some non-trivial apps that you/your team has built using web stack on iOS.

p.s. I've explored JavaScriptCore the first day it was available to developers.

p.p.s. I noticed you are a "React fanboy," so that's normal.

What exactly do you think is "web stack" about React Native? The fact that there's javascript involved in the high level UI state code? I really don't think you grasp the difference between React Native and the various "wrap a web app" approaches.

I've dabbled with this JavaScript for native code since 2010-11. Appcelerator Titanium SDK (now Appcelerator), Telerik, RubyMotion, Xamarin and of course PhoneGap (including PhoneGap Build). I've not used Xamarin, but putting it there to give a broader picture.

Please don't get me wrong, I'd love to use ECMAScript(, CSS and markup) to do all web, native and server side development. Unfortunately they are marred by poor API support, performance and customization. Last two are extremely critical for non-trivial apps.

If you are building run of the mill simple apps like - news feed, photo, video and reading etc. You'll be okay with anyone of the above 'web stack'.

Here's the litmus test. Ask the Reactive Native team to port their non-trivial paper app or mission critical messenger app or main app to Reactive Native. They are using Reactive Native for a lame duck Groups and some ad manager app.

JavaScriptCore is one layer deeper than wrapping a UIWebView, but it's several layers from true native.

> Here's the litmus test. Ask the Reactive Native team to port their non-trivial paper app or mission critical messenger app or main app to Reactive Native.

Facebook is rewriting the News Feed in RN. That's not a trivial example.

Correct, it's not a trivial app by a long shot. Also, a validation for React Native.

> They are using Reactive Native for a lame duck Groups and some ad manager app.

"Some ad manager app" which happens to be the ad manager for one of the largest advertising platforms on the planet right now. It's also composed of non-trivial UI, you should try it before blindly bashing it. I've used both Cordova, and Titanium, too, by the way - Cordova was relatively painless but lacked the native feel. Titanium sort of had the native feel but it was slow. The Titanium community also felt very hostile towards competition and they didn't promote FOSS. Maybe you're a Titanium developer?

> Unfortunately they are marred by poor API support, performance and customization.

Web apps can hit 60fps these days (again, using React (Canvas)).

> Here's the litmus test. Ask the Reactive Native team to port their non-trivial paper app or mission critical messenger app or main app to Reactive Native.

That's a really lame litmus test considering they've got a massive code base in native languages with no reason to throw them away since they're working perfectly and they have a ton of developers to throw at the problem.

> They are using Reactive Native for a lame duck Groups and some ad manager app.

They appear to be using React Native for most new apps that they develop. I would assume it would be up to the discretion of the team to choose whether or not to use React Native. Most do because React Native is way better than plain old native. Even the author of UIKit thinks so.[0]

I'd be interested if you could provide a common real world example where React Native wouldn't be a good fit.

Furthermore, React Native never claims to be a total replacement for native. We openly acknowledge that some problems are best solved in native code. That's why React Native has excellent support for 3rd party modules.

[0] https://twitter.com/andy_matuschak/status/560511204867575808

Okay how about one very, very simple question - Can I replace my all of my Swift and iOS+tvOS+watchOS APIs with React Native? To make it easy for you. Can I do that within next 1 year? What will happen when Apple will introduce a slew of new APIs will be introduced in Sept?

Let's say I don't have any real world examples. I'm not seeing any engineering marvel in React Showcase. https://facebook.github.io/react-native/showcase.html pales in comparison to http://phonegap.com/app/

What are good examples of high quality React Native apps I can try on my iPhone?

Bonus if they are free.

Take a look at the showcased apps on the React Native website: http://facebook.github.io/react-native/showcase.html

As for the styling part, This is actually a relief to see since I am using Radium and it looks like some of the styles I have will work without any modification. Any other styles I would have to rewrite anyway.

Does anyone remember Sun's DevGuide app development platform?

I used this in the 90s, and it was ridiculously easy to get write an application. You visually designed your UI, generated code, and then added your actions/event code. It was straight forward. I haven't seen anything come close. Sure it was limited, but for the small apps I want to write for Mac and iOS, it would be perfect.

'I like react native because I don't have to learn swift' isn't the most compelling argument for why to use it.

this is great and timely! I was planning to do my first proof of concept in RN this weekend in hopes to maybe use it in a hackathon next weekend. If anyone has any other beginner resources that would be great, I've yet to even use XCode :/

"I've yet to even use Xcode"

Boy are you in for a treat!

sarcasm?

Yes. Since the release of Swift, Xcode has Ben notoriously crash-prone and buggy. It is getting better slowly, but that was a pretty terrible first six months.

For a startup still trying to find product-market fit and not building anything intensive (ie mobile games), webview apps are the way to go. Build, test, iterate quickly and fix bugs on the fly.

I'm writing mobile apps using angular / Cordova and ionic. When they are running on a device I can't tell the difference between a native app and a JS Cordova one. I think JS is the future of mobile apps.

On what device? I've seen cordova apps work flawlessly on some and obviously be webview apps on others.

> I can't tell the difference between a native app and a JS Cordova one

Sure, what kind of app are you writing ? games ? a video player ? a messaging app like Telegram ? a background activity on Android ? of course if it's a basic CRUD app, you're not going to notice the difference. try to make a 2D or 3D game with Cordova and see how it runs. The question you should ask yourself is, do you need a webpage in a native-shell at first place when you could just develop a website.

I can tell you from experience that making a robust Ionic 1 app with Cordova that is performant is difficult. Cordova is not good at all.

We did not have chump change for developers either - I've numerous contributions to Angular and Ionic, and one of my former co-workers when I was there is now on the Angular team.

React Native is a superior abstraction, since it allows you to hook directly into native components very easily (try writing custom Cordova plugins), and keeps high level logic in JS.

There is a big different. File size especially.Limitation payPal API and the most buggy me was XCODE upon compiling to apple apps.

really cool. I'd love to see a webcast on this.

Reply on news.ycombinator.com