[00:00:00] (Music) Welcome to the CodeNewbie podcast, where we talk to people on their coding journey in hopes of helping you on yours. I'm your host Saron and today we're talking about building iOS apps. (Music) Amir Rajan is a critically acclaimed indie game developer. He's also CEO of the RubyMotion, a tool that helps developers turn their Ruby code base into a iOS app.

[00:00:29] AR: My name is Amir Rajan, and I am an indie game developer slash CEO Steward of a product called RubyMotion.

[00:00:38] SY: He's learned a ton over the years of what makes a great app. Some of it is technical, but there's a lot of business stuff, too. In this episode, he shares his app-building experience and digs into why a tool like RubyMotion is needed in the first place. After this.  

[00:00:57] When I first learned to code, all I wanted was to be a developer. But then I actually learned to code and realized that you don't become a developer, you become a front-end developer or a rails developer or a full stack engineer or a back-end engineer or the million other job titles that involve coding. So how do you pick? And once you get that first job, how do you turn it into a career? You can use the Dice careers mobile app. This is the tool I wish I had when I first started. You pick the tech skills you either have or hope to have in the future, you type in your desired job title and Dice helps you find other job titles you might also be interested in and maybe didn't know about. But they take it a step further by telling you what skills these job titles require, how much they pay and, based on your profile, they tell you what skills you might want to learn so you can one day apply for those jobs. They simplify a lot of the chaos of job hunting, and it's totally free. So check out the Dice careers mobile app. Go to dice.com/codenewbie for more info. That's dice.com/codenewbie.

[00:01:55] Flatiron School teaches you how to code from anywhere. They've got an awesome community of career-changers and a number of different options for you to pick from to become a software engineer. They've got full-time in-person courses, self-directed introductory courses and a remote online web developer program. They even have a free 75-hour online prep course where you can learn Javascript, Ruby and do some interview prep. Go to flatironschool.com/podcast to learn more. That's flatironschool.com/podcast. Link is in your show notes. 

[00:02:29] One of the best parts of being a coder is finally being able to bring your passions to life. You have the skills to design, to code, to create the thing you're excited about and share that passion with the world. And Hover can help you with the first step of sharing your passion with the world: getting your domain name. They've got a really beautiful and easy-to-use interface where you can find and register your new domain name in just a few steps. And to give you full control, they separate your domain name from your hosting so you're never stuck with one service. They keep your domain name safe while giving you the flexibility to use whatever hosting service is best for you. They also give you free WHOIS privacy, so your personal information is safe, too. To get started, go over to hover.com/newbie to save 10% off your first purchase. That's hover.com/newbie. (Music) Link is in the show notes.

[00:03:20] So you’ve been—from what I've seen, it feels like you've been in tech for a while. You're actually an indie game developer as you mentioned, but you are the steward of something called RubyMotion. I feel like there’s so much to unpack and explore in that. Let's start with defining what RubyMotion is. What is that?

[00:03:37] AR: RubyMotion is actually a compiler. A compiler basically takes a language and converts that specific language into a type of binary that can be consumed by a chipset architecture. So in the case of RubyMotion, RubyMotion is a compiler that compiles Ruby down to a binary format that can be consumed by mobile devices. What it brings to the table is the ability to build iOS and Android applications using Ruby the language. Ruby is a language. RubyMotion is a compiler, and it's a… the value add is basically that little compiler piece is what allows the language to work on mobile devices. 

[00:04:17] SY: Ok so when would I need a compiler? And why do I need one in this situation?

[00:04:23] AR: So a compiler is basically a thing that can take your higher-level language and put it into a form that some kind of machinery or some circuit board can actually interpret. So if you think about—let's say back in the day—PCs, we had the x86 architecture. That's, that's like a standard chipset architecture. So you have Intel, you have AMD constructing these chipsets. And then another company comes in, and they decide to do something called ARM 64 . So ARM is primarily what our mobile devices run. And that is another chipset architecture. So the challenge comes that ok well I have this high-level language. I don't want to code in, you know, ones and zeros. That's not very productive. 

[00:05:06] SY: No.  

[00:05:08] AR: So I have this high-level language, and it has to be converted into something that can actually run on those different chipsets. It's really tough, right? So there's a, there's that low-level aspect eventually everything does go down to assembly and ones and zeros. But it's the compiler that allows you to have a single high-level language that can target multiple chipset architectures. So that's the, that's the value of having a compiler in the middle. There's a lot of compiled languages out there. Ruby is a dynamic language, but in the context of RubyMotion it is a compiled language. Objective-C is a compiled language. Swift is. You have C#. So there's a, there's a lot of languages that are compiled. But essentially what you're doing there is basically saying, “I have a high level language that needs to be understood by many different types of circuit boards, and a compiler is the thing that translates it to those backends.” 

[00:06:02] SY: Ok, so when we say that languages are compiled, does that mean that I have to go and compile them? Like I have to do that stuff myself? 

[00:06:12] AR: Yes. So generally, your IDEs or your—let's say you have things like Xcode. Another IDE would be Visual Studio. So those constructs have these built-in mechanisms that can consume a source code file and send it through this manual step of compilation. And then when and when compilation occurs, you get these assets to come out the other end. It could be DLLs, which are dynamically linked libraries, or .exe files which are executables. And that's basically your compiler right there or your—the artifacts of the compiler. 

[00:06:44] SY: Yeah, that’s the result of the thing that has just been compiled. 

[00:06:46] AR: Exactly. 

[00:06:47] SY: Ok, so for Ruby, which you said is a dynamic language, it doesn't work that way. So how does, how does Ruby work?

[00:06:53] AR: So Ruby is an interpreted language. So there is basically a binary called Ruby that you would pass your Ruby files to. And what the Ruby binary would do is consume that Ruby file and then interpret it on the fly and execute some arbitrary set of code. That works great on the server side, on big machines that can have that language runtime run and have a language interpreted, but when it comes to mobile devices, you want something that is faster and can be consumed in a pre-compiled binary format. There's constraints with regards to Apple and like submitting apps to the App Store. They have to be compiled binaries. So it's just one of those things where it’s like you got to compile it and you got to, you got to distribute it this way. So with regards to Ruby on the server, it is an interpreted language, and the way that works is basically you're getting compilation on the fly—would be a way to say it. And what's happening there is that basically this Ruby binary that you pass all your files into, that's acting as the intermediary as basically a virtual machine. And this virtual machine is what's taking that Ruby code, parsing it on the fly and then sending it to a back end. And it's compiled real time, you could say. 

[00:08:11] SY: Yeah. Ok. So I notice there's two words. There's interpret and compile that we've been using. 

[00:08:17] AR: Yes.

[00:08:18] SY: Are those interchangeable? Or do they have distinct meanings in this context?

[00:08:22] AR: With regards to dynamic languages, they do have distinct meanings. So when it comes to an interpreted language, that means that there is no upfront static compilation or unchangeable compilation to a specific binary. So the bad thing is that it's not as fast as a compiled language, but the cool thing is that you can build programs that change themselves. So the concept is called metaprogramming. Dynamic languages and interpreted language, because they're not statically compiled per se, give you the capability to do a large amount of metaprogramming. And when you get into this world of “I can have a program that can write a program…” 

[00:09:00] SY: Oh, sounds so fancy. 

[00:09:03] AR: Yeah, it gets really fancy, and it's incredibly powerful. But it's one of those things where you just kind of dig in, and then once you get a grasp of how that's possible, it opens up a whole different world. 

[00:09:13] SY: Ok. And I get metaprogramming with dynamic languages?

[00:09:17] AR: Yes, that's correct.

[00:09:17] SY: OK. So I think a good way of just thinking about metaprogramming for our purposes is, like you mentioned, a program that lets you write more programs. 

[00:09:26] AR: Yeah, and it writes based on maybe convention. It basically sets you up in such a way that you can write the framework for how programs should be created and then that program can itself write a program on the fly that does what you needed to do. 

[00:09:42] SY: Wow. So what is an example of that?

[00:09:46] AR: So let's say I had a class, right? And I had a property called, let's say “bio,” and I want to present that bio to something on a web page. Now the tricky part for those that have done HTML development, let's say that the “bio” had like the open caret closed caret that you would get in HTML. If you try to present that directly, what would happen is that it would render as HTML, right? So you have to escape those characters. So in a statically type language, you could potentially have like first name and then first name escaped, let's say, and then have that method available there that does the escaping for you. But the problem is that you have to write that method up front, right? And it's got to be compiled and then shipped that way. So in a dynamic language, what you can do is you can say I have this first name property and dear meta program, if you ever see a property come to you that doesn't exist on you and that property ends in the words safe HTML, what I want you to do is I want you to parse that method, get the first part of that method, which is what I want you to safely compile, and then do the compilation for me. So you get a first name underscore safe HTML property without ever creating it. You just provide the convention for it. 

[00:11:05] SY: Oh, interesting. 

[00:11:08] AR: So basically any property on any class gets that capability. 

[00:11:11] SY: So in that example, is the benefit that I don't have these possibly unused methods lying around? 

[00:11:20] AR: Exactly. 

[00:11:20] SY: I only create them when I need them? Ok.

[00:11:22] AR: Yep. On the creation of it, you... basically, you can create that method on the class and then cash it on that instance. So only those specific instances that ever had that method called would take up that memory space. And then subsequent creations of class would lazily create those methods as needed. 

[00:11:42] SY: Interesting. Ok so that's only possible with dynamic languages not with static languages.

[00:11:47] AR: That’s correct. 

[00:11:49] SY: And so dynamic languages are interpreted? 

[00:11:52] AR: Yes. 

[00:11:52] SY: Ok. And then static is compiled. 

[00:11:54] AR: Yep, and they're statically compiled. 

[00:11:55] SY: Oh, look it, look at me learning stuff. This is exciting. 

[00:11:59] AR: Now there's always a disclaimer so there's always caveats, right? So… 

[00:12:03] SY: Yeah. 

[00:12:03] AR: So like C# has something called a dynamic language runtime where you can do some metaprogramming for parts of the framework but not other parts. So, you know, I just always have to say that, right? If you make the black and white statement of…

[00:12:18] SY: Yeah, yeah. 

[00:12:18] AR: Oh, static language you can’t metaprogram, you'll have someone come back and say, “oh actually…” So it's worth saying, but generally speaking, interpreted language or dynamic languages have a much easier time constructing these kinds of metaprogramming concepts over statically typed languages.  

[00:12:34] SY: Ok, so going back to the Ruby RubyMotion part of things, the idea is that Ruby is a dynamic language and so it's interpreted. But for iOS apps, you need to have static? 

[00:12:50] AR: Compilation. That is correct. 

[00:12:51] SY: Ok, so that's when you like you can't put Ruby Ruby in an iOS app. 

[00:12:56] AR: Right. So what happens is that I guess this goes back to that disclaimer, right? So RubyMotion is statically compiled, but it has metaprogramming capabilities. But not all of it, right? So what happens is that vanilla Ruby can do something called eval where it can take an arbitrary Ruby string and execute it. RubyMotion cannot do that one, but it can still do that previous example that I gave. So it's a minor compromise, and it's just one of those things where you kind of as the language designer, you have to pick and choose where that spectrum exists on your specific language. 

[00:13:28] SY: Ok. So RubyMotion is—it sounds like it's for Ruby developers who want to keep using Ruby or maybe have already made something in Ruby but want to create an iOS app from that. Is that a fair description? 

[00:13:39] AR: Absolutely. So that, that is definitely by far the first customers. You're familiar with Ruby, and you want to continue doing that for your mobile applications. 

[00:13:48] SY: So how smooth of a compilation process is that? Do you know? Are there lots of hiccups and issues along the way? Or is it, you know, I press a button and then magically I have an iOS app. 

[00:13:59] AR: Yeah, so the complexity primarily comes around Xcode. Once you have that installed, you type a command which is rake. It stands for—Rake stands for “Ruby make,” but you type rake, and you have a simulator pop up that is your app. And then there's another command line argument called “rake distribute.” It’s rake archive distribution is the full, unaliased version. And then that gives you your iOS app that you can upload to the app store. 

[00:14:27] SY: Wow. 

[00:14:27] AR: Yeah, the beauty of RubyMotion, or those that have used Ruby, they're generally editor agnostic. So you go to one Ruby developer. They'll use maybe atom, and you go to another one they might use vim. Another one might use RubyMine. It's a big ask for Ruby developers to have to use Xcode. And RubyMotion kind of fills that gap by saying you know we've got these commands that you can run from the terminal that do what you need to do and you can use whatever editor your heart desires. That was one of the bridges that were put together, right? And with regards to these, these command line arguments, that's why it's so easy, right? We have to make it easy to be able to run these commands from a terminal or from a buildbox or some kind of, you know, (Music) continuous integration environment. A CI environment is basically something that automatically builds for you without having to physically press a button or, you know, click something you wiggle your mouse or whatever you have to do. 

[00:15:23] SY: Coming up next we hear more of Amir’s story and how he got into Ruby in the first place. He also shares his thoughts on the importance of a CS degree and what you might want to do if you don’t have one. After this. 

[00:15:37] When I learned to code, I was so excited to finally bring my passions to life. I could build things that I really cared about and share them with the world. And the first step in sharing is getting a great domain name. That's where Hover comes in. They've got a really slick east-to-use interface. They've got awesome domain names to pick from and they separate your domain from your hosting so you have full control and flexibility over your online identity. So go to hover.com/newbie to save 10% off your first purchase. That's hover.com/newbie. Link is in the show notes.  

[00:16:09] You want to get serious about learning to code, but where do you start? Flatiron School's got the perfect thing. They're offering their free 75-hour online prep course, where you dig into Javascript, Ruby and more. If you're not sure where to start, start there. And when you're done, you can keep learning with their self-directed introductory courses, remote online web developer program or full-time in-person courses. Whatever your schedule, they've got options to help you reach your coding goals. To learn more, go to flatironschool.com/podcast. That's flatironschool.com/podcast. Link is in your show notes. 

[00:16:47] Getting a job is one thing. Building a career is another. With Dice, you can do both. They've been helping tech professionals advance their careers for over twenty years, which means they have a ton of data and tools to help you navigate yours. Looking for a job right now? They've got thousands of positions available from top companies like AT&T, Dreamworks, Adobe, IBM and Dell. Wondering what's next in your career? Use their career pathing tool to find new roles based on your profile and see how much more money you can make. Not sure if you're getting paid what you're worth? Use the Dice salary predictor to see real numbers on what your skills are worth. Don't just look for a job. Manage your career with Dice. (Music) For more info go to dice.com/codenewbie. 

[00:17:30] Ok, so what about your role specifically with the RubyMotion. You describe yourself as the steward. What does that mean? What’s a steward? 

[00:17:37] AR: Yeah. So this goes into the deeper aspects or my deeper philosophies of what it means to maintain—for lack of a better term—maintain a compiler or maintain a product. And I see learning a language and using language as a journey, right? There's, there's gonna to be times where you are coming onto it and frankly, there's gonna to be times when you move off onto something else. A perfect example would be Twitter when they started their entire infrastructure on Ruby on Rails and then transitioned away from it, which is… there's nothing wrong with that, right? So when I think about steward and stewardship, I think about it as helping those that are using the product on a journey throughout their usage of it. And I think that's so much more consistent than saying that I'm, you know, someone at the helm leading, leading this initiative. It's more about being a servant to those that are using the product. I fall from that standpoint like officially, you know, my documents or my corporation stuff, yeah I’m CEO slash principal, etc. etc. Right? 

[00:18:41] SY: You’re the boss. 

[00:18:41] AR: Yeah, I’m the boss. Yeah. 

[00:18:42] SY: Legally. 

[00:18:44] AR: Yeah, legally from, from a tax man standpoint, I'm the boss, right? When it comes to just how I want myself to be perceived by the community, it's stewardship. I'm a servant to you, and I want to cater to what's important to you. And I think with regards to RubyMotion we talked about, oh you know it's something that Ruby developers will definitely use, the other side of it though is that this mentality that I've taken with the product is something that's unique to RubyMotion that other platforms I don't think do the same way. Right? It's about me as a person as opposed to RubyMotion as an entity, and that expands across to everyone in the community, right? They might have products that they create or affiliates that they create with regards to RubyMotion, but those things come second to the person themselves. 

[00:19:30] SY: What does that mean in terms of the actual day-to-day? What are the to-do lists, you know, what are the to-do items, the tasks of a steward?

[00:19:37] AR: I'm the guy that will put in five to ten hours into a specific experience with the product that only saves the end user 10 minutes, but that's why I do that, right? That's the whole point. Another aspect for being steward I would say is that I'm kind of using the product myself, right? I'm in the weeds. So for me it's all about being ahead of everyone else that's using the product. Use the product myself, find those pain points—those things that make the journey with RubyMotion painful, make those go away even if it's just a five-second savings here and there. 

[00:20:13] SY: Yeah. 

[00:20:14] AR: Because that expands and scales out to anyone that uses it. And my day-to-day revolves around that mindset. 

[00:20:21] SY: So what are some features, some things that you've worked on to ease the pain of some of your users because from what you've described to me, I'm thinking “this sounds like a finished product like it sounds done,” you know? So what or what's left? Like what are some of the things you've maybe recently worked on? 

[00:20:39] AR: I like to call it Apple Christmas, but it's definitely not Apple Christmas from my perspective because that's when everything breaks, right? So all the new stuff comes out. So just the maintenance of that, right? Whenever a new version of iOS comes out, I make sure that all the betas are in place and all the places where they've moved your cheese are realigned, right, within, with regards to RubyMotion. A very unique example was so there's a concept called asset catalogs, and it was actually something that was introduced in previous versions of iOS. But if you've had [UNINTELLIGIBLE] for a long long time, it's rare that you would have actually used that. So here's the really frustrating thing with Apple. So they're very hush-hush about, you know, all their new devices and everything. So with regards to the asset catalogs and the configurations that existed there, there was a new resolution that they added to the asset catalog. And the asset catalog basically controls things like let's say the icons on your home screen. So there was a new icon resolution they added which was 87.5, specifically for the iPhone X. And of course they didn't tell anyone until the release of the device, right?

[00:21:44] SY: Of course. 

[00:21:45] AR: Of course they didn't. So everybody that was using Xcode or using the native stuff what would happen was they would try to build their apps on the D-Day or the day one release and upload to the app store. And they would get this like arbitrary error message about something about the asset catalogs, and it was just like this arcane error code. And of course, I was one of those people that tried the day one release and saw that happen. And I was like ok I know what happened. They added asset catalog. They released the iPhone X. They've added this new 83.5 icon thing. So obviously in RubyMotion, I’m going to make sure that that is a seamless “hey you need a new icon of type 83.5. You know, type this command, and it’ll resize your existing icon and get that for you,” right? So those are... 

[00:22:32] SY: Yeah. 

[00:22:32] AR: Those are the kind of like niceties that I dealt with and in panic mode as everyone else did, but because I took on that effort, you know, and I put it out there, it became simpler and more straightforward for everyone else. 

[00:22:46] SY: Yeah. 

[00:22:47] AR: And then with regards to stewardship and the growth, the other thing that I think is really, really important for anyone that's in the mobile space is the business of app development. So there's, there's this aspect of well I really care about, you know, what technology I'm using. And I think that's a, that's an important part of it, but there is a right way to build an app and then there's the wrong way, where 99.9% of the apps do it that way, right? So when it comes to the business development, what does it mean to build an app that is worthy of a feature by Apple? And I've been in that place, right? I've been featured by Apple, so I know what it takes. I know what makes a good app and what makes a bad app. And for those, for those more aesthetic… the aesthetics of your application, it goes beyond the language. Right? So with regards to stewardship or the contribution back, those things evolve over time, right? You go from what apps look like on iOS 6 and what apps look like today. They're very different. And there's these subtle, these subtle changes that exist that have to be communicated in some way. So that's another contribution that I try to make from a stewardship standpoint in RubyMotion. 

[00:23:52] SY: Yeah. Because you're absolutely right because if you're, if you're hoping to support, you know, indie app developers and people who have this little thing and they want to, you know, make it available on the App Store. It's not just about the technicalities. It's not just about the features and what it can do. It is about the business and what will make them successful. 

[00:24:10] AR: Yes

[00:24:11] SY: ...as indie developers. Yeah.

[00:24:12] AR: Yeah, so like what's your review conversion rate? What's your call to action for push notification? How do you present your in-app purchases? What's the right way to do ads or interstitials? It's a big deal if you can get like a 2.3% conversion rate, right? So you learn that secret sauce, and it evolves over time as new techniques are created and as the economies of the App Store change. You have to be in it, and you have to study it. And then when you see apps come in and someone builds an app with my product, I’ll say ok well, you know, let's review it. I’ll say, “no, no, no. You want to do X Y Z this way because that's going to increase your conversion rate by .267%” or some ridiculous amount, but it really counts. And those are things that are just not about the tech. 

[00:24:58] SY: And you actually wrote a book about this, right? 

[00:25:00] AR: I did, and the thing is I spent 300 pages—72000 words—writing a book about this. And I took it down like after, after about… yeah after about fifteen, sixteen months I was like... 

[00:25:13] SY: Was it all out of date?

[00:25:14] AR: Yeah. It's like it's relevant but it's almost not relevant anymore. So I'm working on a second edition now, but a part of me was, felt disgenuine to, you know, keep it up there. And the book was literally called “Surviving the App Store.” It's what it is, right? I wish I could say that the App Store is a place where you can make your millions, but unfortunately it isn't. You know, it's really hard. I didn't want to put people in a position where they tried the techniques in the book and find that they didn't work. And it just, it's just one of those things where it's a wasn't entirely relevant. So I took it upon myself. Ok, let me take it off. Let me do a second edition and work through it again. 

[00:25:50] SY: Interesting. Ok, so when you were first writing that book, you know, we talked about how there's two parts to making an app successful on the App Store. Number one is the app itself and number two is that the businessy—the other things that are not necessarily technical. On the technical side, what's one thing that you learned when you wrote that book that was surprising to you and that might be surprising to new developers? 

[00:26:14] AR: Yeah, I think from a technical side before I got into Ruby and RubyMotion, I was a C# developer, so primarily .NET, Visual Studio, C#. And I basically went on sabbatical and kind of put that behind me, and I pretty much quit my job. It was 2013. 

[00:26:30] SY: Wow. 

[00:26:31] AR: I was a corporate C# .NET developer, and I just got really burned out. And I quit my job, and I took a learning sabbatical just to try to pick up other things. And with regards to the tech, I went from C# to Objective-C first before jumping on RubyMotion. And I did Objective-C first, and it was disorienting, right? All the things that I found familiar about C# were not there in Objective-C, and I hated the language. I really, really did.

[00:27:00] SY: Oh no.

[00:27:01] AR: But only after self reflection did I realize that the language is actually fantastically powerful. From a technical standpoint, it was interesting to see that what can be accomplished when you just open up and embrace the capabilities of what you're working with instead of trying to fight them and trying to use it the way that you used something previously. So one of my biggest hurdles was I was using C#, and I wanted Objective-C to be like C# instead of Objective-C to be like Objective-C. And once I, once I mentally flipped that bit, it helped significantly. And with regards to RubyMotion as itself, a lot of the compiler is not even written in Objective-C. It’s written in low level portable C in C++. And from that perspective, again, the technology, you know, hit me upside the head and said, “You've got to, you've got to rethink things.” And just stepping back, I find that the simplicity of C while giving you a lot more boilerplate, it also removes a lot of surprises. The simplicity is intrinsic to how straightforward a piece of code looks like, and there’s tradeoffs. Each little piece, each little tech has its pros and cons, and you have to try to learn and appreciate those aspects of it as opposed to forcing your predisposed opinions on how a language should look. And I think that was very valuable. 

[00:28:24] SY: So wait what made you get into Ruby to even begin with? 

[00:28:27] AR: So the interesting thing was that it was actually at my corporate job. And we had to do build automation. So the gotya was when it came to .NET back in 2010—this was I guess seven years ago now or eight years ago now—there wasn't really a good way to do automation scripting. You basically had MSBuild and a bunch of XML, and that's how you do build automation.There was this emerging group of .NET developers that started using Ruby for build automation. It was basically Batch scripts on steroids is kind of how we saw it. And Batch is a horrible language, so being able to avoid Batch in itself was, was great. So a lot of my Ruby development wasn't even actually through Ruby on rails or any kind of web framework, it was just doing build automation for .NET. And I just started to really love the language, so that's kind of how I kind of sidejacked myself into Ruby from that perspective. That opened up I guess my perspective on what's out there and available from a platform language framework standpoint. And from there, you know, that's all she wrote, right? So I was like I need expand my horizons, and then I took the sabbatical and then here we are.

[00:29:37] SY: Yeah. Very cool. Very awesome. So in terms of the business-y side of things, what's one thing that might really surprise people when they build their first iOS app? 

[00:29:49] AR: I guess it shouldn't be a surprise, but it turns out to be a surprise, but you won't be a millionaire overnight. 

[00:29:55] SY: Yeah. 

[00:29:55] AR: People will not download your app. Sixty percent of the apps out there are never downloaded past their immediate family, right? It's pretty, it's pretty depressing. You have a billion apps out there, and half of them will never ever be downloaded. It's kind of weird that it's a surprise, but if you build it they won't come. I wish, I wish it was easy as saying like, you know, if you build a good product they'll come. But it’s just unfortunately not the case. So A Dark Room is the game that I built. It did hit the number one spot in the App Store. 

[00:30:25] SY: Wow. Congrats. 

[00:30:26] AR: It was one of the top 10 games of Apple's 2014 apps. 

[00:30:30] SY: That's awesome. 

[00:30:31] AR: But when I started off, the game was a web-based game, and it suddenly hit the number one—it hit like that front page of Hacker News, and that's how I came across this weird incremental web-based game. And hitting the top spot in Hacker News is a big deal, right? You get what's called a “hug of death” on your web servers when you start doing that. 

[00:30:51] SY: Best hug ever. 

[00:30:53] AR: Best hug ever, right? So, so you start… I think in one day we got almost 700,000 impressions just...

[00:31:00] SY: Wow. 

[00:31:01] AR: ...in under 10 hours. It was ridiculous. So that's what we're starting with. And then I partner with Michael to reimagine this game and kind of give my own spin to it and put it on mobile. So about six months later, I put it on mobile, and I—in my head, I'm doing this ridiculous math of “oh ok. So we have seven hundred people. We’re gonna totally tweet this out, and we're gonna totally get 700,000 downloads in the first day.” We released to the App Store. We got 36 downloads. 

[00:31:26] SY: Wow. 

[00:31:27] AR: And It's like well there you go there that is… 

[00:31:31] SY: Well, that was fun. 

[00:31:31] AR: And so I mean from that perspective, you would think that given the position I was in, we would have gotten a lot of downloads. Even with that, we got maybe like 60 to 70 downloads. So it's a rude awakening when you, when you get to the App Store and kind of see that. 

[00:31:46] SY: So why is that? Why is it so—because I feel like at some point it wasn't that hard right?

[00:31:51] AR: Yeah, and I would say definitely around the initial release of the App Store, one, it was a huge massive barrier to entry, right? Objective-C around that time period… you basically created—had some form of Stockholm syndrome after that because it was incredibly painful to build anything. But yeah, these days I think Apple gets almost 700 app submissions a day. And when you get, when you get to that point, it's just so much noise. The signal, the curation process is incredibly difficult and in this new age. Yeah, there was a point where, you know, you could release an app and have some sustainable income out, off of that. But in these days, it's much harder. Just a tip, I guess, for those that are really interested in app development, go for hyper-niche applications. Don't build the generic video game app that is a war simulation. Build the video game that talks about some off-the-cuff ridiculous war that happened in 1822 because there are 650 million iOS devices out there. I guarantee you that even half of a half of a percent that is interested in that little war simulation, you will find those people. And they will download your app and they will love you for it. 

[00:31:51] SY: And they will love it. Yep. 

[00:31:51] AR: That's, you know, general piece of tidbit advice, but it's just the nature of what you're competing with, you know. When you have AAA shops that are investing many, many hundreds of millions of dollars in marketing and development teams, it's hard to get that piece of the pie. But there is so much pie to go around. And if you take that angle and if you attack it from that perspective, you can you can find some success there. 

[00:33:34] SY: Ok so knowing all that knowing how competitive it is, if you have the choice are you better off just making a web app than you are an iOS app?

[00:33:45] AR: You are better off being a contractor that can do iOS app development. So learn all the skills of how to build an iOS application or you know, wrap a website and build cross platform responsive web site. And then contract out to people, to companies and say “I know how to build an app. I will build whatever app or offering you want.” And then, you know, make sure that hits the store. Just to put it in perspective, A Dark Room hit the number one spot on the App Store on April 13, 2014. For that time period and that year, we had 800,000 downloads of the application. 

[00:34:19] SY: Wow. 

[00:34:19] AR: We're bringing in this kind of revenue, and after taxes and partnership splits and the time I took off and the amount of time, so it was like a 14-month period to acquire that much revenue… when all the math was said and done, I basically made the same as if I was on a contract gig at $110 an hour. 

[00:34:41] SY: Wow. 

[00:34:41] AR: So for an iOS developer to land a contract gig at $110 an hour and maintain that contract gig for 14 months is many, many times higher than the lottery ticket we won, right? So from my perspective, when it comes to just income potential, doing contract work is, you know, obviously the right choice. Now when it comes to passive income, that becomes a little bit gray, right? Because it's not something that you'll make upfront, but once you have 10 apps in the App Store, you could be making a good amount of passive income like $1,000 a month off of 10 apps. So 10 apps each making a hundred dollars a month monthly… 

[00:35:19] SY: Yeah. 

[00:35:19] AR: ...is a thousand dollars, and that's fantastic passive income. Twelve thousand dollars is great passive income per year, and those assets just grow over time… being that you'll create more assets ,and you'll have interstitials that send people to your other apps, right? And that's a, that's a very interesting way to have sustainable income from that perspective. So I guess to answer your question, it depends. If you want upfront income potential, definitely do contract work. If you want long term passive income, apps are a possibility. 

[00:35:53] SY: So you've clearly done a lot of different stuff. You’re very technical. You know a lot of things, and I want to get into your background a little bit. So I saw that you have a computer science degree. 

[00:36:04] AR: I do. 

[00:36:04] SY: And one of the questions I love asking guests who have computer science degrees is how helpful has that degree been in the things that you've built and the things that you've done?

[00:36:14] AR: When I first started my career, when it came to just general business app development—and line of business applications are your client-facing applications, you know, you can think of it as your eBay's or your Amazon.com’s. Things that front and customers would use like Facebook, right?—when it came to that kind of work, my degree didn't really provide much outside of understanding, you know, control flow and like a programming language. The interesting thing though was the lower down the stack I went, the more important the classical, for lack of a better term, the classical instruction became more important. So the closer I got to the compiler, the more that I wished that I remembered all the things that I remembered in college. 

[00:36:59] SY: Yeah. So you did forget a lot of it like the rest of us.

[00:37:01] AR: Yeah, I mean yeah. So I graduated in 2006, and then I acquired RubyMotion in 2017. And I was kicking myself in the butt around 2017 because I was like great. I wish I remembered all the stuff about compiler theory that they said we would need back in college. It really spans the spectrum. And really what it comes down to is what's considered vocational versus what's your classical fundamental aspects to it. And the world we're in right now it seems like a lot of the stuff that we're learning is vocational. 

[00:37:32] SY: Yeah. 

[00:37:32] AR: And there's nothing wrong with that. It's just the nature of what I've observed so far. All that being said, college did teach me to have the discipline to actually work through these kinds of things, right? That was one of those rights of passage that helped me one, realize that I really did enjoy the stuff and that I was generally good at it and then, and two to follow through and continue that kind of learning and that lifestyle of learning as my life went on. If you don't realize that you're going to be learning for the rest of your life or that’s something you don't want to do, then you want to reconsider it.

[00:38:07] SY: I also wonder if it gave you confidence that you can figure things out that you didn't actually learn. Did you feel like having that degree gave you a little bit more confidence, a little more faith in your technical abilities than if you didn't have that degree?

[00:38:24] AR: Yeah I think… this is the analogy that I generally give. So you have someone that let's say wants to do digital art in Photoshop, right? And you have all these capabilities available to you, all these brush styles, pressure-sensitive Wacom tablets and everything. And what I remember a professor telling me—and I went to DigiPen, which is a videogame institute—and I just went for a hackathon up there back in 2009. One of the instructors up there was talking about this idea of like Photoshop and this digital media, and the professor said, “before I even let them touch a computer, I make sure that they can draw a near perfect circle on like a piece of printer paper with a pencil.” It was interesting to hear that, and the idea there is basically this premise of understanding and having proficiency over the fundamentals and proficiency on something that is such a core building block on top of everything else. And I think that's what the degree gave me was all of my degree was in Java 1.2 and C++. You know, if you think like about just Java one dot anything that's less than maybe 1.6, you don't really see that in the industry. You're not going to see any job postings for learned Java, but the premise is that I learned how to draw a circle on a piece of paper before I was thrown into essentially Photoshop in the real world. 

[00:39:47] SY: So based on that example of being able to draw the circle on the piece of paper before, you know, really digging into photoshop tools, do you feel like getting a CS degree is important or should at least be seriously considered if you want to be a developer?

[00:40:05] AR: I think it's unfortunate, right, that computer science and CS degrees are almost like a, you know, we won't consider employment unless you have this degree. And that's incredibly unfortunate. And I, and I don't like that, and I feel that it's transitioning away from that and more being portfolio-centric. If you want to kind of get the essence of what the CS degree gives you, I would learn C. Just straight C, not C++. I would learn portable C, and I would learn Chez Scheme. The premise for these two languages though is that C teaches you how to use the power of a computer without the constraints of a language. Chez Scheme teaches you the powers of a language without the constraints of a computer. And there are these like two polar ends of a spectrum and the languages that you'll use in your day-to-day fall somewhere in that, in that spectrum. The premise is that you see these purities in these languages, it helps your brain conceptualize everything in between. Understand the spectrum. Understand the fundamentals. Understand these building blocks, and then the vocational aspects will fall in between. The last “three things that I has” are all about execution. Throughout your career, I would say your typing speed is actually really important. You can kind of think of it... I mean it's weird to say. It's so weird to say, but it's one of those things that, that... So experience like architectural design, design patterns and all the things, you can't hack that, right? You have to get the experience. You have to get the intuition. But when it comes to typing speed, you can go home every night and type, right? Then to expand on that proficiency in your editor, whatever editor you decide to use, being able to seamlessly go from one file to another is just incredibly important just knowing how to use your tools. And again, it's something that can be a practiced outside of these more harder problems. And then finally the ability to extend your editor. 

[00:42:02] SY: Ah, that's such great advice. Wow. Very tangible. Thank you for that. So now let's move on to some fill-in-the-blanks. Are you ready?

[00:42:09] AR: Absolutely. 

[00:42:10] SY: Number one: worst advice I've ever received is... 

[00:42:13] AR: My worst advice ever received is invest in real estate. 

[00:42:18] SY: Yeah. Nice and tangible. 

[00:42:19] AR: Yeah. So the reason for that was necessarily bad advice for me was not necessarily that investing in real estate is bad, it's just I wasn't interested in it. And, you know, I suffered because of that, right? So, so it’s... generally speaking, it would be, you know, just because someone—it's good advice for someone else, it’s not necessarily good advice for you. With regards to real estate, that was some very expensive mistakes for me. 

[00:42:42] SY: Number two: my first coding project was about... 

[00:42:45] AR: My first coding project was actually a video game. I was in eighth grade. I got a turbo C++ compiler or something, and then I opened up this book, and you see like you do the cout << "Hello World!". And I just tried to make it almost like a conversational robot kind of game that would try to talk to you, and then the robot eventually go crazy and glitching on. You had to fix it and ask it, ask the right questions to get it back online. It was just a string of if else statements and ridiculous stuff. 

[00:43:17] SY: Number three: one thing I wish I knew when I first started to code is...

[00:43:22] AR: Learn as many languages as possible. 

[00:43:24] SY: Oh. Interesting. 

[00:43:24] AR: The unfortunate advice that I got—and it wasn't as bad as the invest in real estate—was to go all-in on a specific language and get certifications for that language. It helped me, it helped me get my foot into the door to some like specific shops. And I think the short-term benefits were there, but the problem was that my blinders were on, and I didn't have, I didn't have perspective on what I was using. And I wish if someone told me to, instead of doing the certification, learn different languages, I think I'd be even better off now.

[00:43:56] SY: Interesting. Ok. So is there a point where—because you do, you do have to focus, right? Like when you start a language, you don’t want to bounce around so much that you don't know anything about anything. So what is your recommendation on how to approach that? Is there a point, maybe it's a timeline, a milestone that you hit, where you go, “ok, now I'm ready for my next language?”

[00:44:17] AR: Unfortunately, I think the answer is you get a feel for it. You got a gut feel for it on when you're ready to move on. But for me, I think proficiency... you just have to be dangerous enough, right? So you don't have to know the language’s ins and outs for it, but enough to where you can see a piece of code, open it up, build it and potentially work in it, right? And that might be just the ability. Well how do I build it? What IDE should I use? How do I DEBUG this thing, right? So it doesn't… you just have to be dangerous enough, and if I had a put an hour's to it, I would say if he can get in 120 hours in a language, that is a, that is a pretty good, pretty good metric. So a language a year, let's say that. 

[00:45:02] SY: Well thank you so much Amir for spending this time with us and telling us all about RubyMotion and interpreters and compilers. I feel like we went through so much content, so much really good stuff. You wanna say goodbye? 

[00:45:11] AR: Yeah. Actually, I do want to say one thing is that just, you know, reach out to me. E-mail me if you're interested in learning RubyMotion. I will, I will put you in a position where you—with no cost—you can get up and running. And the only thing I ask is that you be open to it and give it a shot, right? So let me, let me help your journey. My e-mail… you know, you can reach out to me on Twitter. I know we'll put in the notes, but (Music) @amirrajan and then a-r@amirrajan.net. I’m here for you. 

[00:45:41] SY: Thank you so much. I really appreciate that. We really appreciate that. Well thank you so much for joining us. 

[00:45:46] AR: Take care, everyone. 

[00:45:47] SY: And that's the end of the episode. Let me know what you think. Tweet me @CodeNewbies or sent me an email hello@codenewbie.org. If you're in D.C. or Philly, check out our local meetup groups. We've got community coding sessions and awesome events each month. So if you're looking for real-life human coding interaction, look us up on meetup.com. For more info on the podcast, check out www.codenewbie.org/podcast. And join us for our weekly Twitter chats—we've got our Wednesday chats at 9PM EST and our weekly coding check-in every Sunday at 2 PM EST. Thanks for listening. See you next week.