10x all the engineers? Or maybe not. Swift Charts and cool CoreMotion

Jeroen Leenarts: Hi, and welcome to episode 85 of a podcast app Force One. My name is Jeroen Leenarts and I've been developing software for over 20 years developing iOS apps for 10 years, and I've been running the Dutch Koch hats for over nine years. If you're an iOS app developer, you should listen to my podcast because it will keep you updated on interesting articles, conferences and events you might not have heard about. In this episode, I'm going to talk about what are vanity metrics and how to identify them. Being a more efficient mobile engineer, my templates, research design and ship iOS apps, how to use inner shadows to simulate depth with Swift UI and core motion. Mastering navigation stack in Swift UI, alone y axis to leading edge in Swift charts, plotting data distributions with Swift charts, comparing build speeds of Xcode 13, and Xcode 14. Better to and SF symbol changes in iOS 16. So let's get started. Hey, welcome, everybody. I've been very busy. Last week I did a presentation at at DEF CON, it's about how you can deal with software developers. And I turned things around a little bit, because I was at the final slot before the closing keynote. And what I did, I just changed everything, like 180 degrees. So I pretty much told the audience the exact things they should do to make the life of a software developer a living nightmare. So if you do the opposite of what I told you to do, then you should be pretty good in managing and dealing with software developers. So hopefully, people learned a little bit from this presentation slides are already available online. And hopefully at DEF CON will publish a video of my presentation as well. And yeah, just creating this presentation has piqued my interest a little bit in what it takes to be a software developer, especially as a mobile engineer. And that's why I'm actually doing something a little bit different this week, because Benoit busker published an article titled being more efficient as a mobile engineer. And it's a really interesting article. And what I'm going to do is do an exact read of his article, and then add some comments on that. And then we'll dive into the articles of this week, I'm preparing my family for a summer vacation. And by the looks of things, we're doing some interesting travels. And in the second half of the summer, we're actually going to Luxembourg with an electric cars. That's the first long distance trip. So looking forward to that one as well. And now I'm just going to dive into this article by Benoit being more efficient as a mobile engineer. I was reading this week about 10x engineer and what it means in the tech industry. If title can be questionable, I wanted to reflect on its definition and what it can mean in mobile engineering. If you search about 10x engineer, it's defined as engineers that are 10 times better than their peers in terms of productivity, or quality of work. Putting the title aside, the definition likes to reflect a person's productivity isn't constant, it can depend on your team, your manager, or the project you're currently working on. Maybe you can be productive in Swift on iOS projects, which would be as productive in Python on a day to project maybe not. So there are some variants around it. You get the idea, right. The second part that struck me is how to know if you are one. Since the definition points towards better than their peers. They only would be to compare yourself to others. That doesn't feel right. Then I read Max Howells definition, being a 10x engineer is being efficient architecting for scaling your code productivity, picking the right tools and knowing them well. Building your own tools, knowing when to quit a failing approach, knowing what to build first to get the most value. This is already much clearer and the first point resonates with me being efficient. So what does it mean for mobile engineers? How can we get more efficient, that's the part I will focus on today, I will cover three main parts about efficiency, planning, execution, tools and automation. First off planning. The best way to do more in a day is to plan your day better. The best way to do more in a day is to plan our day better for a simple thing. prioritizing tasks to make sure urgent things get executed the right way. As part of my daily routine, I make a list in the morning of what tasks I need to complete on the day, the list has to be realistic, too many big items which just demotivate me if I cannot complete it by the end of the day. And the second part is about time management. Keep in control of my day and my calendar. If I work on an important project with some unknown areas, I will timebox it research and document as much as possible for a specific amount of time. If I don't timebox it, I might lose track of time and Miss completing other tasks and blocking other teammates or projects. Finally, planning applies also to the tasks themselves. We're working on a new feature. How much do you know about scope? Does it need to support internationalization or accessibility? What iOS versions do we support? What kind of device do we need? To persist any data, how about security of personal data? Is there any API service dependency? Are they already deployed in an environment? How are we going to roll out the feature safely? It's okay not to have all the answers, but then who can help me answer them. The more questions I raise, the more defined the feature is, and the better I can code and design the project to fit the requirements. From prioritization, time management and planning, I am ready to code and execute the plan. Second topic execution. Nowadays, our laptops and computers are getting faster and faster, we can build fast and often, so we have fast feedback. However, I try to not launch apps from Xcode too often. With my notes aside from before, I should know exactly what is needed or not. So I can stay focused on the code from Xcode, the auto completion and error highlighting are usually fast enough to suggest changes while I'm editing. So compiling isn't even necessary yet. It's just about coding. Once a big piece of code is ready, it's time to compile and launch the app, I take notes of all the bugs and missing parts, like misalignments of UI data, not storing etc. For the next code iteration. Sometimes the feature or screen I work on is hard to access. For instance, I need to add a new journey for a specific screen, I need to be locked in, then go to a listening screen, then the detail screen then make an action to enter a new journey. In these cases, I would create a dedicated deep link URL like deep link colon slash slash test, etc, you get the idea to directly open the destination from a terminal, I can access it much faster and save lots of time in the debug process. I will just use, I would just use xe run sim control open URL on the boot device to make sure that I land on the specific screen that I'm working on. This custom journey allows me to quickly mock different entry points and make sure each dates are covered quickly. So like network errors, or non logged in users. Once I have the feature stable, it's time to refactor and clean the code if needed. It's about making the code testable abstracting the parts that aren't yet injecting dependencies that weren't adding encryption if needed, documenting the hardest part, etc. If there aren't any tests yet, it's time to add some I need to make sure the code behaves as expected. It helps maintain the code in the future flag broken features but also builds confidence in the code. When it comes to API requests mocking network is very beneficial to develop mobile features in parallel with backends effort. Once the API contract and error handling is shared across the team members. Then using a network proxy tool, I can iterate further into code behavior and sometimes be ready before the backend deployments, third, topic tools and automations. This is probably my favorite part. So far, all of what I do is pretty manual, from planning to execution. When it comes to tools and automation. It's about improving further, and the manual tasks to save a bit more time for the next use. The most important part is to have quick feedback when something breaks. Continuous Integration is key in these aspects. There are many continuous integration tools out there, so feel free to pick any, the important one is to have one that fits your purpose and works for your team for tuning to make your life easier. Fastlane is the most common scripting tool for Xcode projects. But Xcode CLI with some shell scripts can be a great start to what other small tasks can we improve? Actually, there are plenty. A simple example opening a pull request requires me to open a browser, go to the repository, open a pull request and compare it against the right branch. If you open multiple pull requests a day, it's sometime that you won't get back. Having a simple alias in your favorite terminal can help a lot with this. If you're not limited on tools, GitHub CLI goes even further to attach title, a description and more all directly from your terminal. On the other hand, Xcode is probably spent the most time during my day. So look for improvements there too. I have created many code snippets on Xcode to help you create new class or unit tests save precious time for any new features. There are many more tools that can help you out the linting and style extension during build phases, UI automation, for App Store screenshots, and many more. It's about finding good solutions that help you daily, forth topics team efficiency, most of the tip. Most of these tips and tweaks are for individual efficiency. But how about your team? I believe improvements can come through the same levels. For instance, better communication and planning as a team allow a better collaboration, especially if you work on a big project, but many people involved. How does your feature fit in the whole user story? Who will handle the previous screen? Or the next one? How will you sync the codebase? How to decide who's working on what? During executions? It's also about following the same standards and best practices your team has. It's much simpler to understand each other when everybody speaks the same language right? It applies similarly to the codebase freestyling for a new architecture that doesn't integrate well with the rest of the app might slow down testing, maintenance and peer review. Finally, tools and automations systems are meant to help you and your team be more efficient. It can be about notifications when a pull request is assigned to you to review on, or auto merge wants reviewed, sorry, team members aren't blocked. It can also be about knowledge sharing. So not only one person can handle a piece of the structure, this comes to documentation, tech sharing sessions, and the tailored onboarding process. creating dashboards and monitoring reports can also help make your team more efficient. If the number of crashes is only accessible to a few. How can we create awareness and make the project better? How does it help to avoid issues in the future, sharing and exposing others allows them to share responsibility and ownership which eventually helped the team and the quality of the shipping release. As your team and organization grow. Keeping your team as efficient can become a full time job. That's where the mobile platform team came in, to support and help other contributors to focus on adding value and stay efficient by providing tools and resources to keep your build stable and feedback loops short. So being efficient is looking at your work and wondering if there's a better way to do it. It's about how to be better on a daily basis. But don't stop at the first solution. Keep digging, and keep reaching for more creative ways to get better, you don't need a fancy title like 10x engineer or compare yourself to others. It's about finding smart ways and keeping learning. And without notice, you're already there. A 10x engineer, I really liked to take that band was taken with this article. Because so often people think when working in software development, that being a 10x engineer is being about crazy productive yourself that you have to do all the work that you have to make sure that you can create more code, more tests more functionality than your peers. But I don't think that's true. I think if you want to be 10x engineer, it's about the influence you have on your surroundings, are you able to make everybody's life in your project better, more efficient? And are you able to find those details in the projects execution that will help everybody further with minimum effort. So find those areas in your project right now today that you can optimize that you can tweak that you can automate, especially that last one, anything that you can automate, it's good, because I always live by a single rule when it comes to automation. If it's the third time I'm doing something, I'm looking for ways to automate it because I don't want to do the same thing over and over and over. So taking work away work, by automating things is one of the easiest quick wins that you can create today on your project to be a more efficient software developer. And maybe today, or tomorrow, you won't be a 10x engineer. But hey, within no time, you can be a 2x engineer or 3x engineer, and you're on your way to career growth, and better opportunities in your future. So let's dive into the articles that I have for you this week. Because I really liked that Ben was stuff. But we also have to look at the number of articles that are found this week, and that I want to share with you. So after this thought provoking piece by Benoit, I want to stimulate you even further by sharing an article by Georgia Morgan with you, I'm not going to read this one out loud, completely. But it is a good one to have a look at yourself. It's titled my template to research design and ship iOS apps. So it's basically a guide that Jordan provides us with the way that he likes to set up and research and design his projects. So with any idea, it's always good to figure out if it's a good idea, then figure out how you're going to do it, and then actually make sure that you can ship it. And the best part is he's actually sharing a craft doc templates with us that you can use to have a look at his process, but also try and apply his process to your situation. So it's really a hands on piece of work, you just open the document and you get started. And if you execute it, well then by the end of the article by Jordan, you have like a game plan on how you can implement your own idea and how you can get to an MVP. So that's very good. Very cool. And yeah, I hope it helps somebody because that's also what Jordan hopes to achieve with his article. So now it's time to get more technical. Again, I have an article here by Tomas father comparing build speeds of Xcode 13 and Xcode 14 beta two, it's an article that basically compares these two versions of Xcode on his hardware. And what's interesting to see is that build times on the beta two are significantly longer than the release version of Xcode 13.4. But one thing to be aware of is that of course, the better version of Xcode probably has all kinds of instrumentation still active that allows you to share on question, any issues with Apple engineers, what's going on? So this version of Xcode being slower than the current production version of Xcode? That's not a surprise to me. So, I think that actually explains what's going on. on here, and I just wanted to provide this comment to Thomas. Because I think a fair comparison between echo echo 13 and Xcode 14, will only be possible with release versions of these Xcode versions. And I'm still very curious to find out how the actual release version of Xcode 14 will compare to the current version of Xcode 30. The next article is by Paul Hudson, it's titled How to Use inner shadows to simulate depth with Swift UI and core motion. And then the sub line is tilt your device to move the shadow as if there's a light source shining from above. In his article, Paul shares a neat little trick you can do with core motion and swift UI that allows you to have like a depth like lighting effect on any asset that you have on screen. That's a good sample code in there, as is always the case with articles by Paul Hudson. It's a complete example at the end. And it's an interesting dive into an API. So you might might not be familiar with like core motion. And yeah, I think it's just a fun article to go through just because of the fact that it's an API that it's not very commonly used in iOS development, while it is used under the hood, of course, but not directly by app developers themselves. So have a look at this article. And just look at the neat integration that Paul Hudson achieved with Swift UI core motion, and publish properties. Next up, it's time to dive into the navigation stack in Swift UI with the help Mudgett, including deep linking. And that's very neat, because in my article read by Benoit, Bhaskar, it was actually mentioned, to do deep linking in your codebase to get to a specific feature that you're developing. So I think this article by Majid is right on the money and that it's this something you have to look at as well, to really apply what Ben was shared in his article. So in this article, my cheat will go into an exploration of the navigation API in Swift UI that is new in the Xcode beta and iOS 16. Better. It's an extension on a previous article that Majeed did mastering navigation stack in Swift UI navigation pattern. And it's a lot of hands on sample code that allows you to get started to try it out yourself, and how to do programmatic navigation in this new structure that Apple is providing for us to navigate in Swift UI based applications. Much it also goes into state restoration, because that's an important use case to programmatically get at a specific screen. And I think in the end, you will have learned how to use the new data driven navigation API to control your navigation stack programmatically and implement a deep linking feature. I think both of those things, state restorations, deep linking, being able to use this feature with custom URL schemes to actually get into your app at a specific point, while also implementing the deep linking a state restoration feature. That's awesome. And I really think you should have a look at this. Of course, this is only applicable to iOS 16. But yeah, in the future, this will be the minimum target at some point. So it's good to have a look at right now, just as well. I've got two articles on Swift charts by Matias Goulart, in the first one, he's going to explore how to visualize data distributions with Swift charts. He wants to look at a dataset of some survey data collected with about penguin colonies. And the data set captures many different anatomical details such as weight flipper length, and buildings. So to start this investigation, he will look at the distribution of values for each of these parameters. To build a histogram, he needs to group his data into bins and count how many samples are within each bins. Charts provides a simple way to do the binning operations with number of bins data types. And it's an exploration of this number of bins and how you can plot a distribution on the chart. It's an interesting article that shows you an interesting application of bar charts to display a distribution of data points in the dataset. And it's a full complete code sample that allows you to get an idea of what is actually possible with the Charts API made available by Apple. After doing the bar charts, he will go into details on how it can do a to d density plot. And this is something that looks really neat, because it's a some sort of a distribution display on two data points on two axes. And it just looks really neat. The second article is started align a Y axis to leading edge in Swift charts. The default behavior in Swift charts appears to always draw the y axis in the trailing edge of the charts. However, in many cases, you would prefer your charts to be rendered. With this y axis on the leading edge mythos has found that he can control the position of the y axis tick using chart y axis modifier in combination with access marks. And it's a neat little trick, sort of like a code sample that allows you to lay out the leading edge of the chart that you're rendering is free of charge. Just the way if you want Jeff Hackworth has an article titled SF symbol changes in iOS 16 and WWDC 2022 What's new in SF symbols for Apple announced the latest updates to SF symbols. There are now over 4000 symbols the default render mode will use hierarchical for some symbols and The new variable color feature progressively colors parts or some symbols to highlight changing states. There are now 10 different sets of symbols to consider. So you have Asif symbols version one version 1.1 Version two to DOE two to one to two to three Dotto treated one treated to treat a three, and now four. So that's a number of different SF symbol versions that you get to deal with depending on which iOS versions and other platforms you are working with. So an app can only use symbol names that are supported by the OS version it is running on, and symbols that were renamed are still available using the earlier names for backwards compatibility. But a newer names will not work on older iOS vs. Obviously, the minimum iOS deployment version of your app will determine which symbols you can use and whether you must keep using the older names or use runtime availability checks to use the new names or newer symbols and later versions. For a detailed list of symbols that were added or renamed in early iOS versions, Jeff has written previous articles before this one. So each version of SF symbols, Jeff has written a nice write up on what SF symbols are available and how you can use them in that specific version of iOS. And the purpose of his article is to describe what has changed in SF symbols in iOS 16 is not how to write code to use the new features. The resources section towards the end of his article has some links to some WWDC videos and blog posts, which explains how you can use these new features of SF symbols. And that's the progressive color thing. That's the coolest bit actually. So Apple has also updated their SF symbols Mac app to support new symbols and variable colors in iOS 16 beta one. And at the time of this writing, the latest version is four dot o built 75, which does not include the symbols changes in iOS 16. Better too. So his own app activity is a tool for iOS developers and designers and one of its features is a very comprehensive view to browse SF symbols. It can view any of the SF symbol datasets that your device supports, and will show symbol names that are valid for that specific dataset. It will not show a new name for any symbols that have been renamed in a later version. Jeff also goes on to describe that there are actually 722 new symbols in the WHAT'S NEW section of the SF symbols version for that though, and compared to previous version of iOS, the default render mode for SF symbols was monochrome. And new automatic mode is now the default in iOS 16. And that is something you have to be aware of. And it uses monochrome for most of the symbols, but uses a hierarchical appearance for some symbols that Apple believes looks better rendered that way, there's some new API in iOS 16, that allows you to specifically request the monochrome rendering version if you'd want to also about different color symbols. Variable colors allow you to show some sort of progress on one of these SF symbols, think like a Wi Fi icon that has like multiple bars that can be highlighted or can be grayed out. And you can actually animate this property. So you can have a animating Wi Fi icon or any of the other variable color symbols that Apple has now made available in SF symbols for though, Jeff goes into a number of other details in his article, but I just recommend that you have a look at his article and also on his look, and also have a look at his app at activity because it's a neat little tool that allows you to explore the SF symbols to in much more depth compared to the SF symbols application that Apple makes available. The final article of this week is on the company block of my work. It's at the stream block. And it's titled, What are vanity metrics and how to identify them. So you've probably heard about the term vanity metrics, metrics that don't uncover meaningful data about your app. And they're probably here because you don't understand how to identify them. So in this article, Frank will go into detail, what are vanity metrics? How vanity metrics can sometimes fool you? And that's the important bit, I think, and how to identify vanity metrics with three questions. So these three questions are is the metric actionable? Dustin metric depends on luck, does the metric reflect business performance. And then he goes on to show some examples of vanity metrics for mobile apps and SaaS companies. And there's some interesting bits in there. Frank thinks that new downloads, traffic and total number of users are vanity metrics. The same goes for social media likes and followers. So he goes into some detail on why these metrics are, in fact vanity metrics and why did not provide much value to your online work. And he got them. And he then goes into detail of what are some examples of actionable metrics. So that are metrics that you can actually work on and that you can actually improve and make some conclusions on so and those are churn rates, user stickiness, average user lunch session length, and the Net Promoter Score. So overall, this article I really liked it because it's, it's because when we're online, we're quite often just Also, in my case, just looking at your social media numbers, how many followers do I have? How many downloads do I have on my podcast. And in fact, I don't really care how many downloads I have on my podcast, I much rather have like a core group of people listening to my podcast that stick with me through thick and thin, and that I can rely on and that also give me feedback on how my podcast is doing. So I really like having stickiness, and people listened to the entire episode of my podcast. So some interesting bits in this article, it's a bit different. But I think it's still applicable to app development, especially in relation to the article by Jordan Morgan that I had at the start of my episode. Because if you're developing a new app idea, I think having the right metrics in place to evaluate the success of your work is very important because it allows you to make good choices, and make sure that you are doing the right things at the right point in time. And that's it for this week. I think this new experiment with a podcast is something I'm really liking thus far. Just doing the article reads and having some more intricate show notes again. So linking up everything and making sure that the chapter markers are in my podcast episodes as well. Give me any feedback if something is amiss there because yeah, I just have to discover how this works in all podcast players out there. So if you see issues, please let me know. Because I just want to improve on this if needed. And yeah, if you want to support my podcast in any other way, then have a look at my buy me a coffee page, you can give me a cup of coffee there or you can even become a member of my podcast. And if you want to you can even get like continuous like consulting coaching type sessions through buy me a coffee. So definitely have a look at that. I would love to get some supporters from a podcast, because I've been doing it too close to 200 episodes now. And yeah, I'm just trying to find new ways to to put some meaning to my podcast and to make sure that I get into contact with my listeners after their stay in contact with my listeners. So definitely have a look at my buy me a coffee page. And if you want to have access to my Discord server without buying me a coffee as a member, please reach out because I can always invite you to my Discord server if you'd like that. Also, if you have any feedback, I'm always available on Twitter at app forest will talk to you again next week.