 This is my first talk, first time dealing with a talk. So please bear with me, I am making mistakes in the kitchen. So my talk today is going to center around the WordPress mobile apps. And it's actually a way to encourage people and you and your family to actually not continue doing mobile apps. But before that, I just want to give a little brief intro about myself. My name is Irina, I'm from Z9, I'm an Android developer. I started developing a mobile app around 2013 after competing in college. I looked at the number of startups in and around Z9 and after a bit I found remote working to be really awesome. And so I started freelance, I did my job, started freelance. So that was my first experience with WordPress. So basically created a website for myself just to talk about Android or coding in general and talk about my freelance project or whatever that I fancy. So two years later I was working at Automatic as a software engineer on the new commerce mobile team. So getting back to topic, WordPress mobile apps. The mobile apps are actually a community product that's owned by the WordPress Foundation. So Automatic actively contributes to the development of the Android and iOS native apps. The WordPress mobile apps have been around for a while now. It's actually been more than 10 years. So they provide people with WordPress experience on your phone. So you can create on your website, you can moderate comments, you can stay on top of your notifications. You can grab your site statistics. There are a lot of features that are available in the apps. I wanted to basically highlight some key features from the mobile app. Some have been around for a while now and some that have been in the edit. So one of the features introduced in the mobile app over the past year or so is the Gutenberg blog editor. Also on the left side you can see that is the old asset character which is slowly getting faked out. On the right side is the Gutenberg mobile editor. So the Gutenberg mobile editor basically develops and values to react native. It basically wraps the asset. There was an asset Android and iOS native library that was added to the application. So basically the Gutenberg editor basically just a wrapper. It's a reactive component that wraps the functionality of the asset Android and iOS libraries. It's not actually enabled by default in the app right now. You really need to go to a setting and enable it. And a lot of some of the features right now that I do with the asset in here is like paragraph settings, image elements, blog video blogs, lists. I'm sure there's a lot more that are getting added as you speak. Another feature that I use are quite important in developing mobile apps is the accessibility support. Mobile devices provide a surprising amount of accessibility features. So we have screen readers. We have control over transparency. We actually can reduce motions and animations on our powered devices. We can add shapes to buttons. We can increase the color contrast basically to make it easier for people with color vision deficiencies. There are also options for users to decide how large they want they want to be. That is basically called dynamic type in iOS and on Android it is called typescape. There are screen readers that provide a way for users to interact with the device only by sound, right? Which is pretty awesome. On Android it is called top back and iOS is called voiceover. So in order to provide support for accessibility, the WordPress mobile apps are regularly audited using the accessibility inspector which is in iOS and the accessibility scanner which is for Android. That actually lets us identify parts of the app that do not yet support accessibility. So we make sure that we run the apps once and a while to our standards and our inspectors and we make sure that we do our user accessibility needs because that is a very important feature. One of the newest features that was introduced a couple of months ago was to provide offline support in the WordPress mobile app, right? And that's a lot of time because the data is actually very extensive and you can't actually always have a neural phone when you're actually 24-7. So but I'm not sure how many people are aware but you can actually edit and create content on the WordPress mobile app right now both Android and iOS where you can, you don't need an internet connection to create content. You can upload images, you can upload videos. As soon as it works, it's like everything gets stored in the device and once it's accessible, internet connection is established. The post is automatically updated to your site. So that's pretty much, I think that's pretty good. So now that we actually know what features are actually being worked on in the app, I just wanted to talk a little bit about how the mobile apps are built. So all development is in GitHub. And it's open source, it's licensed under JTPL. We have a separate project for each of the platforms and one, we have the Gutenberg mobile project which is for the Gutenberg mobile area. The development algorithm for Android right now is carbon and for iOS it's Swift and for Gutenberg it's React Native. As I mentioned before, the mobile apps have been around for a while. So we do have a lot of legacy code in most of the projects. So in Java, it's in Android, it's Java. That's a lot of code for it in Java and in iOS it's in Objective C. And now we come to the development cycle, which is this that we use to describe a process of power product is basically built. So everything happens on GitHub. So each potential development starts with a GitHub issue. And an issue is it just finds the problem statement. It can be anything from finding a bug that needs fixing. It can be anything from changing the font size of the button in the app or it can be something that's complicated as basically providing image of your support in the mobile apps. So what we do is we log everything that we want to do at the future reverse, every bug bit that needs fixing that is necessary on GitHub, which has issues to GitHub and we constantly prioritize that. What I mean by prioritizing is basically being constantly aware that what we do actually can add more value to the end users. So once we decide that this feature or this topics can actually add once we decide what it is that adds more value to the end user we push those issues on to a development cycle which is the sprint. The development cycle happens in an action of two weeks. So we have two weeks to complete a reach. So as a developer what I will do is to look at the list of issues that are already prioritizing GitHub, grab one of them, assign myself to it and then I just start coding. So once I decide that the development is complete whatever I'm working on is done I double the change the code that I made for view. Then that is what we call a peer review or for request. In this case it is basically a request to tell my colleagues that to tell them that my goal is ready for their view and to provide feedback. As I mentioned before that the WordPress mobile act happened after a long time. So basically maintaining a software product for that now actually requires a conscious effort to build the code in a way that is maintainable that is actually readable and not only for us but for anybody who is actually contributing to the app. So the others are not actually going to remember what we built three months ago or six months ago or a year ago. So maintainability, sustainability, making sure that the code does what it's supposed to do making sure that the existing functionality is not broken that it is properly tested. So all of these are good things all of these are the collective responsibility of the entire team. So these are things to keep in mind when actually reviewing a good request. So that there's usually some back and forth some discussions that take place on the board but eventually we always reach a point where we say everyone is going to satisfy with the code submission. So that is when the code is actually released code is merged into the main code base. So this process is actually repeated every two weeks. So once that issue is fixed then we grab another issue and the whole cycle starts again. So that was how we built the app. So once things are built we should then and we can write them to our end users and that's what we call the release cycle. So every two weeks we are watching the code that includes packages to your teacher etc. So we pack up into a binary build and submit that to play data release or test like if it's iOS. So this actually allows us to send the app to testers so they can test it out for the next two weeks. At the same time the build that we provided to testers two weeks ago that is basically gender release to the gender public. So the testers actually use the beta release for the next two weeks and they test it. And if they find a release within it if they find things that they realize is noise broken or that isn't working as well as it should they again get locked as a gift on issue. And that would again get prioritized again and that would be included in the next year of the cycle. Then we know a little bit about the apps and how it's made. I wanted to take a little time to look at the people behind here. So this is us, this is actually the automatic mobile thing. So a majority of us have worked on the web for so while app at one point, at one time or another. But that's not actually very productive you work on. You also work on this if you know about commerce, mobile app, more recently we actually have a number, for example. But as you can see there is a significant number of dots on the left side of the map. That's because most people are from that side and we are actively actually trying our best to change that and maybe spend a little bit of diversity to the rest of the world. At the moment there are about 50 of us in a wider region. So this doesn't just include developers, it includes designers, it includes the UAE as well. And most of us are located across many different countries. So we are always actually trying our best to include the ISP in the team, which as you can see not only includes our gender diversity but it also depends on the economic backgrounds, languages, the geographical location. But it's still a little progress. Now that we know how the apps are built and exactly within the app, I wanted to take some time to talk about how you can actually contribute to the mobile app. So that's part of why we build everything as open source, so that everybody can contribute. And you actually don't need to know how to contribute to the mobile apps. There are, one of the ways that you can contribute is by testing. So as I mentioned, there is a release that happens every two weeks for testers to test their app. So with every beta release, there is also testing that is posted on the main WordPress law on the mobile section. So this app also actually provides a great way for you to actually test your app. All you have to do is join the Android beta program or the iOS test app program. It's just because they're great and accepted, basically. And every time you release, it's actually, your beta release is actually updated from another website or you get a notification of the device and all you do is install the app and that's it. So what all the features that are actually included in that release would always be mentioned when you update the app. So it's an easy way for you to test the app. Even if you don't like testing, you can still use the post on the platform or testing in the evening. And in a format that is really very easy for us to incorporate in the next development cycle. But if you feel that it's not something that you can't work, there's any doubt that you, that you won't pray to me to have any doubt that you can always feature by loving you to the main WordPress Slack and let us know on the mobile channel. Another way to contribute is to translate. Maybe help the localization. So the apps are translated every two weeks and not just the apps, but all the release notes and the app store or description, they are all translated. Every time it's a release. Translation in general is a little tricky to get, right? Just some phrases that make perfect sense in English don't always make perfect sense in other languages, right? So if there is anything wrong that you notice in the app, the best way to fix that will be to just go and fix the translation yourself. Because the translations are managed by WordPress. So it's just as if you just log into WordPress and click on the app, click on the translation that you feel is not right and just change it. Now, if you also more like to have translations for languages that are not yet supported, you can add that to that would be really awesome. But every two weeks, every time you generate a new build, it will be putting these translations from WordPress and you can put them into the app. Last but not actually the least, if you are a file developer or if you are a person calling 40-minute coders or Java or something like that, then all you have to do is just go and set up your system and just download the apps and start working on them. There are a bunch of issues in GitHub. But you have to do a travel issue, assign it to yourself, work on the issue and submit it for a view. So and if you have trouble picking an issue, then there are a lot of the already auditors, regularly auditing issues in GitHub and a lot of issues that we think are root-first issues so people are just starting to continue. Last week that you wouldn't be right, Vanessa Siddharth saying that if you are a file developer, if you are a package developer, if you are a Java developer, if you are a data scientist or whatever it is that interests you, I definitely would encourage you to check out our job switch because automatically we used to do remote companies so I think there are a lot of barriers for that but that's, I might be wise. But yeah, just check out our job switch, it's pretty cool. But yeah, thanks pretty much. Thank you for listening to me.