During our years-long cooperation with Signify on the Philips MasterConnect system, we’ve built multiple mobile applications that bring this industry-leading smart lighting system to life.

The whole system, consisting of smart wireless switches, sensors, and luminaires from Signify’s MasterConnect line, is built on Bluetooth Low Energy (BLE) and Zigbee protocols. Since it utilizes technologies that come with phones we use every day, there’s no need to use any additional devices during installation, as was the case with older connected lighting systems.

While our case study of this project provides an overview of the system features, this blog post will give you a view of how things work under the hood. We will focus on how BLE and Zigbee enabled us to build this product and cover some of the app’s high-end features in more detail.

The two wireless communication protocols that make the magic in the MasterConnect system happen are Bluetooth Low Energy (BLE) and Zigbee. The backbone of Internet of Things, they have been revolutionizing the way we interact with our devices for the past few years.

As its name suggests, BLE is a wireless communication technology created to be low-power and efficient. It is a version of the popular Bluetooth technology specifically designed for IoT devices. While Bluetooth Classic only supports point-to-point communication, BLE provides additional communication options such as broadcasting and meshing, enabling connectivity between devices in a network that supports this type of communication. 

Similar to BLE, Zigbee is a wireless communication protocol specifically designed for low-power, low-data-rate applications. Zigbee efficiently transmits messages that are small in size, while its design allows devices to run on batteries for years, making this technology a great choice for systems that need to be installed in hard-to-reach locations or need to operate without frequent maintenance. 

Both protocols have something in common – the ability to efficiently configure devices into large-scale networks that require zero maintenance. Since our system is fully scalable and adapts to buildings of various sizes, this was exactly what we needed to ensure network reliability in any scenario. 

It might seem surprising that we’ve chosen two protocols so similar in nature. However, to support different types of communication taking place in the system, we needed both. Our smartphones have been supporting BLE pretty much since its release as part of the Bluetooth 4.0 standard, but they don’t support Zigbee, whose mesh networking is perfect for light connectivity. 

To work around this limitation for mobile, we modeled the system so that our apps communicate with devices using BLE, and then the devices communicate between themselves using Zigbee. That’s the high-level overview, but let’s roll up our sleeves and get a bit lower.

When setting up a lighting system, installers first need to physically install all of the devices in their respective places in a building. Once that’s done, they use the Philips MasterConnect app to configure the system.

The app guides the installers through each phase of the setup – from creating projects and groups to discovering and commissioning lights, sensors, or switches into those projects. 

Let’s go over some of those steps in a bit more detail.

All BLE devices need to follow something called the Generic Access Profile (GAP) guidelines, which dictate how they need to advertise data to other devices. This could be a blog post on its own (like our article on Bluetooth Beacons), but in short, the devices advertise information about them with a certain frequency. We could say that they yell something along the lines of “Hey, I’m here, my name is X. I am a light and I support Y features”. This allows us to filter out the devices that are a part of our system and present only them to the installers.

To make things even easier for the installers, we implemented an innovative solution to solve the problem of identifying specific devices in a room where there are hundreds of them. We decided to use torches (not the fire kind, the ones that produce light). Installers just need to point an everyday pocket torch at a light, and the onboard sensor will pick up the spike in the detected brightness. This will cause the device advertisement to change in a way that enables us to identify it and automatically start communicating with it.

Once we have discovered all the lights we need, we have to connect to each of them before we can make them a part of our network. We do this by following the Generic ATTribute Profile (GATT) guidelines, which specify how a device can support various features using services and characteristics.

In short, if you want to get some specific information from a device, you need to read the data from a characteristic that holds it. Alternatively, if you want to write some data to a device in order to tell it to do something, you need to write to a characteristic that is connected to that behavior.

Now that we know how to discover a device and how to communicate with it, we need to bring Zigbee into the picture. Zigbee enables us to arrange devices into groups, which allows us to use group addressing to communicate with multiple devices at the same time. 

Since its introduction last year, SwiftUI has piqued the interest of most Apple ecosystem developers with its “learn once, apply everywhere” approach. After playing around with it for a bit, we wrote an overview of SwiftUI itself, as well as looked into how Combine fits in the picture.

It looked promising and made UI programming really fun. However, its initial shortcomings and imposed minimal OS support version prevented it from ever fully taking off.

Improvements that came during this year’s WWDC, along with the maturation of the toolkit itself, mean more and more teams are going to slowly make a switch to a new way of building cross-platform user interface layers that work across iOS, iPadOS, macOS, tvOS, and even watchOS, using one set of tools and APIs.

I’ve talked about this very same topic at the recent Shift Remote E05: MOBILE event, and if you’d like, you can check out the recording of that talk here.

Now, let’s see what SwiftUI promised, what it delivered, and where it’s going in the future. Grab a coffee, settle in and let’s begin.

When Apple first announced SwiftUI, they backed it up with some big claims regarding the changes it was going to bring to the development world of the Apple platform. Here are some of them.

They said that we would need to write less code.
Stuff like creating a tableView or a collectionView that before took a lot of boring, boilerplate code would become things of the past.

After that came adaptability, in all its forms:

Next things next. After adaptability improvements came something that would upgrade our development process, as well as increase the speed of our output – the ability to preview our UI at the same time as actually writing the code for it.

Technologies like Flutter or React Native had had this option for a while, and last year we were finally given a native alternative to the build-install-run dance that used to bite out a solid chunk of developers’ daily programming time. By using preview, the written code would automatically and immediately be seen in it, as well as all made changes. There was also an option to run a live preview, allowing for test user interaction or navigation testing, similarly to running the app in the Simulator/on a real device.

Code & preview combination also meant that we now had a single point of truth for our UI; checking out storyboard/xib files and/or code to find out who has overwritten whom and caused our UI bugs was gone, going, gone.

Btw, if you’d like to know more about those hardships, we’ve got you covered with our article on the long-term UI-building dilemma of choosing between storyboards and code.

Finally, we got a native, declarative way of writing our applications for Apple platforms. Imperative approach stood the battle of time, but with general advancements in UI development, as well as the increase in app complexity our users expect, we needed something fresh which allowed for faster iterations, as well as easier state management.

All those things were supposed to make SwiftUI great – Apple wrapped them up in a shiny wrapper and told us “Here you go, play around with it.”. Naturally, presented with something new and unfamiliar, we did just that, and it didn’t take long before articles were touting this as the end of Objective-C, UIKit/AppKit and the be-all and end-all way to go.

However, with the honeymoon period over and our rose-tinted glasses off, we started seeing there was still a lot of room for improvement. Preview was not always working and used to crash consistently. New Xcode/Swift versions would break the existing SwiftUI code. Navigation would sometimes break, too. Tab management was not preserving the navigation stack. UI elements that we were used to in the UIKit world were missing their SwiftUI counterparts.

Creating simple UIs was fast and fun, but doing anything remotely complex or adjusting some existing elements like Lists usually meant dipping back into UIKit/AppKit, which kinda defeated the whole declarative purpose.

Last but not least, SwiftUI requires iOS 13 as the minimum OS version. For large scale applications, that meant leaving a significant part of their user-base behind, and that wasn’t really an option. However, it got us thinking about state management, and the way its declarative nature goes around solving issues that popped up.

State management is hard.

Let’s take the screen above from the Apple’s Mail app as an example. There’s a list of data, driven by some data models (in this case emails), as well as some extra navigation options, filters and actions.

To create a screen like this, we need to connect our views with our models, and each one of these arrows seen in the image below represents a dependency.

As you can see, there are a lot of interconnected elements here since UI actions can update our models, and in turn they can update our UI. If you think this is complicated, bear in mind that this is just a single screen, and today our applications have a lot of screens which can share the same models, which makes the whole picture even more convoluted.

This brings me back to the starting point of this section – state management is hard, and state management in large-scale applications that we usually build for our clients is getting harder each year. Supporting multiple device sizes, light & dark modes, accessibility features, complex device features such as AR or Bluetooth, having a multiplayer mode and so much more – it all makes building apps in 2020 more challenging than ever. We work in bigger development teams, where each contributor comes with a different skill set that needs to be aligned in order to make a cohesive app.

Sure, it can be easy to put a custom button on a screen, but how does it respond to accessibility? Does it adjust properly to different device sizes and orientations? Does it break if the customer changes their font scale? Is the state that button updates properly propagated to all the screens that require it? Now do that for not just a single button, but for all the UI elements you have on a screen. Not so easy now, is it?

As iOS developers, our job is to build applications that empower our users and adapt to their needs and potential disabilities. If we don’t, it can lead to a disappointing experience for our customers and can make the end product appear cheap and untrustworthy.

With SwiftUI, we don’t need to worry about how our app is going to transition between all those different states. The age-old problem probably every single engineer has stumbled upon of animating updates to this set of content based on a diff – gone. We just need to write the code to describe how each state should look and the system figures out the rest. Like magic.

SwiftUI offers a declarative approach to user interface design. As you compose a hierarchy of views, you also indicate data dependencies for the views. When the data changes, either due to an external event like a notification or because of an action taken by the user, SwiftUI automatically updates the affected parts of the interface. As a result, the framework performs most of the work traditionally done by view controllers.

This unidirectional Action -> State -> View approach means that we no longer need to worry about keeping our UI and our data models in sync. Our state is the only one responsible for updating our Views, and Actions are in turn the only ones responsible of updating our State. Since our Views can’t update the State directly, the problem is automatically solved for us.

Having gone over how SwiftUI started and the problems it aimed to solve, we should now cover the novelties announced at this year’s WWDC and see where SwiftUI is heading in the future.

SwiftUI’s coverage of commonly used views has been greatly expanded this year, which is fantastic news both for developers who already have existing apps built with SwiftUI, and for people who are now getting started with the framework for the very first time.

What most of us were looking forward to is the inclusion of alternative UI elements we were used to, and I think it’s fair to say that we weren’t disappointed with what we got:

The concept of laziness is a big trend when it comes to this year’s SwiftUI changes, which is only solidified with the addition of LazyHStack and LazyVStack to their non-lazy counterparts. In general, implementations that are lazy don’t perform their work up-front, but rather at the time when it’s first needed. This can often lead to a ton of performance improvements, especially when dealing with larger collections and other heavy data.

There are also a host of other new things which could be a whole blog post for themselves like matchedGeometryEffect, ScrollViewReader, ColorPicker, DisclosureGroup etc. Stay tuned to Capsized Eight, I guess?

Adding to the existing host of property wrappers, we got some new ones which will make our lives a bit easier:

On iOS 13, we had to use a UIHostingController (or NSHostingController on the Mac) to actually render out SwiftUI views, but now, our root view hierarchy can simply be embedded in a type conforming to the new App protocol, and by annotating that type with Swift’s new @main attribute, it’ll act as the entry point for our app – without the need for any app delegate or any other bootstrapping code:

All of this brings me to my final point:

Apple has already started pushing in the spotlight by making it the only way to create widgets for the newest OS versions. MacOS has also started using it prominently in some of its redesigned features, like the new notification center.

The new unified design language Apple is pushing forward, combined with the fact that Apple Silicon Macs will be able to run iOS/iPadOS applications as well, means that having a single UI framework that can be used to develop for all platforms makes perfect sense.

Barely over a year old, SwiftUI is just getting started. Armed with all the new announcements and improvements, it’s already packing quite a punch and is set to be the future of development for all current, as well as future Apple platforms.

Prove me wrong?

Nearly five years ago, we published an article listing the top 10 libraries every iOS developer should know about.

The article provided a great starting point for developers looking to increase their productivity and avoid reinventing the wheel.

Turns out it was a highly searched topic, and the blog post remained relevant a lot longer than we expected.

Some of them listed in that article have stood the test of time and are making a comeback here, but there are also some newcomers which make our day-to-day programming lives easier.

Before we actually start going through the list, I’d like to bring up an important disclaimer – use third-party libraries responsibly.

Be sure to check whether the libraries you’re going to use are actively maintained and supported.

Working on a project a year or two down the line could prove to be troublesome if at some point it stops compiling because of a Swift or iOS change that breaks used libraries.

Also, please, don’t import libraries in your projects just for the sake of it if you’re only going to use a very small part of that library. A great quote I heard at one recent meetup comes to mind here: ”Don’t use an excavator where a shovel would suffice.”

Now that we’ve covered the disclaimer part, I’d also like to point out that this list was compiled and ordered by looking at our recent projects and needs, and does not reflect any official download numbers or rankings that could be found online.

Your mileage may vary depending on your project’s domain, but hopefully, you’ll find something of use here as well.

Alamofire is an elegant and composable way to interface with HTTP network requests. It builds on top of Apple’s URL Loading System provided by the Foundation framework. At the core of the system are URLSession and URLSessionTask subclasses.

Alamofire wraps these APIs, and many others, in an easy-to-use interface and provides a variety of functionality 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.

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

Like the original Rx, its intention is to enable 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 are both entered, and if the password is of appropriate minimum length.

This is just scratching RxSwift’s/RxCocoa’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.

Note – Combine will probably at some point going to slowly start sunsetting RxSwift, but since it requires iOS 13 as a minimum OS version, that is still a couple of years away, and RxSwift will prevail until then.

Kingfisher is a powerful, pure-Swift library for downloading and caching images from the web. It will download the image from url, send it to both memory cache and disk cache, and display 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 the cache and shown immediately.

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

Let’s be honest, animations in an application make a huge difference. They grasp your 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 desinger 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.

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 way to go around doing things.

SnapKit is an Auto Layout library that simplifies writing auto layout in code with a minimal amount of code needed 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:

SwiftyBeaver is a colorful, flexible and lightweight library enabling easier logging during the development of your applications. Gone are the days of bland console outputs; using this library makes finding out what went wrong a breeze.

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

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

Hero is a library for building iOS view controller transitions. It provides a declarative layer on top of the UIKit’s cumbersome transition APIs — making custom transitions an easy task for us.

It works similar to Keynote’s Magic Move. It checks the heroID property on all source and destination views. Every matched view pair is then automatically transitioned from its old state to its new state.

Hero can also construct animations for unmatched views. It is easy to define these animations via the heroModifiers property. Hero will run these animations alongside the Magic Move animations. All of these animations can be interactively controlled by user gestures.

As you can see, Hero does a lot of heavy lifting in order to provide us with a simple API to create powerful animations.

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:

I’ve written about implementing such a demo mode in one of my previous articles, so be sure to check it out if you’d like to learn more about it.

There are a few more libraries we use in most of our projects, but since these are our own open-source projects it didn’t seem fitting that they steal the spotlight of other popular third-party solutions.

However, since they could prove to be of use to you, we should also list them here as well:

While we’re at it, you can also check out Nuts & Bolts, our repo containing a centralized collection of commonly shared and reused code throughout the Infinum iOS team.

Do you agree with us? Got some other libraries you find useful that you would like to share? Leave a comment or contact us on social media. We’re eager to learn about new things and interesting ways of easing common iOS pain points.

Brands introducing mobile apps may have been innovative a couple of years back. Fast forward to 2020 and modern businesses without a mobile app connecting them to end-users are missing out.

Your local supermarket chain? They have an app. The bakery down the street that you visit every so often? Their doors are plastered with stickers imploring you to download their app to collect membership points.

The simplicity and convenience of mobile apps attracts clients and users, who in turn bring in financial profitability and security. What’s not to like?

Deciding you want an app for your business is the easy part. Figuring out which technology should power your app is a daunting task, especially if you’re new to mobile development.

One technology that has stood out on the mobile development horizon lately is a cross-platform technology Flutter.

From the perspective of a company wanting to build their app, these are the things that you’re interested in: 

In the following paragraphs, we’ll put Flutter through the test and examine how it responds to the requirements above.

When using Flutter, developers need to write only one codebase, which will cover all the business logic, as well as the UI on both the iOS and Android platforms.

However, if you still want some differentiation between them and provide the native feel the users are expecting, that’s more than possible with the use of both Material Components widgets, as well as Cupertino widgets.

Those will provide that specific Android and iOS look & feel you’re after.

Having a single codebase also simplifies organizing the workload, as it’s easier to align work on a single codebase powering multiple platforms than it is to align multiple developers, each working on their own platform.

One codebase also means faster testing. Developers will need to write unit and integration tests only once, not once for each platform which was the case previously.

Of course, if you decide that your apps will have some platform-specific differences, those will need to be double-checked, but the bulk of the business logic will remain shared. 

This will result in an expedited QA process which doesn’t cut any corners or compromise the app’s quality.

When talking about mobile development, Flutter has rapidly become a synonym for speed.

When building the app’s UI, it’s possible to make quick alterations in the source code which will make all changes immediately visible with the help of the hot reload feature.

Hot reload also comes very handy in the cooperation between developers and designers, where the end goal is to improve or experiment with an app’s look and check the effects on the spot.

Flutter renders all parts of the interface using internal graphics engine called Skia  –  a 2D graphics rendering library, the same one that is used in browsers such as Chrome OS, Android, and Mozilla Firefox. Even though Flutter is a UI framework in its core, it runs on top of the native hardware allowing it to use all of its potential.

With this core technology, apps will get the benefits of compilation to native code. The UI is refreshed at 60fps  (or even higher on devices which support it) mostly using the GPU , and every pixel on the screen is owned by the Skia canvas which leads to a smooth, highly customizable UI.

Creating great-looking and custom UI elements is easy and fun, and will work and look great on both Android and iOS. This makes Flutter a great choice for apps with advanced, custom UI designs.

Although Flutter is still relatively new (the first stable version was published on Dec 4th, 2018), it has already been field tested by giant companies.

We’re talking Google (Ads and Greentea apps, an interface of NEST Hub device), Chinese wholesale & e-commerce giant Alibaba with their Xianyu app (used by more than 10 million users every day), and Tencent, world’s largest gaming company.

Another great example worth mentioning is Tonal, a company whose product is a wall mounted workout machine with an integrated screen, which is accompanied by iOS and Android applications built using Flutter.

If you’re more of a visual type, Flutter’s development team has created a great showcase of apps which have taken flight with it, which you can check out here.

For some time now (since 2016), there have been reports that Google is working on a new operating system called Fuchsia. Flutter is also a native framework for Fuchsia apps, which means that if you write an application in Flutter, it will be ready for release on Fuchsia from day one.

Flutter’s goals don’t end with mobile development. Its sights are set much higher, with currently ongoing development in support for both web and desktop. These are still in their beta and alpha phases respectively, but taking current rapid development into account, we might see their first stable versions soon.

Internet of Things is also getting bigger by the day, and Flutter is a viable choice here as well. A cool example is this competition from Google, where they asked developers to build a beautiful clock face UI for the Lenovo Smart Clock. 

This is just a taste of things to come, and soon we’ll start seeing more and more apps on all those mentioned platforms built using Flutter.

Google’s support for Flutter is impressive, and they have provided us with a great starting kit full of available libraries and functionalites.

However, since Flutter is still relatively new, not everything you’re used to having while using native apps will be available, which will take some additional development time. In most cases, this won’t be a major problem but it should be taken into consideration.

Another potential problem is a pain that comes with every new technology – the possibility that it will evolve in the way which doesn’t align with your visions, and the ever-existing risk that the creator could abandon the project. Looking at you, Google.

However, considering the fact that Google plan to use Flutter in their new OS and that it’s open source, that’s unlikely.

As you surely know, when building a mobile app, even before a single line of code is written, a lot of consideration goes into deciding which approach to use . There’s native or the cross-platform one.

In the paragraphs above, we’ve covered Flutter and explained why we think it is shaping up to be a very exciting and productive technology.

If you’re opting for a cross-platform solution in 2020, your other possible options would be the Facebook backed React Native or Microsoft’s Xamarin.

There used to be some other solutions but most of them are either dead, or about to draw their last breath.

There have been a plethora of well-written technical articles explaining the differences between those mentioned technologies (e.g. this one ), so there’s no need to get into that here.

What you need to know is that all of them focus on providing “next-to-native” performance. Sure, not everything will be as pixel-perfect when compared to a fully native approach. However, nowadays, you really have to pixel-peep to find those wrinkles.

The existence of such cross-platform technologies doesn’t mean there is no more use for completely native ones. They provide you with a (still) unparalleled look and feel, but also require a significant amount of work to build both the iOS and Android versions. It’s up to you to decide which option fits your needs better.

Something you should also keep in mind when making that decision is that there are cases for which a native approach is a must, and it doesn’t seem likely this will change in the foreseeable future. These would be apps that:

If your app doesn’t fit any of those descriptions, cross-platform might be the solution you’re looking for. We believe this approach works best for small and medium size applications, or when your content and basic features require constant iteration.

As you can see, there are no silver bullets when it comes to programming, as well as general problem solving. Every project we encounter requires careful architectural planning, as well as choosing the right technology which will lay at its foundation.

In the past, we’ve mostly gone for the native approach, but seeing how Flutter is shaping up to be a worthy solution for many possible use cases, we’ve started offering it to our clients as well. 

If you’re inspired to make a leap forward in 2020 and build something exciting and beautiful, don’t hesitate to drop us a line.

After all, the future of your business lies in the smart utilization of technology and software, not the horoscope.

Ever thought about adding demo mode to your application? If I were guessing, I’d say most of you probably haven’t. It’s not a bad thing, it just means you haven’t yet encountered a problem or use case requiring you to build one. However, there are a lot of scenarios when the demo mode comes in handy.

In this article, I’ll show you that implementing a demo mode doesn’t require a lot of time, all the while keeping your existing logic pretty much intact. While we’re at it, the solution I’m going to show you will also make your development life easier in cases where the API is still work in progress, or just flat out refusing to cooperate.

One example that comes to mind would be in AppStore reviews for apps which require a login but can’t really provide a test user. Think of all the banking apps that require users to be legal entities in the app’s origination country.

Other use cases could be apps that would like to show off their premium features without providing a trial period, or maybe those with sensitive data management that would like to familiarize their users with the application’s feature flow before throwing them into the “lion’s den”.

My team has encountered similar cases in the projects we’ve worked on, so we had to come up with a scalable and maintainable way of making it work.

When starting to think about implementing demo mode inside an app, your first thought might be to add an additional parameter to your API call site specifying whether the call should be executed or mocked. 

This would work, but it would also require a lot of “copypasta”, and every new API call you implement should also have the same logic. Since we’re aiming for scalability and maintainability, this approach isn’t the way to go. As your app grows, it would introduce a lot of switch-cases and logic duplication and frankly, it would get tiring quickly.

That is why we’ve decided to make something better  -  a demo manager.

This could be a common response to my proposal since developers like to introduce managers everywhere, even in places where they don’t really make much sense. But bear with me for a minute, this is a use case where a manager fits like a glove.

Our demo manager appears quite basic when you look at it from the outside. After all, it only has a single state parameter isEnabled telling us whether our API calls are being actively mocked or not. However, its ”hidden” responsibilities are where the money’s at, so let’s take a look at them.

The first responsibility is hooking onto every API call your application makes, while the second one builds upon the first one by filtering those API calls in the following way:

For API call mocking, we’re going to use OHTTPStubs, 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, so it’s perfect for our use case.

Of course, if you don’t like adding pods to your projects, you could implement your own hooking logic, but that isn’t the point of this tutorial so I’ll leave that to the brave.

Now that we’ve covered the what and why, let’s move on to the how. We’ll start with the top-down approach, building our demo manager in several steps.

As you can see, our demo manager is a singleton, with one variable for switching the mocking on/off. It might look simple, but this single point of entry provides us with great flexibility . If you want to mock everything in the application, all you have to do is just set the isEnabled parameter to true when the application starts and you’re golden. 

However, if you want a bit more specificity, you have free reign to do so. For example, your API call mocking can start only when you get to a screen which still doesn’t have an API implementation ready on the backend side, and can be turned off when you navigate off this screen.

Here we can see the implementation of our setupStubResponses() method.

It stubs different API calls with responses from JSON files – something_mocked, something_paginated_first_page and something_paginated_second_page, while the second call is mocked with just a 200 code telling us that the update was successful. 

Each call is mocked using the stubResponse() method with individual filtering parameters. To understand that there isn’t some black box magic involved, let’s take a look at what’s going on under the hood here.

This method is basically what you’ve been waiting for. It calls OHTTPStubs’s stub() method which does the API call mocking using a condition closure and a response closure. Each of them plays a major part in mocking your calls, so let’s see what they’re all about.

You can think of the condition closure as a robust version of filtering. If it returns true, the response closure will be executed, the API call will be mocked and it will never reach the real server. Otherwise, if the condition closure results in false, the API call will be executed, just like before.

In our implementation, we go through several major pillars of every API call in order to determine whether we should mock it:

If all our checks are successful, our API call is filtered as ”good for mocking” and the response closure is then finally called to mock the API call. Otherwise, if the condition closure fails at any of the the aforementioned conditions, the call is forwarded to the server – business as usual.

The response closure is used to create the mocked response, and it uses three parameters passed into the stubResponse() – statusCode, method and fileName. We load our mocked response from the file in our bundle using the specified file name, set the headers to the provided values and create the mocked response using the status code. 

This allows us to test our implementation with several responses rather quickly. Want to know how your UI behaves if the array of products you’re expecting is empty? What’s going to happen if the API starts coughing up and returns 4xx or 5xx?

Using the flexibility of call mocking shown here, you can run through all your test scenarios in a breeze, leaving you more time to focus on more important parts of your app.

One thing not mentioned above is the usefulness of OHTTPStubs for writing unit tests (which all of us are doing, right?)

It comes as a real time-saver when testing your business logic that depends on API call results, and all you need to make it happen is the stubResponse() implementation inside your testing environment.

You can do that in no time with the knowledge you’ve accrued. Doing that will not only help you with testing, but also make your apps more stable, resulting in happier customers and better app ratings. 

You’ve just witnessed that the demo manager really is a jack of all trades. It has a wide variety of uses, from showing everything your application has to offer without firing a single “real” API call, to making development faster while waiting for the API team to do their part by mocking the responses based on the agreed specification.

The best part is that it’s not difficult to implement, so give it a go and reap the benefits of the demo mode in your project.

Until next time, happy coding!

Here’s a scenario fellow iOS developers will find familiar: iOS development projects you work on come in all shapes and sizes, but as varied as they get, the same pesky problems in them appear repeatedly. And just when you’ve solved a problem in one project, it reappears in the next one, like in that bunny hammer game.

We’ve had this happen time and time again at Infinum. Project after project, we would go through best practices and fixes we’ve implemented in the past (and which Apple still hasn’t implemented), copying the solution that worked in the last project into the new one, making any neccessary modifications.

Over time, this has morphed into a knowledge base that became our reference point for upcoming development projects. Now, we’re sharing it with the world so that other developers can stop copy/pasting from project to project, and find the solution in a centralized repository instead.

Say hello to Nuts & Bolts!

If you look at the repository, you’ll be able to find all the features inside the Sources folder. Each feature has its sample inside the catalog list which can be run and/or tests written for it, where you can find more info on the specific feature usage. 

Those features are currently split into 5 main domains, and we’ll go through the contents of each one. 

Most of these are written in Swift since that’s what we mostly use nowadays, but if you’re still using Obj-C don’t fret. There are some useful things in there for you to use as well. Also, if you have an Obj-C implementation which you think could be useful, please open a PR–we’re always open for suggestions.

Before we continue, please note that we are using some third party integrations through CocoaPods to make our lives easier–we don’t always need to reinvent the wheel.

As we all know, pretty much every app we build or use depends on some kind of networking in order to provide its full functionality to the user. From complex apps like banking ones all the way to simple workout tracking, networking is pretty much a must. In order to make it a breeze, we’ve added several useful properties to this feature folder:

We’re big fans of reactive programming here, and we use it in pretty much every project we’re currently supporting.

We know that Combine is knocking on the door, but the majority of the projects we’re actively working on will have a minimum device support lower than iOS 13 for some time, which is why RxSwift is here to stay for some time. Since it’s such a central tool in our toolbox, we decided to make it even better with some improvements.

Observables are their main building blocks, and with these they become even better:

We haven’t forgotten about Singles, so be sure to give them some much needed love when you take a look at what’s in there.

When talking about reactive programming for iOS, we can’t forget RxCocoa. It provides extensions to all things Cocoa, allowing them to take advantage of the reactive world.

If you use Drivers in your everyday life, these could be just what you’ve been looking for to drive your projects further than ever before. As you’ve probably noticed, we love our puns.

This feature folder contains a wide range of useful extensions and computed properties covering many commonly used Foundation features: Arrays, Strings, Bools, Date, Optional and many others.

These are just a taste of what we have available there, so be sure to check them out. We’re willing to bet that you will find something of use there.

This one is centered around UIKit–mproving it, as well as fixing some issues which we think should come out-of-the-box. 

Ever wanted to initialize colors more easily, or generate their hex values on the fly? Look no further.

Need to remove insets from your UITextView? We got you covered.

This is the biggest feature folder–for a reason. We love working on UI and strive to make user experience the best it can be, so focusing on improving the tools at our disposal is the least we can do.

If things metioned in this article have sparked your interest, you’ll maybe also want to take a peek inside our other open-source iOS stuff:

Your contributions and support is what keeps them evolving as iOS evolves, and we hope that it will continue to be the case.

We hope all of these are going to be helpful to you. If you have any suggestions of your own, feel free to open a PR by following steps detailed here. We’re always looking forward to learning new things, and can’t wait to see wait to see what other tips & tricks our community can come up with.

Until next time, happy coding!

After waiting for what seems like an eternity, iOS is officially getting a feature its users have been crying for: a system-wide dark mode. As it sees the light of day, Android users should finally stop gloating over their advantage!

The wait has been long but it’s been worth it. Dark mode suits iOS well, as is evident from the settings app screenshot below.

Beg to differ? Well, even if you’re not digging the new color scheme, you should still try it out as it’s not only a visual update–it comes with more hidden benefits.

Dark mode can help preserve battery life on OLED screens since true black (#000000) color means turned off pixels. It’s not much, but if you need every little bit of the energy juice available, it’s worth considering. Also, late-night texters will appreciate the dark color causing less strain than default white.

Chances are these benefits have sparked the interest of mobile users, so in this article we’ll cover everything you need to know in order to make your app a dark mode native.

By the way, adding dark mode support becomes much easier when you put our Bullet-Proof Color-Naming System for iOS Development to use.

Before diving in, there are a couple of requirements you must meet in order to actually make your app dark-mode compliant.

If you built your app using any older Xcode, the app will always display its normal appearance, even on devices which support dark mode. The exact same is true for apps built using Xcode 11 but running on older versions of iOS–these new features will not apply and the app will retain its default appearance.

Now that we’ve gotten the prerequisites out of the way, let’s get started. If you turn dark mode on, it will automatically be applied to all system UI elements and all Apple apps.

Install your application on a device running iOS 13, and you’ll quickly see that it falls into one of the following categories.

But even if your app falls in the bottom two categories, don’t worry. You will learn how to leverage trait collections, dynamic colors and dynamic images in order to successfully transform your application into a versatile theming champion.

The scope of the work on your plate depends on the size of the app, the amount of custom elements used, and your project structure. However, the adoption steps will mostly remain the same. Let’s check them out.

It’s worth noting that traitCollection property was introduced over 5 years ago in iOS 8, as a part of the UITraitEnvironment protocol adopted by UIScreen, UIWindow, UIViewController, UIPresentationController and UIView.

It can be used to provide information about the iOS interface environment to your apps such as device type, device size class and display scale, but with iOS 13, we get a new property–userInterfaceStyle, which is used to determine the view’s appearance style.

Furthermore, .unspecified case is used to say that the object will inherit its style from its superview (or the system in case of a UIScreen), and .light and .dark styles are pretty self-explanatory.

This traitCollection information is passed through the interface hierarchy, as can be seen here:

UIScreen gets the userInterfaceStyle property from the system and passes it onto the window scene, which propagates it to the window etc., etc. You get the idea.

This propagation means that the theme which should be used is not being read from the system on each hierarchical level, which allows us to override system appearance mode whenever we choose. For example, we can define a different interface style for just one view controller inside our app, and that style is then passed onto each of its child views, while unrelated views remain unaffected.

With iOS 13, UIView, UIViewController, and UIWindow have gained a new overrideUserInterfaceStyle property that lets us override the system appearance:

This will get applied to the view at question, but also to all its subviews, so be careful when doing so and make sure it’s what you really want.

Until now, both images and colors were static, which meant that they were always the same, independent of the environment. For example, if we added our own theming before, we would have to specify x different colors or images, with x being the number of themes we support.

Let’s see what has changed here.

Starting from iOS 13, UIColors can be dynamic, which means they contain one set of RGB values for light mode, and another for dark.

Whenever users change the system appearance, the UIScreen trait collection is changed, and the UI objects in the hierarchy are notified. If any view in the hierarchy contains elements which are using dynamic colors, such as labels or buttons, everything will automatically update to the appropriate color instantaneously, without us doing any work.

As you can see from the picture above, contrary to the old static colors, system colors are slightly different for each mode, sporting a shade specifically made to look better on light or dark mode, respectively.

Same as with the static colors before, these can be easily selected from the storyboard/xib:

What makes semantic colors different from regular ones? Naming convention based on purpose. Instead of telling us what color they’re representing, these colors are named with their use in mind.

Previous Xcode versions offered two static colors which were semantically named – .lightText and .darkText. Since they are static, they don’t play nicely with the dark mode. Lucky for us, Xcode 11 provides us with a full new suite of semantic colors such as UIColor.label, UIColor.secondaryLabel, UIColor.headline and many others which do!

The most important take here is that using them ensures your app’s appearance will look familiar to the rest of the system. UIColor.label will look the same in all system apps, and using it in your app as well will make it feel native, which is always the best experience for the user.

Asset catalog provides us with an option to create a different color set, which can later be used in both code and storyboards/xibs. When you create a new color set, choose the attributes inspector and in the appearance section select “Any, Light, Dark” and add appropriate colors for all styles.

If that disclaimer made you think “Oh sh**, I still support iOS 10, what now?”, no worries.

It’s also possible to create dynamic colors in code. You can initialize UIColor via init(dynamicProvider:) and return the corresponding colors depending on the current trait collection.

One thing to note here is that if you’re working with CALayers, they do not play nicely with dynamic colors since they are not a part of UIKit.

However, there is a neat way to get precisely the colors we need. Apple has also provided us with a function we can use to resolve colors for the current trait collection aptly named resolvedColor(with:), as you can see below.

One more thing to consider and keep in mind regarding CALayer: since it’s not a part of UIKit, it also will not respond to any appearance changes. This is something you need to take care of manually, by updating its style through a callback or an observable (if you’re feeling reactive).

In iOS 13, images, just like color sets, can also be dynamic. There are multiple ways to achieve this, so let’s take a look at the different options at our disposal.

Note that not all images will need to be dark-mode compliant. For example, if you allow user-imported images or color profiles, those will need to remain as they are regardless of the currently set appearance, so there’s no need to adjust them on the fly.

SF Symbols are a huge collection of over 1,500 consistent, highly configurable symbols you can use in your app that Apple has introduced during this year’s WWDC. They are fully integrated in the iOS 13 SDK and will automatically be available on every device that is running it, which means you don’t need to increase your app size by adding additional images and icons.

Another thing that really makes them shine is the automatic adaption to light/dark modes that comes out-of-the-box. In the image below, you can see just how versatile they really are, allowing you to adapt them to whichever style, weight or scale you may need.

You can use SF Symbols in two ways in your apps, through storyboards/xibs or by creating them in code.

To use SF Symbols through the interface builder, all you need to do is add an image view, type the symbol name and you’re done. Next to the image name you’ll be able to se the “System” text telling you that you are using an SF Symbol; images you import through the Assets will not have that text.

If you prefer setting up your images through code, you can also use symbols there by using the new UIImage initializer which takes a system name, like so:

Since there are a lot of symbols available here and scrolling through them in Xcode can quickly become tiring, Apple has created an official SF Symbols app that can be used for easier reference or a quick look at all the available symbols.

For your custom images, you can define different image assets for both light and dark modes, and it can be done directly from the asset catalog, just like with custom colors. Just set their appearance in the right pane, drop a new image for each appearance and you’re done.

If, for some reason, you want to resolve the image and determine which one will be used, you can do that easily by resolving images by using the current trait collection:

If you’ve ever used attributed text in your apps, you probably know that unless you specify the foregroundColor property, it will be automatically set to .black.

That was probably fine before if you weren’t using a black background, but with iOS 13, it will not work as expected when using the dark appearance–black text on a black background is a big no-no.

That’s where things like semantic colors come into play, as you can see below.

Whenever users change their appearance styles, several methods get called. You can leverage this by putting any additional UI logic which depends on the current appearance into these methods:

In addition, since all those objects conform to the UITraitEnviromentprotocol, traitCollectionDidChange() will also get called.

To simplify–if you’ve been initializing your colors/images in the init and viewDidLoadmethods, move that logic into the layoutSubviews() and viewDidLayoutSubiews() methods and you should be good to go. Any additional logic you have regarding the appearance can go into the traitCollectionDidChange() method, which will also get called when the appearance updates.

Having read all of the above, this question may have popped into your head, and it’s a perfectly valid dilemma.

There are several reasons why you wouldn’t want to add dark mode support: perhaps there’s no time to implement it properly or your brand guidelines are centered around light themes, to name only a few. Luckily for you, it’s really easy to disable dark mode and forget all about it.

There are three main ways to do this:

For partial support, just override interface styles on screens where you don’t want to support dark mode by using the code shown in the first heading, 1. Understanding the trait collection.

However, keep in mind that Apple really wants you to fully support dark mode, and their quote from WWDC should really drive that point home.

In other words, not switching to dark mode will make you the black sheep… If that makes any sense.

We’ve been eagerly anticipating dark mode on iOS ever since Apple released it on the Mac last year–and it’s finally here.

It appears to be a much-needed trigger which will encourage more iOS developers to look into app theming. By following the steps I’ve detailed in this post, you’ll be on course for perfecting dark mode in no time.

Go ahead, paint it black. Happy theming!

What do crows like? Shiny things. Us humans are not that different, which is why most people prefer using visual interfaces instead of command line terminals.

We love good looking, fluid, modern, responsive, and touch-sensitive applications which provide feedback. We geek out over good looking animations and apps that come alive as we use them. In short, we love our apps shiny. 

As developers, too often we focus on functionalities and just getting things done. If a user story or client requirement is completed and it works, we will pat ourselves on the back and call it a day. But what if we spent just a few more minutes to make things – you’ve guessed it – shinier?

This blog post will provide you with 4 quick and easy ways to make your apps stand out in the sea of similar ones, and all it’s going to take is a few minutes of your time.

Waiting for the coffee to brew or the microwave to finish heating up your food? Spend those few minutes adding these into your apps, and make it easier for users to pick your app as their favourite.

Rectangles; they are everywhere. Let’s take two common UI elements to demonstrate this – the trusty button and the all-knowing, albeit non-native, progress bar. When customizing their look, we would probably come up with something like this:

Sure, they get the job done as best as they can; the button can be clicked and the progress bar shows the current progress (duh). However, are they any different from all other generic UI elements we see throughout the apps we are using? Not really. Let’s change this!

With just a few lines of code, we can easily make them stand out more, and make the UI itself more pleasing to the eye.

Since UIButton is also a type of UIView, no additional code is necessary to make our button rounded as well. All we have to do is set the proper corner radius in the storyboard. After applying this small change, our rounded UI looks much nicer and, dare I say, shinier.

Apple started taking device vibrations more seriously when they removed the home button from the iPhone 7 and 7 Plus. The various haptic signals needed for all the actions in this new buttonless device required Apple to build a 2nd generation of the Taptic Engine, as well as several frameworks in a bundle called Haptic Feedback to easily use this new technology. These frameworks are available from iOS 10, which in 2019 means most of your target audience’s devices support it.

There are three main types of feedback generators that we can use:

Haptic signals are a great way to complement an app’s interface and create a stunning user experience overall. In addition, iOS 13 expands on this with the ability to create your own feedback patterns, which could result in interesting ways of interacting with our phones.

One thing to keep in mind is that you shouldn’t go overboard and make the device vibrate at all times. As uncle Ben said in the first Spider-man movie, ”With great power comes great responsibility”, so use haptic feedback wisely and with purpose.

Following along with the theme of notifying users of their actions, let’s switch from haptic to visual feedback. We’ve all used buttons inside our applications – when we press them, some action occurs. If we use Apple’s default buttons, they change the colour a bit, which notifies us something’s happened. Although subtle, the effect serves its purpose rather great. But why stop at that – why not make it look even better? 

What we can do here is implement button scaling when it’s highlighted, which (subjectively) looks a lot better. The code for that is pretty straightforward:

As you can notice, we have also used our RoundButton created before. They fit together perfectly, and this is what it looks like in action:

You can also do something similar for the tab bar items in the UITabBarControllerDelegate’s tabBarController(_ : didSelect:) method. It looks really nice and provides a visual pop. For bonus points, add selection haptic feedback for a well-rounded user experience.

Last but not least, we will return to our tab bar controller for a moment. When we tap on the bar items, their respective view controllers come into focus. Good thing about Apple’s implementation of this is that their state is preserved when switching. However, the result is slightly basic-looking, which we don’t want. Why not switch it up a bit and improve the looks of this, too? 

All we need are a few lines of code to animate the transition of our view controllers:

After doing this, our tab switching should have a fresh new look, like in the example below:

Since the release of ARKit in 2017., and especially the 2.0 announcement during the WWDC 2018 conference, I’ve been interested in what it can provide.

At first, I didn’t know what I was getting myself into. Coming from a computer science background with some minor experience in computer graphics and object rendering, I was expecting a lot of mathematical black magic. Turns out I was wrong.

Apple, always on the lookout to simplify things, built a framework that’s intuitive and easy to use but packed with powerful features at the same time. If you know your way around XCode and the basics of iOS development, you could be up and running in no time, even if you haven’t touched AR or 3D modeling before.

So what is augmented reality? A short definition I found on whatis explains it quite nicely:

How is it actually achieved? Before jumping into the code, there are three core pillars we need to understand:

Now that we’ve covered the basics, let’s put ARKit into the picture. The framework does the heavy lifting regarding tracking and scene understanding. Its job is to combine motion tracking, camera scene capture, advanced scene processing, and display conveniences to simplify the task of building an AR experience.

There are two ways to implement image detection through its configurations – you could use either ARWorldTrackingConfiguration or ARImageTrackingConfiguration. 

World tracking works best in a stable, non-moving environment, but it struggles if the tracked image starts to move around. That’s why ARKit 2.0 introduced the image tracking configuration. It uses known images to add virtual content to the 3D world and continues to track the position of that content even when the image position changes, simultaneously providing a steady 60 frames per second.

I think we’ve covered enough theory to get started, so let’s dive into some code. We’re going to be building an AR app for tracking and identifying Pokémon in the wild.
Just like in the cartoons!

To start things off, I suggest you use the Augmented Reality app template. XCode will create a view controller with a ARSCNView and a starting ARWorldTrackingConfiguration.

From the visual standpoint, this should be enough for this tutorial so I’ll leave the storyboard file as it is.

We’ll be focusing on image tracking, so we can pretty much delete all the boilerplate code from the view controller and start only with the basic viewDidLoad() and viewWillAppear() methods.

In viewDidLoad() we set the sceneView’s delegate. ARSCNViewDelegate has a set of methods that we can implement to find out whenever an anchor/ node pair has been added, updated, or removed from the scene. We’ll get to this in a minute.

viewWillAppear() implementation is also rather short. Simply tell the sceneView to start AR processing for the session with the specified configuration and optional options (since we don’t need them here, they’re omitted).

Our configuration is defined separately as a computed property for better readability. This is what it looks like:

The first thing we need to do regarding the configuration is to specify which images we want to track. These images can either be loaded from a file or added to the Asset Catalog and then loaded as a group. I’ve decided to do the latter.

After the images are loaded successfully, image tracking configuration is created and its trackingImages parameter is set to those loaded images. One more thing we need to specify is the maximumNumberOfTrackedImages property, which is used to specify how many images we wish to track simultaneously. If more than this number of images is visible, only the images already being tracked will continue to be tracked until either the tracking is lost, or the image is removed from the specified trackingImages. This number ranges from 1 (default) to 4.
My guess is, as hardware and software evolves, there’ll be an option to track even more images at the same time.

As I’ve mentioned previously, ARSCNViewDelegate provides a lot of methods for mediating the automatic synchronization of SceneKit content with an AR session. We’ll be focusing on the renderer:nodeForAnchor: method implementation, so let’s look at how we can handle adding nodes to the existing AR scene.

Here is the overview of our node creation:

Let’s unpack what happens here, section-by-section. Before we get to the interesting stuff, we need to check three things:

After passing all these checks, we can now start with the fun stuff. Firstly, we create our Pokémon object and then an empty SCNNode object which represents all the AR data we will show for that tracked Pokémon. This node will be a container node, which means its sole purpose is to hold a hierarchy of other nodes.

The next step is adding the overlay node:

As its name suggests, this overlay node is laid over the tracked image. We specify its geometry to be a plane, with its width and height being the same as the image’s. After specifying the size, we can set its firstMaterial?.diffuse.contents property a wide array of objects we wish to use – current ARKit implementation allows us to use a color, an image, layer, scene, path, texture, video player etc..

In this implementation, we will add a blue-tinted overlay showing where the tracked image is located. Another interesting option would be to set an AVPlayer as the plane material, which would then play a video connected to the specific Pokémon. Who wouldn’t like if their Charizard started spitting fire when detected? Since we’re covering the basics here, I’ll leave that out for now.

Another useful thing to add is the text node that would tell us which Pokémon is being tracked at the time since there could be more of them.

The procedure is similar to adding the overlay node. First we need to create a geometry – this time it’s a text geometry using our Pokémon’s name. We set the proper font, flatness (accuracy or smoothness of the text geometry) and the text scaling – since SceneKit deals in meters by default, we need to scale it waaay down.

If you’ve implemented everything correctly along the way, this is what should happen when you detect your first image:

The final piece of our Pokémon puzzle we’re missing is actually something which would show us the information about the detected pokemon using PokémonDB, right here inside our AR experience. We can do that by using our newly acquired knowledge about plane and node creation, with making some slight modifications:

After playing around with it a little, your final result should look something like this:

And voilà, you’ve just created your first AR experience. It wasn’t that hard, was it? This sneak peek into AR is just scratching the surface of what’s possible, and as time goes on, more and more options are going to be available to us developers.

To wrap things up, I’d like to share my own opinion about the future of AR. As such, take it with a grain of salt.

This question has started to pop up lately, and even though I don’t have a magic ball to tell the future, looking from the number of devices that currently support ARKit, it really doesn’t seem too far-fetched. Everyone with an iPhone running iOS 12 can enjoy these experiences, and younger generations are probably going to be (if they aren’t already) crazy about them. 

However, the whole concept of AR on mobile phones has one major issue – the practicality of use. It’s too impractical to walk around with your phone pointed at different things all the time, experiencing the real world while interacting with its augmentations through a screen. In my opinion, the way we interact with our phones is not really going to change that much, but instead, something else will rise up to augmented reality’s call – AR glasses. 

Google tried it a few years ago, but it was just ahead of its time for multiple reasons. Nevertheless, with the way mobile AR is advancing, it’s just a matter of time before another major tech player announces their own AR glasses. Judging by the information coming from this year’s CES, Apple seems to be holding their cards close to their chest and are waiting for the perfect moment to jump into the AR game.

What will happen next? We don’t know that yet, but we’ll probably look back at today and think of it as a learning experience for things to come.