Chris' Blog.

There's a lot of hype currently around React Native, so I recently decided to sink a good amount of time into it to give it a shot, and report back with my impressions. Admittedly, these are only a week's worth of impressions so keep that in mind.

I spent a couple week's worth of evenings developing a prototype for an app a friend and I wanted to run by a few businesses, see if there was any interesting in a full build-out. Long story short, we got market validation that the idea wasn't what the industry wanted. But i did learn a lot about React Native in the meantime which I'll now share.

Potential

There seems to be a lot of potential with React Native. It is an extraction rather than a framework. DHH, of rails fame, made this distinction years ago: good frameworks are extracted from things that are required to work, because many people's paycheques/families/mortgages depend upon it. I'll clarify: I assume it's an extraction - we can't know Facebook's internal strategy specifically, but it certainly points that way (eg they use it for their Groups app and now the core Facebook app). My point here is that React Native is battle-hardened and production-ready, unlike say other write-once-deploy-on-ios-and-android frameworks which decidedly weren't.

Working with Swift at scale is an exercise in frustration common to many teams - see Uber. Xcode cannot index, and compiles blow out exponentially once you hit ~20KLOC, depending largely on if you have many small files or fewer large ones. So the opportunity to change properties and see updates in an iOS simulator and an Android simulator on your computer within seconds is compelling. I can confirm that this aspect of React Native is productive.

Don't be scared off because it's Javascript. JS has come a long way since the 90s - ES6 really shines, with elegant syntax for classes, inheritance, avoiding var hoisting, and so on. Take full advantage of all this, because RN uses Babel to transpile your newest-style JS into whatever is necessary for iOS and Android's runtimes.

And, in short: it's not, well, terrible. Most other cross-mobile-platform JS frameworks like Titanium / Sencha Touch / PhoneGap / Cordova / Ionic, well, are. I think it's on par with Xamarin in terms of production-readiness, however its live updates make React Native more productive.

Thoughts

Here's a grab-bag of perspectives gained from my two weeks, in no particular order:

• Watch a lot of screencasts. There are a few at egghead.io. You'll notice that there are a few different styles for coding in RN, which appears to be a bit in flux. Hopefully this coalesces to one style in future.
• Watch the Youtube videos by Tal Kol, Wix is really doing well with RN.
• Check out Ignite and watch their Youtube videos. I think Ignite is like Rails scaffolding for RN, and pushes you in the direction of best practices - highly recommended.
• FlexBox (their CSS-based layout alternative to AutoLayout) is a bit limited. You'll often have to wrap things in a (few) view(s) to get the layout you want.
• The RN 'packager' is buggy, so get used to restarting it.
• I've seen layouts acting buggy, things positioning where the code clearly shouldn't allow, at which point I close and re-open the packager/simulator. There seem to be some kinks here.
• It's hard to find 'best practices' for some things, eg what do I do for a navigation controller? I find Wix or Ignite have great solutions for this particular case. It appears some things like this aren't 'batteries included' by Facebook so you often have to find a good library for things that really should be included.
• Learn the differences between Props and State. Roughly: props are for things passed into your components; state is for things your component changes about itself.
• Flexbox basic stuff here: facebook.github.io/react-native/docs/flexbox.html
• Flexbox advanced stuff here: facebook.github.io/yoga/docs/flex-direction
• TouchableHighlight must have only one child, but that child can have lots of children, so get used to grouping everything in a wrapper view.
• Logging is simple: console.log('foo'), then in the iOS sim, do Menu > Debug > Open system log.
• No type safety is hard to let go of after Swift: I sometimes call a prop 'isSelected' and in some places refer to it as 'selected' and get confused. Flow might help with this - I haven't tried. Also you can strong-ish-ly type your props like this: MyComponent.propTypes = { isSelected: React.PropTypes.bool, etc };
• You have to update a datasource instead of another state property if you want a list to rerender - this got me stuck a few hours.
• To make a button where the text dims on tap but the background stays the same, have a view (with background), containing a TouchableOpacity (no bg), containing a Text.
• Many of the builtin components are iOS only eg the action sheet, so watch out for that. Wix provide cross-platform solutions for most of these.
• When choosing components, choose the one with the most github stars, least github issues, and simplest example usage.
• Don't use var anymore, use 'let' instead. (let is like swift's 'var'; const is like swift's 'let'; var is js-hoisting-madness)
• There are lots of syntax changes re ES6 v ES5 vs classic JS to be aware of, eg use for of instead of for in.

Summary

I recommend at least becoming familiar with React Native. As our industry matures and rates begin to drop, I think it'll become increasingly compelling at job interviews to be able to say: I can deliver iOS and Android apps to the business for the price of one developer.

And here's the prototype that was the result of, say, 10 hours work:

I have a bit of a tale to tell regarding a homegrown Plex alternative which I've been working on for a year or two...

So, for years now, I've had a plex server in the garage, which I've used to entertain my girls and solve the problems of:

• My oh-so-well-behaved offspring scratching the hell out of every DVD we buy them.
• My did-I-mention-they're-well-behaved offspring screaming blue murder as I inch my way through DVD menus to get the damn things to play.

So far, so good: plex has helped keep the screaming-for-blue-murder down to a dull roar for years now. However, there have been many niggling issues with it that have driven me to think 'could I do better?', such as:

• It requires a decently powerful server...
• Which means it has a noisy fan...
• Which means it must go in the garage...
• Which gets awfully hot in the australian summer...
• So I walk in my garage most days and hear the server's fan going full-tilt and I freak out about it being a fire hazard.
• And other issues: Often it just fails for whatever reason and needs a server reboot
• New versions of the client ask me to sign up and in - I'm not doing that!
• If you try to seek in most movies, it spins forever and probably fails (i've never waited more than a minute).
• It doesn't simply figure things out if you drop new movies in, you need to remote into the server and kick off a re-scan.

So, armed with a trusty text editor, I mucked around with ffmpeg, and Go[lang], and so on, until I came up with Gondola, which I'm now releasing as an open-source project here:

splinter.com.au/gondola

Gondola is the full suite: A transcoding-ahead-of-time media server which works from a Raspberry Pi or a fanless laptop (I recommend the latter); a native client app for your Apple TV, iPhone, and iPad; and a web client which will work on any Android device. I've put a small price on the apps in the app store (due to the hassle of getting them approved!) but you can compile and install them yourselves if you like.

Hope you like it!

Swift may be super-fast at runtime, but during compilation... well, it can be slow. Linkedin revealed in a blog post that they gave all their developers Mac Pros to get their compile times under control. I've experienced a project that takes 10mins each time you want to launch the simulator with 40KLOC. I had high hopes that Swift 3 would have an optimised compiler and solve this, however I found my compile times took around 30% longer after I migrated from 2 to 3. Also, after a codebase hits a certain size, the incremental compilation appears to give up, and any changes result in a full re-compile. And finally, code completion becomes unusably slow (or simply fails) after a certain codebase size too. Needless to say, these problems are disastrous to your productivity, so what can we do to solve them? Hopefully I can help you below.

Frameworks

My main recommendation is to split your app up into frameworks. Now I'm certainly not recommending creating your own cocoapods or carthage libraries or git submodules - I've done that before, it's way too much effort. However, with Xcode's nested projects, this solution can work with minimal ongoing maintenance.

The main architectural issue here is that you need to enforce careful separation of concerns, so that your code will split neatly into mostly-independent frameworks. Once you've done this, Xcode will only compile just the frameworks that have changed and your compile times + indexing + code completion should improve.

I recommend splitting your app up into frameworks like so:

• Helpers: These are anything that needs to be used across the board, like currency formatting or styling or common views. This framework is the 'tip of the pyramid' when it comes to dependencies: it is to be used by all your other frameworks, but it cannot depend on anything else.
• Services+Models: You may want to separate your model objects from your API services, but in my experience it's not worth bothering. These may rely on helpers.
• Navigation: You'll probably have a custom home container controller and a bunch of helpers for various complicated navigation - I'd put them in here. This may also depend on helpers.
• Many individual feature frameworks: This is where the magic happens: All your apps independent features, categorised into individual frameworks.
• And: whatever else makes sense for your project.

How?

How do we make these frameworks? Here's the process for adding to a workspace. If you're using a project only, it may be slightly different:

• Open your existing workspace.
• File > New > Project
• Select 'cocoa touch framework' because static libraries are objc-only (I assume this is because the ABI isn't stable yet).
• For product name, use eg 'Helpers'
• Team: none
• Org name: MyCompany
• Org identifier: whatever your normal bundle id is, with '.frameworks' appended, eg: com.mycompany.myapp.frameworks
• Click 'next' and it'll ask where to place it with a save dialog.
• Under 'add to', select your workspace. Under 'group', select the folder you want it to be nested under - folders have a yellow icon (eg skip the workspace and project levels).
• De-select git - you want this subproject to be simply part of your normal git repo.
• It should automatically choose the based on the group you chose, but double check and click 'create'.
• In Xcode, you should now see 'Helpers.xcodeproj' nested under the group you chose.
• Configure the deployment target at the project level to the same as your main project.
• If you have extra configurations in the main project, add them to the subproject.
• If you have per-configuration build settings for your main project, you may want to add these to your subproject.
• Click on the main project, then for your target(s) do the following in the General tab:
• Scroll to 'Embedded binaries' and add the framework MyApp/Foo.xcodeproj/Products/Foo.framework
• Check it automatically got added to 'linked frameworks'. You may need to add it if its not there.
• You can make frameworks rely on other frameworks, just don't make circular references. Eg the main app can use Helpers and Services, and Services can also use Helpers. But Helpers cannot then use Services.
• When creating/moving code into your framework, you'll have to mark some classes and functions as 'public' to provide an interface to the main project.
• You can use open instead of public if things have to be subclassable. I recommend using public where you can because it's like java's final, eg: no subclassing, which gives the compiler room for optimisations.
• Anywhere you wish to use code from your framework, you'll need to have import Foo at the top of your swift file in the main/consumer project.
• Share the scheme for the new project: Product > Scheme > Manage, then select 'shared' next to the project.
• Celebrate!

Gotchas

There really aren't too many downsides to this approach, but some things to watch out for:

Xcode will recompile the frameworks if you change them automatically before recompiling the main module. But if it can't compile a framework, it might try compiling the main project against the last compiled version of the framework, and give a bunch of weird errors. So sometimes you should select the subproject's scheme and try building that first.

Sometimes have to turn off SWIFT_WHOLE_MODULE_OPTIMIZATION to get useful errors if builds are hanging.

Sometimes when you have compile errors, it's worth looking in the Cmd+8 tab to see the build output, in case it's an earlier error in one of the frameworks that is snowballing to further things.

To load images that are stored in the main project's xcassets from the subproject, you'll have to do this: UIImage(named: "X", in: Bundle(for: type(of: self)), compatibleWith: nil). Alternatively you can put assets in a bundle in the subproject which is tidy.

Update:

Apparently if you have an app with too many frameworks, you can increase your app's startup time. For instance, it is common to see 5s startup time on iOS9 with ~20 frameworks. As of iOS9.3 onwards, this problem is largely mitigated, and it is more common to see a 0.3s delay with a dozen frameworks. Apple recommends only having 6 or less frameworks in your app. I haven't done any tests, and I cannot say for sure if these techniques would be any slower than having one monstrously large app module. But this is something to keep in mind. You can read more here: useyourloaf.com/blog/slow-app-startup-times

One more thing

As of writing (Xcode 8.1) you can often get a significant compile speedup by adding the following user-defined build setting, it may be worth a try for you: SWIFT_WHOLE_MODULE_OPTIMIZATION = YES

Thanks for reading, I hope this helps!