The long-awaited spatial computer that seamlessly blends digital content and apps into physical space, enabling eyes, hands, and voice navigation, is finally here. And when we say here, we mean in our very own hands. We are so excited to use this revolutionary product, but we are even more excited about the opportunities that come with it.

Features of the Future

We’ll single out only some of them, not to overload you with the product details that Apple so beautifully outlined here. Building on the existing macOS, iOS, and iPadOS, the visionOS enables spatial experiences. This fantastic new computer provides you with an infinite canvas where you can move, arrange, and scale your apps to create a workplace you’ve always dreamed about while still staying present in the world surrounding you. The Apple Vision Pro camera is something else: it’s the first 3D camera from Apple, making spatial photos and spatial audio a reality. In addition, the Vision Pro offers more pixels than a 4K TV for each eye, so any space you’re in transforms into a personal theater to enjoy your video and audio content in the most magical way possible.

According to Forbes, the first patent related to the technology used in Apple Vision Pro dates back to 2007, when the iPhone was introduced. In particular, it was a patent related to a head-mounted display, as Patently Apple reports: Using one or more optical and digital components, the personal display device may adjust displayed media to overlay features of a theater, stadium, or concert facility, thus giving the user of the individual display device the impression of being in the facility. Since Apple Vision Pro has been in the works for well over a decade, dare we think what Apple might have in store for us for the next couple of decades? Whatever it may be, we’ll be ready for it just like we’re ready for this fantastic new spatial computer today.

Creating New Realities with visionOS

Our team couldn’t wait to get their hands on the Vision Pro, but they are also more than ready to start building apps for it, considering the fantastic new features we now finally have a chance to use, explore, review, and build on. In addition, reimagining our client’s needs in the context of spatial computing is something that we’ve been looking forward to for a long time now, and it’s definitely a pathway for our clients to gain the upper hand.

At Aras™️ Digital Products, we don’t just peek into the future; we sculpt it. Our vision extends beyond screens and pixels — it dances in the ethereal glow of spatial computing. Imagine a symphony of code and light orchestrated by the Apple Vision Pro, our cosmic wand. This isn’t mere technology; it’s alchemy. With every line of code, we weave immersive tapestries that whisk our users across time and space.
Remember those dusty reels of old HNK Hajduk matches? Well, now you’re not just a spectator; you’re a time-traveling aficionado, reliving the crowd’s roar and the thrill of victory. And bathrooms? Oh, they’re no longer mundane. With a dash of spatial magic, you’ll design your Kohler sanctuary — a fusion of elegance and functionality. The tiles align, the faucets hum, and the mirror winks at your reflection, whispering secrets of serenity. But wait, there’s more. Buckle up because you’re about to test-drive a Porsche — not on asphalt, but in the nebulous expanse of our digital realm. Feel the purr of the engine, the wind tousling your virtual hair, and the thrill of acceleration. And when you step out, you’ll carry that exhilaration into the real world.
At Aras™️ Digital Products, we don’t ask what kind of app you need; we ask what universe you want to inhabit. The Apple Vision Pro is our stardust, and we’re here to make your cosmic dreams a pixel-perfect reality.
– William Sullivan, Business Development, Aras™️ Digital Products

Reimagining Art

The visionOS offers tremendous potential when it comes to every aspect of art. And that is where we step in to shape the future: we want to explore and build on the space in which art and technology meet, where they co-exist, intertwine, and blend. If you are an artist with ideas that go along these lines, you have to let us know so that we can start creating something fantastic together and make the most of the spatial computing era.

It will be exciting to see creativity and cutting edge technology come together with Apple Vision Pro. We passionately believe that uniting art and technology is a path to greatness and we are ready to take it. Our commitment to innovation is an important part of our work which keeps our imagination going, allowing us to see no boundaries when it comes to design and development.
- Ivan Aras, Head of Design at Aras™ Digital Products

Real-Life Magic in the Making: Meet the Apple Vision Pro was originally published in Aras™ Digital Products on Medium, where people are continuing the conversation by highlighting and responding to this story.

Screenshot automation on iOS with Bitrise & Fastlane

Screenshot automation is an important feature if you need to make sure everything is displayed properly on all the variations of languages and screen sizes. This can save you a huge amount of time testing all these cases.
I spent some time trying to find the best tool to do this and since I’m using Bitrise for CI/CD I wanted to keep everything in the same channel.

For running UI Tests on real devices, I’m using Firebase Test Lab, but it doesn’t support making screenshots for iOS (for Android apps FTL is a good solution).

I’m going to use the iOS project named ScreenshotAutomation with UITests included for this example and a new Bitrise project named ScreenshotAutomation.

Fastlane

The first step we need to do is add the Fastlane to this project and set it up for making screenshots.

Make sure you have the Fastlane installed and in the terminal just run `fastlane` in the project root folder.

This will start to configure Fastlane for your project, you just have to follow the steps provided.

Don’t forget to create a new Schema and mark it as Shared. I named it FastlaneScreenshotAutomation.

Your project should look like this

Now you can continue with Fastlane setup. Select the new schema you created.

I’m not going to use these screenshots for App Store Connect so I’ll skip this step.

This will create a new Fastlane directory in your project. There are two here that we are going to need.

Snapfile — configuration for our screenshots

Fastfile — defines the lanes that Fastlane can use

In the Snapfile, I’m only going to set up the English language and a few screen sizes. However, this file allows for more configuration and I encourage you to check it out.

This is what my Snapfile and Fastfile look like

You can always check available Lanes with `fastlane lanes` command and run the lane with `fastlane [lane_name]`. We have just one lane, named `screenshots` as you can see in the `Fastfile`.

Run this lane and it will create your first screenshots. Make sure your iOS version is properly set for ScreenshotAutomationUITests target (Build Settings -> iOS Deployment Target) and that your Schema looks like this. Also, I opted out of using Scene Delegate since that can cause some problems.

This is our final result

You can also add some more options to Snapfile. You can find the list of the options by running fastlane action snapshot

I suggest that you add screenshots directory to .gitignore as this is not something you would need in your repo.

Bitrise

For the Bitrise part, I created a new project, connected my GitHub repo (make sure you pushed all the changes from above).

You can skip adding the app icon and webhooks in project setup.

Now we have to create a workflow for screenshots on Bitrise. This should already be done by default and it should look like the image below. I also like to enable verbose logging on the fastlane step until I make sure everything is working fine. To make sure our screenshots are exported correctly we have to try out a build.

This should be in Build - Apps & Artifacts. If you can’t find your screenshots make sure you add the correct Input variables in the Deploy to Bitrise step. I like to compress my artifacts so I set this to true. You can find the exact value for Deploy directory or file path by checking where your screenshots.html is stored in your build log. For me it us /Users/vagrant/git/screenshots.

In the end, it should look something like this

Your build will take some time, so be patient, but your final results will be worth it and this could save you quite some time in the future. You can also add triggers to this build whenever you want so make sure you investigate all that Bitrise offers.

Screenshots automation for iOS with Bitrise & Fastlane was originally published in Aras™ Digital Products on Medium, where people are continuing the conversation by highlighting and responding to this story.

Using MVVM instead of MVC, Apple’s default architecture, has turned out to be a good choice for me. I would like to show you some problems that I ran into using MVVM with RxSwift and some solutions that made my life easier.

In this article, I would like to show you a few things about using the Model-View-ViewModel (MVVM) architecture with RxSwift. We’ll cover a few concepts that made my life a whole lot easier, but also show you some problems that I ran into. When setting up a new iOS project, Xcode defaults to using the Model-View-Controller (MVC) architecture. Switching to MVVM has turned out to be a good choice for the projects I work on.

👉 If you are familiar with the concept of MVVM you can skip to the examples section below.

Comparison between MVC and MVVM

Before getting started with MVVM, I’ve used MVC as my default architecture. The easiest way to get started with MVVM was to compare it against MVC, so I think that might be a good way to familiarize ourselves with it.

Let’s consider the general idea and flow behind MVC.

• The View handles some sort of user action by pinging the Controller.
• The Controller is in charge of updating the Model with the data received from the View.
• The Model handles any data changes and notifies the Controller.
• The Controller updates the View.

The diagram below should make things a bit clearer.

In the case of web development, where you have a clear separation of these three layers, this sounds great! But when developing for iOS, things can get a little more messy.

It is easy enough for us to separate the Model and that stays the same for both MVC and MVVM.

It gets a little bit more complicated when we try to separate the View and Controller parts. If you have been using MVC in iOS you must have noticed that we are missing something. Where are our View and Controller layers? We have the ViewController that should act as a View, yet we still write a huge amount of business logic, data manipulation, networking and UI inside of that ViewController. Even for the most basic of screens, our ViewController can get pretty big, resulting in two things.

1. A huge amount of code that is very hard to maintain.
2. It is almost impossible to test anything in this mess because our presentation mixes with business logic.

What if we separate this mess into two distinct and separate layers, making the ViewController responsible only for the UI and some other layer responsible for the business logic. That is exactly what MVVM does. It introduces the ViewModel as a layer between the View and the Model.

The responsibilities of the ViewModel are to update the Model and prepare the data for the View. A great thing with MVVM is that the ViewModel provides some kind of data binding for the View so it can update automatically on any data change. There are a few ways to implement data binding on the ViewModel: delegates, Key-Value Observing, Reactive Programming and some others.

My favorite approach is Reactive Programming using RxSwift. If you are new to the Rx world you might have some problems following along with the examples, so I recommend you come back here after you read more about it. Or you can continue reading and ignore the syntax, just try to get your head around the idea and how things work.

👉 Quick tip: The ViewModel should never have a reference neither to the View, or any UIView subclasses. As a rule of thumb: if you import UIKit you are doing something wrong.

🛠 Examples

The best way to make all this a bit clearer is to demonstrate it in a simple example. Some things we are going to cover:

• how data binding works,
• the convenience of flatMapLatest,
• a few problems I stumbled upon.

Download the project so you can follow along. If you are unfamiliar with some of the libraries I used, just ignore them, they are not relevant to what I’m about to show.

⬇️ Download the example project here.

Binding

👉 Make sure you are checked out in the master branch.

Once you start the app you are presented with a table populated with a list of developers. Selecting any of them sends you to the Developer screen. On this screen, we have a counter and a button that increases the counter. Pretty useless app, but that’s not the point. 😇

Open the DeveloperViewController, and the DeveloperViewModel files. We are going to bind the text presented in the label to correspond to data from the ViewModel. We are also going to bind the + button taps so we can increase the counter.

On lines 30 and 31 in the DeveloperViewController, we are creating an Observable that is going to emit an event every time the user taps the + button.

let increaseCounterTaps = increaseCounterButton.rx
    .tap
    .asObservable()

self.developerViewModel
    .setupIncreaseTaps(increaseCounterTaps: increaseCounterTaps)

In the DeveloperViewModel we are listening to these events, increasing the counter every time it happens, and binding those changes to the counter Driver. We are doing this so we can listen to these changes in the ViewController. This is the data binding we were talking about before.

func setupIncreaseTaps(increaseCounterTaps: Observable<Void>) {
    counter = increaseCounterTaps
        .do(onNext: { [weak self] a in
            self?.counterState += 1
        })
        .flatMap { [weak self] _ -> Observable<String> in
            guard let `self` = self else {
                return Observable.just("0")
            }
            return Observable.just("\(self.counterState)")
        }.asDriver(onErrorJustReturn: "0")
}

func setupObservables() {
    developerViewModel.counter
        .drive(self.counterLabel.rx.text)
        .disposed(by: disposeBag)
}

flatMapLatest

In this part, I’ll show you how the flatMapLatest operator works on the search example. For this part, I’ve built a DataService service that simulates fetching data from the remote server. As is often the case in the real world, every response from the server has some delay. To demonstrate this better, the delay is a bit bigger than your server response should usually be!

The idea here is that with every new letter typed in the search bar, we are asking the server for results for the corresponding term. At any given moment we want to present results for the last term inputted. So imagine you are searching for a developer named “John”. The last two searches are for “Joh” and “John”. If response for “Joh” comes after the response for “John”, we have to ignore it.

flatMapLatest is the ideal solution for our problem. The corresponding image is shown below and for code check the following files: HomeViewController, HomeViewModel, and DataService.

🤦‍ Problems

The last thing I want to touch upon are the most common problems that come up when using MVVM and RxSwift, and some of these have given me a lot of headaches. They can result in both bugs and crashes with your application.

Drivers

👉 Documentation for the Driver trait can be found here.

Use Driver when you are binding to the UI elements, it ensures you don’t touch UI from anywhere but the main thread and saves you from unnecessary crashes. It’s easy to change threads and even easier to forget about it and by using Drivers you don’t have to worry about going back to main thread before interacting with the UI.

You can find the example on the branch named no-driver-problem, just run it and try tapping on the + button in DeveloperViewController and see what happens.

Dispose Bag

Dispose Bag is there for you so you don’t have to worry about disposing subscriptions. Usually, this is done when the ViewController is removed from memory. But sometimes that is not the right time to dispose and the best example for that are the cells in the table view.

If you are adding disposables from a cell into tableView’s disposeBag, when the user starts to scroll and cells start to reuse, you are going to end up with multiple outdated subscriptions. This usually results in multiple calls to the method in charge of handling cell selection.

Example for using the wrong DisposeBag is on the wrong-dispose-bag branch, in the setupTableView method of the HomeViewController. Try scrolling the table on HomeViewController to get some cells reused, and keep an eye on the lines that get printed out.

Variables and PublishSubjects

When I first started using RxSwift everything seemed like it should be a Variable. That is because they bring mutability to the immutable world, but in most cases that is not good and they can be changed with some Observable. Use them with caution.

Retain cycle

I left this one for the end. I love it as much as I hate it. As we said before, dispose is called on deinit. But what if deinit doesn’t happen? This is a general problem with closures in Swift, but this example demonstrates it in the context of Rx.

Let’s start from the top to understand the problem. The ViewController has a reference to the DisposeBag.

By adding Disposable to the DisposeBag we are giving a DB reference to the Disposable.

The Observable lives within Disposable so Disposable has a reference to it.

If we use self inside Observable we are giving the Observable a strong reference to the VC and that results in the following retain cycle.

There are a few solutions to this problem, and they are all based on breaking the strong reference from Observable to VC.

• We can pass variables we are going to use to the capture list. I don’t like this one because it can get messy when using more than one variable.
• We can use unowned self but the problem here is if something goes wrong it results in crash.
• ❤️ My favorite one is making self `weak` and providing what happens if self is nil, like you can see in the `setupIncreaseTaps` function. Bulletproof!

This was my insight on MVVM with RxSwift, feel free to clap, share and comment. Thank you for your time, looking forward for any constructive criticism 🙂.

I don’t wanna waste your time explaining why writing tests is important since I suppose you already know enough about this if you came across this article.

I recommend reading the chapter about testing from Uncle Bobs Clean Code where he explains why is testing important in his own way, and why is it important to keep tests clean. He also explains five rules called F.I.R.S.T. in a bit more details. Let’s just keep in mind that test should be Fast, Independent, Repeatable, Self Validating, Timely.

We are using MVVM architecture, and you can read more about it in my blog post.

There are many different types of testing but this article is going to focus on the unit and integration tests.

My experience: How writing tests made me a better developer

You can absolutely skip this chapter if you are here just for the code or you want to see the way we implemented tests with RxSwift. I won’t even be mad, I just want to share my story about getting into writing tests and why it was useful to me.

I’m not ashamed to admit that this was my first big project where we decided that we are going to write tests. In the college, there were at least five courses where I was learning about the importance of testing, rules, benefits, etc., but I never fully understood how powerful testing can be. I even wrote tests for the several college projects but I was always writing them with just making them pass in mind, never have I thought about benefiting from them. They were there just so I can say “I’m writing test“ to make me look like a better developer or to meet the project requirements. How young and naive was I? And that was not that long ago.

With getting the new project we decided that this will be the project where we as a team want to take our skills to the new level, with great code coverage, unit, integration, and UI test, and same dedication for tests as for code, architecture, and design.

Writing first tests

So a decision was made and the time has come to start writing tests. We are not doing Test Driven Development so what I tried to do is write tests for the Login feature that I was working on already. The feature was almost done and I wanted to write tests for it to make sure if anything changes in the future, the changes don’t break anything, and if they do, to pinpoint to what is broken. Figuring out why would be much easier then.

• First time I created a new test class in the project using RxSwift I was pretty confused. I wanted to test observables in the view model, but I had no idea how to do it, how to make it a unit and not an integration test, how to simulate events from view controller etc.

I tried to write unit tests for LoginViewModel. Let’s see what this means.

• Unit tests — the lowest level of software testing where individual components — units are being tested. In this case, our unit is LoginViewModel, and writing tests for this unit mean that all the dependencies must be mocked and all the tests must depend only on LoginViewModel code.
• What that means in our MVVM architecture is that we want to tests each layer and every component for itself. So each ViewController, ViewModel , and Model has to have its own tests. For each component in our architecture, we need to have an associated test suite. Basically, you want to isolate and test each of your classes separately. All the services, managers etc. should be tested on its own, and have mocks that can be injected into the class that is using them.
• My LoginViewModel was depending on the few classes, like NetworkingService and ValidationService. Something like this.

class LoginViewModel {
    private let networkingService = NetworkingService()
    private let validationService = ValidationService()
    
    ...

}

• Looking at the code above makes me sick in the stomach now, because this code is hardly reusable or testable. How do you write mocks for these dependencies? The answer is protocols and dependency injection!

class LoginViewModel {
    private let networkingService: NetworkingServiceProtocol
    private let validationService: ValidationServiceProtocol
    
    init(networkingService: NetworkingServiceProtocol,
         validationService: ValidationServiceProtocol) {

        self.networkingService = networkingService
        self.validationService = validationService
    }
    
    ...

}

Swapping concrete implementations with interfaces allows us to write mocks much easier. Our mocks now just have to implement these protocols and we can do that with ease. And we no longer depend on the implementation of these services in our tests and now these tests can be called unit tests.

Once I wrote all the unit tests I start writing integration tests to see if different parts of the system work as they should when they interact with each other.

Integration tests — the next level of software testing after unit testing, This is the place where you want to test the interaction between integrated components in your system. Take ViewController and ViewModel for example. After we wrote isolated tests for SomeViewController, and for SomeViewModel, we need to test do these components work as they should once they interact with each other. This interaction in our MVVM architecture is implemented using RxSwift.

Writing integration tests now should be easy, like playing with legos, since you just connect components that you want to connect and use mocks for the others.

We have testers dedicated to writing UI tests using Appium so I’m not going to write about that since I have very basic knowledge of this.

Testing Rx code

When we started writing tests for our architecture we got stuck immediately, and the reason for this were bindings of View Controllers and View Models. The way we used to implement these bindings is that we would initialize View Model with Observables we needed to handle, or we would just assign them along the way, something like this:

class SomeViewModel {
    var counter: Driver<String>!

    init(increaseCounterTaps: Observable<Void>) {
        counter = increaseCounterTaps
            .flatMap
            ...
    }

}

or like this:

class SomeViewModel {
    var counter: Driver<String>!

    func setupIncreaseTaps(increaseCounterTaps: Observable<Void>) {
        counter = increaseCounterTaps
            .flatMap
            ...
    }

}

Soon we figured out that it was a nightmare to write tests for something like this. A solution we came up with was to switch from Observables to PublishSubject since it is much easier to simulate event on PublishSubject as all you have to do is:

let somePublishSubject = PublishSubject<Bool>()
somePublishSubject.onNext(true)

Also, this allows us to just bind events from the View Controller to View Model, and we are still using Observables in View Model for events that View Controller can subscribe on.

Example

Let’s pretend we have a View Controller that shows one label with counter value and one button to increase that value. View Model is responsible for handling each tap, increasing the counter and letting View Controller know that label should be updated and what it should be updated with. Also, we are going to write unit tests for both, and integration test to make sure these two together are working as they should.

Download example repo and check it out so you can follow along easier.

testIncreaseButtonTaps_WithOneTapEvent_LabelTextShouldBeOne method in CounterViewModelTests is the best example of simulating events from View Controller.

func testIncreaseButtonTaps_WithOneTapEvent_LabelTextShouldBeOne() {

    let observer: TestableObserver<String> = scheduler.createObserver(String.self)

    let correctResult: [Recorded<Event<String>>] = [next(0, "0"), next(1, "1")]

    sut.counterValue
        .subscribe(observer)
        .disposed(by: disposeBag)

    let allEvents = scheduler.createHotObservable([next(1, ())])

    allEvents
        .bind(to: sut.increaseButtonTaps)
        .disposed(by: disposeBag)

    scheduler.start()
    XCTAssertEqual(correctResult, observer.events)

}

Here we are creating TestableObserver that we are going to use to compare with some result of type [Recorded<Event<String>>]. Next thing we have to do is simulate some events, and we have to do it at exact time.

As you can see, we are simulating a new tap event at timestamp 1. The expected result is the label to have text “0” at the start and text “1” after the simulated tap. Run tests and check if everything is passing.

Check out CounterViewControllerTests to see how easy it is to inject Mock of a View Model.

Also look at integration tests for this screen to see the way I implemented it.

Thank you for your attention and please let me know if you have a better solution for anything above.

Testing MVVM with RxSwift code was originally published in Aras™ Digital Products on Medium, where people are continuing the conversation by highlighting and responding to this story.