iOS Accessibility Series (Part 1)
5 (1)

Click to rate this post!
[Total: 1 Average: 5]

iOS accessibility, from a developer’s point of view, refers to the set of tools, technologies, and guidelines provided by Apple to ensure that iOS applications are usable and inclusive for people with disabilities, as a developer, incorporating accessibility features into your iOS app involves considering the diverse needs of users with visual, auditory, motor, cognitive, and any other impairments. (see table below for a list of most common impairments and disabilities)

Many developers and businesses do not prioritize making their applications accessible for several reasons, first, there is often a lack of awareness about the significance of accessibility and the benefits it brings to a broader user base, second, some developers perceive accessibility implementation as a complex and time-consuming task, leading them to prioritize other features instead, there are also other concerns about additional costs, limited resources, the assumption that their target audience does not include people with disabilities can deter developers from investing in accessibility.

Legal enforcement of accessibility regulations may be weak or inconsistent in some regions, reducing the incentive to comply, moreover, the emphasis on aesthetics over accessibility, inadequate training on accessibility best practices, and resistance to change can further hinder the adoption of accessible design, despite these challenges, raising awareness and promoting the positive impact of accessibility remain crucial in encouraging developers to make their applications inclusive and accessible to all users.

Several countries have enacted laws and regulations to enforce digital accessibility. In the United States, the Americans with Disabilities Act (ADA) and Section 508 of the Rehabilitation Act of 1973 outline accessibility requirements for websites, applications, and other digital content provided by federal agencies and entities receiving federal funding.

The Web Content Accessibility Guidelines (WCAG), created by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C), are widely recognized as the global standard for web accessibility, these guidelines provide specific criteria for making digital content accessible to individuals with disabilities.

Failure to comply with accessibility regulations and standards can lead to legal consequences. Companies and organizations that do not provide accessible digital content may face complaints, lawsuits, or enforcement actions by individuals, advocacy groups, or government agencies.

Penalties can include fines, legal fees, court orders to rectify accessibility issues, and reputational damage.

Several high-profile cases have set important precedents for digital accessibility enforcement, resulting in settlements or court rulings against companies that were found to have inaccessible websites or applications, these cases highlight the significance of accessibility and the legal ramifications of non-compliance.

Numerous prominent cases have established crucial precedents for enforcing digital accessibility, leading to settlements or court rulings against companies with inaccessible websites or applications. Notably, Domino’s Pizza, Netflix, and Target faced legal issues related to the lack of accessible applications for individuals with disabilities. The Ninth Circuit Court of Appeals ruled in favor of a blind plaintiff, stating that the ADA applies to websites and mobile apps. Netflix settled with the National Association of the Deaf, agreeing to make its streaming content accessible with closed captions. Similarly, Target settled with the National Federation of the Blind, committing to enhance its website’s accessibility.

These cases emphasize the significance of digital accessibility and the legal consequences for non-compliance, prompting businesses to increasingly prioritize accessibility for a more inclusive online environment.

Main types of disabilities and impairments:

VisualUsers with visual impairments may have a partial or complete loss of vision. They rely on assistive technologies like VoiceOver to navigate the app using spoken feedback. Developers must ensure that UI elements have meaningful labels, provide appropriate descriptions, and support dynamic text sizes for better readability. Additionally, maintaining proper contrast and avoiding reliance on color-only cues is crucial to aid users with low vision.

When creating an accessible app, developers should consider various visual impairments, such as blindness, low vision, color blindness, glaucoma, cataracts, macular degeneration, nystagmus, diabetic retinopathy, hemianopia, and photophobia.

To accommodate users with these conditions, designers should prioritize VoiceOver support, dynamic text sizing, high contrast options, and clear layouts. Regular accessibility testing with assistive technologies ensures the app meets the needs of all users, providing an inclusive experience for those with visual challenges.
AuditoryUsers with auditory impairments experience hearing loss, which can range from mild to profound. Closed captioning and subtitles are essential for video or audio content to make it accessible to this audience. Developers should also consider providing visual or haptic feedback for important alerts or notifications.
MotorUsers with motor impairments may have difficulty with precise touch gestures or using physical buttons. To accommodate these users, developers should ensure that app elements are well-spaced and have an appropriate touch target size. Supporting alternative input methods like switch control and voice commands can also enhance accessibility for users with motor challenges.
CognitiveUsers with cognitive impairments may face challenges with memory, attention, and problem-solving. To cater to this audience, developers should strive for simplicity and clarity in the app’s user interface. Avoiding complex navigation flows and providing clear instructions can make the app more user-friendly for individuals with cognitive disabilities.
SpeechUsers with speech impairments may have difficulty communicating through traditional speech. Developers can consider integrating communication tools or support for alternative input methods like text-to-speech or augmentative and alternative communication (AAC) into their apps.
Situational disabilitiesUsers in certain situations, such as noisy environments or poor lighting conditions, may benefit from accessibility features like closed captioning or larger text sizes.

Book Offer50% OFF in Books Book Offer

SwiftUI views are values and not objects!
4.4 (8)

Click to rate this post!
[Total: 8 Average: 4.4]

In SwiftUI, views are value types rather than traditional objects 🧐, this design approach is a fundamental aspect of SwiftUI’s declarative programming model and is aligned with the Swift language’s emphasis on value semantics.

As value types, views in SwiftUI are immutable and are copied when needed, resulting in predictable behavior and easy management of state and data flow, this means that when you modify a view, you are actually creating a new instance with the desired changes, rather than mutating the existing view, this immutability allows SwiftUI to efficiently track changes and perform targeted updates to the user interface.

Value types promote a more functional and declarative style of programming, where you describe the desired state and SwiftUI takes care of updating the view hierarchy accordingly, they are also thread-safe by default, as copies are made when passing views between different execution contexts.

Another advantage of using value types for views is that they enable SwiftUI’s built-in animations and transitions, by comparing the old and new values of a view, SwiftUI can automatically animate the changes, resulting in smooth and visually appealing user interface updates.

The declarative programming paradigm is at the core of its design philosophy, declarative programming focuses on describing the desired state of the user interface rather than specifying step-by-step instructions on how to achieve that state, SwiftUI’s view tree engine leverages this approach to efficiently manage and update the user interface based on changes in the underlying state.

You define your user interface using a hierarchy of composable and reusable views. Each view represents a specific part of the interface and is responsible for rendering itself based on the current state, by composing these views together, you create a tree-like structure known as the view hierarchy, the view hierarchy in SwiftUI is immutable, meaning that you define it once and SwiftUI takes care of updating it based on changes to the underlying state, when the state changes, (or even when the view re-appears when scrolling back and forth), SwiftUI re-evaluates the view hierarchy and determines the minimal set of updates needed to reflect the new state, this process is known as the reconciliation algorithm (AKA diffing algorithm).

The reconciliation algorithm is where SwiftUI’s view tree engine shines. It efficiently compares the old and new view hierarchies, identifies the differences, and applies the necessary updates to the user interface, by only updating the specific parts of the view hierarchy that have changed, SwiftUI minimizes the amount of work needed to keep the UI in sync with the state, resulting in optimal performance.

In contrast to UIKit, in SwiftUI view construction and updates are unified into a single code path, views are values rather than objects, described by values conforming to the View protocol, the view tree is transient and can be recreated at any time based on the underlying state, this declarative approach eliminates the need for separate event handlers and manual UI updates like in UIKit, SwiftUI’s view tree engine efficiently reconciles state changes, performs targeted updates, and ensures a reactive UI that stays in sync with the data, by relying on value semantics, SwiftUI can perform granular updates and avoid unnecessary computations, leading to a highly performant and responsive user interface.

By relying on a declarative approach, SwiftUI allows developers to focus on describing the desired end state of the UI rather than worrying about the low-level details of UI manipulation, this shift in mindset 😎 leads to more maintainable and expressive code, as developers can easily reason about the UI based on its desired state.

Another significant aspect of SwiftUI’s view tree engine is its ability to efficiently handle updates. As views in SwiftUI are value types, changes in the state result in the creation of new view instances rather than mutating existing ones. SwiftUI employs a mechanism called “value comparison” to determine the differences between the old and new views, enabling it to perform targeted updates to the UI.

Additionally, SwiftUI’s view tree engine embraces a reactive programming model. Views in SwiftUI are not just passive representations of UI elements but are also capable of reacting to changes in the state, this reactive nature enables automatic propagation of state changes throughout the view hierarchy, ensuring that the UI remains synchronized with the underlying data.

In conclusion, SwiftUI’s view tree engine revolutionizes UI development by embracing the declarative programming paradigm. It provides an efficient and responsive user interface by leveraging value types, value comparisons, and reactive programming.

The ability to describe UI in a declarative manner, combined with targeted updates and optimization techniques, empowers developers to create intuitive and performant user interfaces with ease.


Book Offer50% OFF in Books Book Offer

This is why I don’t use GIT GUI tools.
4.8 (4)

Click to rate this post!
[Total: 4 Average: 4.8]

Any seasoned iOS engineer who uses Xcode can see that it lacks a lot of git features, which is OK as it’s not mainly a source control application.

We can see only primitive features there, which may suffice for personal or small projects, but if you are working on a larger team, you will find it very difficult and sometimes impossible to use source control using the IDE only.

Xcode’s Source Control


Some Engineers may also notice that markers near files like “A”, “M” and “C” etc.. are stuck most of the time too, so you wont be able to directly tell about file statuses if they are added, modified, conflicting, etc..

Convincing backend engineers to use the terminal will be easier, because GUI will not automatically update repo’s trunk on a server daily at 1:30 AM, but a cronjob that deals with the CLI can easily do this, on the other hand, convincing a mobile developer about this can be a bit more more difficult, because the need for this is not easily demonstrated.

I will start directly with discussing few real life examples.. I’m sure I can think of dozens of cases, but let’s keep this post small.. I will list the commands I use, so you can have an idea about the more power we can have in terminal.

1- PR Reverts: a feature introduced by Github, PR reverts, say you have an already merged pull request, and you want to revert it before a tight-deadline like a branch cut, using Github’s revert feature will not ask about details of commits to be removed, it most probably will remove commits that were merged in the PR, so you may easily end up removing extra stuff that is irrelevant by accident.

But using such command, you will have fine-grained control about what commit to remove or keep.

git revert --no-commit someHash

2- Submodules: if you have nested git repos (submodules), such feature maybe not be existent in most GUI tools.

I normally have terminal open all day, and I can’t live without it 🧐, I hate to push buttons without knowing exactly what each button does, tools can come and go, the CLI will be always what GUI tools are built on.

It’s convenient to set up install scripts, build scripts, deploy scripts, etc.. when working on a large team, one will have no idea what exactly happens in the GUI based app, and in the old times I’ve seen colleagues do bad things impossible to restore without the CLI 🀦🏻.

I feel several times faster using the command line than clicking through with a mouse.

GIT GUI tools were meant to mitigate complexity, but to me, they seem to add more complexity if the project is large, I once seen non-git standard terminology, which normally makes things harder in general.

PS: the only real use of source control in Xcode is the diffing tools, it visualizes diffs perfectly. πŸ€“

git add
git annotate
git bisect
git blame
git checkout
git checkout -b
git cherry-pick
git clean -fdx
git clone
git clone –single-branch
git commit
git commit –amend -m “New commit message.”
git config
git diff
git diff –check
git fetch
git gc
git init
git log
git log –all
git log –oneline
git log –summary
git log -p
git merge
git pull –rebase
git push
git push –set-upstream origin
git push -u origin feature_branch_name
git rebase
git remote -av
git remote add
git reset –hard
git restore
git revert
git rm
git shortlog
git show
git stash
git stash list
git stash pop
git status
git tag
git worktree
common git commands that I use (sorted alphabetically)