 I, you guys want to focus more on continuous deployment aspect or more on like the background about why continuous deployment. So the talk is basically about architecture of iOS application, so you can do continuous deployment. And that's basically what I have, but if you guys want to go more into step back and look at why even continuous deployment then we can do that. I'm assuming most people would have heard enough about continuous deployment by now, so we can skip that portion and only focus on the approach we took to continuous deployment. I'm going to do a quick demo as well and then we'll get into details of it. So let's just wait for three more minutes and we'll get started at 2.30. This talk is about strategies to achieve continuous deployment, especially for iOS development because of some of the challenges we're going to talk about. This is kind of quickly a very high level overview of basically what I had in mind for five minutes section. We can cut short some of these things and focus more on others as we proceed, so let's see how it goes. I'd actually like to start with a quick demo of the app so you kind of get an idea of what we are talking about and then get into details of this. This is actually a hybrid app, if you will. So I have a couple of apps here to demo. We'll start with Abacus Rush. Basically it's for kids 8, 4 to 6 for them to learn mental mathematics and be using Abacus as a way for kids to learn mental mathematics. This app basically helps kids learn how to represent numbers on the Abacus from 0 to 9 and then moving to two rods where they can represent two digit numbers and then three digit numbers and so forth. We originally started about two and a half now almost three years ago where we were trying to basically, we started originally with in-person classes helping kids learn mental mathematics. Gradually we said we'll automate some of these things, we will use e-learning for doing that and we created some video, some animation, we try to put this together so kids can actually learn through that and we found that was not very effective. So we did little experiments to figure out what will actually stick and after about seven rewrites we have kind of come to this stage and we're just about to do another rewrite which is cool because you can throw away things very rapidly. All this while I think we've written very little code mostly to prove out the concept and to get some buy-in from someone who's going to back us. So let me quickly show you what this game is so as you can see it says in 60 seconds you have to try and represent as many numbers as possible. I've been tweaking with this, there are some obvious bugs in this right now but you'll get the idea still so the right there is the first bug, you have to scale the app the first time and then only it works. The reason I'm highlighting these things is I want to get to another point I'm going to talk a little later that this is buggy, this has lots of issues but the point was not to focus on the quality, the point was to prove out the concept and that's what our point is. It almost seems like I fixed the thing but so it's a little bit of inline instruction helping kids understand how to represent the numbers to start with and here we want kids to use multi-text gesture so we're trying to do that and the game basically starts now and you basically have to represent numbers on this if you do strong numbers it basically complains after three seconds and so forth. The idea is to represent in the 50 seconds as many numbers as possible and get into the red zone, right now it's in green, sorry to get in the green zone right now it's in the red zone. This is one little game that we built. There is another one which is actually our main app which is SpeedMath and all of these are basically, so if you look at this what do you think is this what kind of an app is it? Is it a native app? Is it a HTML5 app? Is it a hybrid app? So folks at Amazon look at this and they said we bet 10,000 rupees it's a native app and I said no it's not a native app, right? I did get 10,000 rupees here. That's the point, that's the earning. So this is actually all HTML5, I can show you on a browser and you will see the exact same thing. This is all HTML5. So here we are teaching the kids as soon as they get in how to assemble an abacus and learn what the abacus is all about. So here you're basically assembling one beat at a time and you're basically showing okay, you just achieved one now you're moving to two. So this is what we call as basically getting them to get in do some activity and learn through that activity. So I can basically go on a bunch of stuff in here I can go into the wall if it opens up, right? I can go feed our character Gugu some interesting food but Gugu is not hungry right now so he's going to eat. Let's go back, let's get into the first mission where we want to calibrate the hyperdrive. I mean you get the idea that this is fairly interactive there is sound, there is animation, there is a bunch of stuff going on there's calculations that are going on in the background. And yes, and that is important, right? There is music playing simultaneously which is almost continuously running in a loop and you try to do some of these things in HTML5 and it becomes fairly troublesome. So I want to get into more details about the way we architecture this to be able to do this. So I'm going to not show off the app too much because it's not the point. So I'm going to switch back to any questions so far on the app itself that I showed the nature of the app. So what I was trying to get at is this is a fairly interactive app it has sound, it has animation, it has a whole bunch of syncing up with the server that goes on in the background. So as you do this thing, you're scoring things and we record whether you've done something right or something wrong we give you feedback, we record all of these things because then you want to calibrate how the student is progressing and things like that. So there is a bunch of stuff that I'm going to show in a while that we have done in terms of architecting this. This is a hybrid application, it is 95% HTML5 and a very thin layer what we call a shell which is required for a couple of reasons I'm going to talk about. But first let's get into a commercial break before we get into any trucks of the stuff. So my name is Nareesh Jain, I live in Mumbai. I was one of the partners at Industrial Logic where we built e-learning for programmers and this is really where I've got my initial idea about using gamification to help people learn stuff and we did a lot of interesting stuff with Industrial Logic where we would record the sections of how a programmer is working and then give them feedback whether they're doing test-driven development or design patterns or things like that accurately, not accurately but we kind of help them visualize things and stuff like that. So after having built this system and looking at maybe about 6,000 people who were using this system one of the things I realized is awesome to be able to influence programmers but I wanted to do something much more fundamental which is kind of really helping kids learn because that has a huge impact on helping programmers get better. So I started a company, I quit Industrial Logic and I started a company called Adventure Lab me and two other people started the company and our idea was to basically revolutionize alternative education the way kids learn outside schools and as I was saying earlier we went through two and a half years of several rewrites before we could figure out what problem we are actually trying to solve and what will be our strategy of solving the problem. So that's a different talk in itself to talk about the whole evolution that we went through but right now our current status is that we have a bunch of apps that are out in the app store. These are all really bad apps. These are stuff that we have just hacked without really caring about code quality or any of that stuff which is another talk at a major point about so much emphasis on code quality while what you're really trying to do is prove a concept if it works or not. So just to highlight some facts we have number of world which is there on Google Play it was number four on Google Play for a while in few countries. We had about 1,20,000 downloads in about four days so it did fairly well for it being something that we just hacked over a weekend and because it is HTML5 we started first with iOS and then ported it to Android to prove to one of our potential partners that we were talking to that this can actually work across all different platforms. I've done a bunch of other stuff providing search for content inside Facebook and some bunch of random other stuff. As you might have heard I started the agile software community of India which is the body which is the agile conferences back in 2004 and I've been involved with a bunch of other conferences that I started, Simple Design and Coachcam. I was part of the CodeCraft team which originally created CodeCraft. I've been building Bettercons which I think I'm going to rename to Confinement which is the stuff that you guys use for the proposal and for registering for online to come to the conference and stuff like that. It has a lot of bugs but it doesn't matter. You guys are captive audience. You can't attend the conference in any other way. So it's cool. These are a bunch of companies that have worked either as an employee or as a consultant just to give you a background that I come from a very heavy server-side background having built a lot of server infrastructure and kind of transitioning into doing something like a game on an iPad was a complete, forget everything that you've learned in the past and start from scratch kind of an experience. So let's come to Continuous Deployment. This is an extremely utterly simplistic view of what Continuous Deployment is but it kind of gives the idea in terms of what is the power of Continuous Deployment. The idea is that as soon as the developer checks in you want to go through a battery of tests and then if it satisfies certain criteria then you want to push it through your user. Now, for something with the server-side this is pretty easy because I have a cluster of servers and I can decide how I want to decide my rollout strategy, put it on one cluster, roll it out to few other clusters and then eventually put it to all my users. But if I have something like an iPad game which is actually distributed and it's more like a standalone thing that's there on people's iPad or devices, doing Continuous Delivery is a little bit more challenging. So let's quickly touch upon CD. Continuous Deployment itself is pretty easy for companies doing content delivery over web. And the reason I'm going to talk a little bit about this is we kind of put ourselves in that mindset and we can relook at what we are doing in terms of content delivery over the web and then maybe we would be able to figure out a solution to do Continuous Deployment. So I was helping this organization called Preset. Preset is based out of Calcutta. They have helped about 280 women get out of prostitution and they actually make bags and t-shirts and things like that to really help them learn how to run a business. So it's a very beautiful organization. I helped them with their online presence. And one of the things that we did with them was we basically, they wanted an online presence. There's a whole bunch of static files, content management system, stuff like that, people updating content and then bunch of people viewing this. A typical CMS, you make a change and you basically push the button, you save it and it's instantaneously available. That is Continuous Deployment. It's as close as you can get to real time. I make a change, I save it, it's available instantaneously. Well, if you try to do that, it's okay if you have changes which are atomic changes. But if you have to make changes like I want to change the styling or the header across a bunch of things or I want to change a bunch of things which is distributed in few different places, if I do it in bits and pieces it will probably not help. So we basically came up with a small strategy over there where we had like an active and passive thing on which it's like dev.presetglobal.com is where we would make updates and we would get it to a stage and then basically you'll run a small shell script, an R sync which would basically sync this with the other thing. So it will sync all the static files and it will also sync the databases between these two servers and people will directly be viewing the latest and greatest stuff. So this is slightly one step, you know, in between what we had earlier to this, but this to me is, again, a simple way of looking at continuous deployment, right? The whole online registration system and the submission system was basically built this way. I would write a feature, I would make a small change, I would run a shell script, go on to the next, it's put to the server. So it was all continuous deployment in this case. Yeah. How's an R sync atomic? It is not atomic in the sense that basically if you pipe them, if the R sync fails then it rolls back because of the piping, right? So, but you could at a millisecond point of view, you could actually see a file which is, you know, not atomic. From a rollback it was atomic, right? Because it's piped together and I could roll it back if something went wrong. And frankly it's been like eight years and we've never had any issues, right? So you don't need to put these fancy infrastructure when you can just do an R sync and a MySQL dump and pipe those things together, right? That's continuous deployment for me. But I don't think it's too good. I think it's just the thing you would do anyways, right? I mean, I don't think it's too good. And I did the same thing for... No, the server is never down. The whole point of continuous deployment is zero downtime. You don't want to have any downtime. We did the same thing on the submission system and the online registration system. The reason I bring online registration is because we actually had real money going through this, right? People paying through credit cards and stuff like that. Even in that kind of an environment it was basically being done continuously deployed. Obviously, bugs people would report and in five minutes I would try and fix those and push it and people would be surprised. This is like blazing fast. You just fix the bug I reported and it's here. My reply to that email is it's fixed now, right? So that's the power of continuous deployment and you can do continuous deployment for various different environments. I want to quickly touch upon another environment which was not as simple as just a website where we're doing a bunch of things, but the thing I talked earlier about industrial logic where we were doing e-learning and e-learning is very interesting because it's not just online content delivery. We also had plugins for Eclipse and Visual Studio and things like that where basically we want to make sure we are recording, thinking things, showing you a score and all of that. So even there we basically were able to do continuous deployment by using the active server kind of an analogy and having basically a reverse proxy to manage that. I don't want to go into details of this. I just wanted to set the context that these are things that I've been doing in the past and this is all cool. This all made sense, but when you actually hit something like an iOS app, you have different kinds of challenges which are not quite covered yet in this kind of an environment. So if you look at any typical iOS app which wants to do continuous delivery, right? The first biggest challenge that you're going to hit is that on an average, it takes anywhere between three days to a week for Apple to actually approve any updates that you send to them. Even if it's a stupid, I fixed a spelling mistake and I need to be updated. It takes anywhere between three days to five, three to five working days for them to basically quickly update. There is a pretty complicated and cumbersome signing and packaging process that you have to go through. As time has gone by in the last two and a half years, people have simplified a test flight, a whole bunch of other things have come in. So they have simplified this step, but it's still something that you as a developer have to worry about making sure your right certificates are in the right place. If you have different certificates, in our case we have the enterprise certificate, we have the developer certificate. You have to worry about all these certificates. You have to be finding it correctly, pushing the right version. If you're doing an ad hoc build, you have to make sure that the UIDs are there in place. So it's a fairly cumbersome and complicated process. Even if you want to just do a simple push of few changes that you have made, you still have to go through this process. And the last thing is you actually need real iOS devices to be testing some of these things. It's not sufficient to look at it only in the simulator. So it is, those were three basic challenges that we faced and we said, you know, this is not going to help us, especially because we were a very young startup and we were trying to figure out what is the problem we are trying to solve. So we really needed the ability to change things very rapidly, push it out very rapidly. So what did we do to solve this problem? Anyone solve this problem? How have they done continuous deployment for iOS development? I think you said you were one person and then on test devices, but that's up to CI level in some sense, right? But you know, when you actually want it to be available to your end users, let's say as simple as you found a spelling mistake, right, in one of your stuff and you want that to be fixed, right? How do you get it instantaneously to your users? In my experience, it takes anywhere between three to five days before it would get to your customer, right? That seems to be a big issue in my opinion. Do you have any experience, Lena? Up to test, like, okay, so cool. Anyone else here, any experience before I jump into what we did? All right. So here is how we basically solved the problem and to be honest, this is more of an accident than, you know, us being smart about it. The reason we chose to go with HTML5 was purely a business decision. We were a startup. We didn't know how this is going to shape up, but very early in our planning, we realized that we are not big guys in the education space so no one gives a crap if narration builds an app and puts it out there. So we actually need someone to partner with and when we talk to a bunch of big shots, their take was that if it's white labeled, we will consider it, but if it's in the App Store and you're already putting it out there, then I don't think we will be interested in something like this. At least two and a half years ago or three years ago, App Store didn't have a bunch of things that they have now in terms of the B2B solution and things like that. Back then, it was pretty much, you know, you put something in the App Store and the only way people can access it. So we went down HTML5 mostly because we wanted to white-label it and we analyzed what kind of changes typically would happen to our app, right? And there were three levels of changes. One was the content change and the logic change in terms of, you know, what is the content? What are the lessons? What are the problems that we give to the kids and what is the logic for calculation and stuff like that? The second was more of look and feel and things like that, you know, characters and animation and stuff like that. That was the second level of change. The third level was really the infrastructural change, right? I mean, those are three levels of changes that we looked at. What I mean by infrastructure changes is let's say a new version of iOS is released, right? And some backward compatibility needs to be addressed or some new enhancement needs to be addressed which is more at the native level. So we looked at this, we split it into three things and we said if we were to model our architecture to take advantage of these three levels, we basically came up with something like this. This is fairly intense. I'll try and take a few minutes to explain what I mean by this. So earlier, as I mentioned, ours is a hybrid app which basically means that we use a web view. We basically launch a web view and then we have a bridge sitting on top of the web view. The bridge, I'll show you the code. It's like five lines of code. Actually less than that. And the bridge is basically what enables the JavaScript to talk to the native app. You would have seen in the demo that we have fairly intense animation going on. There is sound that is playing. If anyone's built HTML5 apps, one of the beautiful things that Apple has done, one of the beautiful things that Apple has done is they block sound or media or any of that stuff to be played offline. One of the most important criteria for us was that things should be available offline. Because the kid is not going to be connected to the internet all the time when they're going to be playing on this. So when you try to play a sound, even though it's cached, it gets blocked by Apple or Safari and it doesn't let you play the offline sound. So sound was one of the things that is the audio. Animation, even if you use sprites and stuff like that, there are limitations in terms of what is allowed, the amount of memory that you can allocate to an image. So your images have to be really small and sprites. If you're doing something as complicated and interactive as that, the size goes pretty big. And that was another issue. Storage, especially if the kid is playing the game and suddenly the game crashes, which happens a lot in our case, we want to store all the data before the app crashes. And if it's just HTML5 before it stores it to local storage, the data is wiped out. So there were a bunch of things that we wanted to do which we wanted to leverage what is there in iOS, the native iOS stuff. So what we had was a little native portion and then a bunch of stuff which is JavaScript and that being launched in a web view via a shell. So the shell is what is basically the glue between the native side of things and the app side of things. Most of this is basically reusable stuff. We've been contemplating of just open-sourcing this whole stuff because none of this has anything which is specific to our application. This is basically how to play audio, how to play animation, how to play, how to have events, how to handle events which are like push notifications and stuff like that. And storage, which I talked about, we also had some HTTP OARP stuff to make sure that, security issues are not there. Some metrics and some updates which is new versions of things, new version of shell is there. So you need to update that and get a notification to push to the next version. So to summarize, I want to pause here. We have three levels of changes that I talked about in the previous slide. The content changes and logic changes. Look and feel changes and infrastructure changes. So if you think about content changes and logic changes, that would be all here. I could change CSS, I could change images, I could change my JavaScript and the content, the logic, all of that stuff would basically be here. This would obviously interact with backend as a service. So we had all our service as a backend. So our next lesson content is basically a JSON that gets pushed to you. So you're going to do some scoring and things like that, that basically gets pushed to the backend via the HTTP OARP. So all the scoring, all of this stuff was JavaScript and we could change the logic and push a new version of the JavaScript through a typical HTTP request and you would have a new logic for scoring. So the content and the logic was all basically JSON and JavaScript and then the look and feel, which was the second thing, was basically CSS and images and things like that, which also could be pushed in a real time whenever a user makes a request. Or we could actually actively push whenever there's an update and this thing would handle it and replace the cache that it had locally with the content that we just pushed. The third thing, which is infrastructure changes basically here at this point, the shell thing. We rarely had any infrastructure changes, but we wanted to make sure that in future when we need to be able to upgrade to new versions or we want to change the audio part of it or the animation part of it, there should be a mechanism to push a new version of that. So whenever we had to do an update to the shell, that's the only time when we had to go to Apple and say, hey, we have a new version of the app, please push it. If we had content changes, if we had things like, you know, changing the logic of stuff, that's all. We never need to go to Apple, we make a change, we check in, go to test, slide, get tested, and then get pushed out to our server, and we are good to go. Any questions here before I jump on to the next topic? It is, as you saw, it was a complete standalone thing because of the shell. The shell is basically a thin wrapper. All it does is it basically launches the web view. It basically launches the browser view and then the whole app gets loaded inside the browser. But as an end user, I don't think anyone can even differentiate. Even tech people can never differentiate the difference between it being the thing. There's obviously some differences where a real hardcore geek can figure out that it's a web-based thing, not a thing. But, you know, most end users would not have a clue that it's actually a web-based thing. Yeah, go ahead. PhoneGap is a monster. And I suffer with not-invented-hear syndrome. So I literally reinvented PhoneGap in some sense. But this is just, in my opinion, it is 100th the size of PhoneGap. I think if I take the overall code base, it's not more than 300 lines of code. So I wouldn't want to take something like PhoneGap and go through all that headache when I could just do this. And also in our case, we didn't start one day building this whole infrastructure saying, okay, let's do this whole infrastructure before we do. We actually started with only HTML5. And gradually, when we found issues, when we found either performance issues or offline issues, that's when we started porting a little by little into this. And at some point, we realized, hey, we've actually built a framework that is reusable. So, and to test that, we actually saw two different apps that I showed you. And both those apps essentially used this infrastructure. PhoneGap is very heavy, in my opinion. And I don't trust PhoneGap. This is 100th the size of PhoneGap. And for me, this is all I need. So why would I want to basically make a monster out of my application putting PhoneGap and having to deal with that? PhoneGap has another serious issue, by the way. PhoneGap does not do... So PhoneGap does all the interceptions at one time and then basically makes the call to your HTML5 code. So it's actually intercepting everything that's happening and then delegating. So you will never get this kind of performance if you use PhoneGap, right? While in our case, it's actually in the browser directly running, nothing intercepting that. Only there is a little hack that we did when we wanted to be intercepted. There's a specific way we do that by using an iFrame, which I'll get to in a minute. But the performance that we measured, there's a significant difference. We have it on Android. What we need to do is we basically need to replace this. Right? So it's about 300 lines of code that you need to write in Java from what we had for iOS. And that's the change you would need. And which we've already done. So we have now something available both for Android for iOS and also... Yeah, I mean for both of those platforms. Different versions of iOS... Different versions of iOS, this does not matter because we support four different versions of iOS, but even though iOS only supports two versions, Apple itself supports two versions, right? But this thing works on four different versions. We've tested that. So Apple is not an issue. Android is a huge fuck-up, right? So we don't even want to go there. The only reason we put it into Android was to show to a couple of companies we were talking to that there is actually a huge user base of people who want to use this, right? Even when we ported this to Android, we only ported it once. But the problem with Android is that the hardware capability for doing something like this is not good enough. It depends. There's a huge range of things. It's very fragmented. They're trying to address that issue. Hopefully they will. But right now, it's very fragmented. And because of the fragmentation, our app crashes in about 20 to 30% of the iOS Android version. So this is a huge issue. Huge issue in terms of 20 to 30% crashing. It's obviously going to be chrome, right? In Android, right? So any other questions before we move on? Do you understand the rationale behind why we went down this route and how this thing works, right? So basically all of these components were fairly well-component in JavaScript. I could replace this whole thing or maybe parts of this. So what's marked here is basically reusable stuff across different games that we were building. This stuff is very specific to the game that we were building. And that needs to be slapped out, put a different thing. And then we could leverage all of this infrastructure that we had built. So we ended up building like a platform where other games can actually run. But that was not what we were trying to do. What we were trying to do was basically make our game work. And this is basically the whole thought process that we went through over a period of two and a half years. So quickly to recap, that's pretty much what I have. I can go into more detail if people want. But we basically split our changes in different layers looking at what our changes would be. We maximized the usage of HTML5 text stack, which has allowed us to basically do continuous deployment very easily. And that's something that I had a background in doing fast and that's why I was giving all that background, is handling server-side HTML5 stuff is something we've done for a long time. So basically took iOS apps, made it hybrid, and then got the advantage of all the experience I had building web-based infrastructure. And then we obviously automated the heck out of it because of all the packaging and deploying and all of those issues and different things. So right now I have a script which basically I run. It's a shell script. And I run the shell script. It basically deploys it. It creates packages for iOS and for Android. And then we can test it, which is to test flight. And when it's okay, we just basically run another script which is promoted. And then that script basically pushes it to Android and App Store. So that's pretty much it. I'm done before time. One of the interesting things I find is all the big guys seem to be moving away from HTML5 and going the native route complaining about performance. And I'm not sure what kind of performance problems they are having. But a lot of big guys seem to have declared that HTML5 is not the right thing from the performance point of view. And they're moving to, you know, native apps. By no means HTML5 apps can compete with native apps. But the question to be asked is how much performance do you really need, right? For a game like this, HTML5 is good enough. And I'm assuming 90% of apps out there won't have more intense stuff than this, right? So in my opinion, you would take any of the phone gap or any of the other infrastructure and you should be able to build a similar architecture on that and leverage the whole continuous deployment approach. So this is not something unique that only you could do on this. I think it's a more generic thing that can be achieved on other platforms as well. Which is, I still am surprised why companies think this is the HTML5 is not performance. I think there are some little tweaks that you need to understand, little hacks in code that you need to understand. But once you do that, I think it performs fairly well in my opinion. I mean, I've built native apps as well to get an experience of what it would mean to build native apps. Native apps, if you were to build native apps, they are faster, any day, right? If you were trying to build a HTML5 app or if you're trying to build a native app, I think HTML5 apps will take you slightly longer than building native apps. So that might be one of the reasons why companies go down native apps to start with. The second thing is that if you have very high connectivity and things like that, constant updates and stuff like that, then that might be another reason where you might see a little lag in this thing. But there again, we found a hack using iframes and stuff like that where you can avoid the lag, you can basically delegate the lag to the shell and let it handle, basically spawn an iframe, make a request and forget about it, right? Put an iframe, make a request, remove the iframe immediately. And the request would have gone to the server side and then when it comes back, the shell handles it and calls the JavaScript back on you. So that was the hack that we did where you can actually do a lot of background requests to the server without actually impacting any of the JavaScript threads or stuff like that. If you're trying to do Ajax calls from within JavaScript, then you might basically still see a lag in performance. Just spawn a JavaScript, just spawn an iframe, let it and just remove it off and let it handle that. So that's a hack we found which helped us do a scale in terms of performance to a large extent. So I'm not sure, I'm assuming the companies might be aware, but there might be other reasons beyond my little experience that they've decided not to go down HTML5 and use the native approach. Any other questions? All right, then we're done. Thank you guys.