First of all, my blog post frequency decreased significantly after changing jobs. In my previous job, I wasn’t learning much, and I was writing to learn more. My new (current) job has changed my life significantly, and fortunately, in a good way. It was a milestone in my life. I wanted to work remotely, without being tied to a specific city. This job allowed me to travel more and work from different places. On a deeper level, I really like to feel like a bird. I don’t want to be in a cage, so it was a nice opportunity for my soul.

In my previous job, I was working on a hybrid app, not a native iOS app. This job involves a native iOS app used by millions of people. In my previous job, there was only one co-worker who could mentor me. My current job has wonderful, genius people who love learning and teaching. This job has helped me learn more about my field and my interests, so I didn’t feel the need to write blog posts because my job was already feeding my desire to learn.

In these almost three years, I built two apps on my own to improve myself. Software development is not only about writing blog posts; I needed more coding experience. During this time, I also gave three talks at the Devnot Mobile Conference in Istanbul, Turkey.

Writing was like a comfort zone for me. I tried new zones, new experiences, faced public speaking anxiety, started new hobbies, and returned to old hobbies. And… here I am. I feel like I’ve learned a lot during these three years. I can’t wait to share everything, one by one. I needed to experience more to write more. Here I am.

I can’t wait to share some technical insights and my experiences, like the mistakes I made when I released my first app. Please subscribe to my mailing list to get notified when I post. Don’t worry, I won’t spam you! Until next time, take care! 🙋🏻‍♀️

UI development

• ContentView is the root view in the hierarchy.

• There can be a maximum of 10 views inside a VStack.

• The default layout priority is 0. The higher the number, the higher the priority to have enough space to not be truncated.

• You can add layers on top (.overlay()), behind (.background())

• All the modifiers (such as padding, background...) create new layers in the view tree, their sequence often matters. Calling .padding().background(..) is different than calling .background(..).padding().

• In view builders, you can only write a very limited subset of Swift. For example, you cannot write loops, guards, or if let's. However, you can write simple Bool if statements.

• When we are talking about views, we are talking about values conforming to the View protocol.

• Calling APIs like .frame and .offset does not modify the properties of the view but rather wraps the view in a modifier.

• Stop using UIScreen.main.bounds. Be open to using GeometryReader. GeometryReader is a container view to inspect and use properties that can help with positioning other views within it. We can access properties like height, width and safe area insets.

• If we would like to update what's onscreen, we can't update it directly. Instead, we have to modify properties that marked with the following attributes @State, @ObservedObject or @EnvironmentObject and let SwiftUI figure out how the view tree has changed.

• Changing state properties is the only way to trigger a view update in SwiftUI.

• SwiftUI views are values, not objects. They are immutable, transient descriptions of what should be onscreen.

• A binding is essentially a getter and a setter for a captured variable. SwiftUI's property wrappers have a corresponding binding that you can access by using the $ prefix.

• In property wrapper terminology, the binding is called a projected value.

• All the property wrappers SwiftUI uses for triggering view updates conform to the DynamicProperty protocol.

Performance related

• VStack loads all child views when displayed. When we use LazyVStack, SwiftUI will not load them unless it needs to show them on the screen. Using LazyVStack increases performance. We are also able to pin a section header and footer. (VStack doesn't allow this.)

• AnyView can contain completely arbitrary view trees with no requirement that their type be statically fixed at compile time. While this gives us a lot of freedom, AnyView should be something we only use as a last resort. This is because using AnyView takes away essential static-type information about the view tree that otherwise helps SwiftUI perform efficient updates.

• We can best make use of SwiftUI’s smart view tree updates when we place state properties as locally as possible. Conversely, it’s the worst possible option to represent all model states with one state property on the root view and pass all data down the view tree in the form of simple parameters, as this will cause many more views to be needlessly reconstructed.

• The State type also enables dependency tracking. When a view’s body accesses the wrappedValue of a State variable, a dependency is added between that view and the State variable. This means SwiftUI knows which views to update when the wrappedValue changes.

Testing

• You can add different devices to previews to see various devices by writing .previewDevice("iPad Pro (9.7 inch)")

• You can add different orientations to previews by writing

  .previewInterfaceOrientation(.landscapeLeft)

• The List component uses UITableView in iOS 15, and UICollectionView in iOS 16. If you are using List, there might be bugs about this difference.

• Make sure you test on different iOS versions because most probably there will be unexpected bugs.

• Testing on a physical device is always worth it.

Programming mentality in general

• If you see something new and don't understand why it's used in your codebase, research about it.

Some notes are based on my experiences, some of them are taken from Thinking in SwiftUI book and SwiftUI Views Mastery book. Hope you enjoyed this article, looking forward to publish part 2. Happy coding!

While my insights might be iOS development specific, if you are a mobile developer or front-end developer, I believe you'll find them relatable at many points.

Identify the problem first.

A clear understanding of the problem is essential for developing an effective solution. To gain this understanding, it is necessary to conduct a thorough analysis of the problem. During the analysis process, it is important to ask questions to gain a deeper understanding of the problem.

For example, if the problem is related to a user interface, it is necessary to determine whether the issue is a bug or a data-related issue. Additionally, it is important to determine if the problem is limited to one specific type of device or if it occurs on other types of devices as well. Furthermore, it should be considered to identify the operating system version in which the problem occurs, as this information can provide valuable insights into the cause of the problem. By asking the right questions, we can gain a clear understanding of the problem.

Some questions that I frequently think about when I encounter a UI bug are the following.

• Does this problem occur on every device (every model of iPhone)?

• Does this problem occur on every iOS version?

• Does this problem occur in the simulator?

• Does this problem occur on physical devices?

• Do other components of the UI match the design?

• Could it be related to the dark theme or the light theme?

• Could it be related to the system settings?

In addition to code review or testing on different devices, I use two tools to find the problem and the solution. One of them is a Figma plugin that I developed, and the other one is Visual Debugger on Xcode, which we will talk about later on.

To measure the size of components, paddings, and other details, I use Screenshot Resizer. It is not directly a tool to measure components. I take a screenshot of the simulator or physical device, add it to a Figma canvas, run the plugin, create a new frame on that canvas, and place it where I want to measure. I wrote an article that covers the story behind that plugin and how to use it.

Before we start to Xcode's capabilities for debugging, I would like to share a recent UI-related debug story that I won't forget.

Recently, while developing a screen, I encountered UI bugs. The issue involved distortion on the physical device, but when I tested the screen on the iPhone 14 simulator, everything was properly displayed in the correct place and size. However, when I checked the physical iPhone 14 device, I noticed excessive padding and truncated text that made it difficult to understand. Since the project is confidential, I was not able to share the UI with the developer community and get opinions about the problem from them. I investigated the issue, trying to determine the cause, but the problem was not limited to a single component. Instead, it was occurring in multiple components, and I attempted to identify a pattern or common component that may be contributing to the issue. After spending many hours investigating, checking iOS versions, and testing other iPhone models, I finally found the problem. The font size on my device was set larger than the default one in system settings, which distorted the UI. After discovering this, I felt a great sense of relief. 🤗 This was a valuable lesson for me, as it taught me that not every issue is caused by code; sometimes it can be an accessibility issue by not making the components dynamic size to the system settings.

Debugging on Xcode

In two previous articles, we covered the Screenshot Resizer Figma plugin, which makes it easy to measure component size and paddings easily. Another way to debug for UI issues is to check View Hierarchy on Xcode. When you run the app and then click View Hierarchy, it takes a snapshot of the current screen and lets you inspect the layers. This allows you to see whether a component is rendered or not, which layer is on top, the frame size of a component, and more. Sounds interesting? If you'd like to learn more about Visual Debugger on Xcode, Sean Allen's following video is really helpful.

Working at a startup for over 2 years gave me some nice development skills and helped me to become a product-minded developer. Now, as I change my job and work in an enterprise company, being a member of an iOS team with talented people has brought me new skills and new perspectives. During our pair programming sessions, I realize that they debug on Xcode effectively. I used to be the type of person who added print statements inside functions to see if they worked. Now, I use breakpoints more than ever. I have added two helpful videos to learn more about debugging tricks on Xcode. I believe that learning the IDE's capabilities and features better helps us to code more effectively.

Friendly reminder: If these don't work for you, and you are stuck at some point, it is okay to ask for help 💙

I would like to finish my article with a quote by Nicholas Negroponte: "Programming allows you to think about thinking, and while debugging you learn learning." We all need to improve our debugging skills for greater productivity. I hope you enjoyed this article and the resources that I recommend. If you have any feedback, do not hesitate to write me via hi@iremkaraoglu.com. If you would like to be notified when I publish new articles, please subscribe to my newsletter. Until next time, take care! 🍀

Creating engaging apps is what I do every day. It could be challenging to include amusing components while developing an app. Whenever I manage a complicated design, I use UIBezierPath as a solution. You don't need to worry if you are unsure of what it is. In this article, you will find the answer to UIBezierPath.

To fully describe it for this blog, I made a simple demo application. I won't go through each line step by step. I'll try to give you the idea, but feel free to look through my source code and use this demo program however you like.

This is how the demo application looks:

To result in the same application, what you need to do is

• create separate UILabels

• create a ball as UIView

• create a path for the ball to travel through

• assign animation durations to the spots the ball will bounce on.

I start by including dummy labels like "Lorem Ipsum Dolor Sit Amet." Every word in the sentence is actually a UILabel, and I provide a certain distance between each one. I won't go into these because I want to concentrate on the bounce effect, but you may check the source code as described above.

Then, let's create a ball as a UIView since it will be crucial to our efforts. We will bounce this ball by building a UIBezierPath because it needs a path to travel through; however, we will get to that part of the discussion later.

    func addDot() {
        let ball = UIView()
        ball.layer.cornerRadius = dotSize/2
        ball.backgroundColor = UIColor(red: 242/255, green: 141/255, blue: 10/255, alpha: 1)
        ball.translatesAutoresizingMaskIntoConstraints = false
        view.addSubview(ball)
        self.dot = ball

        NSLayoutConstraint.activate([
            ball.widthAnchor.constraint(equalToConstant: dotSize),
            ball.heightAnchor.constraint(equalToConstant: dotSize),
            ball.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: initialPoint.x),
            ball.topAnchor.constraint(equalTo: view.topAnchor, constant: initialPoint.y),
        ])
    }

The ball on the screen is made with the code snippet below. Let's go on to the section where the ball should land. I want the ball to bounce at each of the label's middle places in this demo application.

We must calculate the points where the ball bounces in order to understand them. The UILabel's width is returned by the next function, which retrieves a UILabel.

   func findWidthOfEachLabel(label: UILabel) -> CGFloat {
       // returns the width of a given UILabel
       let width = label.text?.size(withAttributes:[.font: label.font as Any]).width ?? 30
       return width
   }

The path must now be drawn. The ball must traverse curves. As a result, we make curves like this:

We use UIBezierPath in order to produce this curve graphic. UIBezierPath is a class by UIKit and Apple’s developer docs put it this way: “UIBezierPath is a path that consists of straight and curved line segments that you can render in your custom views.” We can draw vectors thanks to it. In the below code snippet, we check the labels which we created and we have a starting point for labels. Then, we move the path to the point where we start the path. Since I preferred to observe the ball arrive at the first label—in our case, "Lorem"—from the outside, I made the decision to begin this path before the label.

      func createBezierPath() -> UIBezierPath? {
        guard !labelWidths.isEmpty else { return nil }

        let path = UIBezierPath()
        var point = initialPoint
        point.x = initialPoint.x + labelWidths[0]/2 - 10
        var previousLabelWidth = 10.0
        var deltaX = 0.0

        for index in 0..<labels.count {
            deltaX = (previousLabelWidth  + (space*2) + labelWidths[index])/2

            if index == 0 {
                path.move(to: point)
            }

            let controlPoint1 = CGPoint(x: point.x + deltaX/2,
                                        y: point.y - dotYvalue)
            let controlPoint2 = CGPoint(x: point.x + deltaX/2,
                                        y: point.y - dotYvalue)
            let destination = CGPoint(x: point.x + deltaX,
                                      y: point.y)
            point = destination
            points.append(destination)
            path.addCurve(to: destination, controlPoint1: controlPoint1, controlPoint2: controlPoint2)
            previousLabelWidth = labelWidths[index]
            durations.append(0.3)
        }
        // last bounce
        let controlPoint1 = CGPoint(x:  point.x + lastBounceX/2,
                                    y: point.y - dotYvalue)
        let controlPoint2 = CGPoint(x:  point.x + lastBounceX/2,
                                    y: point.y - dotYvalue)
        let destination = CGPoint(x:  point.x + lastBounceX,
                                  y: point.y)
        point = destination
        points.append(destination)
        path.addCurve(to: destination, controlPoint1: controlPoint1, controlPoint2: controlPoint2)
        durations.append(0.3)

        return path

    }

Now, the path is available but not the animation. We first establish the aforementioned path in order to witness the animation. We construct CAKeyframeAnimation, which is yet another UIKit class that is described as "An object that provides keyframe animation capabilities for a layer object" in the Apple documentation. Our UIBezierPath object's cgPath is passed to the animation's path attribute, and keyTimes is assigned to help determine how long each curve animation will last.

func startDotAnimation() {

        let path = createBezierPath()

        let animation = CAKeyframeAnimation(keyPath: "position")
        animation.path = path?.cgPath

        animation.duration = durations.reduce(0, { partialResult, v in
            partialResult + v
        })

        var cd = 0.0

        let times: [NSNumber] = durations.enumerated().compactMap({ index, duration in
            cd = cd + duration
            let xd = cd - duration*0.5
            return index + 1 == durations.count ? 1.0 : xd / animation.duration as NSNumber
        })

        animation.keyTimes = [0.0] + times
        self.dot?.layer.add(animation, forKey: "bezier")
        self.dot?.alpha = 1
        self.dot?.center = self.points.last!

    }

For each label, I specified values of 0.3 seconds when I wrote the UIBezierPath. You are able to alter it as you work on it. Also, if you would like to see the path you created during your implementation, you may use the following function.

func showPath(_ path: UIBezierPath) {
        let shapeLayer = CAShapeLayer()
        shapeLayer.path = path.cgPath
        shapeLayer.fillColor = UIColor(red: 222/255, green: 120/255, blue: 180/255, alpha: 0.3).cgColor
        shapeLayer.strokeColor = UIColor(red: 222/255, green: 120/255, blue: 180/255, alpha: 0.9).cgColor
        shapeLayer.lineWidth = 3.0
        view.layer.addSublayer(shapeLayer)
    }

This function adds a CAShapeLayer to your screen and shows the path we created. You may call this function inside the startDotAnimation function since we create the path there.

During this article, I tried to give you the general idea of achieving the bounce effect. I hope this article helps you to learn about the animations and the UIBezierPath. You may work on this demo app's source code. Thank you for reading, if you have any feedback you may reach me at the comments below or via hi@iremkaraoglu.com. If you like this article, please add some reaction 🦄 Thank you, see you in the next article!

Before we start, you may access the plugin that I built - called Screenshot Resizer - from here and the demo video is here. In this article, I am going to share the story of that product, the process of building it in TypeScript, and the useful resources that I have used throughout this journey.

Background Story

As a mobile developer, I use design tools a lot to get the design from the design team in our company. I got a request from one of my designer co-workers, Ersin Kıymaz, about developing a Sketch plugin when using Sketch in our company. To be honest, I procrastinated it. Then, after a year, we switched to using Figma in our company instead of Sketch and he again requested a plugin from me for Figma.

Identifying the problem

During his design process, he often takes screenshots from the mobile applications on his phone and imports them into Figma. He checks for the widths, heights, margins, paddings, and so on. The problem here is when you add a screenshot to Figma, it seems a lot bigger because it imports according to the device’s physical width and height. Let’s dive in to understand clearly.

There are two concepts here, point and pixel. A point consists of pixels. If a point has more pixels, the screen looks sharper. The below image gives an example of some devices. iPhone 6 Plus looks sharper than iPhone 6 because it has more pixels.

Source: https://www.linkedin.com/pulse/difference-between-point-pixel-charanjeet-singh/

For instance, let’s say we have iPhone 13 Pro Max. This device’s screen has 1284 points in width and 2778 points in height. If you create a prototype on Figma for iPhone 13 Pro Max, it’s going to be 428 x 926 because it is a logical size. There is a scale factor of 3. So, each one of the 428 points has 3 pixels. Therefore, the physical size is the logical size’s multiplication by 3. The scale factor changes according to the device and it’s hard to remember this for all of the iOS devices. You may check online the device’s scale factor and update the frame’s size on Figma, yes that’s an option but we wanted to make it automated and a basic thing as a first product.

Use case

As a mobile developer, I use this plugin in order to see if I developed the app’s UI correctly. My designer friend, Ersin, also checks the app to give feedback to the development team. In addition to them, Ersin also takes screenshots from other applications, imports them to Figma, and observes the size of the components, margins, and paddings.

Finding the Solution

The solution was clear actually. We have the screenshots. We know devices’ physical size, scale factors, and logical size. We thought there should be something to convert the screenshot’s frame size ( physical size in this case) to the logical size.

We planned to save all of the iOS devices’ physical sizes in our plugin’s codebase and when a screenshot is selected on Figma, run the plugin, and resize the screenshot to the logical size by diving by the scale factor.

Let’s start building a Figma Plugin

My favorite two resources during this journey were:

• A video on Youtube
• Documentation of Figma’s Plugin API
• Apple Devices’ Resolution list

If you haven’t already installed VSCode, Node.js, TypeScript, and Figma Desktop applications, I recommend you install them before you start developing. For this, you can follow Figma Plugin’s Setup Guide.

Get Know - How

Before diving into the development of my product, I watched the Beforementioned tutorial and followed the steps in the tutorial. I learned how to develop a Figma plugin with that tutorial and while I was watching that, I was already thinking and planning about how I would develop my product.

Implementation

I first understood the Figma API during the example projects. During the implementation, I was communicating with my product partner Ersin about this product. I shared what I learned with him and we discussed whether the plugin should have a UI or not. He suggested not having a user interface.

Then, I checked if I am able to get the frame’s size and yes, I am able to. So, I started with getting the frame’s size information and then save all of the device sizes which I get help from iOS Resolution I also, saved the information for the device model and the scale factor. The reason for saving the device information is just to note down which devices this plugin is going to support and see the same size devices clearly on the codebase. Therefore, in a few weeks people will be able to see if we support the new iPhone 14 - Hopefully, iPhone 14 will be released on September 7, 2022. The reason for saving the scale factor is, that we planned to divide the frame size by the scale factor to reach the logical size. Then, I implemented the way we were thinking. Developing a Figma Plugin requires knowledge of TypeScript. Since I know TypeScript I didn't get help from any resource at this point.Finally, it is done. We started it with iOS devices because Android has various devices of different sizes. We made the plugin open source by releasing the source code, so it is open to contribution. You may reach the source code from here.

So, let’s watch the demo video and make it more visual.

Here, I took the screenshots from Xcode’s simulator and I created the same device’s prototype frames on Figma. I import the screenshots and they are bigger than they should be. So, I run the plugin and the size automatically changes according to the scale factor. I use this plugin to see if I met the design correctly. I take a screenshot from the app that I am developing and check it with the design. It made my job easier because now they have the same sizes.

Source: Photo by Sigmund on Unsplash

Since my childhood, I have always loved creating things. I created this plugin in a day and in the following days just did some tiny improvements but it’s created in a day. I was feeling accomplished when I went to bed. I was also regretting why I procrastinated in the first place. So, If you would like to build something but procrastinate, start today. It is such a good feeling that I created the product that I use almost daily in my work and it is nice to see other people use it as well. I hope you liked this article, if you have any feedback about the plugin or this article, meet me in the comments below. If you enjoy my articles, please react or subscribe to my newsletter. Thanks for reading, happy coding! 👩🏻‍💻

Writing

An illustration by me 😊

The thoughts in our heads become clear when we write them down. Personally, when I am doing some calculation or figuring out a problem in an algorithm, I like using pen and paper while focusing on the problem, and writing everything down one by one. Also, a good alternative is to use a digital tablet for the same purpose - I like using Apple Notes or GoodNotes on the iPad. Another option might be using a whiteboard. It is also a convenient way to write and draw something since it has a larger area.

Photo by ThisisEngineering RAEng on Unsplash

StackOverflow

Stack Overflow is a question-and-answer website. If you're a developer, most probably you know that but I didn't want to take it for granted. StackOverflow is full of people that are having problems and giving solutions. If we search our problem/error clearly, we are more likely to find our answer.

For writing a better search query in StackOverflow, you may check here

It's okay if we couldn't find the similar or the same problem as ours on StackOverflow, we are able to ask about our own problems in public. You may check a resource to how to write well our questions in here

Friends

Photo by Mimi Thian on Unsplash

Another way to find a solution is basically to get help from our friends/coworkers. We can ask them to spare some time with us to debug our code or ask if they have ever experienced the same problem. It is a nice way to speak about the problem and solve it, also it bonds us and supports our communication. If we are in the same place with that person, I like to do pair programming. If we are in different places, having a call and screen sharing is also a good option. Also, we may consider asking our mentors/supervisors in the company as well.

Rubber duck debugging

Generally, developers solve problems more easily when they speak about the problem out loud. It is a good method to talk about the problem and solve it. It is common and it's actually called Rubber duck debugging in The Pragmatic Programmer book. It is about talking to a rubber duck to solve the encountered problem while skimming through the code line-by-line. Talking through the process helps us to slow down and see our code's wider picture, which makes it simpler to identify issues because we speak more slowly than we think.

Discord servers

An illustration by me 😊

Discord is a platform for voice, text, and video chatting which is also suitable for communities. There are many discord servers for developers. I believe you may find some servers related to your domain. Me, as a mobile developer and more specifically an iOS developer, I am a member of various mobile development Discord servers both in Turkish and English. There are some channels for people to ask questions there. I sometimes ask questions on these active discord channels.

For example; one day, I had a problem with SpriteKit (SpriteKit is a 2D game development framework by Apple and there is not a big community for it). I wrote my question on one of the iOS development servers and I hoped someone would give me an answer. Luckily, I found someone that is interested in SpriteKit as well, he helped me to solve my problem. Also, I try to help people as well when I have free time. This is actually how the community grows.

I would love to share the iOS development discord server's link here but it was a server from students of a Udemy Course and the discord invitation is disabled. However, I may share another Discord server for iOS developers: https://discord.gg/69xeSDCf9y

For your particular domain, you can google relevant discord servers.

Twitter Communities

After the release of the Twitter Communities feature, people started to have their own communities. I am a member of some mobile developer communities both in Turkish or English like Discord. Similarly, I am able to ask any question, answer someone's question or read someone's problem and answer. I am an active user of Twitter and I always check it during the day. I rarely ask questions but when I do, I get answers immediately. It is such a relief that there is someone on this planet, who knows the answer to my problem and chooses to help me with it.

Unfortunately, because it's on Twitter, it doesn't allow a good service for sharing videos, having calls with people, or sharing the screen. I like using Twitter Communities because it's the platform that I use every day and I think people are more active on Twitter. It is important to choose the platform according to your needs. For example, if you would like to share a screen recording, Twitter may not be the best place for that. Because of the fact that Twitter compresses the videos you upload to reduce their bandwidth. Hence, making the uploaded video of your screen record really low-resolution one. That was one of the mistakes that I made back in the time. However, I still like to use Twitter Communities.

My favorite iOS developer community on Twitter is this

My favorite React Native developer community on Twitter is this

Telegram Groups

Telegram is again a chat application and another option for the communities. I am a member of some of them. Similarly, people ask their question and get answers from the members of the group. My favorite one is for iOS development and it's in Turkish. If you are interested you may join here

Similar projects on GitHub

GitHub is an online software development platform used for storing, tracking, and collaborating on software projects. If you are building something new, you can find similar projects to be inspired and learn from them. You can find answers to questions like: How do they make the structure? Which version of any third-party library do they use? Again, you need to search clearly to find these projects. To be honest, it is not an option that I choose every single day but I sometimes use this tip.

Take a break and go for a walk

An illustration by me 😊

Up until here, we generally considered getting help from other people. This one doesn't require any people. It is a good practice to take a break when we are stuck on solving a problem. Go for a walk, go grab some coffee, or talk with your loved ones. That's what I try to do. Sometimes, I got stuck at some points and time passes without noticing it. It is nice to have a break and move my body. I recommend it to you as well. Just spend some time without looking at your screen, come back to the screen with a fresh mind, and try to solve your problem again. It is scientifically proven that walking improves creativity. For reference, I am attaching an article here

Photo by Tai Bui on Unsplash

To conclude, there are various ways to solve our problems when we are stuck at some point. Today, we have covered rubber duck debugging, walking, writing, StackOverflow, Discord, Github, Twitter, and Telegram. Choosing the best one depends on the situation. Each one of them has pros and cons. We don't have to choose only one of the options beforementioned. We can keep trying new ones till we succeed. I hope these tips are helpful for you and you solve your problems easier than before. If you have another tip, please share it with me and other readers in the comments section below. Happy coding! 🐝

By applying and having interviews;

• You become more comfortable in each interview because you are getting used to having interviews.
• You get to know this position and the company better and your opinion about looking for a job may change for the positive.
• You learn what the companies ask for and what they evaluate.
• You may learn the salary range in different companies.
• You get to know people and in the future, they can reach out to you.
• You are given tasks and you learn something by doing them.
• If you are lucky, even if it ends up with failure they give you feedback.

Today, I would like to share with you the most valuable feedback that I have received from an unsuccessful interview. A few years ago, I applied for a position in a company and they assigned me a task. Even though I couldn't finish the whole task due to it being too hard for me, I still submitted the project and had a technical interview with the CTO and the Tech Lead of that company. Two days later, I received an e-mail from the CTO and it was a reject e-mail but with more feedback than I expected.

First of all, he said that the project that I sent was insufficient - I was expecting to hear that because I couldn't finish it 🤷‍♀️ I thought that I would still get some points for trying to come up with a solution even if I couldn't finish it completely, just like in college but as far as I experienced, things don't work that way with companies. They mostly care if you managed to complete it or not. Also, he pointed out some really good points to be improved upon. Let's go over each one of them.

Improve yourself outside of work.

He said, "Improve yourself outside of work because the difference between good developers and great ones is the ones who improve themselves outside of the work, create personal projects, etc." It is a very nice saying and I loved it. After that, I became more motivated to create my personal projects and I wrote blog posts about them.

Keep up-to-date with the trending libraries and technologies.

I wasn't following the trends and what is new. I was hearing some stuff but I wasn't actually following and reading in-depth. I am better at following what's new now but I can't say I am 100% up to date with new technologies. I can still improve this point.

Read and contribute to open-source projects.

Just like this one, I received another piece of advice from someone "read others' code as much as you can and see what they are coding" I am now reading more of it, contributing to open-source with my blog posts and public repositories but haven't contributed to any third party library's repository yet but I think it's something and I am better than how I was.

Read the documentation and create personal projects.

He said "Read the documentation and create personal projects with React-Native, React, Unit-Testing, JavaScript" Back when he gave that advice, I was a React Native Developer, however, I decided to make a change in my career path and chose to follow the path of iOS development with Swift. So, I am not following that piece of advice on those technologies but I am trying to read the Apple documentation and developing personal projects in Swift.

Understand why a piece of code is in the codebase.

He said "Understand why a piece of code is in the codebase. Go deep into the logic and structure." This is still a point for me to improve on. I just focus on my task to do on a project. I don't investigate the codebase and understand why that code block is there, what's the purpose of that function etc. Also, unfortunately, when I'm stuck at some point I copy-paste the solution from StackOverflow but don't think about why that code block is the answer, just focus on solving it and don't think about "how". So, this is another point that I still should improve for myself.

To conclude, applying for companies is OK. Being rejected is OK. You learn some stuff and get experiences during these interviews. This was my unforgettable failed interview with valuable feedback and I am glad that someone told me these things. By writing this article, It was also a nice feeling that I am not the same person as I was. I have improved and I will continue to. I hope these pieces of advice help you in your career as well. Hope to see you in the next article, take care!

The SwiftUI framework supports declarative programming, meaning it requires less code. In addition, it easily manages themes, offers a live preview, uses Canvas instead of Interface Builder, and is less prone to crashing.

So, SwiftUI vs. UIKit — is one better than the other? Well, despite its many advantages, companies have been slow to adopt the use of SwiftUI in their iOS apps. Some organizations are willing to try SwiftUI for a new project, but many are hesitant to migrate existing UIKit projects to this framework.

SwiftUI requires iOS 13 or later, so it’s not compatible with apps developed using an older iOS version. Also, transferring large apps to a different framework is time consuming and could hamper developer bandwidth.

This tutorial will demonstrate how to add a SwiftUI screen to a UIKit project. This SwiftUI UIKit integration solution can provide the experience of using SwiftUI without creating a new app from scratch. Adding SwiftUI to an existing UIKit project will also make it easier for us to migrate the app to SwiftUI in the future.

Final project: UIKit app with SwiftUI screen

Here’s the final version of the app that we’ll build in this tutorial:

We’ll create a SwiftUI screen within a UIKit app, and then add functionality to allow navigation between the SwiftUI screen and the UIKit screen.

Creating the iOS project with Storyboard interface

Let’s start by creating the UIKit project.

First, we’ll select App from the iOS tab:

Then, we’ll select Storyboard from the Interface dropdown:

For this tutorial, I‘ll remove Storyboard and will build the app’s UI programmatically. Here’s an article that you may find helpful for learning more about creating an iOS app’s UI with Storyboard vs. programmatically.

Check this GitHub commit to get the changes necessary to remove Storyboard from your sample project and specify the navigation controller as a root view controller.

Creating the SwiftUI screen

Now, let’s create a SwiftUI View file.

Create a new file in SwiftUI. Select iOS for the platform and SwiftUI View for the user interface:

Next, give the file a name, and click Create:

Now, you should see the default SwiftUI View file with text “Hello, World!”

Next, let’s add a simple UI design consisting of some text and a button:

struct SwiftUIView: View {
    var body: some View {
        VStack {
            HStack {
                Text("SwiftUI Screen")
                    .bold()
                    .font(.system(size: 21.0))
            }
            Spacer()
                .frame(width: 1, height: 74, alignment: .bottom)
            VStack(alignment: .center){
                Button(action: {
                }) {
                    Text("Navigate to UIKit Screen")
                        .font(.system(size: 21.0))
                        .bold()
                        .frame(width: UIScreen.main.bounds.width, height: 10, alignment: .center)
                }
            }
            Spacer()
                .frame(width: 2, height: 105, alignment: .bottom)
        }.navigationBarHidden(true)
    }
}

After updating the SwiftUI screen, we can see the live preview on the canvas. Our new SwiftUI screen has a label, SwiftUI Screen, and a button to navigate to the UIKit screen.

Creating the UIKit view

Now, let’s work with the UIKit’s ViewController to create a basic user interface. It will include a label with text “UIKit screen” and a button to navigate to the SwiftUI screen.

override func viewDidLoad() {
        super.viewDidLoad()

        view.backgroundColor = .white

        let label = UILabel()
        label.text = "UIKit Screen"
        label.textColor = .black
        label.translatesAutoresizingMaskIntoConstraints = false
        label.font = .boldSystemFont(ofSize: 21)
        view.addSubview(label)

        let button = UIButton()
        button.setTitleColor(.blue, for: .normal)
        button.setTitle("Navigate to SwiftUI Screen", for: .normal)
        button.titleLabel?.textAlignment = .center
        button.translatesAutoresizingMaskIntoConstraints = false
        button.addTarget(self, action: #selector(openSwiftUIScreen), for: .touchUpInside)
        button.titleLabel?.font = .boldSystemFont(ofSize: 21)
        view.addSubview(button)

        NSLayoutConstraint.activate(\[
            button.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            label.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            button.centerYAnchor.constraint(equalTo: view.centerYAnchor),
            button.topAnchor.constraint(equalTo: label.bottomAnchor, constant: 64)\])
    }

Displaying the SwiftUI screen

We need a way to present our SwiftUI screen. Right now, our application opens with the UIKit screen but doesn’t navigate to the SwiftUI screen.

To set up the functionality to navigate between the UIKit screen and the SwiftUI screen, we’ll use the UIKit’s UIHostingController class. The UIHostingController is a UIKit view controller that manages a SwiftUI view hierarchy.

To create UIHostingController, ensure that you import SwiftUI at the top of the code module.

Now, let’s open the ViewController.swift file and create a function to navigate to the SwiftUI screen:

@objc func openSwiftUIScreen() {
        let swiftUIViewController = UIHostingController(rootView: SwiftUIView())
        self.navigationController?.pushViewController(swiftUIViewController, animated: true)
    }

Inside this function, we create a UIHostingController by passing our SwiftUI screen as a root view and also passing the main navigation controller to that. UIHostingController is a UIKit view controller and we push that view controller to our navigation controller.

Next, we need to add a target for our button to fire the openSwiftUIScreen function:

button.addTarget(self, action: #selector(openSwiftUIScreen), for: .touchUpInside)

Now, we can navigate from the UIKit screen like in the demo below. Notice that we’re not able to go back from the SwiftUI screen. This is because we didn’t give any action to our button.

To go back from the SwiftUI screen, we need to add a UINavigationController and pass our root navigation controller to the SwiftUI screen.

We pushed to the SwiftUI screen before using the UIHostingController. Now, we will use the UINavigationController to pop back to the UIKit screen.

struct SwiftUIView: View {

    weak var navigationController: UINavigationController?

    var body: some View {
        VStack {
            HStack {
                Text("SwiftUI Screen")
                    .bold()
                    .font(.system(size: 21.0))
            }
            Spacer()
                .frame(width: 1, height: 74, alignment: .bottom)
            VStack(alignment: .center){
                Button(action: {
                    navigationController?.popViewController(animated: true)
                }) {
                    Text("Navigate to UIKit Screen")
                        .font(.system(size: 21.0))
                        .bold()
                        .frame(width: UIScreen.main.bounds.width, height: 10, alignment: .center)
                }
            }
            Spacer()
                .frame(width: 2, height: 105, alignment: .bottom)
        }.navigationBarHidden(true)
    }
}

Next, let’s update our function in ViewController:

@objc func openSwiftUIScreen() {
        let swiftUIViewController = UIHostingController(rootView: SwiftUIView(navigationController: self.navigationController))
        self.navigationController?.pushViewController(swiftUIViewController, animated: true)
    }

With this update, we’re able to navigate from the UIKit screen to the SwiftUI screen and then back to the UIKit screen.

Here’s the final version of our application:

Conclusion

In this article, we demonstrated how to integrate SwiftUI into a UIKit project. The 2021 iOS Developer Community Survey indicated high levels of interest in SwiftUI. Given SwiftUI’s growing popularity among developers but slow adoption rate for organizations, it’s important to understand that it’s possible to use both SwiftUI and UIKit in a single application.

I hope you enjoyed this article. You can share your valuable feedback or questions in the comments section or via hi@iremkaraoglu.com. See you in the next article! Take care!

The post How to add SwiftUI to a UIKit project appeared first on LogRocket Blog.

In this article, we’ll review how to handle JSON data easily in Swift with SwiftyJSON. We’ll use a demo project with a macOS command line interface to walk through the tutorial.

For the examples used in this article, we’ll use Swift v5, Xcode v13.2.1, and SwiftyJSON v5.0.1.

Let’s get started!

Creating a macOS CLI

Since a user interface is not important for this project, we’ll create and use a macOS command line tool. To create a CLI for macOS, open Xcode and click on Create a new Xcode project. Next, under macOS, select Command Line Tool, then click Next, and follow the remaining instructions.

Setting up the demo project

I like Pokémon, so I’ve decided to use it as the project’s topic. In this project, we’ll use the RESTful Pokemon API. We’ll request data for the character, Charmander, by fetching this JSON: https://pokeapi.co/api/v2/pokemon/charmander.

This article will focus on handling JSON, so we’ll skip over the process of requesting the JSON data.

For this demo, I’ve used the macOS URLSession to handle the HTTP requests, but you may also use Alamofire or Moya. In addition, you can always access the code in my GitHub repository. After we get the data, we’ll request some of Charmander’s attributes (for example, name, abilities, and type) and then we’ll display them in the terminal output.

The terminal output will look like this:

Let’s get started.

Photo by Akin Cakiner on Unsplash.

Adding SwiftyJSON to the demo project

To use a third-party library, we need to import that package in our project. Therefore, our first step is to add the SwiftyJSON package to our project; we’ll use the Swift Package Manager.

Here’s our path: Xcode > ( Xcode project name) > Targets > (Xcode project name).

In the General tab, under the Frameworks and Libraries dropdown, we click on + and select Add package dependency. Then, we enter the package Git URL: https://github.com/SwiftyJSON/SwiftyJSON.git.

After the package is successfully added, we’ll see SwiftyJSON listed under Framework, as well as under Package Dependencies in the Project Navigator:

Using SwiftyJSON to parse JSON in Swift

Now, we’re ready to write some code. To start, we’ll use a snippet from our JSON data:

"name": "charmander",
"order": 5,
"past\_types": \[\],
...

We’ll create a JSON object that includes the name attribute of the data. Then, we’ll create a function to get the name attribute so that we can access it:

func getName(data: Data) {
    if let json = try? JSON(data: data) {
        let name = json\["name"\].string ?? "N/A"
        print("Name: \\(name)")
    }
}

When we call the getName function, we get the following output:

Name: **charmander**

Now, let’s work with the nested JSON from our Charmander HTTP request:

"abilities": \[
    {
      "ability": {
        "name": "blaze",
        "url": "<https://pokeapi.co/api/v2/ability/66/>"
      },
      "is\_hidden": false,
      "slot": 1
    },
    {
      "ability": {
        "name": "solar-power",
        "url": "<https://pokeapi.co/api/v2/ability/94/>"
      },
      "is\_hidden": true,
      "slot": 3
    }
  \], 
{...}

We’ll create a function to get the abilities attribute from the Charmander data. Previously, we created a JSON object, but now we have an array of objects. We’ll need to trace through the abilities array and get the name attribute of each ability.

func getAbilities(data: Data) {
    if let json = try? JSON(data: data) {
        for (\_, abilities) in json\["abilities"\] {
            let ability = abilities\\\["ability"\\\]\["name"\].string ?? "N/A"
            print("Ability: \\(ability)")
        }
    }
}

When we call the getAbilities function, we get the following output:

Ability: **blaze**

Ability: **solar-power**

Similar to abilities, we also have the types attribute. Then, inside the object, we have a type object with a name attribute. We can see both attributes in the below JSON snippet:

"types": \[
    {
      "slot": 1,
      "type": {
        "name": "fire",
        "url": "https://pokeapi.co/api/v2/type/10/"
      }
    }
  \]

Now, we’ll trace through the types array and get the name attribute of each type.

func getType(data: Data) {
    if let json = try? JSON(data: data) {
        for (\_, types) in json\["types"\] {
            let type = types\\\["type"\\\]\["name"\].string ?? "N/A"
            print("Type: \\(type)")
        }
    }
}

When we call the getType function, we get the following output:

Type: **fire**

Addressing type issues in Swift

In Swift, we have to use explicit typing. The benefit of this is that we are less likely to make mistakes. The downside is that it is not very flexible.

For example, when we fetch JSON data, we create the attributes by declaring their data type. If the data type changes from the server side, we’ll be unable to parse the JSON data and the app will crash. Fortunately, SwiftyJSON helps us address this issue.

Let’s look at an example.

In the below code snippet, we specify that the data type is a string. We could also specify that it must be an integer; the point here is that the code indicates it must be of the type we are specifying.

let ability = abilities\\\["ability"\\\]\["name"\].string!

In this example, as long as the data type actually is a string, everything is fine. But if the data type changes, the value becomes nil and the app will crash.

Now, let’s look at the same example, but this time we’ll use a nil-coalescing operator to accomodate any possible changes in data type:

let ability = abilities\\\["ability"\\\]\["name"\].string ?? "N/A"

In the above snippet, we check to see if the data type is a string. If it is not a string, the value “N/A” is returned. The app does not crash. Of course, you are not limited to “N/A”, you may use any designation you like.

Conclusion

In this article, we reviewed how to handle JSON in Swift with SwiftyJSON and discussed how to handle type issues. We walked through the article examples using a demo with a macOS command line interface.

I hope you’ve enjoyed this article. Go to GitHub to check out the sample project that I made for this article. Feel free to reach out to me at hi@iremkaraoglu.com or in the below comment section. I appreciate your valuable feedback. Take care!

The post Easily handle JSON in Swift with SwiftyJSON appeared first on LogRocket Blog.

When I first started learning to create user interfaces for iOS, I wasn’t sure how to decide between using Storyboard and coding the UI programmatically. However, after much research and hands-on development experience, I’m ready to share what I’ve learned and also offer some insights and opinions.

In this article, we’ll compare the pros and cons of creating UI for iOS with Storyboard vs. programmatically. We’ll demonstrate coding the same UI using both methods, and we’ll also discuss which method is preferable for certain circumstances.

Let’s dive in!

Designing iOS UI with Storyboard

Storyboard allows us to add UI elements to the screen by simply dragging and dropping. To create a project in UIKit with Storyboard, we select Storyboard in the Xcode project Interface dropdown:

Using the Interface Builder, we add UI elements to the screen, as shown in the below video. We click on the + button, select an object, and then drag and drop it to the desired location on the screen.

Creating a sample UI with Storyboard

Let’s create a sample project called Koala-Storyboard. As shown in the below video, we’ll add a koala image and the text “Koala” in the Interface Builder:

Storyboard enables us to add objects to a UI in just seconds. We simply place the object in the desired location and it’s done. However, it’s important to understand that this method does not automatically result in a responsive design.

When we create a UI on a sample iOS device canvas and then build the app on a different device, the end result may have a slightly different appearance.

Here’s an example that illustrates this issue:

This UI was created on an iPhone 11 canvas (right image) but looks different when run on iPhone SE, 2nd generation (left image).

In order to create a UI that looks the same on all devices, we must add relationship constraints for the different UI elements and use the Interface Builder’s Auto Layout feature. Auto Layout automatically adjusts a UI’s layout to account for device screen size, as well as external changes like a user rotating a device or resizing a window.

First, we’ll add some constraints to have the same UI for different devices. We’ll resize the image and position it to the center of the screen:

Next, we’ll position the “I love koalas” text 64px below the image:

This process enables us to build the same UI for different devices such as iPhone 11, iPhone 8, and iPhone 13 Pro Max. Each device displays the image centered on the screen with text 64px below the image:

App UI built in Storyboard, using the Interface Builder’s Auto Layout feature.

Although Storyboard does not automatically generate a responsive design, it can be a very useful method for prototyping. To create a demo or prototype, we simply select the appropriate device canvas.

Merging conflicts in Storyboard

Merge conflicts are probably the most significant downside to Storyboard. Merge conflicts can occur easily, and because Storyboard is actually an XML file, it can be difficult to debug and resolve the conflict.

Let’s review a Storyboard merge conflict scenario:

Assume we have two developers: Developer A and Developer B. Both are working on a particular screen. Each developer has their own branches that are created from the main branch.

During development, the following sequence of events occurs:

1. Developer A moves the imageView (in this case, the koala image) up by a certain number of pixels
2. Developer B adds a button and moves the imageView down by a certain number of pixels
3. Developer B’s branch is merged to the main branch

After these events, Developer A’s branch is behind the main branch, and their branch’s codebase is outdated. Developer A tries to merge their branch with the main branch, but there is a merge conflict:

Merge conflict shown in VS Code.

We can see the conflict in the VS Code. The updated stream (shown in green) represents Developer B’s changes. The stashed changes (shown in blue) represent Developer A’s changes.

There are three options for attempting to resolve the conflict:

1. Accept the most recent changes (Developer A’s changes) and lose the updated stream (Developer B’s changes)
2. Accept the updated stream (Developer B’s changes) only
3. Accept all changed lines, without losing a single change

Accepting every change (option 3) may initially seem like the best option, but first, let’s take a closer look at the code.

One developer moved the imageView up, and the other moved it down. The file now consists of two imageViews (on lines 26 and 48). Since both imageViews have the same ID, we’re seeing an error when we open Xcode:

Merge conflict error in Xcode.

Merge conflicts are not uncommon in development, and they happen fairly frequently in Xcode. Xcode adds some references and IDs to the XML file. So, as a UI becomes more elaborate, the XML file becomes more complex. Even just two developers working on the same UIKit Storyboard project can face a merge conflict that will take some time and attention to resolve.

Pros and cons of using Storyboard to design UI for iOS

Here’s a summary of Storyboard’s pros and cons:

PROS

Easy option for adding UI elements to the screen (drag and drop)

Easy option for prototype creation (static UI)

Provides a visual representation of all screens on Xcode

CONS

Difficult code review (XML file)

Requires constraints for auto layout (responsiveness)

Hard to resolve merge conflicts (XML file)

Difficult for more than one developer to work on the same screen

Code is not searchable

Performance (app load time) can be impacted if Storyboard is not well organized

Does not support animations (any animations must be added programmatically)

Difficult to see the properties of UI elements

Designing iOS UI programmatically

Building UI programmatically means creating the user interface in code (Swift, to be exact), rather than using the Interface Builder.

To create a project in UIKit programmatically, we create a new Xcode project and initially select Storyboard as we did before. Xcode creates a storyboard by default and makes it the initial screen. We go to Project Navigator and remove any references to Storyboard. We also make some configuration changes to Info.plist and AppDelegate.swift to remove the Storyboard dependency. For a tutorial of these configuration changes, follow along with this video.

To build UI programmatically, we first create an instance of a UI element. Then, we code the position of the instance on the screen.

Creating a sample UI programmatically

Let’s create a sample user interface programmatically that will match the Koala-Storyboard.

We’ll use the following Swift code snippet:

let koalaView = UIImageView()
koalaView.image = UIImage(named: "koala")
koalaView.translatesAutoresizingMaskIntoConstraints = false
view.addSubview(koalaView)

NSLayoutConstraint.activate(\[
  koalaView.centerYAnchor.constraint(equalTo: view.centerYAnchor),
  koalaView.centerXAnchor.constraint(equalTo: view.centerXAnchor),
  koalaView.widthAnchor.constraint(equalToConstant: 320),
  koalaView.heightAnchor.constraint(equalToConstant: 320)
\])

First, we create an UIImageView called koalaView. We give it an image attribute, UIImage, and a file name, koala. We add this subview to the parent view.

Then, we use the NSLayoutConstraint class to position the UI element. We center the UI element in the screen by specifying that its centerYAnchor and centerXAnchor values should equal the parent’s (in this case, the screen’s) centerYAnchor and centerXAnchor values. Just as we did with Storyboard’s Interface Builder, we specify the image’s width and height to be 320px.

let koalaText = UILabel()
koalaText.text = "I love koalas ❤️"
koalaText.font = UIFont.systemFont(ofSize: 42)
koalaText.translatesAutoresizingMaskIntoConstraints = false
view.addSubview(koalaText)

NSLayoutConstraint.activate(\[
      koalaText.centerXAnchor.constraint(equalTo: view.centerXAnchor),
      koalaText.topAnchor.constraint(equalTo: koalaView.bottomAnchor, constant: 64)
\])

We create a UILabel() for the “I love koalas” text and specify a UIFont size to match that used in the Storyboard example. Next, we use the centerXAnchor.constraint to center-align the text horizontally (along the x-axis). We use the topAnchor.constraint to position the test 64px below the image’s bottomAnchor.

Here’s an example of the UI created programmatically:

Demo of the app UI built programmatically.

N.B., Apple provides theNSLayoutConstraint class for constraining the relationship between UI elements; however, some third-party libraries provide the same functionality with greater ease. One of the most popular libraries is SnapKit. To learn more about SnapKit, check out its repository on GitHub.

Pros and cons of creating UI programmatically for iOS

Here’s a summary of the pros and cons of building UI programmatically:

PROS

All UI and screen control is in one place

Code may be searched and reused

Easy code refactoring for experienced developers since the developer is in control of the UI elements

Easier to resolve merge conflicts

Easy to see the properties of UI elements

Supports adding animations

CONS

Most developers find it more time consuming to write code vs. drag and drop

No visual representation of screens until the code is run

Potentially complex refactoring, in cases of old code or code that was written by another developer

Requires constraints for auto layout (responsiveness)

Conclusion

in this article, we evaluated the pros and cons of using Storyboard to create an iOS app user interface vs. building it programmatically. We showed that each method can be advantageous, depending on the scenario. Here are the repositories for the Storyboard example and the programmatically example used in this article.

I recommend getting comfortable using Storyboard as well as designing programmatically so that you can decide which method to use on a project-by-project basis.

If you have an urge to create a static UI and are a solo developer, Storyboard is probably the best option. Storyboard is quick, and without other developers working on the project, you won’t face merge conflicts.

I hope you enjoyed this article. If you have any feedback or would like to share knowledge on this topic, feel free to reach out to me in the comments below or directly at hi@iremkaraoglu.com.

The post Storyboard vs. programmatically for iOS app UI design appeared first on LogRocket Blog.

When it comes to software products, they need to be accessible. Disabilities should not be a barrier to their usage. Products should be usable for everyone. By making your app more accessible, you can reach a larger audience and make it easier to use.

Operating systems do have accessibility features for their users, and mobile developers for iOS devices should consider getting benefits from these accessibility features. Today, I will be focusing on iOS app development for supporting accessibility.

Photo by Ben Kolde on Unsplash

In iOS devices, when you open Settings, you will see a title called Accessibility. As I mentioned before, accessibility is a general concept, so there are many options to help people use the applications in their best use case.

What we can do to support accessibility in an iOS application are research the iOS capabilities and features, and how we can use these features in our apps. Today I will provide a few common examples to give you an idea.

An accessibility example: Contrast

As I mentioned previously, there are some responsibilities for designers. Before we start the technical stuff, I would like to give a basic tip for supporting accessibility.

If you are developing an app on your own, focus on color contrast. To make your app easy to read and see, the background and the text colors should contrast each other. It is beneficial for everyone but especially for people with low vision and reading disorders.

Let’s see the example below. The left one has more contrast than the right one. The label and the button text are more readable, right?

This is an example of accessibility to bear in mind when creating your app, related to visual design.

Accessibility features on iOS

Now, we can go over accessibility features for iOS. I created an example iOS application and we will walk through it in each step.

This app consists of two screens. The first screen has a label, image, and a button to navigate the second screen. The second one includes labels, an animation consisting of four images in a loop, and a slider. Let’s cover this app’s accessibility features.

VoiceOver

I will mention VoiceOver a lot, so I need to talk about what it is first. VoiceOver is a screen reader on iOS and iPadOS devices. It reads the user interface of the device to help people with visual impairments, and it is also used by people who have motion sickness and when they are in a moving vehicle.

VoiceOver reads the screen as much as possible, but developers should also be sure it reads coherently. For instance, we have text on the screen and a star icon button to add the text to favorites. Probably, it will read the button as “star, button,” and developers can change the way it reads and give a label like “add to favorites, button.” It is better to check and give some attributes for VoiceOver by code to be more informative to users.

By coding with VoiceOver in mind, you can decide:

• which UI element is or is not to be read by VoiceOver
• what the text will be when it is reading that element
• what the value will be when it is reading that element (e.g., if the button is selected or not)
• what can be a hint for that element to inform the user moreisAccessibilityElement: Bool

This shows the value of whether the UI element is accessible or not. If you use a UIKit element, the value is true by default. If you create a custom UI element, you need to set this attribute to true.

accessibilityLabel: String?

This is a string that an assistive app — VoiceOver, in this case — reads for that UI element. VoiceOver reads the text of the UILabel or UIButton by default. However, you can still give the accessibilityLabel to be informative.

accessibilityValue: String?

The current value of the accessibility element is represented by a string. For instance, it can be a text value from a UILabel, a percentage from a UISlider, etc.

accessibilityHint: String?

You probably need to use this in some cases but not always. If you would like to give too much text to read in the accessibilityLabel, you may move some of them to the accessibilityHint. accessibilityHint gives the clue of what’s going to happen if they press that button or use some UI element.

Bear in mind that, generally, UIKit elements have default values to support accessibility. However, if you create a custom UIView subclass, you need to create an instance of UIAccessibilityElement. In this way, you will be able to use UIAccessibility properties.

To start my example, I didn’t need to code anything related to VoiceOver and ran my project with VoiceOver. Here is the demo:

VoiceOver: Before

I found out that it doesn’t see the image as an element and doesn’t read anything related to them. In addition to that, I also wanted to customize some values because VoiceOver was reading the default texts of the UILabels.

⁕ I added an accessibility label to my UILabel and it shows the text as Welcome. However, VoiceOver reads it as “Example Accessibility Label” because I customized it.

let pandaLabel = UILabel()
pandaLabel.text = "Welcome"
pandaLabel.accessibilityLabel = "Example Accessibility Label"

⁕ pandaImageView is what I called my image view, and I added pandaImageView.isAccessibilityElement = true to inform VoiceOver that it is accessible.

⁕ I added an accessibilityLabel to my image view and gave pandaImageView.accessibilityLabel = "Panda"

⁕ I also added accessibilityHint to the next button at the bottom, to inform the user what that button performs when it is pressed.

let nextButton = UIButton()
nextButton.setTitle("Next", for: .normal)
nextButton.accessibilityHint = "Navigates to the next screen"

So, let’s see how it is changed:

VoiceOver: After

Text size

While developing, we generally give the font-size value to meet with the design. However, it doesn’t let users change the font size according to their visual capabilities and preferences.

For this example, I first created a screen, including hardcoded font size.

let pandaLabel = UILabel()
pandaLabel.font = .boldSystemFont(ofSize: 24)

As I mentioned before, in this case, font-size does not change according to accessibility settings.

What we can do here is give a dynamic text size to the label to meet the user’s intentions.

N.B., sometimes a user’s choice can lead to inaccessible app UI. For instance, much bigger text sizes can cover the whole screen and displace a button.

Let’s see how we can give a dynamic text size to the label.

let pandaLabel = UILabel()
pandaLabel.font = UIFont.preferredFont(forTextStyle: .body)
pandaLabel.adjustsFontForContentSizeCategory = true
pandaLabel.numberOfLines = 3

Reduce motion

Reduced motion is used for people who are sensitive to motion effects and screen movements. Reduced motion disables the animations in certain applications.

If we have any animation, switching on the Reduce motion feature probably won’t disable the animation in our app. What we can do here is remove the animation if the Reduce motion feature is enabled by using isReduceMotionEnabled property.

We can benefit from this feature using this code snippet.

if (UIAccessibility.isReduceMotionEnabled) {
// add what your app should do with reduced motion version

} else {
// add what your app should do with motions are allowed

}

In my example project, I created a UIImageView, an array including four images, and made a loop to show these images in that image view. In the beginning, when I enabled the ReduceMotion switch, it didn’t affect my application. So, I decided to show one image when it’s enabled like in the following.

if (UIAccessibility.isReduceMotionEnabled) {
// Settings > Accessibility > Motion > Reduce Motion switch is turned on
    pandaImageView.image = UIImage(named: "panda2")
} else {
// Settings > Accessibility > Motion > Reduce Motion switch is turned off
    let animationImages = \[UIImage(named: "panda.png")!, UIImage(named: "panda2.png")!, UIImage(named: "panda3.png")!, UIImage(named: "panda4.png")!\]
    pandaImageView.animationImages = animationImages
    pandaImageView.animationDuration = 1.5
    pandaImageView.startAnimating()
}

In the end, it turned into this:

Conclusion

We are living in a digital era, so why don’t we make it accessible for everyone? If we want to create a better world for humans, we can start here.

Each major iOS version update brings new accessibility features. We can start by staying up to date on the capabilities of these features and how we can support them in our applications.

Today, I covered some tips on supporting accessibility in iOS applications. It is a broad concept, so I mentioned as many as possible. You can reach my demo app here.

If you would like to give any feedback, ask questions, or share something, feel free to reach out to me via hi@iremkaraoglu.com. For further information, I recommend you to check out the resources in the references section.

See you in the next article!

References

• https://developer.apple.com/accessibility/ios
• https://developer.apple.com/documentation/uikit/accessibility_for_uikit
• https://developer.apple.com/documentation/objectivec/nsobject/uiaccessibility
• https://developer.apple.com/documentation/accessibility/supporting_voiceover_in_your_app
• https://developer.apple.com/design/human-interface-guidelines/accessibility/overview/text-size-and-weight/
• https://developer.apple.com/documentation/uikit/uiaccessibility/1615133-isreducemotionenabled
• https://developer.apple.com/documentation/uikit/uifont/scaling_fonts_automatically

The post Supporting accessibility in iOS applications appeared first on LogRocket Blog.

My game is called Panda Clicker, and the aim is to touch the Panda image in the center of the screen. In each touch, a small panda slides from the top of the screen, a sound plays, and the score increases. When the score becomes a number that is a multiplier of 10, the device vibrates, and the user sees a particle animation on the screen. You may reach the source code here. I will cover it in this article in detail.

Nodes and scenes

During this article, I will mention nodes and scenes. Let’s talk about what they are first.

In SpriteKit, nodes are organized hierarchically into node trees, similar to how views and subviews work. Apple’s developer docs put it this way: “Most commonly, a node tree is defined with a scene node as the root node and other content nodes as descendants. The scene node runs an animation loop that processes actions on the nodes, simulates physics, and renders the contents of the node tree for display.”

With that in mind, we are ready to talk about the comparison between 2D games and mobile development!

While you are developing a game, you need to think more about the senses. What will be the player hear when they click that button? What will they feel while holding their phone? What visuals will they see? How long will that animation take? What will be the aim for the user? You will probably need to think differently than developing a mobile application. Let’s start!

Randomness

You may have seen an example of a treasure hunt game. As a basic explanation, it is a game where a user attempts to find something that has been hidden.

I am adding an example from the Sims Mobile Treasure Hunt event. In this example GIF below, two spots have fifty ancient relics and one has thirty golden bunnies. Each time, the rewards in the area (and the spots with these awards) generate randomly, and there is one chance to select — or you need to spend some SimCash to get one more chance, but whatever.

If we could have the treasures in the same positions, the game wouldn’t be entertaining, right? If I knew the left one always contains golden bunnies, how would I get excited? It would be consistent, stable, and boring. We are looking for randomness here to have fun. It gives us uncertainty about where the treasure is. It gives a little bit of stress, but also joy when we succeed. Trying to find where would it be and listening to my instincts about the treasure position is the fun part of this game.

However, we wouldn’t like randomness in a bank application. Imagine you open your transfers page and your transfers are not ordered chronologically. No way! Every user would be complaining about it.

We are looking for consistency in the mobile applications to use them easily. Otherwise, users get confused about finding the section they need. But in a mobile game, randomness is one of the things that will help you to achieve fun!

I am adding an example code snippet below to give you an idea about randomness. It is from Panda Clicker, which is my example project. The following code creates a node for the scene. I added an image I drew on Procreate and called it “panda.”

It gets the image and creates a node called “panda.” It gets a random x position between 0 and the screen width. Then, it positions the node in that random x position at the top of the screen. How they slide on the screen is the topic of the animations that we will cover later on:

let screenSize: CGRect = UIScreen.main.bounds
let panda = SKSpriteNode(imageNamed: "panda")
let randomXPos = CGFloat.random(in: 0..<screenSize.width)
panda.position = CGPoint(x: randomXPos, y: screenSize.height)

Calculations

While I am developing the user interface in a mobile application, I don’t need to calculate much. The paddings, height, and width are certain and I can reach the values on Figma. I never calculated a complex equation in developing UI.

However, developing a mobile game was different. As I stated before, there might be randomness in 2D games, and maybe in the specific part of a screen. You need to set the boundaries for that randomness.

Let’s say there will be images in those random positions. What happens when your image’s center is inside the boundaries but some parts overflow? You also need to consider your image size. How about the boundaries? They may differ depending on device; some devices have larger widths, some devices have larger heights. You need to consider the device size. You need to think about this in detail and calculate more!

Apple’s developer docs have this to say: “Although you can control the exact position of every node in a scene, often you want these nodes to interact with each other, colliding with each other. You might also want to do things that are not handled by the action system, such as simulating gravity and other forces.”

For these purposes, you need to add a physics engine to your game. SpriteKit and Unity have this feature already. To hear more about the physics engine, you can check out this video on designing a physics engine.

Input handling

In mobile app development, there is no need to handle inputs manually. However, in game development, inputs are the most important part of games. As developers, we are coding according to the input we take from a gamepad, touch, mousepad, keyboard, and so on to provide the best user experience.

In our case, this is a mobile game, therefore touch is important as an input. In application development, UI elements are giving the data of what the user touched on the screen. In game development, we are converting the screen position as a game camera and finding the touch position of the user.

Animations

In mobile applications such as a bank application or a chat application, you probably do not see animations as much as in 2D games. The user doesn’t have an interest in animation in a bank application; they would like to use a bank application in a secure, fast, and easy way! Good user experience is the key!

When it comes to 2D games, animations are what make the games fancier. Just think about match-three games like Candy Crush. Think about this game without any animations. The box just disappears when you clicked. The lack of feedback would make users disinterested. When developing games, animations are not a must, but they’re recommended if you want to attract users.

Just a basic example to show the difference with and without animation below.

In the Randomness section, we saw the pandas sliding down the screen at a random x coordinate. Now it’s time to hear more about how they slide. In the below code, let’s recall how to add the node to the screen. Then just a statement provided slides it: that moveTo() function.

// recall creating a node and giving a random x position at the top of the screen 
let panda = SKSpriteNode(imageNamed: "panda")
let randomXPos = CGFloat.random(in: 0..<screenWidth)
panda.position = CGPoint(x: randomXPos, y: screenHeight)

// below codes moves the node to the -72 in the y coordinate, in the 0.80 seconds and removes the node from the scene. 
panda.run(.sequence(\[
      .moveTo(y: -72, duration: 0.80),
      .removeFromParent()
      \]))

Particles

When we are considering animations, there can be elements that move on the screen, or an effect called particles. A particle system is a complex node that emits these so-called particles in the game scene. Particle effects are largely used in video games for various graphic touches — glitter, smoke, explosions, rain, snow, and so on.

In comparison to mobile app development, no one thinks about adding particles to the screen when you are just sending some money to someone else, but in a game, it needs to be exciting and engaging. Luckily, particles will help you to achieve that! Add special effects to your app, such as glittering or realistic fire with smoke, using particle effects.

If you are developing using SpriteKit, you may create and configure particle effects using Xcode’s SpriteKit Particle Editor, or in code. In PandaClicker, I created a SpriteKit Particle File and called it “MagicParticle.” I changed the values on the Xcode editor like the amount of the particles and the colors. Particles appear when the score is a multiplier of 10 and then disappear.

if let myEmitter =  SKEmitterNode(fileNamed: "MagicParticle.sks") {
      myEmitter.position = CGPoint(x: screenWidth / 2, y: screenHeight / 2)
      addChild(myEmitter)
}

In the above code snippet, I created an emitter node and I positioned the node in the center of the screen. Then I added it as a child of the scene’s root node.

Haptics

Until now, we have covered some visual elements. Let’s change the topic and talk about haptics. It is the use of technology that stimulates the senses of touch and motion. In other words, it is the science and technology of transmitting and understanding information through touch.

As macReports puts it, “Some iPhone models include haptic feedback (also called Haptics or System Haptics). This feature uses the Taptic Engine to provide haptic feedback, combined with an audible tone and/or visual feedback. Taptic Engine produces vibration and haptic feedback functions.”

Taptic Engine from macReports

When we are addressing the player’s senses, it is a great option to provide something that the player will feel. Therefore, it is engaging to feel something through your phone when it’s quite exciting at that moment in the game!

In Panda Clicker, I have added the haptics when the user achieves a score that is a multiplier of 10. I am adding the haptics code below. I have selected the medium style, you may choose what you desire by trial and error. If your device doesn’t support this feature, but you would like to get an idea of how it works, check out information on haptics here. It shows you how they sound and feel:

let generator = UIImpactFeedbackGenerator(style: .medium)
generator.impactOccurred()

Medium impact haptic sound

The above video shows how the medium impact haptic sounds. Also, bear in mind that this feature requires hardware, it is not possible to see if your haptics code runs as you desire on a simulator. You have to test it on a physical device that supports haptics.

Sound

We covered touch senses, but what about hearing? When you are developing a game, sounds are essential as well. You may put background music, or just add sound effects, or why not both? You need to consider the harmony between the game and the sounds. If you are working with a design team, they will probably give you the sound files, but if you are an indie developer working alone, you need to think about your own.

I found a royalty-free sound to add to Panda Clicker and named it panda_tap.mp3. When the player touches the big panda on the screen, the following code runs and the panda_tap sound plays:

SKAction.playSoundFileNamed("panda\_tap.mp3", waitForCompletion: true)

We walked through randomness before, and when it comes to sounds we may randomize them as well! We may have several sounds for the win case of the game to make it more exciting!

An example code snippet is below. It is not from Panda Clicker, but I am adding it as an example of randomness in sounds. In this code, we have four sound files in an array that gets a random element in that array and assigns it to a randomWinSound variable. Then, SKAction plays the randomWinSound:

var randomWinSound = \["AudioAssets/perfect.mp3",
                      "AudioAssets/awesome.mp3",
                      "AudioAssets/well\_done.mp3",
                      "AudioAssets/congrats.mp3"\].randomElement()!
SKAction.playSoundFileNamed(randomWinSound, waitForCompletion: true)

Win/lose conditions

In mobile applications, there is no win or lose. However, when we are developing a mobile game, it is better to have winning or losing for anything to make users play with a purpose!

If you start developing, you should consider: what will be the player’s purpose? What will be the obstacles to achieving that or what would make them fail? You need to think from the player’s perspective and how will they engage with the game.

Conclusion

These are all of my observations until now. I hope it gives you an idea about the comparison between mobile app development and mobile game development. Your experiences may differ, but I wanted to share my journey and point of view. You may check out my example 2D game called Panda Clicker here.
You may reach me via hi@iremkaraoglu.com for any feedback or questions.
See you in the next article!

References

https://www.ultraleap.com/company/news/blog/what-is-haptics/
https://developer.apple.com/documentation/uikit/animation_and_haptics
https://www.androidcentral.com/haptic-feedback-most-important-smartphone-feature-no-one-talks-about
https://developer.apple.com/documentation/spritekit/sknode/getting_started_with_nodes
https://macreports.com/iphone-system-haptics-what-they-are-enable-or-disable/

The post Developing a 2D mobile game as a mobile app developer appeared first on LogRocket Blog.

Applications should not be able to directly access the user’s camera, microphone, location, and so on in order to protect the user. We need to respect user privacy by seeking permission to capture and store photos, audio, and video.

Let’s check on Facebook to see an example of camera permission. You are familiar with these alerts, right?

To be able to present your application fully, your users have to give permission. But what if the user denies it? As you may guess, you can’t provide that feature. Therefore, permissions are essential.

What if we are developing a photo editing application? The solution is simple: we need to get their permission to access their data. In this article, we are going to dive into permissions and how we can get permissions in React Native by using zoontek’s react-native-permissions library.

Unfortunately, React Native doesn’t support getting permissions. Luckily, there is a popular third-party library we can use: Mathieu Acthernoene’s react-native-permissions library.

Let’s assume we want to ask for camera permission. The steps are easy to do.

To start, make sure you add this library to the project:

$ npm install --save react-native-permissions
--or--
$ yarn add react-native-permissions

Then, be sure you import the library by writing at the top of your file where you’ll handle these permissions:

import \* as permissions from 'react-native-permissions';
// you may also import just the functions or constants that you will use from this library
import {request, PERMISSIONS} from 'react-native-permissions';

react-native-permissions for iOS devices

• Make sure you add all wanted permissions to your app’s Podfile and run this command:

pod install

CocoaPods is a dependency manager for Swift and Objective-C Cocoa projects. The Podfile is a specification that describes the dependencies of the targets of one or more Xcode projects. Running pod install helps you to install the dependencies. You can check out CocoaPods here to read more.

→ In our case, we will add

pod 'Permission-Camera', :path => "#{permissions\_path}/Camera"

to Podfile and run pod install.

• Update the Info.plist with wanted permissions usage descriptions. You may achieve this in two ways; choose which suits you.

Option 1: Xcode

• Open the Info section
• Add a new line
• Select which permission you would like from the options as a key
• Add value to that key

→ In our case, we will select Privacy – Camera Usage Description.

Option 2: Text Editor

• Open Info.plist file
• Copy key and string values from the following and paste that file
• Update the string value according to your need:

<?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>     
      <!-- 🚨 Keep only the permissions used in your app 🚨 -->
      <key>NSAppleMusicUsageDescription</key>
      <string>YOUR TEXT</string>
      <key>NSBluetoothAlwaysUsageDescription</key>
      <string>YOUR TEXT</string>
      <key>NSBluetoothPeripheralUsageDescription</key>
      <string>YOUR TEXT</string>
      <key>NSCalendarsUsageDescription</key>
      <string>YOUR TEXT</string>
      <key>NSCameraUsageDescription</key>
      <string>YOUR TEXT</string>
      <key>NSContactsUsageDescription</key>
      <string>YOUR TEXT</string>
      <key>NSFaceIDUsageDescription</key>
      <string>YOUR TEXT</string>
      <key>NSLocationAlwaysAndWhenInUseUsageDescription</key>
      <string>YOUR TEXT</string>
      <key>NSLocationAlwaysUsageDescription</key>
      <string>YOUR TEXT</string>
      <key>NSLocationTemporaryUsageDescriptionDictionary</key>
      <dict>
        <key>YOUR-PURPOSE-KEY</key>
        <string>YOUR TEXT</string>
      </dict>
      <key>NSLocationWhenInUseUsageDescription</key>
      <string>YOUR TEXT</string>
      <key>NSMicrophoneUsageDescription</key>
      <string>YOUR TEXT</string>
      <key>NSMotionUsageDescription</key>
      <string>YOUR TEXT</string>
      <key>NSPhotoLibraryUsageDescription</key>
      <string>YOUR TEXT</string>
      <key>NSPhotoLibraryAddUsageDescription</key>
      <string>YOUR TEXT</string>
      <key>NSRemindersUsageDescription</key>
      <string>YOUR TEXT</string>
      <key>NSSpeechRecognitionUsageDescription</key>
      <string>YOUR TEXT</string>
      <key>NSSiriUsageDescription</key>
      <string>YOUR TEXT</string>
      <key>NSUserTrackingUsageDescription</key>
      <string>YOUR TEXT</string>

      <!-- … -->
    </dict>
    </plist>

→ In our case, it is as follows:

<key>NSCameraUsageDescription</key>
    <string>YOUR TEXT</string>

The value section in the first option and the <string> section in the second option correspond to the text inside the alert message.

Let’s recall the Facebook camera permission alert. The description part is the text you give as the value here:

→ In our case, I just gave “Camera” to the value, and here it looks like this:

react-native-permissions for Android

• Add all wanted permissions to your app’s android/app/src/main/AndroidManifest.xml file:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
      package="com.myawesomeapp">
      <!-- 🚨 Keep only the permissions used in your app 🚨 -->
      <uses-permission android:name="android.permission.ACCEPT\_HANDOVER" />
      <uses-permission android:name="android.permission.ACCESS\_BACKGROUND\_LOCATION" />
      <uses-permission android:name="android.permission.ACCESS\_COARSE\_LOCATION" />
      <uses-permission android:name="android.permission.ACCESS\_FINE\_LOCATION" />
      <uses-permission android:name="android.permission.ACTIVITY\_RECOGNITION" />
      <uses-permission android:name="android.permission.ANSWER\_PHONE\_CALLS" />
      <uses-permission android:name="android.permission.BODY\_SENSORS" />
      <uses-permission android:name="android.permission.CALL\_PHONE" />
      <uses-permission android:name="android.permission.CAMERA" />
      <uses-permission android:name="android.permission.GET\_ACCOUNTS" />
      <uses-permission android:name="android.permission.PROCESS\_OUTGOING\_CALLS" />
      <uses-permission android:name="android.permission.READ\_CALENDAR" />
      <uses-permission android:name="android.permission.READ\_CALL\_LOG" />
      <uses-permission android:name="android.permission.READ\_CONTACTS" />
      <uses-permission android:name="android.permission.READ\_EXTERNAL\_STORAGE" />
      <uses-permission android:name="android.permission.READ\_PHONE\_NUMBERS" />
      <uses-permission android:name="android.permission.READ\_PHONE\_STATE" />
      <uses-permission android:name="android.permission.READ\_SMS" />
      <uses-permission android:name="android.permission.RECEIVE\_MMS" />
      <uses-permission android:name="android.permission.RECEIVE\_SMS" />
      <uses-permission android:name="android.permission.RECEIVE\_WAP\_PUSH" />
      <uses-permission android:name="android.permission.RECORD\_AUDIO" />
      <uses-permission android:name="android.permission.SEND\_SMS" />
      <uses-permission android:name="android.permission.USE\_SIP" />
      <uses-permission android:name="android.permission.WRITE\_CALENDAR" />
      <uses-permission android:name="android.permission.WRITE\_CALL\_LOG" />
      <uses-permission android:name="android.permission.WRITE\_CONTACTS" />
      <uses-permission android:name="android.permission.WRITE\_EXTERNAL\_STORAGE" />
      <uses-permission android:name="com.android.voicemail.permission.ADD\_VOICEMAIL" />

      <!-- … -->

</manifest>

→ In our case, we need to add only camera permission to the AndroidManifest.xml file:

Requesting the permission: return types

request(Platform.OS === 'ios' ? PERMISSIONS.IOS.CAMERA : PERMISSIONS.ANDROID.CAMERA).then((result) => {
        setPermissionResult(result)
        console.log(result)
      });

The return types and the meanings are here:

The flow differs by the operating system. Here, there is the flow chart for permissions for iOS and Android, which is taken from the documentation of this library.

The final product

Voila! You are ready to run your code! Basically, that’s it!

You may still encounter a few problems, like maybe your device doesn’t support that feature or the version is not valid. My advice: the first place where you check for the solution should be the documentation of the library.

While writing this post, I built an example React Native application that includes camera and microphone permissions. It shows the result of the permission and the explanation of the result.

You may play with it, see the result types, and observe when that result is returned. You may first approve it, then change the permission in Settings, open the application, and see what happens. Work with it to understand better!

You may also use the sample for testing while you are coding for specific occasions. Other than playing with the sample, you can check out the source code, and if you are having trouble with anything, you can compare it with mine!

When I was about to finish my example project, I found out zoontek also made an example app for this just like mine but including every permission! You can check out zoontek’s example application here.

Key points for configuring permissions

Permission appearance

Bear in mind that if you answer a permission request, it won’t ask for that permission again. If you want it to appear again, delete and install the app.

If you only want to change the result, you may change it on the settings of your device.

In iOS, the user must explicitly grant permission for each app to access the camera and microphone. Before your app can use the capture system for the first time, the operating system shows an alert asking the user to grant your app access to the camera. They remember the user’s response to this alert, so it doesn’t reappear each time you access a user’s camera.

The user can change permission settings for your app in Settings > Privacy in iOS, or
Settings > Apps > “Your App Name” > Permissions in Android.

Dangerous permissions

Previously in Android development, every permission had to be added in the AndroidManifest.xml file. They were called Install-Time Permissions, and they were requested at the installation time at the Google Play Store.

Starting from Android 6.0 (API 23), the dangerous permissions, in other words run-time permissions, concept came up and these permissions became necessary to ask in runtime rather than install-time. Runtime permissions are the alert dialog boxes that come up when the app is running.

Let’s examine Instagram for permissions. When we check Instagram on Google Play Store, we see a bunch of permissions.

User’s camera, contacts, location, microphones, phones, and storage are their sensitive information. Therefore, they are dangerous permissions. So, in the Android 6.0 and later versions, users see run-time permissions when they are using the app; here, it’s Instagram.

When a user is trying to post a photo or a video, the run-time permission dialog comes up on the screen.

Similarly, when a user attempts to take a photo or a video on Instagram, these permissions come up.

Android 11 permission updates

In the Android ecosystem, there have been changes that come with Android 11:

• If your application requests permission related to camera, microphone, or location, the permission dialog includes the “Only this time” option. If it is selected, your app is granted permission for one time. It is called “one-time permission.” The second time the app is opened, the permission dialog comes up again
• If your application hasn’t been used for a few months, the system automatically resets the sensitive runtime permissions that the user had granted for the app

To learn more, go check out Android 11’s updates.

iOS 14.5: App Tracking Transparency

For iOS 14.5, iPadOS 14.5, and tvOS 14.5 and newer, developers are required to ask users for their permission to track them across apps and websites owned by other companies. One of the best features of this library is that it is up-to-date. You may add an AppTrackingTransparency (ATT) prompt and request by using react-native-permissions. Remember, only iOS devices version 14.5 or newer are able to request this.

When to ask permissions for the best user experience 🤗

Asking for permissions in the onboarding of the application or asking them at the specific time that you need is still a user experience debate. There is not an answer; there are opinions.

What I would suggest is asking when you need it. As a user, seeing all the permissions in the onboarding scares me, and most of the time I don’t give the full permissions. As I said before, this is open to debate. Choose what suits you.

Conclusion

We have covered the concept of permissions and how we can get them in React Native by using react-native-permissions. I gave you the key points you may need in your permission journeys, such as the Android 11 and iOS 14.5 changes. You can find my example project in this GitHub repository.

I hope you have enjoyed this article and your users give the full permissions to get benefit from your application features! If you have any feedback, feel free to reach out. Until next time, take care!

References

• Android permissions docs
• iOS permissions docs

The post Managing app permissions in React Native appeared first on LogRocket Blog.

UI testing is basically what designers, testers and the frontend developers do maybe without even noticing it. When we are testing a screen, we check the components: The button is located in the right place, the content is correct, the button navigates the user to the X screen, and so on. We were all doing it and it was namely UI (User Interface) Testing. It can be done manually or automated with a testing tool. Regardless of the method used, the goal is to ensure that all the UI elements meet the requested specifications.

The more features your application has, the harder it is to test manually. Automated tests help to ensure that your application performs correctly before you publish it while retaining your feature and bug-fix velocity.

In Otsimo, we develop our products in React Native and one day we faced with a major bug that costs a lot for our company. Then, we realized that we should do something to prevent this situation to happen again. Also, we add features each day so we need to be sure that we are not breaking anything and continue developing with confidence. So, we ended up with the solution which is building End to End testing.

When it comes to the comparison of tests, Integration Testing has the highest maintenance cost, has the most dependencies, and slowest in execution speed but gives the highest confidence with respect to Unit and Component Testing. According to our reasons, it was fair enough for us to do Integration Testing, so we dived into UI Testing.

Table for comparison of tests

To learn more about the test types you can check React Native’s Testing documentation.

Detox

Detox is an end-to-end testing framework which is developed by Wix. This means it runs your app on an actual device/simulator and interacts with it just like a real user would. This type of testing can give a lot of confidence in your app and help automate a manual QA process. To learn more about how detox works, you may want to check here.

Detox was the best fit for us because it is built from the ground up to support React Native projects as well as pure native ones. It is built for gray box end-to-end testing for iOS and then started to support Android as well. It offers more capabilities for iOS rather than Android and since we are not fond of Android default emulator, our tests only run on iOS.

Testathon

In our company, we spared two days just for testing in the developers team. We called it Testathon. We wanted to have UI Tests and have the artifacts (logs and video recordings from the tests) to be stored. Therefore, we created a new backend service to store artifacts that runs on Raspberry PI in the office near our real UI testing device.

We separated into two groups, one group listed down the test scenarios and wrote tests, the other one worked on backend service to store the build artifacts to our Raspberry PI in the office. I am not going to dive into this part because this is not relevant to the topic I would like to cover but as a brief, I may say, we also added these tests to our CI/CD process. When one of the tests fails, It doesn’t pass the CI and the fail message comes with our internal Slack bot. Gitlab does not have any feature like having these logs and videos to show, we needed to build this. We store each one for 90 days. These all are built using Go. Let’s go back to the first group’s part which is about the test itself.

Creating UI Test Scenarios

It’s better to focus on what is essential for your application. For example, if registering is mandatory in your application, you should better be checking if sign up and login screens and their functions work as intended!

While doing that, you have to code the tests as if you are testing manually. What do I mean by that? When you are manually testing, you check the screen like if the title and the content are correct. Then, check the the button if it is located correctly and you press a button. Next, you wait for an action like navigating to a new screen. You understand you have navigated correctly because you saw a new title and the content are changed. Same way, you should code your UI test. You should write the commands like what you normally do when you are testing it manually.

For example:
1. Check if there are “Sign Up” and “Sign In” buttons on the screen.
2. Press the “Sign In” button and wait for a screen to have e-mail input field.
3. Type correct email address and password and expect to see the Home screen
…

As a company, we need to be sure that our users or potential users should successfully sign up/sign in, they should be able to purchase a premium membership and successfully open the screens in the application without any crash. We started with these essential tests. Before diving into the code, let’s see my frequently used stuff which is taken from the API documentation, and see an example to make it clear.

The Device Object

device is globally available in every test file, it enables control over the current attached device (currently only simulators are supported).

• device.installApp()By default, installApp() with no params will install the app file defined in the current configuration.
• device.uninstallApp()By default, uninstallApp() with no params will uninstall the app defined in the current configuration.
• device.launchApp()Launch the app defined in the current configuration.
• device.terminateApp()By default, terminateApp() with no params will terminate the app file defined in the current configuration.
• device.openURL(url)Mock opening the app from URL.
• device.enableSynchronization()Enable (restore) synchronization (idle/busy monitoring) with the app — namely, resume waiting for the app to go idle before moving forward in the test execution. Enabled by default.
• device.disableSynchronization()Temporarily disable synchronization (idle/busy monitoring) with the app - namely, stop waiting for the app to go idle before moving forward in the test execution (rather, resort to applying unrecommended sleep()'s in your test code...).
• device.setURLBlacklist([urls]) Exclude syncrhonization with respect to network activity (i.e. don’t wait for network to go idle before moving forward in the test execution) according to specific endpoints, denoted as URL reg-exp’s.

MATCHERS

Detox uses matchers to match UI elements in your app. The ones that I use so often are below.

• by.id()
  Match elements with the specified accessibility identifier. In React Native, this corresponds to the value in the [testID](https://reactnative.dev/docs/view.html#testid) prop.
   — testIDUsed to locate a view in end-to-end tests.
• by.label()Match elements with the specified accessibility label (iOS) or content description (Android). In React Native, this corresponds to the value in the [accessibilityLabel](https://facebook.github.io/react-native/docs/view.html#accessibilitylabel) prop.
• by.text()Match elements with the specified text.

ACTIONS

Detox uses actions to simulate user interaction with those elements. My frequently used ones are below.

• .tap() Simulates a tap on the element at the specified point, or at element’s activation point if no point is specified.
• .typeText()Simulates typing of the specified text into the element, using the system’s builtin keyboard and typing behavior.
• .clearText()Simulates clearing the text of the element, using the system’s builtin keyboard and typing behavior.
• .tapReturnKey()Simulates tapping on the return key into the element, using the system’s builtin keyboard and typing behavior.

[wix/Detox
Detox uses matchers to match UI elements in your app. Use actions to simulate use interaction with elements and…github.com](https://github.com/wix/Detox/blob/master/docs/APIRef.Matchers.md "https://github.com/wix/Detox/blob/master/docs/APIRef.Matchers.md")

EXPECTATIONS

Detox uses expectations to verify those elements are in the expected state.

• .toBeVisible()Expects the element to be visible on screen.
• .toExist()Expects the element to exist within the app’s current UI hierarchy.

Bear in mind:
If we are checking the element’s visibility, we are expecting that the element is on the screen (not scrolled or something) and has at least 75% opacity. Alternatively, you can expect the element .toExist(), but that might result with an element that a user can't interact with. .toExist()checks for the current UI hierarchy.

Photo by Cookie the Pom on Unsplash

👩🏻‍💻 EXAMPLE

Talk is cheap, show me the code.

Here is the coding part 🐝

I created a repository to show you an example. Now, I will summarize it here with simpler code.

I created two screens and they have the following UI elements inside the render methods. I added testID attribute to the elements to reach during tests.

Then, I added the detox library and made the configurations.

Now, time to write the first test !

• First, we should see the sign up and sign in buttons on the screen. Expect the elements’ visibility by their id (which are the testID’s we recently gave)
• Secondly, sign in button should be clicked and it should navigate to a new screen. Its ID is “emailField” and it should be visible.
• Thirdly, emailField and passwordField should be filled by the values “irem@test.com” and “123456” respectively. Then the “My Courses” text should be visible on the screen. (This time, I checked by text not by id — this is a separate screen and it just has a text component, so I didn’t place it here)

DEMO 🎉🎉🎉

Hint — 1💡

It is more practical to check the elements by ID because the machine finds the elements by id more easily and also it avoids the ambiguity. For example, there might be “Done” button twice in a screen, one on the page and one may occur in a popup. If we expect the element by text as “Done”, it won’t be able to decide about which one we are aiming for.

Hint — 2💡

If there are multiple elements on the screen (most probably this will be the case) if one of them’s visibility gives you the confidence that you are on the right screen, you do not have to check for every element. However, if there are essential ones, it’s better to check them too.

While you are running your UI test, make sure that you opened Simulator by XCode to see how the tests run on a simulator. Therefore you may easily see where it got stuck; in a popup or a screen that you might have forgotten for instance. Other than that, it gives me joy to see someone is clicking on the buttons and testing the app :)

Hint — 3: Common Mistake 💡

You may see console warn messages appear during the UI tests just like in the gif above. When there is a warn message and it comes across to the element you expect it to be visible or will have an action with it, it ends up with failure because warn messages block the button’s visibility and the actions. You may avoid having console warn messages and learn here how to achieve that:

[How do you hide the warnings in React Native iOS simulator?
I found that even when I disabled specific warnings (yellow-box messages) using the above mentioned methods, the…stackoverflow.com](https://stackoverflow.com/questions/35309385/how-do-you-hide-the-warnings-in-react-native-ios-simulator "https://stackoverflow.com/questions/35309385/how-do-you-hide-the-warnings-in-react-native-ios-simulator")

Useful Video Resources

I personally love reading the Detox documentation because it gives me all the information I need. However, if you would like to search for more resources here is a list of my favorite others.

• Real World e2e Testing with Detox by Vojtech Novak :
  It is a presentation in React Native EU 2019 Conference. As a visual learner, I like to see someone explains a technology with a presentation. This video was my first resource before diving into the Detox! After getting to know the concepts, using the documentation became easier!
• Detox: Tackling the flakiness of mobile automation by Viktorija Sujetatie
  It is again a presentation and it’s by Mobile QA Engineer of Wix. She revises React Native, mentions why they need to implement their own framework for E2E testing and explains Detox.

Please like this article if you liked the content, it helps me to get motivated and create more 🌟

A design system is a system that all your components are already planned to use in the screens to be compatible. So the designers decide on what kind of buttons there will be in the application, which colors will be used, and so on. So, when a screen is updated or a new screen is coming up, designers focus on making it compatible and use the same kind of components or improve them without changing them much. After all, the design process becomes faster than before and the development as well. 🏃‍♀

Building a design system requires teamwork. Now, I’m going to mention what we have done in Otsimo as the development team and how we cooperate with the design team.

The design team discussed what kind of buttons will we have, which size, font, colors, and so on. After all, we started to build the components and also made a specific React Native application to see what the design components are. It gives us the benefit of seeing how an upcoming component is compatible with our system, how do they look, and inform us about the design system components. Nowadays, we are updating our products with the new design of the screens using design system components! 🧙🏻‍♀️ If all of these sound complicated, don’t worry it will be clear. Let’s start!

Typography

Text variants were decided and as developers, we created our Text component which takes the variant as a prop and we only use these variants to maintain our design system.

The code snippet shows how we would style a text in a way that probably most of you all know. What we have done is, having stylings and just giving the styling name as a props, and voila! Let’s see how it works.

We called our text component as OtsimoText. It works similarly with the Text component, the only difference is it has the variant props.

Two of the variants are listed below. So, the styling changes according to that variant and it makes our job easier.

Colors

Designers set the color palette that our application will have and as the development team, we created a file to add these colors as constants and named them. We don’t use any other HEX or RGB code, we stay in that color palette.

Some colors are listed below.

Writing style={{ color: colors.yellow.dark1 }} instead of style={{ color: “rgb(245,198, 0, 1.0)” }} is more practical and also prevents typos.

Buttons

Designers designed what kind of buttons we will have and they divided these into three.

• Filled Button
• Text Button
• Iconic Button So, we created separate components for each of them. They have the Pressable component inside.

Example of our button variants:

👩🏻‍🎨 Theme Support

Until here, all were somehow easy if you are already a React Native Developer. Let’s dive into deep and build a theme! But why do we need that? We have several mobile applications and each one has different color palettes. We care about reusing the components and we don’t want to give hardcoded color values, therefore, we build theme support and each application gets the color from its theme. For example, one application may have a dark background, one may have light and we get the color value from its theme according to which application is it. After we built this, it became essential for us. Let’s see how it works in detail.

If you have a theme with background, primary, and secondary colors and you change one of the colors in your theme, the change will apply to every place where the color is used in the application.

Assume that your primary color in your application is dark blue. You use this dark blue all of your buttons in your project. You access this color not by this dark blue’s hex or RGB numbers, you access it by your theme like color:theme.primary.

When you change your opinion about this primary color and you decide to make it dark green, you don’t need to change every single button’s color, you just need to change the primary color’s value and here we go! It’ll be changed dynamically!

So, let’s see some code! 💻

We used React Context which is designed to share data for a tree of React components. We created a Hook to access easily to the theme values.

Usage

How we use this theme support in our design system application is shown below.

This shows the process of changing the primary color from blue to yellow in the theme, and the buttons that use primary color changes to yellow immediately. Why don’t we play and mix it more?

Changing primary, secondary, background, and textPrimary colors result with this grey backgrounded screen. We use these theme colors especially in the buttons, see how they changed:

SVG Icons into Font! 👀

First, we created a separate repository for this purpose. We used fantasticon which is an icon font generation tool. It generates TTF, TypeScript, and JSON files. When we need new icons we add them to that repository. We run the command to convert SVG icons and then update our development repository with the new output files. Fantasticon’s documentation is so good, so I won’t go over it. I want to mention what we have gained after this conversion.

Earlier, we were putting icons as Image and it was making our application size larger. Styling was also taking the time.

Then, we came up with converting SVG Icons to the font. We can access them by using the Icon component.

✓ Takes less space on disk than png images. ✓ Fewer lines of code. ✓ Can be scalable to any size.

To see our icons list and how do they look according to the size, we created a page on our design system application.

Accessibility!

Accessibility is a part of our design system. During the building process of the design system, we also paid attention to how we can make our components and application accessible.

It is a long story so for further details, you can read an article about how to support accessibility in React Native from here. ⬅️

“With design system, we have minimized to use of time, maximized to speak same design language with design crew. Not just for that, but also design system has been an icebreaker to set up fast and healthy collaboration with the dev-team.” — Mehmet Çam, Head of Design at Otsimo

Hope you enjoyed this article!

If you’d like to see more articles, please subscribe to my newsletter 📨 Thank you for being here and for your support. 💙

Tuukka Ojala is a blind developer who listens the code line by line by screen reader. He speaks in detail about how he uses his computer and writes code in his blog post. He is one of the best examples that visually impaired people do exist, they have jobs just like us and use technological devices as well. They are able to use these devices, thanks to the accessibility features of softwares.

What can we do for visually impaired people not only as humans but also as developers? We can make the apps suitable for their needs. We can add accessibility features to help their usage.

We generally think like only people who have blindness use screen readers, but it is only 64% of users of screen readers. People who have low vision are 39% and there are also cognitive, deafness, motor and other ilnesses who use screen readers.

To support accessibility in a mobile application project, emphaty is the key to understand. I am going to mention how to make a mobile application more accessible for people who use screen readers on a React Native project especially for iOS devices.

My development started as testing it on iOS Settings. It reads the text of a button and then says “button” to let the user know it’s pressable. If you have already implemented at least a page of your mobile application, you can check out what are the necessities. Probably VoiceOver won’t understand that it is a button and won’t say “button” after reading the text of your button. So you need to make it accessible first (by default, all touchable elements are accessible) and declare accessibility role as button. If these don’t make sense, don’t worry. Keep reading, everything will be clear.

Let’s start

To ensure that VoiceOver can access your component, type accessible={true} in your component.

Whenever you have a control, add all of the accessibility information you can. At a minimum, implement the following properties

• accessibilityRole (button, text, link, etc.)
• accessibilityLabel (when the operating system can’t derive a useful read out on what this control does)
• accessibilityHint (when the label alone won’t tell the user what’s going to happen when they click it)

AccessibilityRole

To inform the user that it’s a button, add accessibilityRole=“button” to your component in the same way.

Some accessibility roles you may probably use often are listed below. There are bunch of other roles so you can check it out for more to find out which suits your needs.

alert: Used when an element contains important text to be presented to the user.

button: Used when the element should be treated as a button.

header: Used when an element acts as a header for a content section (e.g. the title of a navigation bar).

image: Used when the element should be treated as an image. For example, it can be combined with button or link.

switch: Used to represent a switch which can be turned on and off.

text: Used when the element should be treated as static text that cannot be changed.

AccessibilityState

You can inform the user by adding accessibilityState={{ disabled: true }} if the button is disabled so the user can’t press that one. VoiceOver reads it as “dimmed” when it’s disabled. You can also use accessibilityState={{selected: true}} if you want it to be read as “selected”.

Let’s see some code to make it clear. Following code renders a Pressable component with a “This is an example” text on it and Accessibility VoiceOver reads it as “This is an example dimmed button” on iOS.

AccessibilityState takes an object which is not limited with the disabled key. You may also add selected, checked and so on.

Selected is mostly used in the components that include buttons and users are able to select only one. Therefore, VoiceOver informs the user about which is “selected”.

In the above example, “While iPhone is Locked” is selected so these two rows are read as “Always” and then “Selected While iPhone is Locked”.

When it comes to “checked”, you may use it on your switch buttons just like iOS’ airplane mode on — off. Also, make sure that you are writing accessibilityRole=“switch”

Above example is read as “Do not disturb on double tap to toggle setting, scheduled off double tap to toggle setting” by VoiceOver.

AccessibilityHint

An accessibility hint helps users to understand what will happen when they perform an action on the accessibility element when the result from the accessibility label is not clear. Such as telling the user that back button’s action as “Navigates to the previous screen”.

Bear in mind that if the user has hints enabled in the device’s VoiceOver settings, VoiceOver reads the hint after reading the label. When it comes to Android, TalkBack (Android’s screen reader) will read the hint after the label as well but hints cannot be turned off on Android.

Did you know that VoiceOver uses Machine Learning ?

You may think like it just reads and we give the roles, states, labels to make it read. Where is Machine Learning in this?

As a personal experience, while using our application, I realized it reads my iconic button (which has a + sign on it) as “Add” but we didn’t provide any accessibility information to it. I thought probably it just reads the icon’s name but icons are just unicode numbers and voice over doesn’t know it’s name.

While investigating this with our CTO, we tested it by opening the gallery and it started to read the photographs like “image, a baby crawling on the floor”. Then we found “VoiceOver Recognition” feature which uses on-device machine learning models. According to Apple, It improves accessibility of an app that have no accessibility information such as identifying the state of buttons or toggles.

As a user, you can switch recognition features ON under the VoiceOver Recognition title. If Image Descriptions is on, VoiceOver speaks descriptions of images in apps and on the web. If Text Recognition is on, VoiceOver speaks descriptions of text found in images. When it comes to Screen Recognition, it automatically make apps more accessible by recognizing items on the screen and especially this one is what makes your mobile application more accessible. For instance, it identifies the state of buttons or toggles, and by grouping related items together.

So, especially for icons and images, if you don’t want VoiceOver to read your visual component according to Machine Learning result, just give it an AccessibilityLabel to specify what you would like to be read. Otherwise, if your screen recognition turned on iOS users may experience some readings not matching what you have intended.

Recommendation

I recommend two movies (Theory of Everything and Gleason) to help you understand how accessibility features are beneficial for people. As you may know, Stephen Hawking is one of the well known people about experiencing Voice Technologies. Helping them and making their lives easier is our responsibility.

Conclusion

This article was only for supporting screen readers in mobile applications. As Otsimo development team, our work about accessibility is still going on. Now, we are searching for taking input just by head or eye movements and how we can add these features to our products.

I hope this article was beneficial for you and will help you to support accessibility in your products. If you are not developing anything at least having awareness is important too.

Thank you for reading, if you like this article and want to hear more please like this article. If you want to be notified about my next article, you can subscribe to my newsletter.

This article is originally posted on my medium blog. See you in the next article! 🦋