Matt Mohebbi (twitter) (github) is the technical co-founder/CTO of Iodine alongside CEO Thomas Goetz (former executive editor of Wired Magazine & author of The Remedy and The Decision Tree). Before Iodine, Matt worked for nine years at Google on a variety of projects including Search, Flu Trends, Correlate, and Consumer Surveys. Now he wants to bring his experience with big data to health in a way that hasn't been done before. For the past couple of months they have been building an app in React Native - an app that may end up being an important piece of their business. I've had the great fortune to be able to work with their team recently, and it it has been a fantastic experience, so I'm happy to be able to share some of the insights that Matt and I have previously discussed off-the-record with the rest of you!
Hello Matthew, or can I call you Matt? Anyways, can you give me the elevator pitch for Iodine and explain how react native factors into your technology story?
Matt is great. I’m only called Matthew when i’m in trouble with my mom or my fiancee! Iodine is building tools to help consumers understand if they are taking the right medication for their condition The status quo for this is pretty terrible. I challenge you to find someone who loves webmd or drugs.com as products and yet these sites have hundreds of millions of visitors every month. This experience is not great for many reasons but one of the biggest is that these services are mostly just reference material. They don’t really help someone directly answer the question of if a medication is right for them.
That’s where we come in. We started by building web apps and collecting data directly from users around their experience with the drug. As part of this effort we conducted a 100,000 person survey of people’s experience and we also surveyed a team of pharmacists to build new data around what people should expect when starting a medication.
This was built using an isomorphic React stack using bootstrap and Google Closure. This launched last fall. We’ve been quite happy with the results but we released that we were only taking a small step in the direction of answering the question, “Is this drug right for me?”. In order to really address that, you can’t just have a one time information exchange as is typical with the web. You need to have an app.
But how does a team of web engineers build a native iOS app? Well around the time that we were trying to figure that out, React Native was released and it just clicked for us. We’ve been really pleased with the results so far.
What were the the biggest struggles your team had going from react on the web to react native on ios?
It took some time to adjust to the flexbox model but it was worth the investment. Also, since we were so early there were features missing that we either had to wait for (like profiling, animations, inspection) or just build ourselves (like push notifications).
There also were times where people would get stuck given the error messages they were getting. In general, the red screens of React Native are great but sometimes we’d get something that really require some digging. And since the system is so new, searching on Google didn’t always provide answers. I think in part that’s why the Slack community is doing so well with React Native - React Native sometimes moves faster than Google can recrawl Stackexchange or Github!
The final bit that has been interesting is figuring out how much native to target in our app. We know we want to target Android very soon and thus the less we build that’s native, the easier it will be to support Android. That said, we also want our app to not feel like a webpage but instead like a real native iOS app. So there’s a constant balance we try to strike in our design in order to achieve that and we’ll only know if we’ve done a good job when React Native Android is out!
Aside from having those apis that you mentioned above built already and improving the quality of error messages, is there anything else that you can think of that would make the developer experience better for your team? Let’s also leave out hot reloading
Apple watch support would be great to see!
We’re also excited to see some of the update mechanisms released this week by folks like apphub and reploy. We’d really like to have this now as the app we’re building is a big experiment (no one has done quite what we’re trying to do) and as a result, we’ll likely need to throw out a lot of stuff until we find what resonates with users.
Finally, I think more real world examples of how people address storage on these devices would be really useful. something more than an todo app. There are lots of tradeoffs here and i think it would be awesome for the community to see what people are having success with.
I agree it would be nice if there was a go-to story for session management for a react native app, for example.
What advice would you give to people who are just getting into react native to build their product?
Just roll up your sleeves and have fun with it. I know i’m not alone in saying this but it still brings a smile to my face every time i Command-R when working on a react-native app. It’s really fun and really fast to build things.
As your app moves from prototype, to something you want to ship, I do recommend that you invest the time to integrate flow into your app (and that’s another thing for the wish list above - to have flow types on all of the react native JS code!). These apps are giant state machines and it’s really easy to introduce run time errors in parts of the app that aren’t visited often. the other bit of advice that i have related to that is using some server side exception logger like sentry when building in prod mode so you can catch these sorts of errors when they slip through the cracks of flow and your QA process.
Have you ever felt that you’ve been forced to compromise part of your app’s design or functionality because of react native? Or really any part of the user experience.
There have been some things that have been harder as a result of react native but nothing comes to mind in terms of something that we just couldn’t do in react native and we needed to revert to building that part in native code. it helps that our app is not a game or something that involves a lot of data like a photo app.
In the category of making things harder - there’s always a question when we integrate a service do we use the iOS bindings or the JS bindings. for example, for analytics we use mixpanel. We use the native iOS bindings and built a simple bridge to do event and profile updates from JS. we did this so we’d get things like the mixpanel iOS surveys for free.
For Parse, we use the JS bindings which enables us to do all of the storage logic in JS and also integrate Parse React, which in theory should make it easier for us to do storage in React. this will also make it easier for us to update the app over the wire in the future.
Finally for Sentry, which we use for exception handling, we use both the JS library for catching JS exceptions and (once we integrate it this week), iOS crash logging on the native side.
So whenever we’re adopting a new library, we need to ask ourselves which side of the fence it should live. We default to JS, since that’s the best across platform and best for updates but sometimes that doesn’t work out.
What would you like to see more of from the community? And from the react native team?
From the react native team- I think it would be great to see more of a roadmap. I know they want to avoid over promising but it's hard for me to say at this point what it will take for react native to be declared 1.0
I think also getting more transparency into what is being fixed/built internally. I've seen some folks in the community build things that FB already has built but not open sourced. I've also seen people wait on doing something thinking that FB is going to build it in the next release and then it never comes through because it's not important to FB (local notifications are a good example of that). That said, I know that the FB folks are already aware of this and that it is a hard problem to solve.
Those are all of the question I had, do you have any announcements or shoutouts you’d like to make before I let you carry on with your Sunday?
As for shout outs: I wanted to thank you for putting this great newsletter together and everything else you do for the react native community (animations!). I also wanted to thank the folks at Facebook for taking the time to open source react / react native and in doing so changing the way people think about building applications.