From Eye Tracking and Music Haptics to CarPlay updates, the new accessibility features in iOS 18 promise to transform how users interact with their devices, further strengthening Apple’s position as an accessibility powerhouse.

Apple’s history of pioneering accessibility features for iOS dates all the way back to 2009. That was when the launch of the iPhone 3GS introduced VoiceOver – still a flagship feature that is typically the first one to become supported in most apps.

In a recent update, 15 years after the initial VoiceOver release, Apple announced new accessibility features in iOS 18 and iPadOS 18, coming this fall. They are some of the most innovative and complex ones so far. 

Since we got the opportunity to try out the features during beta testing, we can confirm from experience that they are indeed quite impressive. Have you ever imagined being able to control your phone using just your eyes? Or feel the music? By leveraging the power of artificial intelligence, Apple’s ecosystem is becoming more accessible to even more people, and this year feels like a major milestone in the Cupertino company’s accessibility journey.

A truly revolutionary feature that was originally developed for Apple Vision Pro made its way to iOS and iPadOS. Designed for people with physical disabilities, Eye Tracking offers a completely new way of controlling our phone or tablet. Users can move through app elements and utilize Dwell Control to select each one, enabling additional functions like physical buttons, swipes, and other gestures using only their eyes.

Further, Eye Tracking can conveniently be triggered from shortcuts or Siri and is integrated with AssistiveTouch, a virtual, on-screen menu that allows users to perform various actions, such as accessing the Home screen, adjusting volume, taking screenshots, and using gestures, without needing to use physical buttons. 

Having tested the feature in the very first beta release, we must admit that it still feels a little rough around the edges. However, it will undoubtedly prove very handy in many use cases, which can also be said for Music Haptics.

The feature introduces a new way for people who are deaf or hard of hearing to experience music on the iPhone. When Music Haptics is turned on, the iPhone will use its Taptic Engine to work in sync with the audio to generate patterns of taps, textures, and vibrations.

The feature not only enhances the Apple Music experience but can add another dimension to sound in third-party apps. Developers can take advantage of Apple’s API and add Music Haptics to their own music applications.

We should note that this is an iPhone-only feature because the hardware that supports it is not included on the iPad.

Introduced in May 2023, Atypical Speech has already been available in iOS 17. The feature enhances the communication experience through personalized speech recognition and text-to-speech functionalities.

Primarily intended for people with acquired or progressive conditions that affect speech, such as cerebral palsy, amyotrophic lateral sclerosis (ALS), or stroke, the feature leverages artificial intelligence to improve speech recognition for a wide range of users.

Third-party libraries shorten development time, provide easy access to additional features, and help us focus on the core aspects of our projects. Once again, we present you with our selection of the best iOS libraries of the year. 

Any iOS engineer’s day would be much more complicated without the many tools and libraries supporting the development process.

Knowing which libraries to use is essential for shortening development time and finding better solutions to common problems. This article showcases all the libraries our iOS team loves to use and utilize, as well as the ones we have created for our needs.

We’ve been presenting our top selection of libraries since 2015 and showed you some of our favorite ones in 2020 and 2021. It is important to write about this topic from time to time since our work is sometimes heavily concentrated on using libraries and even creating new ones.

This year, we’re bringing a selection of tools we use the most. Some of them are oldies but goldies that continue to stay relevant for our everyday work.

Keep in mind that using third-party libraries comes with a responsibility. If you plan to use the libraries on the list, or any libraries in fact, you should ask yourself these two questions first:

If both of your answers are yes, feel free to take it to the next level.

I couldn’t imagine a world without this library, and I would immediately notice it missing from the project. It is a simple and powerful tool for defining constraints, resulting in better, more responsive, and faster development. Its fluent and expressive syntax provides many functionalities, including anchoring views, simplifying aspect ratio, and other advanced features.

It’s hard to call Firebase just a library since it contains a suite of tools that simplify different aspects of app development, such as authentication, real-time databases, cloud storage, messaging, analytics, crashlytics, and more.

Firebase is well adapted across our projects and has become our tool of choice for achieving the goals mentioned above.

A popular library in Swift with the primary goal of simplifying interaction with the Keychain. It offers a simple and easy set of APIs for storing, retrieving, and managing secure information. We recommend using it if you want to enhance your app’s security and protect its data from unauthorized access. For example, you can see how easy it is to save and get a password from the Keychain.

Sourcery is a powerful code generation tool that automates repetitive tasks using user-defined templates. This is very useful in mocking when you have to create many new testing files that just use different class names. 

With Sourcery, you need to make your protocol inherit Automockable, and you are all set. Also, the last thing to mention is that Sourcery works with SwiftLint, so all your generated lines will conform to best practices from the beginning. 

SwiftLint is an extensively used and highly configurable library that enforces Swift’s writing style and conventions for Xcode projects. It helps keep a consistent and readable codebase by applying a set of rules defined by the creator and the development team. 

Lottie is a valuable tool for developers who are always trying to enhance their apps’ look and feel. It supports vector-based animation, easy installation, cross-platform compatibility, and more. Since animating can be pretty complex, Lottie will easily incorporate complex animations created with tools like Adobe After Effects.

It is very easy and straightforward to import and configure animations using Lottie.

Charts is a library that integrates different charts into iOS applications, providing a very customizable solution for data visualization. It supports different chart types like line, bar, pie, radar, etc. Users can interact with charts through various gestures, animations, and more.

You should note that since iOS 16, Apple has released its own version of charts, and this may be the last time we’ve written about this tool.

Kingfisher is our go-to tool for image loading and caching. You provide an image URL for the tool to download, which sends it to memory and disk caches and then displays it in many UIKit-friendly classes. Kingfisher can also help with async image loading, placeholders, transition effects, processing, and much more. It also has SwiftUI support.

Alamofire is one of the best and most used frameworks in iOS development. Its main task is simplifying networking requests, handling responses, authentication, and other useful capabilities the tool provides. 

From top to bottom, you make your request, validate your response, and decode it into necessary data models.

Reactive programming is simple, elegant, and powerful. It intends to enable easy composition of asynchronous operations and data streams in the form of Observable objects. Learning this way of working takes time, but once you know it, you’ll never use it any other way.

RxCocoa goes hand in hand with RxSwift (since it includes some iOS-specific features). For example, button tappings, text inputs, and all other UI elements are way easier to maneuver when RxCocoa is on.

To be fair, we have started moving towards Combine where it makes sense, but this process is still ongoing, and we’ll still heavily utilize Rx in years to come.

Like any other development team, we are constantly working on new ideas and have created many libraries we use heavily in our projects. Check them out below as well.

There are many libraries in the ocean of iOS. Here, we picked some of our favorites that make our lives easier and shorten the development time so we can use them in other productive workflows. If you have another one we might have missed, feel free to contact us on social media.

Since my earliest days in iOS development, I have wondered about the best way to work with colors.

If you don’t believe me, try painting an error message green – and wait for the users to get confused. 

After years of using colors in different areas like design, programming, and even cooking, I can conclude that color is a property added to basically everything surrounding us, including us.

My opening rant aside, the use of colors is an important topic for any development team. A structured approach to color-naming helps in onboarding new team members to our way of working, and what’s more, adding dark mode support becomes easier. 

This article will present our naming system and provide a way of implementing it. The implementation example we use is iOS-based, but the naming principles can be applied on any platform.

Our team used to have a confusing naming system that took a lot of time to learn. Wanting to up our efficiency and lessen the confusion, we set out to create a simple system for naming colors that would also be easy to explain to new team members. This way, they can use it much sooner, and as a bonus, save the nerves they would rack trying to discern what color is jupiterSunset and what is tigerCat.

First of all, a good naming system requires you to communicate with the app’s designer. They have their own color palette, which means you have a list of colors you need to name. When deciding what names to use, take into consideration these three simple facts:

Learning how to build the UI without using storyboards is an option most iOS developers will encounter at some point during their work. You could call it a natural evolution that occurs as our knowledge expands and we start to get a glimpse of a very different world.

The theory behind this way of thinking is quite simple – ditch the storyboard and start writing your views using just code. However, bear in mind that you’re diving into an ocean of complexity called UIKit without the inflatable floaters a storyboard provides, and you will probably need to take some time to learn new swimming techniques.

The answer is not that simple. Even our iOS team remains neutral on this topic and doesn’t favor one option over the other by default. Since each comes with its benefits, it’s a choice based on the project situation and its necessities.

Why not storyboards? Creating user interfaces using storyboards is simple, and it’s what Apple recommends to everyone starting out in iOS development.

It’s easy to pick an element you want to display and position it on a screen. When you learn how to manipulate these elements to get them to look like you want, then you already know how to use outlets and constraints, connect the views, etc.

We use storyboards on our projects, and you’ll find them in practice for many types of screens – from the smallest ones containing only two labels to large scrollable ones where each section has some labels, images, or other elements.

However, we strive to make everything reusable, which can often get complicated when using storyboards. Not impossible, though.

Mobile app consumers, product owners, and developers all have one thing in common – everybody wants a beautiful, functional, and crash-free app.

However, when talking about mobile app development, developers tend to spend so much time just testing the app and checking if everything works correctly in certain conditions.

Depending on the tools we decide to use, we can either waste time reading monosans letters in the logger or have everything implemented in an interactive way so that the information we need is reachable at our fingertips.

We’ve developed two libraries to help you take advantage of debugging and make your life easier.

Collar is a library for analytics debugging that can show you three types of analytic collecting data as they happen in the app: events, screens, and user properties.

It is easy to configure and straightforward to use – it’s as simple as just importing the library and using several methods to collect the data for preview.

import Collar

After you’ve imported the library, you can add three analytic collecting types. To collect events, see the code below.

As you can see, collecting the data is simple and does not require much work. However, please remember that Collar does not send out any analytics data to remote services. Developers are left with solving this within their own codebases, and Collar is just there to reflect the current state of the analytics data.

To display events, you can choose to view it as a popup every time when the Collar collects any analytics or at some specific point which will display all of the collected data.

You should insert the line below to view the analytics as a list at a specific point in the code lifecycle.

AnalyticsCollectionManager.shared.showLogs(from: viewController)

To see it as a popup every time something gets collected, insert the code below.

You can also choose to receive notifications when new logs are added to the list, so your app can observe the AnalyticsCollectionManager.Notification.didUpdateLogs notification.

Bear in mind that AnalyticsCollectionManager and LogItemPopupQueue are not meant to be used in production builds. The best option is to exclude Collar from your production targets/configurations altogether. This can be done by following the Podfile configuration example below.

pod ‘Collar’, :configurations => [‘Development-release’, ‘Development-debug’]

Sentinel is a library created with simplicity in mind. It allows developers to configure a single entry point for every debug tool being used. This library’s primary goal is to give developers the ability to configure the screen with multiple debug tools that will become available on some event (e.g., screen shake, notification, etc.).

The library is available for both Swift and Objective-C.

Sentinel is the main class used to set up the Sentinel that will be used in the application. The Sentinel object can be configured with the setup method by the Configuration object.

The Configuration object contains multiple objects that define general Sentinel behavior. All the inputs this object needs for initialization are trigger, sourceScreenProvider, and tools.

The self-explanatory trigger object is a type of Trigger that defines the event that will trigger the Sentinel. This will result in presenting the Sentinel to the developer. At the time of writing this article, three trigger types are supported by default – ShakeTrigger, ScreenshotTrigger, NotificationTrigger. Bear in mind that new triggers can be added as well, they just need to conform to the Trigger protocol.

SourceScreenProvider is a type that provides the view controller from which Sentinel is presented. For now only one (default) type is supported.

The array of Tool objects is the last one required for final Sentinel configuration. This type of object represents the tools which will be available for use in Sentinel. Multiple tools are already supported by the library, but you can also create custom ones.
To create custom tools, create a new class that conforms to the Tool protocol defined below.

Based on the code above, you need to provide a name and a presentPreview method, which is used for presenting the tool view controller from the sourceScreenProvider view controller defined in the Sentinel configuration.

Adding Sentinel to your project is done by defining Sentinel.Configuration and calling the setup method inside the AppDelegate‘s well known application(_:didFinishLaunchingWithOptions:) method. All that said, creating a Sentinel that triggers all the debug tools to display on device shake would look like the code below.

To conclude, both Sentinel and Collar are very useful libraries. The former is a library that helps you save time by organizing all your debug tools into one place, and the latter allows you to observe the flow of analytics data visually.

You can check them out here: Collar and Sentinel.

With another year of experience behind us, we bring you a handy list for every iOS developer’s collection – the curated list of the best, most important, most useful iOS libraries, updated for 2021.

If this feels like deja vu, it’s because we published top 10 iOS libraries lists in 2020, as well as the age-old article top 10 iOS libraries of 2015.

Those articles proved a great starting point for developers looking to increase their productivity and avoid doing unnecessary work. With the same goal in mind, we’ve kept some oldies goldies on the list, but added the hottest hits of 2021. As our knowledge grows, we recognize what stands the test of time and what should be replaced with something new and innovative.

Speaking of innovation, this time around the libraries are sorted into two categories, development and testing. It might help you navigate faster if you’re looking for something specific.

We’ve also decided not to limit ourselves with a top-10 format, and just present all the libraries we believe may prove useful.

We’ve said it time and time again: It is really important to use third-party libraries responsibly. Here are some points that should help you decide whether a library is worth importing to your project:

It should also be noted that this list was created by surveying our recent projects and needs, and only contains sources or opinions of the iOS team at Infinum.

The Swift version of Rx tries to port as many concepts from the original version as possible, but some of them have been adapted for a more pleasant and performant integration with the iOS/macOS environment.

Like the original Rx, its intention is to enable an easy composition of asynchronous operations and event/data streams. KVO observing, async operations and streams are all unified under the abstraction of sequence. This is the reason why Rx is so simple, elegant and powerful.

Here’s a simple example of how RxSwift can be used to create a logic for enabling a login button that checks two things – whether the username and password have both been entered, and if the password is of appropriate minimum length.

This is just scratching RxSwift’s surface, but you can already see how it can make your life easier. RxSwift has a steeper learning curve than most libraries you could include in your projects, but once you get the hang of it, you’ll be thankful you did and will probably never look back.

The other library that RxSwift goes hand in hand with is RxCocoa. It is built around the Cocoa API, making it easier to use in a reactive manner. For example, check out how easy it is to catch all button tap events, without dealing with IBActions.

Note: Combine will probably start slowly sunsetting RxSwift at some point. However, since it requires iOS 13 as the minimum OS version, we’re still not at a point where we can start using it in most projects. Until then, RxSwift will prevail.

SwiftLint is a tool used to enforce Swift style and conventions, loosely based on GitHub’s Swift Style Guide.

SwiftLint hooks into Clang and SourceKit and uses the AST representation of your source files for more accurate results.

Its rule list is quite extensive, and covers pretty much everything you would want to keep track of in a well-maintained project. It also has the option to disable rules per-file or even per-line, but use those responsibly. Silencing a warning about a 700-line file or a too long method is maybe not the best tactic.

Alamofire is an elegant and composable way to interface to HTTP network requests. It builds on top of Apple’s URL Loading System provided by the Foundation framework. At the system’s core are the URLSession and URLSessionTask subclasses.
Alamofire wraps these APIs, and many others, in an easy-to-use interface and provides a variety of functionalities necessary for modern application development using HTTP
networking.

From top to bottom, you request the endpoint, validate the response by ensuring the response returned an HTTP status code in the range 200–299 and decode the response into your data model. Easy peasy.

Let’s be honest, animations in an application make a huge difference. They grasp the user’s attention and steer them through your app’s flow, all the while providing a fun and memorable experience. Since creating animations by hand using UIView or CoreGraphics animations can prove to be quite challenging and time-consuming, Lottie provides us with a perfect tool to incorporate designers’ creations into our applications.
Lottie loads and renders animations and vectors exported in the bodymovin JSON format. Bodymovin JSON can be created and exported from After Effects with bodymovin, Sketch with Lottie Sketch Export, and from Haiku.

After importing Lottie into your project, this is all the code needed to add a beautiful animation to your app. Quite a timesaver.

If there was an award for libraries called “Simple integration, huge benefit”, I would undoubtedly hand it out to SVProgressHUD. Basically, all it does is display the progress of an ongoing task on iOS and tvOS. Using this library is as easy as calling the method;SVProgressHUD is a singleton, so all you have to do is use the methods show() and dismiss().

Even though it is simple to use, it can be customized in various ways – from animation type to ring radius, icons, and it even offers haptic feedback on success, info or error statuses.

KeychainAccess is a simple Swift wrapper for Keychain that works on iOS and macOS. It makes using Keychain APIs extremely easy and much more manageable to use in Swift.

Saving data to the Keychain and retrieving it has never been easier:

Kingfisher is a powerful, pure-Swift library for downloading and caching images from the web. It downloads the image from its URL, sends it to both the memory cache and the disk cache, and displays it in an UIImageView, NSImageView, NSButton or UIButton. When you try to retrieve an image with the same URL later, the image will be retrieved from cache and shown immediately.

It also provides many powerful additional options such as showing a system indicator and a placeholder image while downloading, built-in updating transitions, extensible image processing and formatting and much more. A must have if you’re working with remote images!

SnapKit is an Auto Layout library that simplifies writing auto layout in code, so that a minimal amount of code is needed, but without losing readability. It is type-safe by design to help you avoid programming errors while coding your user interface.

It’s also very powerful when it comes to views whose constraints are updated frequently. Remaking constraints is much more pleasant than dealing with Auto Layout by hand:

Sourcery is a library that finally puts a stop to writing repetitive code and creates better architecture and developer workflows. One of Sourcery’s best usages comes with implementing Mocks, and it is usually this kind of code:

With Sourcery, all you need to do is make your protocol inherit Automockable, like in this example:

extension ViewInterface: Automockable {}

Now you know how Sourcery has been a great help to our team and it is one of our favourite libraries for generating tests.

We’ve put these two libraries together as they usually go hand in hand. Quick is a behavior-driven development framework for Swift and Objective-C, while Nimble is used as an assertion framework that makes it easy to match expectations on tests. To get an idea how tests written with these frameworks look like, check the code below.

OHTTPStubs is a library designed to stub network requests by using method swizzling. It works with NSURLConnection, NSURLSession, AFNetworking, Alamofire or any networking framework that uses Cocoa’s URL Loading System.

This library comes in handy in several situations:

If you’d like to learn more about implementing such a demo mode, you can check out one of our previous articles.

RxTest and RxBlocking are both parts of RxSwift. They are available via separate pods and also require separate imports.

RxTest is a great addition for testing Rx code. It comes with a TestScheduler, which is a virtual time scheduler. RxTest gives out two types of Observables: HotObservables, which replay time specified events using test scheduler, and ColdObservables, which behave just like regular ones.

RxBlocking gives you the power of converting a regular observable sequence to a blocking observable, which blocks the thread it is running on until the sequence times out or completes. This makes it a perfect tool for testing asynchronous tasks.

We also use our own libraries in most of our projects, but since these are our open-source libraries, it did not seem right to steal the spotlight from other popular third-party libraries. However, you can check them out below as well.

Prince of Versions – used for easier versioning of your applications, allows you to prompt your users to update the app to the newest version.

Japx – lightweight JSON:API parser that flattens complex JSON:API structure and turns into simple JSON and vice versa

Locker – a lightweight library for handling sensitive data (String type) in Keychain using iOS Biometrics features

I18n – a library that allows you to localize your app much easier, by adding custom properties to UI elements and setting up available languages within the code.

Loggie – used for capturing all HTTP/S requests the app makes and showing them in a simple table view, enabling easier API debugging.

Also, be sure to check out Nuts & Bolts, Infinum iOS team’s repo containing a centralized collection of commonly shared and reused code.

Do you use the same or similar libraries in your work? Or perhaps you know of other useful libraries that should be included in this list? Let us know via social media – we’re always happy to learn new things about iOS.

Until next time, happy coding!

Ever since the first iPad release in 2010, this lightweight, big screen device has gotten more powerful hardware with each iteration. It has given developers the opportunity to create a variety of apps, from beautiful, graphic intensive games to Apple Pencil-supported apps for drawing. An iPad can even run things we never would’ve imagined these days.

However, until WWDC 2019, the software inside the iPad was just a scaled-up version of iOS, minus a few distinct features that were custom-created for the iPad. To say the least, it didn’t look like much.

Then, in June 2019 at WWDC, Apple finally offered a solution for the problem in the form of the iPadOS 13.

In the background, it featured everything iOS 13 did, plus some of the functionality features created specifically for the iPad and based on the philosophy of the device itself. In addition to Home Screen, multitasking, Safari, and Sidecar changes, there was also mouse and keyboard support, which marked the beginning of change in how people can use their iPads.

However, the new features hardly offered any info about designing the apps other than how to adapt the design to the newly introduced dark mode.

Luckily, in the summer 2020 edition of WWDC, Apple decided to push the iPad experience even further with iPadOS 14, introducing the new Scribble mode, a compact UI, and several essential system-wide redesign features.

This new design took the best ideas from macOS and iOS and combined them into something that looks new but feels very familiar. It reminded us that the iPad is a device in its own right, and urges designers and developers to make an effort and adapt a digital product’s design according to the device it will run on.

When adapting your current iPad apps, you should revolve around two goals, or checkpoints, depending on the app and its purpose: layout and user interaction.

Can you tell what’s wrong with the user experience in the screen below?

We can see a tab bar app with the Home screen, and that the enlarged iPhone interface doesn’t really work. By applying a few simple steps, we can make this app easier to navigate and utilize space in a better way.

Ever since iPadOS 13, iPad apps come in two width classes – regular and compact.

Compact sizes are used for slide-over apps. This means that if this app happens to be displayed in its compact width, the sidebar will never appear and the user will navigate through tabs. However, once any app is in its split view or full size, the sidebar is the way to go.

Apps should never use both the sidebar and tab bar at the same time because it can be confusing to the user. Stick to one option depending on the app width.

Let’s add the sidebar.

With the iPadOS 14, sidebars do not only display navigation but can also be customized by the user. For example, users can simply drag and drop favorite artists into the sidebar, making the most important content easily accessible. Awesome!

Sidebars can be toggled with a button that comes automatically, after which the full size of the view will emerge. However, if you want to access it in portrait mode, you have to swipe from the left side to the screen and it will present itself.

The best use case of the sidebars is quick and easy access to important content. Don’t go too deep into the hierarchy because this kind of UI is not suitable for that.

When talking about content size, always think about displaying it in a sense where you can put as much as possible in a way that is pleasant to the eye and readable.

The next screen shows things you should avoid.

Imagine owning a 12.9 inch iPad Pro and being able to see only six albums at a time. Does that make sense at all? And what if I told you that with a simple readability rule, you could put more content on a single screen, without forcing users to scroll through six things at once?

Here’s how it works.

This has a lot to do with modals and popovers. If possible, modals should be avoided unless using them really makes sense. Their actions may be better presented as a popover or a simple toolbar.

The end result of either option is staying in the same context of the screen you are currently on.

For example, using a modal in the screen above doesn’t make sense at all. Since the content behind those actions is under their direct influence, the best way of representing them is within the same context to which they are applied.

Now, the only thing left is to check whether there is enough space to put them. In this case, the answer is yes.

This way of displaying actions provides more context to the content and gives the user ability to use these actions much quicker than before.

There have never been more possibilities to use an iPad. What used to be just a multi-touch device nowadays has a pencil, keyboard, and mouse support.

This means that you can easily integrate keyboard shortcuts into your app. You can also combine multiple interactions to achieve the specific usage functionality. For example, keyboard and mouse combined can be used for selecting items the same way like we’ve been doing it on macOS for years.

Repeat after me: Great iPad apps shouldn’t be lovechildren between a Mac and an iPhone, stuck in 2016.

Even though adaptation cannot be applied on every app, or every screen of the app, reorganizing the user interface in order to create a better user experience is probably easier than you think.

So add that sidebar and allow the user to customize it to achieve faster access to their favorite content, and take advantage of the new interaction methods to complement new usability options when developing your next iPad app.