 I know, I will be shy, you can come. Okay, so yeah, as Lucy said, thanks for coming tonight. That's my first talk, so there's going to be a lot of information, but I'm going to try to keep it as simple as I can. And so tonight I'm going to talk about scalability on the iOS app. So we often talk about scalability on the front end, on the backend side, like APIs and things like that. But I will talk much less about the mobile development, the code behind, and how we can make sure that it goes as well with the team. What about if you team the whole tomorrow, are you sure you can achieve it as good as today? So that's why we're going to cover tonight. But first, let me introduce myself. So my name is Ben, I'm one of the iOS developers here at Zara. If you're content by my accent, I'm French, and when I'm not writing code here, I'm also blogging about iOS development in general. Back to our subjects, so first we're going to see what is scalability and why it's really important to anticipate it. Then I'm going to share some tools and tips about how to manage your code days as well as your project, and finally, how automation can assist you in that job. Okay, let's start with what? So why is scalability? Scalability is the property of a system to handle a growing amount of work by adding resources to that system. So that's the definition by Wikipedia, that's all mine. What does it mean? It's like, if you've got more users tomorrow, you'll still be able to adapt to make sure that, for instance, your API is still going to be able to take care of all this work. On the front-end side, on the iOS parts, I kind of interpreted differently. If your team grows, does your code quality stay the same? Can you ship as fast as usual and so on? Especially if you move from two people to ten people to maybe a hundred people, as I heard earlier. So it's still something very important. So let's see what we can do for this. What about the why? So I think it's something we always learned before where we start working on a small project, and maybe it's one or two developers, and you're very feature-focused, no time for documentation, comments, maybe you're like, oh, yeah, I'll do that later. And then time pass and team growth, and then you're like ten developers. It's like a lot of good ideas every day. Everybody has his different codes, and you're like, it's really difficult to review your code. It's maybe difficult to read your mind. And it's kind of like, you become a mess, and there's no proper direction of your project. You're like, wait, what are we talking about? It's like, they said no, it's like, both of us, it's very difficult to just see, can we actually do that? And that become a real problem. And we're just talking about moving from two to ten people. What about the next ten? What about a hundred more? So we need a plan. So if you don't know where to start, the easiest way to start is probably to make sure that the code you're going to add tomorrow is as clean as possible. So that at least you've got something new and quite fresh in design. So the first rule might be just to define your own style guide. You can make sure every iOS developer in your team speak the same language. So the style guide is just like a set of basic rules to make sure that it could be name and convention, could be like using a specific pattern of another one, just like maybe commands or invotations. So you don't need to create your own style guide from scratch. You can just use someone existing one. So for instance, Google has a sweep style guide. You can just reuse it, adapt it, and just check with your team and say, okay, this is a good rule, we should enforce it. This is like we can just ignore it for now. But that's still a lot of rules that every developer has to think about. So what do they mean by convention? What was it again? So to enforce these kind of rules, you can use linked tools such as sweep links or sweep formats to make sure that any kind of new code kind of like going to go through this, just maybe read them, maybe create warnings or even arrows at real time to make sure that you can't just go further with that code because it's against our style guide. So what I put on the side is just like sweep links and sweep formats. You can just adapt it and say, I want this rule, I don't want that one, and so on. Then come like best practice, best use mainstream one. Work on mainstream is like, it's not because Facebook or Google are using like specific tools that you have to use the same one. And that's kind of like good against best practices. So for instance, here that we use, let's say, MVVN and RxRx. But that doesn't mean like you have to use MVVN and RxRx. It just like, it kind of feeds our purpose and feeds like a specific problem we have and we wanted to make it testable and like testability is like, would be the best practice. But maybe like tomorrow it won't be MVVN and RxRx or maybe it will be let's say Viber or like any other things. So you have to kind of like adapt to your new projects. Kind of like address the right problem and not like, you know, you kind of like take somebody else's solution to address any kind of problem. So that's true like for best practice, but that's also true for any iOS architecture. Which kind of like simulate like, yeah, you don't need like, you know, get the big games for like a simple, maybe like a small, a small market place. So we select what we can do for the code days. So let's say like what we can do for the project. Like just like files and folders. So I think a couple years, maybe a project like this. So you start with like, view, view model, maybe like model folders and then just like get probably like you get more and more files and folders all over the place and it's really difficult to find anything. And maybe just like he and he say, oh, this is that place. So like you've got shortcuts. But for new joiners, it's still like, it's a bit of mess. So let's see what we can do for that. So first we'll be, just try to reorganize files and folders. You might, don't take much of the time, but just like for the nice one, that'd be like, yeah, thanks. At least that's clean. You don't need to come in like a proper folder system. Just maybe like you can check some of that's already existing. For instance, Kickstarter iOS is open source and you can see like the templates, the documentation and how they manage this. You say like, oh, yeah, maybe I should do the same thing. It's not great. The other part is with the growing team, you might have like some conflicts. And like we're reviewing one, might be like your expert project file itself, which is like a massive XML. You feel like a main target. Every time you're out of file and somebody else has this file, it's the same file in another branch. You can have like more conflicts and so on and so on. So one way to tackle this is to actually use Xcode Gen or XK or any kind of like expert project generator. So it kind of like based on like a demo file, which is way easier first to review, you can have like any conflicts and especially if they don't project all that. So every time you've got a regenerated project, you actually can have like what point in the project itself instead of like just keeping reference from like previous events. Finally, differences. So I think that's something we all use. Cocoa Pulse, Cart-H, Swift Packet Manager, maybe Geed Submodules. It's kind of like best practice in the way that you're going to try to break down your massive thousand files application into like smaller PCs, like reusable, testable and so on. And that's something we do here at Zara. We also break down like different other PCs. For instance, it's not like a Star Guide for our code. We find also a UI Star Guide so that we've made like all the UI components reusable across any kind of like project platforms, which are like way easier for new joiners to just like direct up which one I want. Okay, now talking about UI. So in iOS, there's like three main ways to deal with this. Either like using storyboards using like Z file or just like programmatic way. And if you're like a growing team, you might be like, yeah, storyboards like it's good, can process out faster and so we did. And you also have a different new problem like where do you complete the same way where two developers couldn't work on the same storyboard without creating conflicts. So we just like went back to like programmatic way. So that's just like an example. We say like, maybe I'm going to save some time at first for like prototyping and like doing my MVP but maybe it's like this time that you're going to waste later and maybe it's going to be six months later, maybe it's going to be two years later. You might just want to like think about first and say like, where are we going to do that solution? Finally, asset stabilization. So if like same as Zara, they've got like multiple language supported. So I think Zara would be like five or six. So it's like a lot of strings to manage. And it's just like copy pasting. You might like, it's a typo, it's hard to review, you're not even sure. If you would like 10 files to review. I mean, again, it's difficult. Like a lot of it falls for reviewer, for reviewer, tester and so on. And it's certainly like assets. Everything is like they don't like a string base. You could just resolve that using Swift Jet, which is like a single tool that actually can help you create checks and enums for you to just like post completes and make it like all your like localization file assets, even like storyboards, color, fonts, all these kind of elements to your developers. So that's like, again, any new joiners with like a team group, you could use that guy, you could like all of these discoverable just from like post completion. You make it like way easier. So hopefully, with like some time there and thoughts, you got something like that. They like organize everything at this place. It's easy for new joiners to just like pick up the right elements, support it, test it and so on. So that's what we aim for. So we saw like a bunch of tools to see like and practices to see like how we can make like our code and our project later for tomorrow. And basically like what manual, say like I need to like do Swift Jet, I need to like do maybe Xcode Jet, I need to like go through Swift Formats. So let's see like how automation can help us in that. So maybe like the first day it would be just like to use some like scripting tool to create one of the most popular with the Fastlane. But you might just want to think about like do I want like dependencies on Ruby, do I like some private APIs, maybe I cannot, you know, to like think about first. And not because like everybody use Fastlane, but again you have to use it. It's more like maybe with like some customized scripts, I can do the same and like less risk of breaking because better like Xcode come online for instance. These are more people moving from Fastlane to Bezo and like other kind of tools that can help you do that. Again after that you've got like scripting and automation. You can just like press the button and it's going to build to instantly go for you. So it's just good time to like do that on another laptop, not too much anymore, but like maybe maybe Jenkins, maybe CycleCI and so on. Finally, you can just like do everything together using GitFlow to make sure that any new code added to your project automatically can like trigger new builds and maybe like verify your code and your code days. One thing that you might want to use is actually add extras there to your GitFlow. So for instance here at Zara we use the engine and I don't know if you guys know about it but you can have like easily check the side of your prove request if it's too long you can like raise the warning or if you just like miss unit test it and that's like that's what you want to enforce and if like any table machine has been moved and it's kind of like where you have to like verify any other prove request. Just kind of like create it to the main one. Last thing for the mission tool I can't ignore is this crash reports. So you have to like all your assembly gate. If you don't, let's go back. Your application might crash at some points you won't just be notified but because every time you like build a new app you need to like upload the like assembly gate files to your crash reports to make sure that you got all these metrics and that's something you also want to automate at some point. So let's just show that this part looks like part of your view. Okay, so that's the information I feel like everybody is like who is talking about. So let me show you quickly what we can do with like couple things. You don't have any more? Okay, so I've got one project and I'm just going to code it based. Can you guys see? So far. Okay, so here we won't pay attention to like architecture, architecture. We're just going to ignore that because it might be like different. So I just want to show you so I've got an application where I've got a list of strings and then when I click on it I go to a detailed page with like an image very basic app. So can we see? Yes. So I got like some string when I click on it, I can see a picture. Okay, looks, looks, okay. But wait. So here like we got start having typo. So localization become a problem and assets are also there in my string. So let's see how we can do to just avoid these kinds of contents. So I'm going to put sorry, we need the string because it's very high. It's changed by some string. Presentation. Let's go. Oh, this one. Yeah. We changed the string to everything we can see. I'm afraid I would interfere with the recording. Okay, can you see now? Okay. But like somebody like intent it before you and it's kind of like you might come in anything. So I'm just going to like show you how Swiflin can do that. Obviously you could just like intent with AISCAN, but the idea is like show you alternative solution. Swiflin I can like do way more but I just like give you like some tips and tips. Can you get Swiflin? And there is like my code behind and I'm just going to like try to reformat all the projects and that's it. So I just like re-intense, but I'm also going to like take all the warnings, maybe like some code practices. So everything you can enforce based on that. So the second part was all the like translation and like all the local label strings. So I've got like here, but like like somebody like copy pasting wrongly and it become like a problem. So what I'm going to do is like use um um Swifthgen to like actually create like assets and also localization localization string based on this. Um so to do that I'm just going to reuse one prepared obviously. Swifthgen demo file. So because I create like a configuration file for it, then it's just going to like pick up the configuration file and execute everything. If you look into this slightly closer I'm just like giving like the inputs of where is my string localization the same as my assets and where I want the outputs to be. So I'm just going to run it obviously there's an error I'm just creating that wrong place sorry okay so I created two files. We can't see straight in the code because it's not automatically imported but here they are so one is like the strings and let me just show you and import this one. So you automatically generate like localization based on like what I had before. So now I can just replace it in my content 10 good morning. I'm going to do the same for the assets okay the same for the assets like this is like my generated file. So every time I'm going to have like new localization new assets I just need to like rerun the same thing and I can just reuse it and I'm going to have my assets I'm going to just keep the same because I got like the image name I'm just going to use image name as well and last image. So now we're going to just like check that everything is working but also in French because well I'm concerned for my French users and let's read it again. So now everything got picked up so automatically localization everything is like auto-completion so easier to find for your users for your developers sorry and also like the images still a match. So it's kind of like safer on the development side so like the developer experience just like increase quite quickly and the last thing I wanted to show you is Excogen. So let me clear that so one thing is like my project here I'm just going to remove the Excogen project file and I'm just going to move around the assets from one file one folder to another just to show you like how does it work so for Excogen project you're going to create like a general file describe what's the content of your project for itself and I'm just going to create my configuration so here you can see oh yeah we're already at the bottom, at the page so here you can see like the name of my application that's one target going to be application iOS like deployment targets and the other one going to be a test target and like the folder so let's see how it goes in the app okay and now Excogen generate okay so now I created like the project thing is like I used spot file before so I still need to run Insta on top of it just to make sure like everything going to be picked up and then my project is regenerated and okay the thing is that we can't see they were but now in localization I got my assets that's mean like that's mean like based on my configuration and my project my folder structure the project can be like just reorganized and everything everything is like that the good thing about this is you can actually remove your expert project from like UP triple and like just in your steps just like repeating every time you need it so it's kind of like safer again for your developers but also depending on like the size of your team like 100 developers and might be something you want to move okay so in conclusion we define like some tools and spend hours for your team to kind of like follow and like make it easier for your developer to have like a direction for your project we also see how to organize either like your code base, your project localization assets all these kind of like elements that make it maybe just painful for you today and we saw some how to set up some tools and workflow to just like remove all that pain it could be like code reviews it could be just like missing differences thing like that that might be easier tomorrow for you when you have a team group and finally for something like that we either consist integration switching tools and so on so yeah that's it do you guys have any questions sure yeah I'm Jin and I want to know how many smoke tests does your productist have how many what sorry? smoke tests does your productist have how many smoke tests my the the request so at the moment our testing is separated between we got like a specific mobile dynamic so it's not part of like the presentation is it your question I'm just wondering how long does it take and how it's long and how do you know how we handle that right okay so I think I mean it would be great because we got like automation engineer behind but I'm going to reply for him so I think on the mobile side we mainly do like unit testing but we got like QI automation team that do also like QI testing and like all these parts of like daily smoke tests and all these parts I don't think it takes that much time so we just like break down the assist in like specific areas of the app so for instance Zahra, e-commerce and checkouts is like where we make money so we make sure that it's not broken but we also got like a mobile back end like mobile back never they won't smoke there and so on and so on so we kind of like the same as like I show you how to break down your application to make easier to test we do exactly the same in the biggest fail between like iOS Android we use a film for for UI and mobile back end and like the rest of the back end and like all the CMS and so on and so on so on time I can tell you it would be like our alternative curve maybe like 30 minutes to an hour for like a full sanity test I would say I have a question about sweet format versus sweet blend like we are also thinking of injecting it into our project but is there advantage of having both or if you have one is that sufficient I think I think it's like one is enough like I think it's more depending on what you need we use sweet format here but it just depends on like what are the tools we might use and also implement sweet blend at different levels so you just might want to find the one that suits you best it's kind of like cookbook or cottage and kind of like find the right balance so I think it's like to say I would say for you it's kind of like something we also like try to explore because we we have some like issues like a lot of you if you use fast lane like some idea is broken and you can see like a lot of people moving to basil but again like we didn't have time to actually explore like what would be the benefits from it so yeah we haven't yeah so there's another tool for us we have been making up in many ways you just overdo it you overdo it yeah it coordinates the entire process and in that link they did mention that we then as well as sweet format so how is that why is that so what's the advantage of one or the other I think to be honest like the tools I show you it's just like show you alternatives and like one different ways so I'm not setting any solutions specifically so it is like all the alternative I would love to treat as it and see like if it's actually a benefit but again it's kind of like why using really gentile cycle CI or things like that it's just like I guess different like solutions fit to the best so yeah I noticed that you mentioned that we could remove the entire export project if we are using the of course to generate so that means you can be completely removed it's quite similar to POTS as in the run POT in it and POT installed once you put from there POTS so is it quite similar to that the more the more complex becomes the project maybe like the more tricky it might be to adjust to like go to migrate to this but if at some point you want to kind of like remove all that thing from conflicts that might be a good time to invest and take on but yeah the idea would be you can actually just regenerate the project whenever needed so it could be like a real piece so then that means the development is slowly working off the to make it yeah so that's why I started with like CodeSpar out and maybe like some workflow is because like you kind of need to align all the things to make sure that you know it's like the way kind of like the way you're going to use the project for instance I also noticed that you never mentioned Jenkins oh yeah so it's fasting yeah I kind of like hide behind CI because I'm not sure like some of you guys might have solutions to Jenkins like so I didn't give you a lot about like CI I assume people might know actually yeah any other questions any other questions cool so you would like a long talk I said you would like a lot of information so yeah I'm just going to give you to the next one thank you guys