alloy

At Artsy, my team of long-time native developers, started using React Native on valentine’s day 2016 in our pre-existing iOS app. Overall it has been a net-positive for us. In short, the developer experience and ability to be productive is much better, we now are able to leverage the product engineering skills from devs that would previously only work on web projects, and our initial tests in porting our React Native iOS code to Android are looking promising.

I think there’s no binary answer to whether or not React Native is a viable option. I can definitely imagine a bunch of situations where that would not be the case, but in our case the app is largely just a collection of views that show remote JSON data. Some small animations are done using the React Native animations API, but e.g. our navigation completely relies on native APIs and also has custom native transitions.

In short, I think that the companies that will succeed with RN are those that have native experience and a can-do-self attitude, both to ensure proper platform UX and deal with lower-level details such as RN bugs and limitations that would prohibit the product design from being possible to implement at all (for instance, in our case nested scrollviews); or those that are willing to sacrifice on UX and product design. (Not making any judgements here btw.)

We’ve written a bunch about our experiences https://artsy.github.io/series/react-native-at-artsy/ and I recently spoke about our specific case of integrating RN into our existing native app at React Native EU https://github.com/alloy/react-native-eu.

It’s been a great time!

CocoaPods has been generating aggregated lists of licenses of libraries that you use in your app since a very long time, I don’t know of any other system that people use to pull-in dependencies that does this.

We also only accept libraries that specify a license. This has lead to many more licensing issues being clear than before people used CocoaPods.

We are, however, definitely not going to build in functionality that would give you the green or red light, because it’s impossible to do this right in an automated fashion. In the end, any licensing issue is your responsibility regardless, of how you pull the code in.

> I don't understand your "build settings" comment. Why would there be any build settings originated from a library?

Your project might need to link against frameworks/libraries that the dependency requires. Your project might need certain search path. There are more, but I hope you understand what I mean now.

> As for "making too many assumptions", it sure would be nice if you could, say, explain yourself > […] > Your FAQ link doesn't explain anything

You hear “transitive dependencies” and you assume somebody is “doing something terribly wrong”. I’m saying that that’s not necessarily the case and in the FAQ item that I linked to I state that I’m against the scenario that you assumed.

The blog article that is linked to from that FAQ item goes into more detail about why it’s good to keep it to a bare minimum. (More on that below.)

> and that my wrongness upsets people

I wasn’t referring to you specifically, but rather to people on both sides (for/against) discussing this topic in general, which was the premise for me needing to ‘port’ that blog article. It was a side-node and I see how it could be taken the wrong way.

> To explain my side: third-party code tends to be of low quality and interact with other third-party code in interesting ways. When things go wrong, and they always do even with the best programmers and the best code, the more bad third-party code you have, the more you have to dig through to find and fix the fault. This objection largely goes away if you only use dependencies of extremely high quality

I already knew what you meant, this is not the first time I have this discussion :) But I should have been more explicit:

When we talk about dependencies that were created by a third-party, so _not_ dependencies per se, you are completely right and we are in full agreement. To quote from the blog post:

    “Minimal dependency is not just about the number of libraries you use,
    but also about the total amount of code you pull into your project.
    Less code means less bugs.”

> but to be brutally honest, there aren't enough such projects out there to be able to make a mess from them

I doubt you checked all of them, but seeing as everyone makes mistakes in their own code, I think it’s fair to assume that there is a lot of code that could be improved.

Where we seem to differ, but tell me if I’m wrong, is that you in principle choose to not deal with any of them, probably because it wastes time (?). Whereas I prefer to choose a small one that does (almost) exactly what I need and (almost) is where I want it to be code-wise and then contribute to that project, instead of starting over.

To facilitate the mentality that I and many others have, it helps to have a tool and ecosystem that makes libs discoverable and ‘simple’ to build upon/together.

Very fair points.

I hope to see the day that they will sanction a small format around clang modules, we can always hope :)

> It shouldn't be time consuming to manually integrate a dependency either. Add it to your project and go.

I’m not going to play the yes-no game with you on this.

> I further don't understand how it's a problem if you commit them to SCM and then decide to remove them. If you decide to remove them, then remove them, and you're back where you were.

You will have to spend time to figure out which build-settings originate from which library. Or you do it properly upfront with a xcconfig, which also costs you time.

> Perhaps this is the gulf in understanding: when you talk about transitive dependencies, my immediate reaction is that if you have so many different dependencies and dependencies-on-dependencies that it becomes difficult to manage by hand, you're doing something terribly wrong and setting yourself up for a world of pain.

You’re simply making too many assumptions then. Also see: http://guides.cocoapods.org/using/faq.html#cocoapods-is-bad-...

I’m still planning to port that old blog post, by my then-colleague, to an iOS context and post it on our blog. This assumption you make is a common one and tends to leave sour tastes with everyone.

> editing my Xcode project files underneath me creeps me out

You can use the `--no-integrate` flag and it never touches your project, leaving integration of the Pods Xcode project up to you as you see fit.

Yes, CocoaPods can’t fix API breaking changes, but as we use semantic-versions and encourage authors to follow those, it can at least be mitigated more easily. E.g. A version requirement of: ‘~> 1’ should then install the latest v1.x.x, but not v2 which has API breakage.

Obviously this is not fool-proof and many are still getting used to it.

You assume that any code installed through CocoaPods will be created by ‘third-parties’, this is incorrect. Dependencies are simply that. You can use your own, like many companies have been doing successfully internally. E.g. http://dev.hubspot.com/blog/architecting-a-large-ios-app-wit...

Regarding “it’s not difficult” to do; Indeed it’s not, but it can be time consuming when you do want to quickly try out some libs. Especially once you have committed them to SCM and later on decide to remove them, because they weren’t what you wanted after all. This becomes even more a factor if you want to see a community that builds stuff together, instead of everybody re-inventing the wheel and/or vendoring their dependencies inside their lib leading to the mess that brings (at linker and runtime level), because then you need actual transitive dependencies and calculate a graph.

It is my experience that the lack of a tool and an ecosystem, such as CocoaPods, has led to the Objective-C OSS community staying minimal, in terms of working together. This can be noticed by the instant feedback people get on their projects when they release a library through CocoaPods and the decline of monolithic frameworks.

Whether or not your situation asks for this is another question. In consulting you’ll notice the benefit of quickly adding your dependencies, while on your own (single) product that’s probably a negligible amount of time. YMMV and all are fine.

While on the topiZZzzzZzzzzzzzzz…………

Alcatraz manages ‘Xcode packages’, e.g. Xcode plugins and color schemes. CocoaPods manages dependencies of your Objective-C project.

Except, he didn’t lie. He spent money to have Watson also do maintenance work on MacRuby.

[Disclaimer: MacRuby core member here.]

I agree, it’s too bad that people can’t just work for free as much as they would like on the stuff they love.

Now it is true that Laurent himself has not touched the repo since that email you linked to, but you know just as well as me that Watson has been doing maintenance work on MacRuby while on the payroll of RubyMotion (HipByte). His latest commit was 15 days ago and here’s a generalised diff of all the work done since the email: https://github.com/MacRuby/MacRuby/compare/94c90b351c18ce1f5....

This is what people with limited time resources do, they delegate.

To conclude, when you’re out to paint someone black, you really should be more specific. As it stands, there are no lies in that email, which means that you are the one that is not telling the truth. I’m not sure why you want to spread FUD, but it’s quite obvious and really does not make you look professional.

PS: Whatever Apple chose or chooses to do has absolutely no relevancy to this at all. The moment they released it as Open-Source, they effectively said that people can do what they want as long as they follow the license.

> This is kind of the opposite of the standard advice of "don't repeat yourself" and "don't reinvent the wheel". Both those pieces of advice make an awful lot of sense to me.

It’s not about re-implementing everything per project, it’s a reminder to think about all of the code you pull into your project.

We use some third-party gems, we have our own gems, but as a rule these should all provide the minimum necessary and not try to solve all higher-level use-cases. Because these types of libs, that do come with the proverbial kitchen-sink, tend to bring in functionality that you won’t be using but are still very much opportunities for bugs.

> You shouldn't have to be thinking about its inner workings. Some gems really can carry big risks with them.

Some might indeed carry big risks, which is why it’s good to know your code and that is made significantly easier with less code.

However, you should be thinking about their inner workings. Especially, but not limited to, open-source code which all (afaik) provide no warranty whatsoever. So when you pull it in, directly or indirectly, you are responsible.

If you mean on the end-user's machine: $ pod repo update

Is there a specific feature that makes you say that? Or is it the age?

Also, please please please start contributing specifications: https://github.com/alloy/cocoapods-specs :)

ZOMG, indeed! You’re welcome! :D

On a more serious note, I had been trying not to create this for about a year now. The release of the boilerplate project made me decide it’s time to finally scratch that itch.

Starts with “J” and ends with “ava” ;)

* Yes, good documentation is needed. Patches are very welcome :)

* The community. The idea is that once you have one patch accepted you get push access. This applies to both https://github.com/alloy/cocoapods and https://github.com/alloy/cocoapods-specs.

* “How is it kept up to date?” Can you explain what “it” is?

Good question, it’s because of reading and writing the project.pbxproj file through NSDictionary: https://github.com/alloy/cocoapods/blob/master/lib/cocoapods....

Very true. However, judging by the chatter about this article on, for instance, Twitter [1], many don’t really seem to get that the ‘confirmed’ part in the title isn’t true. So I simply wanted to emphasize this point for others, not the author as he knows it already :)

[1] http://twitter.com/#!/search/macruby

I’m talking about “MacRuby on iOS 5 - CONFIRMED!!!”.

Well, I simply can’t say ‘it will not happen’, because it is open-source software, so for all I know you are currently implementing it. However, I wouldn't hold your breath on someone else stepping up to make this work, because we have been saying this for a while now… C’est la vie.

Yeah, sorry to rain on your parade, bro. But these kind of ‘confirmed’ articles, in the end, help nobody. Users will be sad when it doesn’t happen, whereas neither Apple nor the MacRuby team have actually confirmed/promised this. Sorrow all around isn't good publicity.

Thanks for the update, though! :)

Although I empathize with your wishes, your article is way too sensationalistic. Let me confirm (I’m not with Apple); MacRuby on iOS has _NOT_ been confirmed.