Leave no one behind

Accessibility on apps is the practice of designing apps that are usable by people with different abilities and preferences.

As an iOS developer, it’s important to create apps that are accessible to everyone, regardless of their abilities. Besides being the right thing to do, it also expands your user base and make your app more appealing to a wider audience.

This is not a code or tech article; it’s intended as a nudge to start identifying any accessibility issues your app might have. I’ve also included a bunch of tools to help you with that, and I recommend you make a list of points you find interesting so you can start exploring and implementing them in your own lovely app.

Let’s get started! 🚀

Identify colour contrast issues 🎨

One common accessibility issue is a lack of contrast between text and background colours. This can make it difficult for users with low vision to read content in your app. To fix this issue, you can review your app’s color contrast and make sure it meets accessibility standards.

There are several online tools you can use to check your app’s colour contrast, such as the WebAIM Contrast Checker. To use the tool, enter the foreground and background colors for your UI elements and it will provide you with a contrast ratio. Ideally, your app’s contrast ratio should be at least 4.5:1 for normal text and 3:1 for large text.

Adjust font sizes 📏

While some users might have perfect vision, others may rely on assistive technologies or have specific visual impairments. In such cases, the ability to adjust the font size is key to a comfortable and enjoyable user experience. This is where Dynamic Text comes into play. By offering the flexibility to increase or decrease the font size, Dynamic Text lets users with low vision or other visual impairments to customise their reading experience to suit their individual needs.

A user who can effortlessly read and navigate your app is more likely to engage with its content and features, in turn to increase user satisfaction and retention.

Implementing Dynamic Text in an iOS application is relatively straightforward. Apple’s developer guidelines provide comprehensive documentation on integrating Dynamic Text throughout the app’s interface, ensuring that text elements automatically adjust their size based on the user’s preferred settings.

If you use SwiftUI you can easily preview how your app will look in different scenarios. At the bottom of your preview, select Variants > Dynamic Type variants to see something like this:

Provide clear feedback 👀

In addition to visual impairments, it’s essential to consider the needs of users with cognitive disabilities when designing and developing your iOS app. These individuals may face challenges related to memory, attention, and comprehension, making it crucial to provide clear and effective feedback within your app.

This includes visual cues, such as displaying success messages or highlighting completed tasks, as well as auditory feedback through sounds or voice prompts. We can also enable haptic feedback using the great API that Apple provide us. Using a combination of visual, auditory and haptic cues helps accommodate all users, ensuring that they can comprehend and process information more effectively.

Let’s say you have a button that leads to a page with more information about your product. Instead of just changing the button colour when the user taps on it, you can also add a short message that says ‘Loading…’ to indicate that the action is being processed.

As well as immediate feedback, you should also consider providing error messages that are clear, concise, and easily understandable.

Support VoiceOver 🦻

One of the most important accessibility features on iOS is the VoiceOver tool. VoiceOver is a screen reader that provides audio descriptions of on-screen content, allowing users with visual impairments to navigate.

With VoiceOver activated, users can navigate an app using swipe gestures and double-tapping to activate buttons or links. VoiceOver also provides audio feedback when an action is performed, such as a button press or text field input.

Here, you can get started by documenting how VoiceOver should work in your app. Define groups of elements that must be read together and set traits, labels, values and hints for each element that needs them.

Trait: Constants that describe how an accessibility element behaves.

Label: A string that succinctly identifies the accessibility element.

Value: A string that represents the current value of the accessibility element.

Hint: A string that briefly describes the result of performing an action on the accessibility element.

The graphic bellow is an example of how I defined how VoiceOver should work in the You section on XING, the app I work on at New Work SE. The numbers show the order that VoiceOver should follow when reading the content. The yellow notes are the default behaviour, while the green ones are a custom element we should create.

There are a lot of different points to cover here, so I’ll include them in a future post. In the meantime, you can check this documentation from Apple to find out more about this.

Testing your app’s accessibility 🧐

The final step to improve your app’s accessibility is to test it thoroughly. Here are a few things to keep in mind:

👀 Test with assistive technologies: Use assistive technologies like the Accessibility Inspector app to test your app’s accessibility. To open it, just click on Xcode > Open Developer Tool > Accessibility Inspector.

The Inspector pointer button will allow you to point a specific section on the screen to see the accessibility traits and values of that element.

The Audit button is also really useful as it lists all the issues it finds in the current view of your app.

🕵️ Test with real users: Get feedback from users with disabilities to make that your app is truly accessible to everyone.

📱 Test across devices: Make sure you test your app’s accessibility on different devices and iOS versions to ensure compatibility.

Leave no one behind 🧏

Improving the accessibility of your iOS app is both important and a great way to expand your user base and provide a more inclusive app. There are a lot more ways to make sure your app is accessible, but by following the tips and techniques I’ve outlined in this article, you’ve already got a great starting point to create a more accessible and user-friendly app. So go ahead and give it a try! 🦾

Thanks for reading my post. You’ll also find me over on Twitter: @dev_alhambra.

🙇🏻

The importance of accessibility on your iOS app was originally published in New Work Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

Good review = Good code

Pull Requests (PR), or Merge Requests, are a must to maintain the code's quality. A pull request is a place where you can offer your code for review before it becomes part of your source code. A good review can be useful to find a bug that you missed or even to help you improve the readability of the code.

At New Work we have two mandatory code reviewers per PR. One is inside the team (or the code owner), and another is randomly by our custom script program.

This article is not about technical aspects or best practices, as this is something that each company owns, this article is about the importance of good feedback. By good, I mean valuable in any situation.

Start by creating a checklist for you to review each PR. Here is mine if you need some inspiration:

• 💅🏻 Coding style: The code must follow the code styling guidelines.
• 👓 Readability: By reading it, you should understand what the code is doing. A good naming of variables and functions is important to achieve it.
• 🔨 Maintainability: Code should be easily maintainable. For example, try to avoid leaving any magic number on the code.
• ✅ Test coverage: Don’t settle for the “tests have been added” check on your CI/CD system, sometimes we can forget to add tests for the logic we are making.
• 📝 Documentation: I’m not a documenting-everything-lover, if it’s self-explanatory it’s enough, but sometimes we sin by leaving important things without commenting on them. Take care of it in your reviews.

Let’s see this comment.

Looks pretty normal, right? Do you find anything wrong with it? Let’s discover how to improve it step by step.

⭐️ Be respectful with the time

If someone asks you to review a PR their workflow is in your hands, but that doesn’t mean rushing the review. Save time on your working days to do code reviews.

When you receive a pull request let the person know that you are aware of it, and tell them when you will review it.

Carla: Hey! I have this PR for you, please review the code when you have time 🙂

Mario: Sure! 👍🏻 I’ll review it at the end of the day.

⭐️⭐️ Give constructive feedback

Please, you don’t need to destroy your teammates! Help improve the code with respect, explaining why you suggest every change. No sarcastic words nor condescending ones.

The point of the review is not only to add value to the code but also to help the person who did it to understand why you think the change is needed.

⭐️⭐️⭐️ Be precise — use code proposals

The more specific the suggestion, the better. The most precise way to do it is to take time to improve the code by yourself. If you do a code proposal you will help your teammates to understand your point of view. If they feel that you are interested in their code, you are doing a good job. ☺️

Here is a secret Golden Rule: Don’t propose anything without testing it, make sure everything works!

⭐️⭐️⭐️⭐️ Don’t define — be open to discuss

Follow your feedback with an open question standing up to start a discussion. Do not define what the solution is, write your opinion and then try to reach a common point to solve the problem. Maybe both of you will learn something in the process 🤓

⭐️⭐️⭐️⭐️⭐️ Get the big picture

Focusing on single lines is good to improve readability and the coding style, but you need to get the big picture to understand what's going on. The scope of the source code is an extensive system of functionalities, not just what you are seeing on the bricks on the PR.

Do not ask anything that can be known having the context of the entire PR. One tip is to leave draft comments until you review everything, and then read again your comments, maybe some of them are already answered!

Many times a good review does not depend only on the reviewer, but also on how the PR is opened, but let’s leave that topic for another article, you already learned a lot today!

Thanks for the reading, and happy reviewing. 🤓

Five stars code reviews was originally published in New Work Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

Learn about the project-based learning methodology advantages through my own experience as an iOS Developer

What is project-based learning?

You can learn computer-science or software development in many ways. Let me tell you the story of how I became an iOS Developer and what I’m doing to continue learning.

Hello, world! 👋🏼 I’m David Alhambra, and I’m using the project-based learning methodology, or PBL, to learn and improve my skills by solving real-world problems.

This method was first described by John Dewy in 1897 and currently is used in many fields to teach students. I started using this method years ago in my studies, and after that, I used the PBL to help junior developers in the companies I have worked for, like in New Work.

How I started 🤓

I knew about project-based learning when I started my degree in web development. Yes, I studied web development, but I consider myself an iOS developer. I applied the PBL when I started the transition from Web to Mobile, and I learned about this method thanks to Angela Yu and her iOS development course.

The course was divided into sections, each one with a mini-project at the end so that you could practice what you just learned. It didn’t take long till I decided to start my first personal project, that decision was a game-changer.

The rules of the PBL

1. Find your motivation 💪🏼

I love playing Magic: The Gathering with my friends. It’s a card game where you play against other players with your deck, casting spells and summoning creatures. Each deck has one or more theme colours. The objective of the game is to dial 20 damage points to the opponent. I needed an application to track the number of life points left, that could be adapted for more than 2 players, in which each player had their colour identity represented. There were a lot of apps with some of the functionalities I just described, but none had all of them, so I decided to develop my own app.

The Magic: The Gathering app was the first project I started and finished, and I learned a lot more developing it. Other projects I made later were, for example, a Marvel Comics searcher, a drawing challenges app, or an app companion for the Animal Crossing: New Horizons videogame. In fact, I launched the Animal Crossing one, and some blogs posted an article about it (in Spanish).

Find a real-world problem and solve it. Try to think about something you need and build it.

Everything that comes to your mind is a good idea. Everything is perfect to start learning. Don’t worry, in case you get uninspired, ask a friend, surely they would like to have an app that does not exist yet.

Here comes some ideas:

• 🌌 An app that shows which is the best day of the year to see some star in the night sky.
• 🍫 An app to record the food date of expiry and sets notifications to warn you.
• 🎮 An app to track your progress on a videogame.

2. Keep it small! 🧩

If you try to build something so big, most likely you’ll need to use technologies that you don’t know how to use yet. You can always return and iterate your lovely project later.

My first app project was super simple, as you already saw. Here are my tips for your first app:

• Keep the UI as simple as possible.
• Don’t use soporific navigation.
• No server-side connection.

It’s your first project, so do what you know you can do. Later, you can include all those functionalities and many more, so don’t be in a hurry. It is always better to set a good foundation before doing a super big and fancy project.

The advantages of the PBL

1. You’ll learn more than one skill 👨🏻‍🏫

Although my first app was super simple, I was getting better in a lot of fields.

• Planning: I learned to organize myself, as I needed to plan how the creation part was going to be.
• User Interface and User Experience (UI/UX): I also needed to do the UI of my app, so instead of starting coding I also learned to use Sketch, an UI design software.
• Software development: Then I got into the code, so I started using project structures on the files and the code, and later I learned that it had a name: software architectures.

It was suuuuuuper fun! I just built an app by myself, did all the research I needed, and now I can use it in my games! 🥳

2. Practice makes permanent 💻

I’m already working as an iOS Developer at New Work, and I have more than 4 years of experience in the sector, but I’m still applying the PBL method on a daily basis. Why? Because we are developers, we need to be constantly learning.

Apple launches new development tools regularly. You can read the documentation to be informed about all the news, but if you also try those things on your personal project, that one that you love, unintentionally, you will put more emphasis on understanding everything.

I have an app, Moobee 🐝, which I use to test the new APIs that Apple launch every year, like:

• ⛵️ The new SwfitUI’s Navigation API
• 📲 HomeScreen widgets
• ☁️ Xcode cloud

This list could be endless. Each year we have tons of new frameworks and tools. Practice and test it on your project, don’t settle for watching a tutorial or reading the docs, practice makes permanent.

Apply it to your company

If your company has a good flow of junior developers joining, for sure you need to teach them. Even more if they are students or if it is their first job. You don’t need to give them a real project. In fact, they’ll get more motivated if they do a personal project or something they love, and they will learn a lot more in the process.

At New Work, we apply project-based learning. When giving them a project they gain more agency in their path to learning software development.

We are currently searching for new students in Valencia, Barcelona and Porto constantly, so feel free to ping us to get informed! ☺️ And by the way, we are always searching for new talents.

As a student, following PBL at New Work has allowed me to apply my learnings through the workshops to already existing and successful projects, helping me shape theoretical knowledge. I have been involved in everything the team was doing, which gave me a broader view of the whole project.
- Kike Signes, iOS student on New Work. Currently working as junior developer.

What we do is mix bootcamp trainings with team projects. In our case, each student is involved only in one of our teams, just like in a real job. During 6 months they become a formal junior developer in their field.

Project-based learning is a natural way to learn. You’ll get motivated and you’re going to have solve a real-world problem while having fun. Apply it if you are a student, or even if you are an experienced developer.

Thanks for taking the time to read my story. 🙂

Project-based learning: how I learned software development was originally published in New Work Development on Medium, where people are continuing the conversation by highlighting and responding to this story.