 do the motion meetup just about every month, sometimes less. And we have a good old time, and I've been fortunate enough to be asked to help lead the panel today. We have some amazing people. The category is Ruby Motion in Production. So if you have any questions about your particular apps in production, we have a great set of people here. We have Ryan Rominchuk from Frontback. We have Daniel Dickerson from Bandcamp. And this guy, nobody knows who he is, Colin Gray, everybody. So we have Colin Gray, and he's going to be representing Jukely today. And so we have some questions. Now, the great part about this is that you guys get to come up and ask your questions as well. We're going to go ahead and seed some questions to start it off. But if you have a question, please line up right over there on the left side. We'll form a line, or any way you want to. And we'll divide the questions out to you as we see fit, which means if Todd comes up here, we'll ignore him. It's fun to dig on Todd Day. All right, guys. So what I'd like to do is I'd like for each of you to introduce yourselves formally. Talk a little bit about your app so that everybody knows we might not have used each of these applications. So if you don't mind. Colin Gray, and I am the community manager at Hip-Bite. When that role comes up, it's kind of ad hoc and here and there. My full-time job is at Jukely. It's a startup based in New York City. We've built a music application and music promotion platform. So we link up local live shows with people who love music. And hopefully we give them music that they're interested in. I think the tagline is it's like a mixtape made by your stalker. So we really try to use your, re-aggregate, Facebook information, SoundCloud, let's see, your iTunes music, lots of different music sources, Spotify, RDO. We take all those likes and favorites, put them in our algorithm, and then deliver recommendations back to you. Hello, I'm Daniel Dickison. I work for Bandcamp, which is music, a lot of music, I guess, online service for artists to sell music, digital music online. And the app, the first version of the app, was basically a way to listen to your purchased music on the go. And since then, we've been slowly adding more discovery features. You can follow artists and other fans and see what they're listening to, see what they're buying, and check it out. So the Bandcamp app. And yep. Yeah, I know. Hi, I'm Ryan Romachuk. I'm an iOS developer at Frontback. And we are a photo sharing app that is you and what you see, much like the name suggests. You're able to take two photos with both camera devices, or two fronts, or two backs, and two photos on top of each other. Excellent. All right, so I'm going to go ahead and start with the first question here. Basically, a start. What made you choose your production app to be in ruby motion over any other possibility that was out there? Yeah, so the origin story of Frontback is interesting. I was in Russia for the last two years, doing iOS Objective-C app for a company that are called Osterok.ru. And Frontback is basically another company, a consumer web company called Check This. And they basically were out of money. They were Rails developers. And they started working on a fun little app, which is now today's Frontback. If it wasn't for ruby motion, Frontback would not be where it is today. So I was able to really save that company. Nice. Yeah, so I had done, personally, I had done some Objective-C and iOS development before. But the rest of the band camp guys are all familiar with ruby. So that was really the driving reason for using ruby motion to write the app. Michael Bieber, who's over there, he's another band camper. But so he was able to come on to the iOS project sort of after the initial release and just kind of get up to speed real quickly, because a lot of the code is just straight ruby. So that's the big reason. So I'll answer this in two ways, because I came on to the app later. Bora Selleck is the creator of the app and founder of Jukely. And he chose it because he had had a long history of Java and before that, Microsoft development. And he knew that he wanted to do a startup. He wanted to do an iOS app. He had a Jukely idea. Him and one of the original Kickstarter designers, Andrew Cornet, got together. Cornet, Cornet. I hope he doesn't watch this. And they chose ruby motion because, again, of the ability to write in ruby, he wanted to enjoy this startup that he was creating. So he created the app. It took him about three months to release the first version. Then they contacted me because of my activity in ruby motion, asked me to help them out with some bugs. And I said, well, I'm actually already working full time in other capacities. And about six months later, he said, OK, how about an offer? And at that time I was like, OK, yeah. I would love to do ruby motion full time. Nice. Yeah, all right. So to dig a little bit deeper, let's go a little bit further. And now we know a bit about it. Which gems and coca pods are you using in these production apps? Well, we care. So actually, in Jukely, I inherited the app. And so they weren't using many gems at all at that time. I brought in Sugar Cube because I don't know how to write iOS code. I just write Sugar Cube. So of course, I'm the maintainer of Sugar Cube. So there's that inside Juke. They do use a lot of coca pods, AF networking. I'm not going to remember them all. Reachability, Mixpanel. I've played with Firebase for remote logging. Gosh, I'd have to pull up my rake file. I don't keep things in memory very long. And let's see here. As we've developed, I've brought in a lot more gems. So I am starting to build the UI and motion kit now. And I think that's the majority of them. Oh, and bubble wrap. Yeah, we also didn't use a whole lot of gems in libraries. Well, part of it was we started development pretty early on and wasn't clear at the time which gems would become sort of stable and a long-term thing. But we wrote a lot of utility stuff in-house also. Some utility things to do auto layout, constraints, and things like that. But yeah, we do use some libraries, just pulling in source files from GitHub and putting it in the vendors directory, kind of old school way, like FMDB if we're doing SQLite accesses. I think we use TMDiscash, which is, I think, Tumblr's caching library, and a few other ones, reachability. I mean, reachability's everyone uses that. Yeah, so yeah, but even now we don't have a whole lot of gems pulled in, which I think probably will change after learning about a lot of the libraries here, so we'll see. Yeah, we use very few. We use, basically, we cherry pick the things that we really need. So like CherQ, we cherry pick the localization. Bubble wrap are using just the location. It just makes it a little bit cleaner. The only DSL we're using is Clay's AFMotion for AF Networking, which makes it much nicer. We're using SDU Web Image for our image caching. Yeah, yeah, yeah, it's amazing. AF Networking, the usual suspects, but that's about it. Gotcha. Excellent, so as far as all the different setups, what's the exact business model? I'm especially interested with Frontback and some of these other items. What's the idea here? You're going after the user base. What's the financial roadmap? Well, I mean, the photo sharing space is huge risk. The only way to win is to win the entire market, so it's all or nothing. It's like we're not, you know, we're gonna kill Instagram or not, and AFMotion's gonna hopefully help us get there. Yeah, for us, I guess we already had a established business, sort of, so it is a little bit unfortunate that we can't sell music directly through the app because of the Apple restriction. But yeah, people go on the web to buy the music and then just have a new way to listen to it easily without having to import music through iTunes, which is the pain of the butt, so that's just adding extra usability, really. So yeah, in Jukely, we have a couple revenue streams. We sell tickets through the app, so it is you're scrolling along, you've gotten a recommendation, you open that up, you can listen to it on the app, and it does a fun thing if you let it just play from person to person. We use the speech synthesizer to say the artist's name and the date, so you can hear beforehand, oh, I dig this, and you can open it up by the ticket right there in the app. And then the other part is the marketing aspect, so we are bringing artists to customers. I think there's value in that, and so we get some, actually I don't know how much I'm allowed to say about that, but that is, obviously there's revenue to be made from that. Very nice. And so actually, I see we had an audience question from a gentleman who's gonna be talking about marketing today, Mark Rickert. Hey guys, so I know when you have an app in production, things don't always go the way that they went on your simulator or on your device, and so there's inevitably problems that rear their ugly head in production. Can you guys talk about how you handle those things, maybe services you use? I know you mentioned Mixpanel for analytics, but what about crashes in production? How do you guys track those and handle those errors? So yeah, we also use Hockey App, and I highly recommend Hockey App. There's lots of bug reporting tools, and I've actually had some success with, as far as setting up, I've set up Test Flight and Criticism and Hockey App. I like all three. We're using Hockey App, and it's working very well for us. We also use, yeah, I actually use kind of three logging, so Hockey App on a crash, Mixpanel for user interaction and user behavior, and then I also use only in development, I use Firebase to send logging events, and it's very verbose, so it's like this streaming log of every request and kind of everything. So that's my noisy developer log, but let's see. Also, a lot of fixes have happened by having an API that is catering to iOS. What I mean is our API is obviously consumed by the web service as well, but we can change the web service very quickly. So if we find out that data is being expected on iPhone and that's not coming from the API, we'll rework the API to accommodate that and then rework the web service to accommodate that just because we can do those two things instantly. You can go really far down that road to, I've heard of people having all their UI serve from the web, so you have a version on the device, but then it can get refreshes from servers. That seems like some voodoo to me, but it can be done. Yeah, crash reporting is a good one, because in theory, you can go to iTunes Connect and you can see crash reports there, but most crashes don't actually show up, so we ended up just using a PL Crash Reporter, which is just a client-side thing that dumps out a crash log locally and then we just upload it to our server on the next launch and we track it that way, which is, it's okay, it's kind of a pain to symbolicate after the fact, but at least we do get a sense of the frequency of the crashing and there's definitely things that crash only very infrequently, like especially with concurrency-related things, so it's good to actually get a hard count of the number of crashes that are happening, which you just won't see in beta testing. Yeah, and also for general event logging, again, we kind of queue them up on the app and then send them to our server, where we have, we already had various ways we're tracking stats on the site, so we kind of tie into that, have a new stream of data that's coming in just directly. Yeah, pretty much a lot of the same. We have a large, dedicated beta testing group on Hockey app through our enterprise certificate, so we try to get hundreds and hundreds of people downloading and catch the crashes on Hockey app. For non, for events that I want to know about that aren't, I don't want to cause a crash, I send to Google Analytics, because our mixed panel bill is already way too high. The other tricky thing is, when you build a binary for Apple with your app store certificate, you actually never get to run that binary on your own device, so there are actually, you can really mess up and wrap some code around a production if block and not realize that, have a bug in that section, so the best thing I do now is under the notes is to say, sometimes Apple will not test your app, so I say, please make sure the app launches. And so that, that goes a long ways actually sometimes. I might have to quote you on that. So there's a constant RubyMotion underscore in and you can have this kind of fork of code, so for instance my Firebase logging only happens in development, so that's Hockey app simulator and on device when I compile it. Anything in production doesn't go there, so yeah, if that's the other if block, you will never run that. You could compile your app for release, so mode, rake, mode equal release, and that'll compile it for production. It actually leads me into a really good statement. I have some insider trading information on you here, I know one of the problems that I think people come across is that you'll have an app with more than one developer working on it and then you'll have the issues, like how do you handle that? I know specifically use a motion M, is that the gem or do you just set up in your environment? No, I do in the rake file. I should use motion M or something, but again this is a situation where I kind of came on and fixed what I needed to do what I wanted, so what I do in my rake file, so there's three people who, actually four people now who will compile the app, most of the time it's me, I'm the iOS developer, but also the two founders and then also our API guy, so they'll compile it and for each of them, basically I check the end user and if it's Bora then I do the settings for Bora and he can change those, if it's Andrew I do it for him and then we have another version for Hockey App and another version for release, so if it's in release mode it goes down there. So yeah, if you need to enable and disable things for you or for certain testers, things like that, so for instance you could do A-B testing, there's a fun trick where you can go in your rake file, check for those settings, so this is during compile time and then include a Ruby file, either this one for one, kind of like an A-B testing, or you might generate a Constance file and include that at compile time, and we do both of those. Another way you could do it also is in the rake file you could set arbitrary keys in the info P list and then you can pull that out at runtime, so I think we do that for enabling test flight, SDK stuff for test flight builds, but I think we try to keep the test flight builds as close to the production release settings as possible, so try to minimize things that are, just come out for the release build. Also, if you're working on a team, I strongly recommend you actually version your Ruby motion, so like if you have a new hire, he could download the latest head when you're working on another version, and that can cause a lot of issues, so I check in, if I'm running 2.28, I check it in and everyone is forced to download and cache that version of Ruby motion. Nice. You can specify a version at the top, I'm just loud so this thing doesn't actually affect my, and that reminded me of another thing and I'm gonna forget it. Oh, tag your releases, so when you put out version 2.1.1, tag 2.1.1 because in your stack traces sometimes they won't symbolicate right, and you'll just get all these memory addresses, and if you try really hard, you can symbolicate them on your machine. You can go, you can compile it for production, you can find that address, and you can use A2S to get that line number, it's not easy, it's not enjoyable, but it's possible, and with some of these crashes it'll save you, but you must tag that release, any small change, and all those memory addresses are just all different. Gotcha, all right, it looks like we should take another audience. How do you guys do your builds? So how frequently do you release a production build to the app store, and when you do that do you build it just by hand, or do you have that automated in any way? He's thinking. Well, I mean like we have, so I love to deploy bugs into production, like co-founder doesn't, so Hockey app is great for me because I'm pushing, if you have an enterprise certificate and you have users testing it, and who are always testing it, you can basically get a build out, I mean sometimes I'll have a build five times a day, it'll be fix, oh sorry, fix, oh sorry, fix, which, and then we just basically stay consistent, so if I'm doing the app store build, I'll do the app store build the next time as well, I mean we have, there are those issues where configuration problems, but you can usually have a pretty clean rake file across environments, but it's just, it's more superstition than anything. I'd say for release builds, you know we'll have a release with features that you know that might take weeks or months to do, and then often right after the release we'll find some bugs, so they'll be within the course of a few days, we'll submit another bug fix, but yeah for testing builds, yeah usually we try not to do more than one a day, maybe a couple a day, because I think you get tester fatigue, so yeah but for release builds, it's basically as soon as, if it's a bug fix build, you just submit it as soon as possible and just hope it gets reviewed quickly. Yeah and there is a possibility that you can ask Apple to rush a build, that you won't do it very much, so you can't abuse that feature, but if it is something that's like all your app, it's on the app store and if you open it, it immediately crashes, you can ask them to really please rush this, and sometimes they will or won't honor that, especially if you just ask them before that, then they're more likely to ignore you. So yeah for builds, we also, I do all the code and I never submit to the Apple store, I'm not allowed anymore, for the same reason. So yeah, I build, I send it out, testing happens and then that, Bora will submit it to the app store. Use Hockey app, do have testing, oh we have a checklist that I resend and that's like me being a jerk, like whoever is testing, I want a star by all of these, I did open settings, I did do a filter, I did close it and verify that it did filter, things like that, that we've broken that before, we've broken that before, we've broken that before, so every time we break something, it gets added to the list or of course hopefully we've added things preemptively, and that checklist has helped us a lot, I think that's our earlier best bug fixer. How big a to-do list kind of guy anyway. So I wanted to ask, besides writing tests, which is everybody's favorite part, what was your favorite part of writing the application? The iOS 7 transition, so actually when Laurent showed Jukli, I reeled in horror because that was the iOS 6 version, and our designer is, he's awesome, he is so good and he has such an eye for the iOS 7 mentality of content and context and he just nailed it. If you've used Jukli, you might know what I'm talking about, but it's an iOS 7 look and feel that's just really enjoyable. So it has a lot of custom transitions, custom controller transitions, and those were kind of a joy to code. A lot of blurring and opacity, fade-ins that are just, for me I like to build myself as a UI and UX experience kind of person, and building those out was a lot of fun and I think iOS gives you a lot of really neat tools to accomplish those. Yeah, and didn't it release, iOS 7 was announced right in the middle of all that, and I think that they were announced it and then it released in September, so you got caught right in the mix. We did, yeah, we kind of, we had to, we didn't have to rush iOS 7, we were really glad to do it, you know, Andrew's the designer and he was like, ah, this is gonna be awesome and we had a lot of fun building the designs, but it was also an entire app to update, so just as far as volume, it was quite a rush, but we wrote a lot of helpers, like the nav bar, we rewrote nav bar, so we have our own UI navigation bar like item, but it's all of our own buttons, our own graphics, and it kind of works our way. So yeah. Nav bar's interesting, we have to write our own nav bar too, because the built-in UI navigation bar is really limited in customization, but yeah, and I have to confess, we're pretty bad about writing tests, so we should probably do, I don't know what test, yeah, so that's something we'd probably do more of, but I guess like, favorite part is, when you're working on individual pieces of the code, it can get frustrating, but it's when you see all the pieces finally come together, like you got your server-side APIs working, then you got the client-side stuff working, you buy some music on the site and you launch the app and suddenly it shows up, it's, you know, that's the best part. I'm sure, you know, everyone that writes software can relate to that feeling. And the angels sing. I think one of the great things for me coming to Remotion was, before this I was the iOS developer of Objective-C, so when I first joined, I was like, oh, we're rewriting, we're rewriting, we're rewriting, we have to, but I was actually pleasantly surprised about how compatible becoming, I mean, I was a Rails developer too, extremely compatible, like coming over to Remotion as an iOS developer. At first it's a little like, where's my Xcode tool set, where's my debugger, where's my, I mean, where's my, now you have all of that, those tools, so. Even with like, things like core data, will this even work in Remotion? Everything has worked. Very, almost no problems, so, it was great. Very cool. All right, we're gonna go ahead and do probably our last audience question. Sorry, Todd. He has a back front question, he's working on his own. All right, so, my question is, whenever Hit Fightin' Team releases one of these like 30% increases or something, have you ever been guilty of just, like, bug fix releasing, and just by recompiling, and you're like, ah-ha, we did something cool. We should, it's a great idea. No, I think whenever they happen, actually I'm usually the first one to download it and test it and make sure it works. And I'm always in the middle of something. He doesn't time it for me, for some reason. So yeah, I haven't gotten to do that, but actually, when a Ruby Motion 3.0 comes out, or what version are we on? 3.0, it'll be 3, yeah. With Watson's speed increases, I think that's a great idea. Yeah, I mean, by the time there's a new Ruby Motion bug fix, we have plenty of bug fixes of our own, so there's always something. But it's actually kind of an interesting, with all the speed increases lately, there's one part that we did some profiling in, that we kind of wrote in Objective C, because the Ruby Motion dispatch and string manipulation was just kind of slowing it down, which is the searching through your collection feature, which does some fuzzy matching. So a lot of string operations in a tight loop. So I'd be curious to see, with all these speed increases, if we just go back to the pure Ruby version, maybe it's fast enough now, so it's great that Ruby Motion lets you write Objective C and seamlessly just call out to it. Really trivial to do, which is awesome, but it'll be great if we can just, as much as possible, keep it in the Ruby world. Yeah, and we support over 30 languages, so our language file, our strings are always updating, so I love to have an excuse to get a new version out as soon as possible. And another pro tip is, don't actually write updates in your update field. Write something funny. We have a competition to see how many tweets we can get from our ridiculous staff. I mean, Apple doesn't care. Marketing tip. Very nice. Okay, so it seems we're running out of time, so one of the things I wanna do is I wanna ask one last question with the announcement of Ruby Motion 3 with the BlackBerry support, I mean Android support. What do you see, how do you see this working for your application moving forward? Are you gonna jump straight into using it on the Android side or are you just gonna kind of test it out? What's your plans? Well, unfortunately, we already have the Android version out already, so if this was like a year ago, it would have been awesome. We probably would have been writing the Android app in Ruby Motion 2, but who knows, maybe. I mean, I think we'll definitely play with it, so it'd be interesting to see that. So yeah, I actually had a really hard time because I didn't feel right to tell my coworkers that Android support was coming. I was on strict, no one is told this, so they're asking me, hey, we wanna do an Android app, would you be willing to do that? I'm like, yes? Great, how's your Java? I'm like, okay. Maybe we could use Roboto, and of course, I'm saying we should use Roboto, and I'm knowing it's got the startup time issue, it makes big files, but I don't have to tell them that, but they'll figure it out quickly because of the startup issue, and luckily, at one point, they said, hey, real sorry, but we're gonna have to put that off for many months, and I was like, oh, bummer. So, and then today happened, I'm like, oh, I'm in the clear. Yay, so, Go Team Jukely will be writing our Android app in Ruby Motion. Yeah, we already crossed that bridge. Yeah, we needed Android out, and just bad timing, so we have a great Android developer, we're already down the road, but I'm excited to actually play with it myself. Gotcha. All right, well thank you everybody. I'm sure these gentlemen, let's give them a round of applause to the great gentlemen. I see we didn't get to the end of the questions here, but I'm sure these guys will be around, right? So, thank you everybody.