NOEL:  Hello, welcome to XI to Eye, a podcast series from Table XI. I'm Noel Rappin and today I'm talking to Ed Lafoy, Table XI's Director of Mobile Development.
      Ed, why don't you to start by telling people about yourself and what the mobile practice at Table XI does?
ED:  Like you said, I'm Ed Lafoy. I've been building iPhone apps for probably four or five years now. I first came to Table XI in about 2012. I've gone to a couple of corporation places, a few other consultancies but I really found a home here.
	The mobile practice here, we do iOS work, Android work. WeÕve done a couple of projects on some cross-platform solutions like React Native, dabbling in a little bit of hardware. But the company as a whole, obviously, does Rails work and design, as well as UX in strategy.
NOEL:  Cool. YouÕve mostly done iOS and then switched to Android. Are you doing native Android or is the Android mostly through the cross-platform tools?
ED:  Well, we've done a couple of projects with React Native, as well as a couple of projects that are straight up Java and built on the standard Android libraries. I, myself, haven't done enough of the native Android stuff, although I did build a React Native project. I am significantly stronger in iOS than I am in Android.
NOEL:  I mostly do web development. I've never really done much mobile app development at all. I think for a lot of web developers, there's a whole ecosystem of mobile apps and mobile app development. ThatÕs just sort of opaque that we don't see. How do you decide when to do a native project, when to do a cross-platform tool, when you might use Swift versus Objective-C, or Java versus React Native? What kinds of things go into that decision?
ED:  A lot of it depends on the developer make up. For us, we can kind of do it all so it really becomes like a question for the client, like do they want us to maintain the code base long term? Do they want to transition to their own team? If so, do they have a team now? Are they going to hire a team? If they have a team now, are they iOS? Are we adding to an existing internal team? Do they have a team of Rails developers only?
	For example, if they have a team of Rails developers and some of them are familiar with JavaScript, React Native might actually be a really good option. If they have a team of iOS developers or Android developers, that's a pretty obvious answer as well. If they plan on hiring in the future, currently, React Native is so new that they might not be able to find anybody so it might be a better option to go native.
NOEL:  How hard is it to balance cross-platform native if you're doing a native iOS app and a native Android app? Does that just two completely separate code bases? Is there any way to share tooling?
ED:  Yes and no. I mean, you're tackling the same problem in just different platforms so there's some kind of business logic wins that you kind of learn at the same time. ItÕs easier in some aspects but it's not like you can share those things. YouÕre going to find different tools that you want to use for each one. None of that stuff really carries over.
NOEL:  So that leads to using something like React Native. I think maybe you should describe what React Native is and how it solves that cross-platform problem.
ED:  Sure, for any of you that are familiar with React in general, it's kind of the same thing.
NOEL:  React as a JavaScript library, a JavaScript view, single-page app library?
ED:  Yeah, React Native is basically a toolset built on top of React that gives APIs into the native iOS and Android components so you would build a standard React app, except that you'd be interfacing with things like a tab bar controller or things like a table view. Those essentially just are abstractions of the native components themselves. You really aren't using and talking to real components without having to worry about the underlying implementation of them.
NOEL:  Is there kind of a lowest common denominator problem where it becomes hard to use things that are unique to one platform from the other?
ED:  That's kind of one of the main constraints. I remain a skeptic of cross-platform solutions just because I've been burned by them in the past. I will say that I have been very impressed with what I've seen in React Native as well. But yes, there is always that risk. Well, there's this one small control in iOS that doesn't exist in Android and it's not available to me.
	But what React Native does a good job of doing is getting out of your way if you want to do something custom. It allows you to like go in, grab a component you want to use, write a Java wrapper around it, [inaudible] Android app and then interface with that component using JavaScript and it does the same thing for iOS. ItÕs nice in that regard. You'll never program yourself into a corner.
NOEL:  I know that on the iOS side, Table XI was a really early adopter of Swift. How's that going? HowÕs that gone? Do you end up having to rewrite everything every time like Apple Blinx or has it been pretty stable?
ED:  This is a good timing considering Swift 3 came out recently. That was a gigantic change and one I would really appreciate not having to do again. Having said that though, it was a much needed change.
	A lot of redundancy and verboseness removed from the language, especially the UI kit. It makes a lot of naming convention shorter and ultimately less code. But when you have a large code base like we do on 'Everything But The House', it takes a significant amount of time to convert that stuff over.
NOEL:  You started, though, on Objective-C. How does that switch go? Is Swift a lot easier? Does it make certain things easier and certain things harder because the ecosystem [inaudible]?
ED:  I am a huge Swift fan. It's a very powerful language. I like how type-safe it is. ThereÕs some really modern kind of thinking that's gone into the language that makes it really nice to use, things like protocol extensions really just make your life easier.
NOEL:  What kinds of things does that help with?
ED:  Well, it helps with the way that you think about the objects that you're going to create and how you can go about. For example, if you had two base classes that update and you're going to use UI kit and you wanted to write a set of extensions for both of them. There's no base class in Swift so what you could do is write a protocol, then write an extension for that protocol, and then extend those two classes with that protocol, and you just inhibit those.
NOEL:  So the protocol then gets the common behavior?
ED:  Yes.
NOEL:  And then the protocol is sort of what talks to the underlying framework?
ED:  I guess a good way to explain it, are you familiar with prototype in JavaScript?
NOEL:  Yes.
ED:  So you can write a prototype or you can extend it.
NOEL:  ThatÕs what JavaScript used to use instead of classes, yeah?
ED:  Right, okay. So obviously, I haven't done normal JavaScript in a long time. But yeah, it's kind of the same concept.
NOEL:  I guess the thing that spark of me there is I know that on the web side, we are continually like trying to keep up with new tools and new things like that on the iOS side. You have in some ways a more stable platform because you really only have one primary vendor that you're dealing with but that vendor also changes a lot. Do we have, as a practice, updating applications as a matter of course every year when Apple unveils the new hotness?
ED:  Yes. ThatÕs kind of been a huge push from us. It's kind of like, "How do we update a customer's code base and have them expect that that's going to happen?" And so, it's somewhat difficult to do and difficult to frame but it really comes down to like Apple moves quick in this. Swift has changed a lot more than Objective-C has in the past two years. It's been significant amounts of work on the Swift 3 side, not so much when we move from 2 to 2.1, 2.2, stuff like that.
NOEL:  So what kinds of tools do you use to manage that? What kind of tools do you use to maintain your code quality or testing? What's the toolchain like there, beyond just typing Swift in the Xcode?
ED:  There's a lot of parallels you can draw. The Ruby environment -- your Ruby gems would be CocoaPods, your bundler would be, I guess, CocoaPods. It's kind of the same thing.
NOEL:  Is CocoaPods from Apple or is that a third party tool to manage extensions?
ED:  A third party tool to manage third party dependencies, basically. It basically takes your Xcode projects, creates a workspace from it, and injects the dependencies that way. For the dependency management, it's just CocoaPods. There's a bunch of other deployment gems and stuff like that but they're not really dependencies.
NOEL:  What do you do for testing and continuous integration and things like that? Things that might automatically manage whether the code continues to work in the face of changes?
ED:  We use a CI platform called Bitrise. Bitrise allows you to lock an environment so you can target Xcode 7.3 and not have to worry that a break can change and that 8.1 is going to kill it. Our deployment platform is called Fastlane. A lot of iOS developers are pretty familiar with it, probably Android uses it as well. I think it really started off being a tool to make the Apple tools not a huge pain. The amount of work that had to go into managing your provisioning profiles, your certificates, and getting the devices updated, and doing your rate of deployment and then that's not even when you go to PushLive and you have to update them, it's just all that stuff.
	So there is just like so much effort that had to go in to just pushing a production builder or a beta build. So Fastlane became this tool to automate that entire process in five minutes and so it's really, really blown up to being this huge suite of like really useful tools.
	There's this part of it called Match. Everyone had a certificate and those certificates had to be applied to the provisioning profile and the provisioning profile would have to be updated on CI and when you made a change or added a device, you had to re-upload it and there's all this stuff that went into that and Match kind of uses this. You set up a git repository. It pulls down one shared certificate, updates the provisioning profiles for you when a new device is added and keeps them all encrypted in this git repository. You don't really ever have to worry about that stuff.
NOEL:  Does that make you more likely to do your own testing on the device rather than the simulator?
ED:  Most of the stuff that we run is done in the simulator. There are certain things that you won't get access to. You can fake a GPS location, for example, but you can't test it if you're going to go into a walk or something like that. Well, I guess, actually I take that back, you can. ThereÕs a highway drive simulation as well.
	Push notifications I guess, would be one. If you want to test push notifications, the simulator straight up doesn't support it so you have to test it on your device. But there's a surprising amount that you can do in the simulator.
NOEL:  Does it affect how you design the application whether it's being run in the simulator? Are there things that you're surprised by the interaction once you get it on the real device after you test it in the simulator?
ED:  Yes. Sometimes, performance looks good and then you run it on a device and you find out that it's actually pretty poor and that's because it's leveraging your laptop's CPU. So there's stuff like that. Sometimes, you'll be surprised by the fact that you're developing on a 5S-size simulator and then you'll run it on your iPhone 6 and realize that you didn't quite pay attention to the UI as much as you thought you did.
NOEL:  How hard is that than the design for devices that might potentially have in multiple different sizes that even the Apple ecosystem has what, five or six sizes now, and Android system has a jillion? How much effort is that to keep up?
ED:  A good question. Remember, when there used to be like two phones?
NOEL:  Yes, I remember when the Apple programmers would all say that one of the huge advantages of dealing in the Apple ecosystem for iOS was that you only had to deal with one device size.
ED:  Yeah, they're not wrong.
NOEL:  But that was five years ago.
ED:  Right. ItÕs definitely better. I'll take three or four sizes over a hundred any day. But other layout is pretty good for that kind of stuff. We were long time users of storyboards, which is a kind of GUI/UI interface, it's called Interface Builder. Storyboards are what you build in them and you can think of it as literally laying out iPhone screens on a table. ThatÕs kind of what it looks like and we are a long time users of those. But we've since actually ditched them.
	WeÕve found this library called SnapKit. It's an excellent little tool that acts as a DSL on top of Auto Layout. Auto Layout is very verbose to write by hand and this makes it pretty simple. It almost feels like cheating a little bit. But in Auto Layout, you set relative constraints to other elements and it's apparent to use and such and you can do a pretty sensible layout that will work on all devices without much hassle.
NOEL:  Yeah, one of the great things, as an iOS user, you particularly see it on the iPad when you go to split screen and you really get a sense of which applications paid attention to their Auto Layout because then you see them like transition from their wide to their narrow layout right in front of you.
ED:  Yup, it's pretty nice in that way, as long as you're not using static. If you think about the way the interface that you're building would look if it was humungous versus the way it would look if it was tiny, you can really kind of get an idea of what constraints you should set that are practical.
NOEL:  So, how closely do you work with the design team in order to create those kinds of layouts? What do our designers deliver to you and how do you guys turn that into working layouts?
ED:  It really depends. I've worked with designers that haven't had a ton of experience building mobile apps so there's obviously a difference in terms of what you get. Fortunately, for us, we have Yana and she spent a tremendous amount of time working on mobile software design, so she delivers things that I don't really have to even ask a question about.
	But typically, you're looking for something that's going to scale well, something that's going to work on iPad if you can get it and something that's going to leverage components that are already built-in and required a small amount of customization, most likely, but not things that you're going to have to build from scratch that are going to suck up a bunch of your time.
NOEL:  In terms of the actual code itself, I know that one of the things that Ruby developers get really excited about is being able to write automated tests and I also know that sometimes that's hard in the JavaScript environment. ThatÕs very heavily view-based or even in an iOS environment. What kinds of tools do you guys use for that?
ED:  We kind of have an RSpec inspired tool called ÔQuick and NimbleÕ. Nimble is the matcher librarian and Quick is kind of RSpec style test framework. They're both built on top of XCTest but they kind of make it not crappy to look at. Then the other tools that we use, we try to stay away from doing view tests as code, instead we use this little library called FBSnapshotTestCase and it essentially allows you to construct a view and take a picture of it. So it takes that picture, stores it in the file system in your git repo and then basically, later when you run that test, it will take another picture of the same view and compare the diff of the existing image that it has. Now, if the diff isn't the same, the test fails. It allows you to construct the view, not worry about like, "Hey, is this thing brown? Does it have the right font? Is the font the right size? Does it have a left margin of this?" It allows you to just say like, "Does it look like this picture?" If it does, the test passes.
NOEL:  How brittle is that?
ED:  That was my thought the first time too. I was thinking like, "This thing is going to fail. I want to get it in the CI and it's going to [inaudible] a bunch of times. I'm going to spend much time on it." But I've actually been pleasantly surprised. We set a tolerance of 5% so it's allowed to be 5% off and that seems to be a happy medium to get some non-breaking changes but also not senseless failure.
NOEL:  Switching direction a little bit, you have only what, three or four developers working on mobile projects?
ED:  Yep.
NOEL:  Do you guys overlap on projects? Do you pair program? When one of you finds a cool tool like that image testing, how do you get that across all of your projects?
ED:  We usually bring it up in Slack. I'm sure most companies will know that Slack is incredibly useful for that kind of stuff. But we also talk about it in our stand-up. Every a couple of weeks, we meet for a couple of hours, talk about things we want to potentially use. Sometimes, we'll do a spike on them. But a lot of it, since the team is small, there's always at least half of us working on the same project. So if there's something we want to try, we just give a shot and that affords us the ability to do that.
NOEL:  Do you guys pair program a lot?
ED:  Yeah, we do a lot. A lot of it comes to, [inaudible] something new, we do it together. If we're having problems, we'll help each other out in that regard. But yeah, we do pair program a lot. A lot of times, we pair program with our clients as well. Right now, we are working with one of our clients who is an internal developer. As you can imagine, we do things differently than their developer does, so we have to spend some time with them to wrap them up and so we do a lot of pair programming with the clientsÕ developers as well.
NOEL:  I guess that brings me to another set of questions. You get the app to the App Store and it goes live and then you still need to maintain it. So what kinds of information can you get about a live application, first of all. Then how do we deal with that as a matter of project management? How do we deal with the maintenance and ongoing incremental kind of work?
ED:  We currently use Fabric which is a nice little suite of tools by Twitter. They give you beta deployment. They give you a Crashlytics, which is crash reporting. They give you Answers, which is an analytics tool and we kind of pay attention to that stuff alongside just the standard analytics that come with iTunes Connect.
NOEL:  Do you need to build those analytics into the system then, the way like Google Analytics might work?
ED:  Kind of. It depends if you want something custom. If you just include the standard answers library and give it your API key and you turn it on, you're going to get a surprising amount of metrics just from that. YouÕll get the session-length, how many users, how many new users? They give you retention data. They give you crash for users. They give you the crash reports from that. They give you all sorts of stuff, monthly active users.
	But if you want to say like, "Hey, somebody signed up," or, "Somebody that was offline six months ago, logged in for the first time," or, "Somebody was viewing this screen," or something like that or some type of action, "Somebody liked this page." Those are all custom events that you have to put in but those are surprisingly simple as well to put in.
NOEL:  Then how do you turn that into ongoing maintenance work to balance with existing projects because a problem is getting stuff to the App Store when you have fixes. Is that a barrier?
ED:  Not necessarily. We try to deploy every week. That only needs to happen for so long and then we'll try to transition to an every two-week type of thing. But usually, if you get crash reports in and they're looking at below 80% stability, you want to hop on those immediately. So far, we've been able to do that just through iteration after the initial product launch.
	You essentially go live with an MVP and then there's some iterations you want to do after that and you kind of address the stability issues if there are any, alongside the features that you want to have.
NOEL:  What's the project that we're doing that you are really excited with how it turned out or some new technology that you relatively recently able to use and bring to bear that you're really happy with how it turned out?
ED:  Well, the most recent one that we just pushed live was Everything But The House. That is probably one of the best pieces of work that Table XI has done.
NOEL:  Can you describe what it is, what it does?
ED:  Everything But The House is an estate sale platform. If you have a family member die, you would call them, they would come to the house, they catalog, package, and take everything to their warehouse. Then they'll take pictures of it. List it online and then put it up for auction.
	So basically, you say, "I want to get rid of all the stuff in this house," they come and take it all and then you just receive a check later. It's a very hassle-free way to empty out a house before you sell it.
NOEL:  When you say that that's some of the best work that Table XI has done, like what kinds of things were you able to bring to bear on it that made it so?
ED:  We had an incredible amount of test coverage. We worked really well with their internal developer. Their internal designer was phenomenal and the app looks really great. Aside from that, we got to do some really deep snapshot test case stuff in that app, so we really got to put it through the ringer in terms of like, "Is this going to work long term?" And it succeeded with flying colors, in my opinion.
	We've also got a really, really high code coverage number. We got the developer to buy into that so we got really thorough testing. We got to use PubNub on it, which was cool as well.
NOEL:  What's PubNub?
ED:  PubNub is a messaging service. I think it uses web sockets that's like real-time messaging. So basically, like if you bid on something and someone outbid you and you're on another screen, you can get that notification. It doesn't have to get routed through APNS or anything else.
NOEL:  Cool. Sounds neat. Is there another tool that you are using now that we haven't talked about that you would recommend to mobile developers who are looking to really up their game?
ED:  One thing that I recently used on a personal project that I really, really like is ReSwift, It's essentially a Swift Redux implementation.
NOEL:  What do you mean by Redux?
ED:  Redux in the React world.
NOEL:  Okay, so Redux is the event library, correct?
ED:  Yes. It's a Swift implementation of that. So you have your actions and reducers in app state. ItÕs a really, really good way to keep everything in order and you'll attract when something breaks and where it broke. Have you even seen implementations that used recorders, where the app crashes? You can take the recording of the app state and play it back and watch what the user was doing at the time in the simulator.
NOEL:  That sounds helpful.
ED:  Yeah, it's awesome.
NOEL:  Neat. Thanks Ed for talking to us today. 
	XI to Eye is brought to you by Table XI. We are 35 meticulous and curious minds in Chicago with a 15-year history of building websites, mobile applications, and custom digital experiences for everyone from startups to story brands. Our partners trust us to create innovative solutions that drive their businesses forward.
	Let's work together. Find us at TableXI.com where you can learn more about working with us or working for us. I'm Noel Rappin and I've been talking to Ed Lafoy about our Table XI's Mobile Development and we'll see you next time on XI to Eye.