Sofapps · Blog

Liquid Glass vs Material 3: The End of Convergence in Mobile Design

2025-09-02T00:00:00Z

2025 has forever changed the aesthetics of the mobile world.

Apple unveiled Liquid Glass, a digital meta-material bringing transparency, refraction, and dynamism to iOS, iPadOS, and macOS.

Google responded with Material 3 Expressive, the evolution of Material You, built around bold colors, variable typography, and elastic animations.

Two visions that couldn’t be more different. And with them, the end of an era: the era of aesthetic convergence.

A Step Back: When Paths Seemed Aligned

To understand the significance of today’s divergence, we need to go back more than a decade.

With iOS 7 (2013), Apple permanently shelved skeuomorphism: goodbye to wood and leather textures, hello to thin typography, flat surfaces, and subtle transparency.

Just a year later, Google introduced Material Design, a visual language inspired by “digital paper”, capable of moving and gaining depth through shadows and elevation.

At that moment, the two paths seemed parallel. Minimalism, clarity, and motion design were shared values, and for third-party developers, it finally looked possible to imagine a consistent cross-platform experience.

The Illusion of Neutrality

The aesthetic convergence of those years fueled tools like Flutter or React Native, which could offer interfaces that looked at home on both iOS and Android.

But adoption was uneven: Android’s fragmentation slowed the spread of Material Design, while iOS’s stricter guidelines accelerated alignment.

For years, the impression was that of a nearly universal visual language. But today, the trajectory has shifted, a lot.

Liquid Glass: Apple Bets on a Sensory Future

With Liquid Glass, Apple moves beyond flat minimalism: three- dimensional surfaces, light refraction, dynamic transparency.

It’s an aesthetic clearly pointing toward the future of spatial computing and continuity with visionOS, weaving a direct thread between smartphone, tablet, desktop, and headset.

A sensory, almost physical design language — one built for the long term.

Material 3 Expressive: Google’s Take on the Present

Google, in contrast, pushes its visual language forward with Material 3 Expressive, embracing a bolder, more immediate direction.

Saturated colors, variable typography, elastic animations: an aesthetic that speaks to Gen Z, emphasizing accessibility and visual impact in the short term.

Not the future of the metaverse or mixed reality, but a lively, everyday, and inclusive design system.

Consequences for Developers and Brands

This divergence is more than just a shift in style — it marks the end of neutrality for app development.

The choices are now threefold:

Native UI with shared logic → maximum aesthetic fidelity to each platform’s guidelines.
Adaptive cross-frameworks → branching and skinning to respect stylistic differences.
Brand-first approach → increasingly chosen by major players, imposing their identity above OS rules.

In other words, the challenge is no longer writing a single codebase, but translating one design system into two different dialects — without losing coherence or usability.

A New Aesthetic Competition

Liquid Glass and Material 3 Expressive embody two opposite philosophies:

Apple bets on the future, with a sensory interface paving the way for spatial computing.
Google optimizes the present, with vibrant, accessible design tuned for today’s users.

For users, this means experiences ever more defined by their chosen ecosystem.

For developers, it means making sharp, unavoidable choices about whether to adapt — or differentiate.

Once again, design is not just aesthetics. It is competitive strategy.

YouTubePlays on YouTube. Nothing is loaded until you click.

— Happy coding! 🖖🏻

WWDC25: Hello, Liquid Glass

2025-06-23T00:00:00Z

Among the standout announcements from WWDC25, one of the most impactful is without a doubt Apple’s new design system, paired with a reimagined user experience and fresh interface paradigms.

We’re talking about Liquid Glass — Apple’s latest design language unveiled in early June. This new system effectively unifies the entire suite of Apple operating systems under a single visual paradigm. The goal? To ensure unprecedented continuity and fluidity across iOS, macOS, iPadOS, watchOS, visionOS, and even tvOS.

To truly grasp the scale of this shift, it’s useful to take a step back in time — all the way to 2007, when the very first iPhone was introduced.

The Origins of Skeuomorphism

To bring that revolutionary device to life — a smartphone made almost entirely of a 3.5-inch touchscreen — Steve Jobs and his team opted for a visual interface grounded in skeuomorphism. This was a deliberate decision from Jobs himself, who believed it was critical to give users the sense they were interacting with familiar, now-touchable objects. Skeuomorphism uses graphical elements that mimic real-world items to create instant recognizability.

The calculator looked like a physical calculator; the Notes app featured yellow ruled lines like a real notepad; the Calendar resembled a leather-bound planner. Every detail was crafted to make interaction feel as intuitive as possible.

At the time, no one had ever used a fully touch-based smartphone. Competing devices clumsily combined screens with physical keyboards. Jobs wanted something radically different, and skeuomorphism proved a winning idea. Buttons appeared three-dimensional, complete with shadows and highlights, encouraging users to tap. No stylus, no physical keys — just tap, swipe, and pinch.

The term skeuomorphism originates from Greek:

σκεῦος (skeuos) = tool, vessel
μορφή (morphē) = form

In essence: “an object that retains the appearance of an older or more familiar object, despite serving a modern and different function.”

The physical world offers plenty of analogies: ceramic vases that mimic metal, concrete pillars styled after marble, decorative buttons on jackets that no longer fasten anything but recall functional closures.

By the 1980s, the concept had entered the digital world. As graphical user interfaces emerged, designers sought a visual language that could resonate with millions of new users. Apple was among the first to adopt this approach: folder icons, the Trash bin, even the Finder™ were early skeuomorphic elements. These evolved in the early 2000s into the now-iconic AQUA interface of MacOS X.

Skeuomorphism didn’t originate with the iPhone — but it found its fullest expression there, thanks in large part to Scott Forstall under Jobs’ leadership, who between 2007 and 2009 solidified its presence in iPhoneOS.

Many agree that the early success of the iPhone was largely owed to this revolutionary visual choice. The skeuomorphic interface reigned for six years, maturing and becoming a reference point for independent developers who, during that golden age of the App Store, produced apps of remarkable quality.

The Rise of Jony Ive’s Minimalism

In 2013, with iOS 7, Apple abandoned skeuomorphism in favor of a flat, minimalist design language introduced by Jony Ive. Everything became two-dimensional, essential — and, at times, monotonous. The initial interface needed refinement: low contrast, ambiguous interactive elements, and overly saturated colors drew criticism. It took a few years before this new language evolved into something cohesive and appreciated.

Apple wasn’t alone in this transition. Minimalist design found its way into other ecosystems too — first through Microsoft’s brief foray into mobile, and especially through Google’s Material Design, which expanded on the ideas of iOS 7. Over time, Apple would borrow several ideas back from Google to evolve its interface, culminating in the maturity now seen in iOS 18 — twelve years later.

Time for Change

Eighteen years after the iPhone’s debut, the devices we carry in our pockets are full-fledged computers, with capabilities once thought impossible. Minimalist interfaces — even when enhanced with animations and transitions — now feel overly simplistic for such advanced hardware.

That’s why Apple’s decision today makes perfect sense: sacrificing a small portion of processing power to make interfaces feel more alive, expressive, and ready for the spatial computing era. It marks the beginning of a new cycle.

Why the long backstory? Because Liquid Glass represents a shift comparable in magnitude to that of skeuomorphism. It borrows its core ideas, reinterprets them, and encapsulates them in a new symbolic material: glass.

As Craig Federighi explained in an interview with the Wall Street Journal, glass is the perfect metaphor for an interface designed for spatial computing and augmented reality — based on the overlaying of layers. But to make those layers useful, you need a system that’s coherent, readable, and usable across both touch and non-touch devices.

Glass meets those needs: it’s transparent, reflective, fluid. It allows users to see through layers while maintaining focus on foreground elements — preserving environmental continuity.

This concept will take time to mature. But one thing is certain: Apple has chosen its direction — and done so with consistency. This fall, we’ll see its first concrete implementations.

Welcome, Liquid Glass.

— Happy coding! 🖖🏻

Dynamic Island: Neverland and the new iPhone 14 Pro

2022-09-08T00:00:00Z

A stroke of genius. A move nobody expected. Not even the most hardened leakers had grasped the essence of that magic hole which, until a couple of hours earlier, was rumored to take some not well identified digital shape.

Hundreds of words and minutes spent talking about it. The defeatists were already ready to announce the end of Apple, which would lose its distinctive brand: the notch. Someone more cultured wondered whether this choice had not led to dangerous asymmetries and cognitive difficulties with the content shown on screen. Someone else swore to have proof that the notch would become an i of iPhone turned on its side.

One thing is certain. Nobody managed to take away from Tim Cook and his Apple an astonishing surprise effect.

So here we are, admiring in awe and speechless the latest masterstroke from Apple at its event of yesterday, 7 September 2022: the Dynamic Island.

A concept that clearly shows how Apple's design evolves over the years following a precise script, and never at random.

In 2017 (5 years ago, ed.) Apple announced the iPhone X to the world, the first device with a notch, a cutout at the top center of the screen meant to house the bulky sensors for face recognition and the front camera. The choice was heavily debated and caught the eye of the specialized IT press with a mix of approval and dissent, as always, I would add.

At the time OLED displays were already a hot topic and iPhone X had one. We have since seen 4 more revisions of this notch, through Xs, 11, 12 and 13. In the latest revisions its size was slightly reduced and over these 5 years it has become a bit part of us: a unique identity of the Apple brand and of the iPhone. Copied in countless attempts by the competition, but never matched in its stupid and absolute simplicity.

It is 2022 and the time is ripe to go beyond. The display on the new iPhone 14 Pro has a peak contrast ratio of 2,000,000 : 1 and blacks as pure as ever.

It is time, in short, to make creative those holes in the screen that remain indispensable to host sensors and cameras.

Technology is now ready to turn into magic, to give the user the feeling that those holes are not an obstacle but, on the contrary, a feature that makes the experience on the new iPhone more fluid and unforgettable.

It makes me smile because, in this too, I find an analogy with the philosophy of the beloved and late Steve Jobs, who turned a hardware problem on the iPhone 4 into a killer feature, giving birth to the market of cases and bumpers.

What can I say? The result of this dynamic island suddenly makes everything look old. Any existing version of the notch suddenly takes us back well over 5 years, making the whole experience around it feel dated.

An Apple ad I am very fond of comes to mind, which in my opinion perfectly captures the process of conceiving and building this masterpiece of synergy between hardware and software.

YouTubePlays on YouTube. Nothing is loaded until you click.

There is a lot of loose talk that today's Apple no longer knows how to innovate and that there is not much more to get out of our smartphones. In part it is true: we are at the edge of an island and, sooner or later, we will have to set sail to look for other lands.

Knowing how to innovate is also this: seeing something on the horizon that is not there and turning it into a real, tangible island.

App Tracking Transparency using Combine

2021-05-04T00:00:00Z

One of the most publicized feature coming with iOS14.5 is the new App Tracking Trasparency feature. There are plenty of articles around that aim to pinpoint the relevant positions in this decision from Apple and counterparts like Facebook. I don’t want to digging out the political aspect of this feature. Instead, I would like to quickly overview what you need to work with this brand new capability and what this means in terms of technology underground.

App Tracking Trasparency consists of one piece of software in the form of a class named: ATTrackingManager.

Swift

class ATTrackingManager : NSObject

Apple states that this class provides all what you need to ask for permission and get the current status of your request. This class collaborates together with the Ad framework in order to identify anonymously users and let track their habits / interests.

Ad frameworks has a shared instance, available within the whole system, in the form of a class named ASIdentifierManager. We can ask for the shared instance as usual with the classical approach:

Swift

ASIdentifierManager.shared()

Furthemore, we can ask for the current anonymous identifier as easy as:

Swift

ASIdentifierManager.shared().advertisingIdentifier

Before iOS14.5 you (the developer) was always granted to get the above identifier in the form of an UUID object. This identifier is anonymous and consistent across all the operating system allowing to track users across different apps and domains. This, obviously, could lead to a lack of privacy if one or more players in this game are malicious (and, believe me, there’re tons of malicious players all the way around).

Since iOS14.5 you need to ask app based user consensus before you can access the above identifier. This means that you (the user) can decide who can access your identifier at every moment either when you install the app or - if you change your mind - from the Settings. That’s awesome in terms of user rights! And it's not opinable at all.

Our goals for today is to wrap the above classes into a more convenient object that we could use both with Swift and SwiftUI. To achieve that we will use some basic Combine capabilities in order to expose correctly all pieces that we need.

For such of conciseness we will use a pure SwiftUI approach, but all the relevant code will be also ready for Swift standard projects as well. Let’s start and create a SwiftUI project.

The first thing to do is to add the relevant description within our Info.plist in order to populate correctly the message that will appear to our users. Pretty much as with CoreLocation or Photos, we need to describe with an effective sentence what and why we need user consensus to track. To do that, we need to add a new key NSUserTrackingUsageDescription and a paired phrase String as well.

Once we’re ready, we can start coding our helper class that will expose the relevant accessors to our App. We named this helper ATTrackingHelper. Since we want to be notified each time there’s a change either into AuthorizationStatus or AdvertisingIdentifier, we inherits from ObservableObject and mark the two relevant properties as @Published. This means that Combine, under the hood, will create for us all the relevant code in order to track and notify subscribers whenever there is a change.

The last missing piece in order to make this class useful for our purpose is to expose a requestAuth() method. The latter will interact with the framework and will populate the results accordingly.

Swift

class ATTrackingHelper: ObservableObject {
    @Published var status = ATTrackingManager.trackingAuthorizationStatus
    @Published var currentUUID = ASIdentifierManager.shared().advertisingIdentifier

    func requestAuth() {
        guard ATTrackingManager.trackingAuthorizationStatus != .authorized else {
            return
        }
        
        ATTrackingManager.requestTrackingAuthorization { status in
            DispatchQueue.main.async { [unowned self] in
                self.status = status
                if status == .authorized {
                    self.currentUUID = ASIdentifierManager.shared().advertisingIdentifier
                }
            }
        }
    }
}

Time for a Proof-Of-Concept. Given the above approach it will be as easy as declaring an ObservedObject within our ContentView. Pretty much like that:

Swift

struct ContentView: View {
    @ObservedObject var trackingHelper = ATTrackingHelper()

    var body: some View {
        VStack(alignment: .leading){
            Text("Your advertising ID:").font(.callout)
            Text("\(trackingHelper.currentUUID.uuidString)").font(.caption)
            HStack {
                Spacer()
                Button(action: {
                    trackingHelper.requestAuth()
                }, label: {
                    Text("Ask for tracking")
                })
                Spacer()
            }.padding(.vertical)
        }
        .padding()
    }
}

Now we can ask for user consensus, first time we will run our app and populate the required uuidString. What a great time to be an iOS developer! :-)

— Happy coding! 🖖🏻

SwiftUI within UIKit: Connecting two worlds

2021-03-24T00:00:00Z

Last evening, I was involved in a very interesting Clubhouse room, talking about SwiftUI and Swift interoperability. The rest of the article is a proof-of-concept exploring some interesting ideas arisen with Dimitri Giani, Stefano Mondino and Andrea Mengoli, during the chat.

SwiftUI comes with both interesting performances and facilities in creating even complex layout but moving a complete project from Swift to SwiftUI couldn’t be always feasible for a lot of reasons (framework maturity, time constraints, etc.). So, why don’t take the best from the two worlds?

There’re tons of tutorials and articles related to the use of UIHostingController that, as of today, seems to be the only viable solution to make the above propositions coming to light. However, last night we focused on a slightly different point-of-view:

Moving only very small portions of code from Swift to SwiftUI.

For example, one of the most hated things that every iOS developer would like to skip is dealing with Storyboard for UITableView/UICollectionView cell design.

Wouldn’t be nice to migrate just the content of such UITableViewCell to SwiftUI for performance, maintanability and easiness purpouses, making also future-proof at least some portion of our code? That was the Dimitri Giani proposition.

Everyone, including me, was sceptical since the use of UIHostingController seems a really complicated over-engineered approach for such performance-critical task (aka UIScrollView reusable components).

Needless to say, I was wrong. At least, in a very early test discussed in the rest of this article, this approach — with some caveats — works like a charm, without any performance issue.

Above, there is a draft of what we would like to achieve. As you can see, the UITableViewCell needs to be aware of the corresponding UIHostingController rootView property and, since each UITableViewCell instance needs to be reusable we should keep those property unique.

We make our CustomTableViewCell aware of that, by creating a private constant that instantiate a UIHostingController and configure that object in the very early awakeFromNib stage.

The configure(title:sfIcon:) method is just a placeholder that exploit the Combine / publisher approach in order to communicate with the corresponding SwiftUI view. Here, we send a plain Notification when we need to configure the corresponding SwiftUIView.

Please note, that we need to specify the object property, since, we would like to deal just with one instance of the object.

Yep!, I’ve to admit, this looks really hackish…

The SwiftUI counterpart is really simple. Here we create just an HStack container, in order to old both thumb image and title. We, also, adjust the frame in order to get all the space available without further constraints (the corresponding UIView that hold us will be responsible for the container dimension, ndr.). onReceive we will update our corresponding states, making the view update itself where required.

You’ll notice that I made the struct itself conform to Equatable, by adding both an id and the relevant override method. This’s required in order to distinguish if we need to discard or take into account the received published method coming from NotificationCenter.

That’s all. Even if the above solution is a really hackish / over-engineered cell architecture, I’m really impressed by results: scrolling is smooth and without any glitch.

I’m pretty sure that there should be other ways to achieve the same result with less boilerplate and/or in a much more elegant way (especially for the UIKit to SwiftUI communication).

I can not wait to see your comments / commits. The full code is available here on GITHUB.

Apple Silicon: Back to the future

2020-11-20T00:00:00Z

Year 2020 is gonna be remembered as a milestone for information technology, pretty much as 2007 was a milestone for mobile telephony.

Tim Cook’s Apple has succeeded, once again, marking an historical step forward in the world of computing. I don’t think I’m exaggerating comparing the M1 introduction to the iPhone historical presentation that everyone here surely remember.

Certainly, times and actors are much different but the final result (and execution) is blowing away, the same way.

Intel will have to rearrange many of its (prehistorical) timelines in order to try to close the gap. Still, a comparison to 2007 comes naturally to me, like when Blackberry was suddenly ousted from the podium in a sudden and almost unexpected way — only for them, who did not want to see beyond their nose. Today’s Intel has an awkward production pipeline able to create just foot warmers; I don’t want to appear biased or whatever, but this is pretty much resembling reality of things, by now.

Real problem is that in computers world things are far more complex compared to what happened for mobile phones in 2007. Computers are different beasts with a well established workflow and culture composed by a lot of tiny third parties components: Intel doesn’t produce final computers directly but only a small amount of those final products. And it’s not a case.

Apple, on the other hand, since the very beginning has opted all-in to a seamlessly full integration among hardware and software. Stop reading and think for a moment:

What about if, when everything started, Wozniak had financial availabilities (such as the nowadays multimillionaire Apple) to build its own processor?

At the time things were completely different and Motorola was the closer partner in the quest to defeat a common enemy. Fortunately for them, times are changed and today’s Apple doesn’t seems to be interested in “sharing” its technological advantage (estimated in at least 6 years) with the world. Worth to note that six years are almost an era in computer field.

Dell, Hp, Lenovo and all the other players has little to do other than try to bridge the gap starting to run the race. There are just two alternatives, imho:

Establish an alliance (as it was for USB) and try to build a processor as similar as possible to the Apple’s M1.

2)Stay on the Intel boat, hoping that the latter will give a radical change to its asset and something will change as soon as possible.

Both solutions are doomed to fail for the same simple reason: time.

Whatever choice competitors take, it will take time and if it’s true, as rumors suggest, that Apple has been working on M1 for over eight years, this gives a clear idea of how long it takes to catch up the winner.

In the meantime Apple will rise, once again, the “best-selling computer” podium as it was in the first half of 2000 and - hopefully for them - the virtuous lock in / loop that binds Apple ecosystem will be secured for the next decade, at least.

Steve Jobs could not have been prouder of his successor.

SwiftUI Programming: ObjectBinding and BindableObject

2020-01-10T00:00:00Z

In a previous article we have seen that in SwiftUI is possible to associate one or more states to a View through the modifier @State; the latter must be used with value types allocated within the declaring View. This way our application is able to autonomously understand when to update the user interface with respect to the changes made to our variable marked with @State which, we recall, is identified as a source of truth.

But what if our source of truth is a complex object designed, for example, as a class construct? In this case @State will fail in its intent because it is designed to work exclusively with local properties of our View.

SwiftUI provides a better further concept to dialogue with that case: @ObjectBinding. The latter could be used in all cases in which the property is passed by reference such as in the class case.

Swift


struct MyCustomObject : View {
    @ObjectBinding var myObject
    var body: some View {
        Text(myObject.someTextProperty)
    }
}

BindableObject protocol

Properties with an associated @ObjectBinding modifier, therefore, refer to class objects. In order for a class to be compatible with the @ObjectBinding modifier, the BindableObject protocol must be adopted.

BindableObject protocol is fairly simple in its simpliest variant and requires only that our class implement a property called didChange, which will notify the subscribed View objects so that they can react correctly to visual interface changes.

Swift


class MyObject : BindableObject {
    let didChange = PassthroughSubject<Void, Never>()
    
    var someTextProperty:String = "" {
        didSet {
            didChange.send( () )
        }
    }
    
    ...
}

Combine framework and PassthroughSubject

In order to work, the code above needs to include the support for the Combine framework at the beginning of our swift file.

Swift


import Combine

Combine framework is a very powerful and somewhat complex tool that we will see in a future article. For now we just need to know that it - among many other things - provides a class called PassthroughSubject (our property didChange is an instance of this class). It is responsible to notify (Publishing) the interested parties (Subscribers) that a specific event happened.

PassthroughSubject, as the name suggests, behaves very similarly to traditional notifications made available by the Swift Foundation framework with NSNotificationCenter: the object specified as a parameter (in our case Void, since we don't want to pass any parameter) is passed roughly and without any modification to the recipient along with a notification event that trigger a new rebuild of the view.

If you want to specify an error along with the notification, you can pass it as a second parameter. In our example we are not interested in this eventuality and it is the reason why we pass Never as the second parameter for the PasstroughSubject invocation.

Swift


let didChange = PassthroughSubject<Void, Never>()

Once an instance of type PassthroughSubject is created, it could be used to perform the publishing of our event whenever we wish to notify subscribed Views about changes in our source of truth.

To accomplish the last requirement we use the didSet construct made available by Swift which is invoked whenever the value of a propery changes:

Swift


var someTextProperty:String = "" {
    didSet {
        didChange.send( () )
    }
}

This way, when we make a change to the someTextProperty the didSet construct will be invoked. Inside it we will make a call to the send() method of the PassthroughSubject instance.Notice how we specify a Void type parameter by passing a pair of parentheses () within the method.

Doing so all objects subscribed to changes - those that have declared their property as @ObjectBinding - will know that the time has come to refresh their body.

Fig.1 - Simple schema illustrating references with ObjectBinding.

As you can see from the diagram above, our model is characterized by a single instance in memory, through a class compliant with the BindableObject protocol. Our View objects contain a reference to the original object.

This way a characteristic problem known as the duplication of the source of truth is avoided: changes to the model will be unique and characterized by an immediate update of all the views that refer our class.

Fig.2 - Simple schema illustrating source of truth and ObjectBinding.

An example

Let's try to put the above concepts into practice with an example. In the previous article we had configured our CustomTableViewCell to use a variable passed by value containing a struct named Person.

Swift


struct CustomTableViewCell : View {
    var model: Person
    
    var body: some View {
    ...

This approach didn't allow the CustomTableViewCell to be independent regarding updates of its own content; The variable, in fact, was copied during the CustomTableViewCell init phase.

Every change to its content was managed through a @State variable, owned by ContentView that regenerate the new cell with the new content each time a change happen.

Fig.3 - State vs Object binding reference.

Through the use of the @ObjectBinding concept, we can make unique the Person model by passing just a reference to the CustomTableViewCell, as shown in the graph above on the right.

The first thing to do is modify our Person model to use a class that conforms to the BindableObject protocol instead of a struct.

Swift


class Person : BindableObject {
    let didChange = PassthroughSubject<Void, Never>()
    
    var photoName:String { didSet { update() } }
    var title:String { didSet { update() } }
    var subtitle:String { didSet { update() } }
    
    init(photoName: String, title: String, subtitle: String) {
        self.photoName = photoName
        self.title = title
        self.subtitle = subtitle
    }
    
    func update() {
        didChange.send(())
    }
}

Our new model adopts the BindableObject protocol by implementing the +didChange* property through a PassthroughSubject instance.

Each property affected by possible changes to the visual interface ( photoName, title and subtitle ) has been adequately modified to react through the didSet construct. This way, whenever we update one of the variables, the update() function will be triggered by sending, in turn, a notification to all subscribers through the PassthroughSubject instance.

Finally, CustomTableViewCell will be modified to take advantage of the new reference model. To do this we simply prepend the @ObjectBinding modifier discussed above.

Swift


struct CustomTableCell : View {
    @ObjectBinding var model: Person
    
    var body: some View {
        return HStack {
            Image(model.photoName)
                .resizable()
                .aspectRatio(contentMode: .fit)
                .clipShape(Circle())
                .frame(width: 60, height: 60, alignment: .center)
            VStack(alignment: .leading) {
                Text(model.title).font(.title)
                Text(model.subtitle).font(.subheadline).fontWeight(.thin)
            }
            Spacer()
        }
    }
}

This way the CustomTableViewCell does not have a copy of the Person model. Instead it works with a reference to the memory area in which the original model is stored. Let's see where and how to create the model to be passed as a reference.

ContentView will be responsible for such requirement, creating the actual model in memory and by passing it by reference to the CustomTableViewCell.

Swift


struct ContentView : View {
    var dataSource:[Person] = [
        Person(photoName: "photoThumb", title: "Mario Rossi", subtitle: "Amministratore"),
        Person(photoName: "photoThumb", title: "Giuseppe Bianchi", subtitle: "Consigliere"),
        Person(photoName: "photoThumb", title: "Luca Verdi", subtitle: "Funzionario"),
    ]
    var body: some View {
        List {
            CustomTableCell(model: dataSource[0])
            CustomTableCell(model: dataSource[1])
            CustomTableCell(model: dataSource[2])
        }
    }
}

List and TableView

This new version of ContentView uses a new object called List which groups elements pretty much the VStack counterpart. The difference is in the visualization: the result will be much like an UITableView from the counterpart UIKit framework

What we see above is List simplest form of declaration. In the next article we will see how to make its content dynamic, based on the declared model.

--See you soon!

SwiftUI Programming: An Introduction to States

2020-01-09T00:00:00Z

We have seen in a previous article that in SwiftUI a View is a struct that conforms to the View protocol. Therefore, it does not inherit any stored property just because there is no father at all; it is allocated on the stack and its operated by value and not by reference (as is the case with classes in UIKit).

How views works in SwiftUI

Behind the scenes, SwiftUI manages the Views with the help of an highly efficient data structure for on-screen rendering of the content. For this reason it is advisable to use and create specialized and reusable components. During development - Cupertino reassures - you should not have hesitations to extract views that perform a specific task and create for them a specific View object.

Together with the body, a View in SwiftUI defines its dependencies.

Let suppose we want to create a View in SwiftUI specialized in creating and handling a button. Simply, our object will have to take charge of managing a single scope: at its pressure, the label will have to change reflecting the new state.

That last point is where the declarative programming shines: the consequence of an action as a way to update the interface.

The @State attribute in SwiftUI

Our button, therefore, will have a dependency between its state and its representation on the screen. In SwiftUI this dependency is automatically managed by the new @State modifier. Let's try an example to better understand this concept.

Swift


struct MyButton : View {
    @State private var toggleStatus:Bool = false
    var body: some View {
        Button(action: {
            self.toggleStatus = !self.toggleStatus
        }) {
            Text((toggleStatus == false) ? "Press Me" : "Unpress me")
        }
    }
}

@State binds the toggleStatus variable to the interface concept: whenever its value changes, SwiftUI will know that it is necessary to generate a new body (and therefore a refresh of the label associated with it).

Fig.1 - Simple diagram illustrating the data flow related to the code above.

Try removing @State from the code above. What happens and why?

Removing the @State attribute, the compiler will complain that we are trying to change an immutable value: don't forget that we are in the presence of a struct. Every object that is rendered on the screen, in fact, is immutable for performance reasons. This way, SwiftUI knows what needs to be updated and what can be left out By adding a @State modifier, we are explicitly telling SwiftUI:

"Beware! There's an object here that could change its state, so you'll need to update its contents."

Therefore, SwiftUI implicitly defines a dependency between this variable and the View on-screen presentation each time it will encounter a @State attribute. That way, whenever the variable changes value, SwiftUI will know that the View must be redrawn using the new value.

To seal this concept and see how much different it is from traditional programming, let's try to make a joint with UIKit:

Swift


import UIKit

class ViewController: UIViewController {
	@IBOulet var aButton: UIButton!
	var toggleStatus:Bool = false
	
	override func viewDidLoad() {
		super.viewDidLoad()
	}

	@IBAction func buttonDidPressed(sender: UIButton) {
		sender.setTitle((toggleStatus) ? "Unpress me" : "Press me", for: .normal)
		toggleStatus = !toggleStatus
	}
}

Clearly in UIKit, the code above is not enough to render a working screen application. We will have to create a Storyboard with a UIViewController and an UIButton. We will, also, have to align the button with Constraints in the center and create the correct @IBOutlet and @IBAction references to make the whole flow working.

Leaving aside the obvious greater amount of code and actions compared to SwiftUI, let's focus on our state. Also in this case, in fact, our button needs to discern the current state in order to be able to change its representation (label). Notice how, in the case of traditional imperative programming, there are two major conceptual concerns:

toggleStatus is managed (allocated, initialized and modified) by the Controller.
There is no clear code-level way to separate variables related to the state of the interface from traditional ones: they are all the same!

Fig.2 - A diagram illustrating the relationships and flow of our Button object in UIKit.

It is also evident how the complexity of this approach grows exponentially with the increasing number of objects and states.

Fig.3 - Diagram illustrating the increase in complexity as the states managed by the interface grow.

There's one more thing we should underline there: iOS is a multithreaded operating system. This means that requests for status and interface updates can come from multiple points in the code and that threads work independently from each other. Without a clear way to handle such kind of circumstances lead to inconsistences in the UI and therefore a bugs that are hard to discover and fix.

Fig.4 - In the case of a multithreaded application boundary between who updates the interface and who updates the status is not clear.

The search for truth

But how is managed this dependency between variables and interface in SwiftUI? And what makes the system resilient and scalable unlike a traditional imperative approach?

When SwiftUI processes a View with a variable of type @State, it allocates a space for this variable in memory on behalf of the View.

Fig.5 - @State variable allocation in SwiftUI.

By adding the @State attribute, we are able to modify an object that is otherwise immutable as a struct: behind the scenes, in fact, the variable is allocated by the SwiftUI framework in a read/write area of the application.

In SwiftUI, every possible View state (scrollview offset, button status, stack contets, etc.) is managed by this concept otherwise known as Source of Truth. Following this concept, it is possible to classify each variable either as a source of truth or a derived value.

Fig.6 - Diagram showing classifications of variables in SwiftUI.

In our example above, toggleStatus is a source of truth. Moreover, from the diagram above, we could argue that all constants are also a source of truth while a simple property is a derived one.

We will see in the next chapters that there is another mechanism for passing derived read/write values, called @Binding. We will focus also in what a a derived value differs from the corresponding source of truth with a practical example. We will analyze the differences with @State and how and when to use one with respect to the other.

Organize the code: view extraction

Now that we have clear how a View updates and rebuild its content, let's try to put together what we learned in relation to the example of the last article. Last time, we left our ContentView as follow:

Swift


import SwiftUI

struct ContentView : View {
    var body: some View {
        VStack {
            HStack {
                Image("photoThumb")
                    .resizable()
                    .aspectRatio(contentMode: .fit)
                    .clipShape(Circle())
                    .frame(width: 60, height: 60, alignment: .center)
                    .padding(EdgeInsets(top: 0, leading: 20, bottom: 0, trailing: 0))
                VStack(alignment: .leading) {
                    Text("Mario Rossi").font(.title)
                    Text("Amministratore delegato").font(.subheadline).fontWeight(.thin)
                }
                Spacer()
            }
        }
        
    }
}

Clearly this approach is not maintainable. The code has a tendency to nest and growing towards the right, in a so-called "doom pyramid".

At the beginning of the article, we mentioned a mechanism for extracting subviews in order to make the code scalable and maintainable. Let's see what the new Xcode11 and SwiftUI environment offer us to solve this problem.

Be sure to be using Xcode11 and move the mouse to the HStack tag. Holding down the CMD (⌘) state click on the tag, as follow:

Fig.7 - Xcode automatically creates a new struct giving us the possibility to change the name.

Xcode automatically creates a new struct, extracts the selected content and uses it to populate the body of the newly generated object. At the end of the operation, it also offers us the possibility of changing the name: rename the View extracted in CustomTableViewCell.

The new version of ContentView has now become much more readable and lightweight, including only a reference to a new object. As a niccce to have, we could also move the contents of the CustomTableViewCell into a new file to better isolate the concept of component.

Passing parameters

Wouldn't it be interesting to pass the right parameters to our new CustomTableViewCell, in order to generate a cell with dynamic contents such as title, subtitle and image? Let's try to modify our new class to get this result:

Swift


struct CustomTableCell : View {
    var photoName:String
    var title:String
    var subtitle:String
    
    var body: some View {
        return HStack {
            Image(photoName)
                .resizable()
                .aspectRatio(contentMode: .fit)
                .clipShape(Circle())
                .frame(width: 60, height: 60, alignment: .center)
                .padding(EdgeInsets(top: 0, leading: 20, bottom: 0, trailing: 0))
            VStack(alignment: .leading) {
                Text(title).font(.title)
                Text(subtitle).font(.subheadline).fontWeight(.thin)
            }
            Spacer()
        }
    }
}

Now, inside the ContentView, our CustomTableCell can be created with parameters that uniquely define its content.

Swift


struct ContentView : View {
    var body: some View {
        VStack {
            CustomTableCell(photoName: "photoThumb", 
                                title: "Gianluca Verdi", 
                             subtitle: "Consigliere")
        }
        
    }
}

What if we would like to go further and create, for example, a button that changes the contents of the subtitle field?

The model, the object and SwiftUI

The model linked to a View object plays a fundamental role in SwiftUI's declarative paradigm. Each object typically has a model associated with it that, together with the state, completely identifies the user interface displayed.

For example, we could associate a model of this type with our CustomTableViewCell:

Swift


struct Person {
    var photoName:String
    var title:String
    var subtitle:String
}

As a result, our View will have to be changed in order to take advantage of the new model just created:

Swift


struct CustomTableViewCell : View {
    var model: Person
    
    var body: some View {
        return HStack {
            Image(model.photoName)
                .resizable()
                .aspectRatio(contentMode: .fit)
                .clipShape(Circle())
                .frame(width: 60, height: 60, alignment: .center)
                .padding(EdgeInsets(top: 0, leading: 20, bottom: 0, trailing: 0))
            VStack(alignment: .leading) {
                Text(model.title).font(.title)
                Text(model.subtitle).font(.subheadline).fontWeight(.thin)
            }
            Spacer()
            }
    }
}

Finally, the ContentView must reflect this change to properly render on screen our CustomTableViewCell.

Swift


struct ContentView : View {
    @State private var model = Person(photoName: "photoThumb", 
                               title: "Mario Rossi", 
                            subtitle: "Amministratore delegato")
    
    var body: some View {
        VStack {
            CustomTableViewCell(model: model)
            Button(action: {
                self.model.subtitle = "Consigliere"
            }) {
                Text("Change subtitle")
                .foregroundColor(Color.white)
                .padding(EdgeInsets(top: 8, leading: 8, bottom: 8, trailing: 8))
                .background(Color.blue)
                .cornerRadius(8)
            }
        }
    }
}

This time the model variable has the attribute @State: The model owner is the ContentView object, it is then passed by copy - let us remember that we are working with structures and not with classes - to the CustomTableViewCell which, in turn, uses it to render the corresponding fields of its objects: Image and Text.

The button has an action to update the model that changes its subtitle. Since ContentView has added the @State attribute to its model, any change of the latter triggers the update of its body which, in turn, regenerates a new CustomTableViewCell with the brand new content.

Fig.8 - Flow schema illustrating object status update.

You may have noticed that I added the private attribute before declaring the model status variable. This is because, as we explained above, the variables marked as @State belong exclusively to the View that declares them. It is therefore a good idea to reinforce this concept by marking them as private.

We will see in the next article that SwiftUI exposes other ways to manage parameters and injection when we are dealing with situations like the one illustrated above. In this case, in fact, although syntactically and functionally correct, our flow suffers from a small problem: our CustomTableViewCell uses its own copy of the model which in turn is exposed, allocated and managed by ContentView with a private variable.

SwiftUI offers abstractions very similar to the @State attribute to handle these circumstances and allow the model to be propagated correctly where needed.

What happens if we change the model from struct to class?

Although the project will continue to compile and run without problems, unfortunately we will notice that in practice the button will no longer change the content of the subtitle field.

@State works with value types, while classes are reference types: by changing the value of a class marked with the @State attribute, its internal change does not trigger the body update.

-- 🖖🏻

SwiftUI Programming: Building more complex views

2020-01-08T00:00:00Z

We have seen that SwiftUI always requires to expose a body that returns a View. In the construction of complex views, however, it is necessary to compose these Views with a specific layout and return them in the form of a single object. To do this, SwiftUI comes to our aid through the Content View concept.

The basic objects with which we talk, such as Text that we saw in the previous chapter, adhere to the View protocol. There are other, more complex objects, that in the declaration of their API have a format similar to the following:

Swift


public struct VStack<Content> where Content : View

The above is the declaration of the VStack component that we will analyze during the rest of the article. If we look at the definition of Content, we will see that:

Swift


@_functionBuilder public struct ViewBuilder {
    ...
    public static func buildBlock<Content>(_ content: Content) -> Content where Content : View
    ...
}

Basically, objects like VStack use a ViewBuilder constructor to compose multiple View types together.

The ViewBuilder closure

The closure viewbuilder allows us to insert typically declarative instructions inside it: instead of invoking an addSubview method, as we did with UIKit, we will insert a list with all the views contained directly within the closure.

To better understand this concept, let's take a closer look at the definition for the VStack struct:

Swift


public struct VStack<Content> where Content : View {
    public init(
        alignment: HorizontalAlignment = .center, 
        spacing: Length? = nil, 
        @ViewBuilder content: () -> Content
    )
}

The content parameter is defined as a closure () -> Content. The compiler knows this attribute implicitly marked as @ViewBuilder and knows how to transform it into a new closure that returns a view representing all the content declared within VStack.

This principle is present in all objects that expose a where Content: View clause

Stack View

A Stack View is a special View of kind Container View that allows us to return a composition of other View objects, according to a vertical, horizontal or depth layout.

Continuing our comparisons with the UIKit framework, the corresponding object that we will analyze in this paragraph, are the UIStackView. In SwiftUI, however, apart from the basic concept there is very little of the classic UIStackView.

Stacks objects currently available are of three flavours: HStack, VStack and ZStack. Respectively: Horizontal Stack, Vertical Stack and Depth Stack (Z indicates the depth dimension).

These objects together with the modifiers we saw in the previous chapter, allow us to completely replace the concept of Auto Layout and Constraints. From a technical point of view, this greatly increases the responsiveness and the rendering speed of the application, because the system does not need to pre-calculate any specific constraint or layout: everything is declared a priori, in a full declarative style.

Fig.1 - A simple hierarchy that show a typical VStack use.

In code, we'll write something like this:

Swift


import SwiftUI

struct ContentView : View {
    var body: some View {
        VStack {
           Image( ... )
           Text( ... )
           Text( ... )
           Text( ... )
           Slider( ... )
        }
    }
}

As you can see, unlike UIKit, references to methods like addSubview are no longer present. In SwiftUI, views are created entirely with a process of declarative composition of the structures. Simply, let's say to the compiler that our ContentView has inside a VStack container with inside: Image, Text, Text, Text and Slider.

We are not paying attention to individual factory methods for now. We will have time to return to slider images and advanced controls immediately ahead. For now, the important thing is to understand exactly what is happening and why.

A very important note relative to ViewBuilder regards the syntax to be used in it. Even if we are in the presence of Swift, in fact, within this closure it is not possible to use some typical operators to which we have been accustomed, such as the optional unwrapper:

Swift


...
VStack {
    if let anImage = anImage {
       Image( ... )
    }
    Text( ... )
    Text( ... )
    Text( ... )
    Slider( ... )
}

This code will produce a compilation error. The ViewBuilder closure cannot - for now - correctly parse the optional unwrapping concept. The following code, on the other hand, works correctly:

Swift


...
VStack {
    if anImage != nil {
       Image( ... )
    }
    Text( ... )
    Text( ... )
    Text( ... )
    Slider( ... )
}

Build a custom TableViewCell

Since the easiest way to learn a new tool is to go to practice, in this section we will try to replicate the typical behavior of a UITableViewCell with title and subtitle. The result we would like to achieve is something like this:

Fig.2 - TableViewCell that we would like to achieve.

First thing to do is to create a new project that includes support for SwiftUI:

Fig.3 - Steps to follow

We will now replace the ContentView struct provided by default with the following code:

Swift

struct ContentView : View {
	var body: some View {
		VStack(alignment: .leading) {
			Text("Mario Rossi").font(.title)
			Text("Amministratore delegato").font(.subheadline).fontWeight(.thin)
		}
	}
}

At this point in the Preview Canvas pane, you should see the result of your statements appear magically:

Fig.4 - Preview pane in Xcode11 showing the result of our declarations to the SwiftUI framework.

If you don't see anything, first make sure you're in a MacOS Catalina 10.15 environment, the Live Preview system, works exclusively on this environment. If you are already in 10.15 but you still don't see the live preview, make sure you have enabled the Canvas panel as follows:

Fig.5 - To get the Live Preview working, be sure to be in Catalina 10.15 and have enabled the Canvas panel.

Simple? You bet! We still lack some elements to complete our work. The first thing is the image. Download the reference image that you find at the bottom of the article and, taking care to select the Assets.xcassets folder of your project, drag the image you have just downloaded into it.

Fig.6 - Import an image for our assignment inside the assets folder.

The Image object

Every framework must have the possibility to dialogue in a more or less complete and complex way with images. SwiftUI offers a truly formidable support for this type of objects that will not make us regret even its cousin UIImageView.

Image is a View object (the result is an object adhering to the View protocol). In its most basic form, we supply the name of an image to display:

Swift


Image("photoThumb")

The result is the a View with the image provided as an argument. If we try to insert this instruction inside the VStack:

Swift


...
VStack(alignment: .leading) {
    Image("photoThumb")
    Text("Mario Rossi").font(.title)
    Text("Amministratore delegato").font(.subheadline).fontWeight(.thin)
}
...

result will not be exactly what was hoped for:

Fig.7 - The first attempt with Image is not exactly what was hoped for!

Lets try to solve this problem. The first thing to do is to align the image horizontally with the rest of the content. Remember when we were talking about VStack?

His job is to vertically align the list of items provided in his ViewBuilder block. It is clear, therefore, that it is necessary to slightly change the diagram of the views on which we are working on, taking care to add an additional variant of Stack provided by SwiftUI: HStack.

Fig.8 - The new tree diagram of how we would like to modify our ContentView.

Swift


struct ContentView : View {
    var body: some View {
        HStack {
            Image("photoThumb")
            VStack(alignment: .leading) {
                Text("Mario Rossi")
                    .font(.title)
                Text("Amministratore delegato")
                    .font(.subheadline)
                    .fontWeight(.thin)
            }
        }
    }
}

Fig.8a - Second Attempt

Much better!

We still have to adjust the shape and size of the image. The first thing I want to do is tell our image that it should be resizable and keep its aspectRatio.

Swift


...
Image("photoThumb")
    .resizable()
    .aspectRatio(contentMode: .fit)
...

Then I would like to give it a circular shape and force its size to 60pt:

Swift


...
.clipShape(Circle())
.frame(width: 60, height: 60, alignment: .center)
...

and, finally, I would like to add some padding from the left, let's say 20points:

Swift


...
.padding(EdgeInsets(top: 0, leading: 20, bottom: 0, trailing: 0))
...

All together:

Swift


struct ContentView : View {
    var body: some View {
        VStack {
            HStack {
                Image("photoThumb")
                    .resizable()
                    .aspectRatio(contentMode: .fit)
                    .clipShape(Circle())
                    .frame(width: 60, height: 60, alignment: .center)
                    .padding(EdgeInsets(top: 0, leading: 20, bottom: 0, trailing: 0))
                VStack(alignment: .leading) {
                    Text("Mario Rossi").font(.title)
                    Text("Amministratore delegato").font(.subheadline).fontWeight(.thin)
                }
            }
        }
        
    }
}

The Spacer object

At this point our CustomTableView seems to be complete but a small problem still persists: it seems to be aligned to the center rather than to the left.

The problem is related to the fact that Stacks by default - I remember that the main one we are working on expands horizontally (HStack) - are designed to take all the space available on their main axis, dividing it equally between the children.

Therefore, to be able to align the entire object on the left it is necessary to add an additional neutral view called Spacer. The View Spacer is a flexible view that expands automatically throughout the main axis of the stack in which it is inserted. We will add this View as the last element of our horizontal stack:

Swift


struct ContentView : View {
    var body: some View {
        VStack {
            HStack {
                Image("photoThumb")
                    .resizable()
                    .aspectRatio(contentMode: .fit)
                    .clipShape(Circle())
                    .frame(width: 60, height: 60, alignment: .center)
                    .padding(EdgeInsets(top: 0, leading: 20, bottom: 0, trailing: 0))
                VStack(alignment: .leading) {
                    Text("Mario Rossi").font(.title)
                    Text("Amministratore delegato").font(.subheadline).fontWeight(.thin)
                }
                Spacer()
            }
        }
        
    }
}

Here's how our preview will look, once the job is complete:

Fig.9 - The final tree hierarchy of the CustomTableViewCell.

Note: current version of Xcode11 contains a known problem that does not correctly resize the image when using the .fit option getting, instead some sort of stretch effect on the content.

In the next chapter, we will see some rules of good conduct that try to make the code as minimal and compact as possible, adopting subviews extraction techniques. We will also see an introduction to passing parameters and how SwiftUI manages the status of its elements.

-- 🖖🏻

SwiftUI Programming: Classes and Structs in SwiftUI

2020-01-07T00:00:00Z

I'm pretty sure that everyone had the following question, at least one time.

"If the concept behind a View is the protocol, what if I try to use a class instead?"

Let's try to analyze it in detail.

Swift


class ContentView: View {
   var body: some View {
      Text("Hello World")
   }
}

The code above, although syntactically perfect, produces an error. In fact, the compiler complains that the class itself is too mutable in the course of execution. In fact, a class is indeterminate by its nature: what would happen if ContentView itself had a subclass?

The View protocol would not know how to guarantee uniqueness. * Self * would continue to refer to ContentView and the subclass would violate this rule.

Swift


class SomeView<T: View> {
   var body: some View {
      Text("Hello World")
   }
}

or, simply:

Swift


final class ContentView: View {
   var body: some View {
      Text("Hello World")
   }
}

At this point - if it is really necessary - we can use a class to work in SwiftUI.

SwiftUI Programming: The View Object

2020-01-06T00:00:00Z

We have seen that SwiftUI is a declarative framework. The visual result of what we see in our device is the result of a series of statements we make to our compiler about how we would like to see our interface. But if the UIView was the beating heart in UIKit, what is the equivalent in SwiftUI? The answer is a new object, called View.

What is a View?

The first real and big difference compared to a UIView is the fact that in SwiftUI a View is a struct that conforms to a protocol. The basic example provided by Apple begins this way:

Swift


struct ContentView: View {
   var body: some View {
      Text("Hello World")
   }
}

The one above is a fully functional SwiftUI object named ContentView and which contains (returns) a label with "Hello World" in its body.

You will notice that I talked about the concept of "containing" (return was only hinted at in brackets). In fact, one of the cornerstones of SwiftUI is the reusability of the code and the concept of View reusable as if they were Lego ™ bricks.

Fig.1 - Tree like hierarchy about the above example.

A view, therefore, defines a piece of our User Interface.

Everything in an app in SwiftUI can be traced back to a View. The latter defines, therefore, a piece of our interface. As a consequence, complex views are constructed from elementary bits that cooperate and work together creating a tree hierarchy. Behind the scenes, the compiler handles all the Views an translates them in a highly efficient data structure that display the required content on screen. But how does this composition work?

One only requirement: body

We said above that a View is a struct that conforms to the View protocol. The only requirement of this protocol is to provide our View with a body responsible for the content of our object. The body is a special closure that returns a content also in the form of a View. For example, in the code above provided by Apple:

Swift


...
   var body: some View {
      Text("Hello World")
   }
...

In the above case, the body of our View is a basic component, called Text, which in turn returns an object conforming to the some View type request expressed in the body. This syntax is part of a new concept presented with Swift 5.1 called Opaque Types. For now it is enough to know that the opaque type required by the body, allows us to effectively interchange objects of which we do not know the specific type in advance but which is well determined at the level of compilation (unlike a simple protocol).

Opaque types

Returning an opaque type seems very similar to using a protocol. However, these two constructs differ in the fact that the opaque type preserves the type. An opaque type refers to a specific type, even if the caller of the function is not able to see which type it is. A protocol, on the other hand, can refer to any type that conforms to it. The latter offer more flexibility with respect to the returned type. The opaque types, on the other hand, allow us to have specific guarantees regarding the returned type.

Let's try to give an example, to clarify the concept better:

Swift

mport UIKit

protocol Humanoid {
}

struct Woman : Humanoid {
}

struct Man : Humanoid {
}

func child() -> Humanoid {
	Bool.random() ? Woman() : Man()
}

The Humanoid protocol is adopted by two structures: Man and Woman. The child function, returns a Humanoid type that can be equally probable one of the two cases mentioned. At this point, we create two humanoid instances:

Swift


let first = child()
let second = child()

and since we are curious to know if our children are male or female, let's try to compare them:

Swift


print((first == second))

The compiler, at this point, will blame us - rightly - about the fact that the humanoid class is not comparable because it does not adopt the Equatable protocol. Not bad, you'll think. Let's try to adopt it:

Fig.2 - Playground output.

Problem is that Humanoid cannot be compared because Swift has no guarantee that the returned items are of a comparable type. I recall that any structure can adopt the protocol, by implementing the required methods.

To solve this problem, opaque types are born. The code above can be transformed as follows:

Swift


import UIKit

protocol Humanoid : Equatable {
}

struct Woman : Humanoid {
}

struct Man : Humanoid {
}

func boy() -> some Humanoid {
	Man()
}

func girl() -> some Humanoid {
	Woman()
}

let primogenito = boy()
let secondogenito = girl()

An important observation about the code above is that, as you will notice, I had to create two different children() functions (one for female - bambina and one for Male - bambino) because one of the main requirements when working with an opaque type is that the methods must return only one type of object. You will find this concept very often in SwiftUI when we will work with Views.

SwiftUI Programming: An Introduction

2020-01-05T00:00:00Z

SwiftUI certainly marks the beginning of a new chapter in the history of development at Apple. For years we have witnessed the proliferation of frameworks based on the concept of declarative interfaces; the web is a prime example of this phenomenon, but there are other notable examples in the field of mobile development. We are constantly amused with marketing messages that state how:

"maintaining a single codebase for all platforms is the best way to increase business productivity and provide effective solutions to our customers."

React Native (Facebook) and Flutter (Google) are an excellent example of this proposition. It is not the purpose of this article to make a comparative analysis of these technologies; the point for which these two examples have been cited is to show how the software trend of recent years is moving in different directions from those we have been used to up to now.

Our devices are increasingly powerful and this power finds its natural placement in increasingly sophisticated and complex interfaces and interaction paradigms. Last year, I wrote a piece about the release of iPhone X and the feeling of fluidity that this new device, combined with the latest stylistic choices of iOS 11 and 12, had aroused me.

Smooth, continuous and consistent animations, gestures merged within the navigation experience. These are just some examples of what I am trying to convey to you: the expectation bar has risen once again and these new features are not easily expressed with a traditional framework.

"The discrete nature of imperative languages is in great difficulty, compared to the sense of continuity and fluidity imposed by the new interfaces."

Apple has always been a very conservative company (Objective-C continues to operate and compile quite well) in relation to its development environments and, in general, with respect to its entire ecosystem. The introduction of Swift, 5 years ago, with its new paradigms and its burst of modernity had already been a big sign of change by Cupertino. But it was clear that it was not enough. So, surprisingly for everyone, here comes Apple's response to the other giants of the web: SwiftUI.

SwiftUI is a declarative component-oriented framework. Let's forget, therefore, the MVC pattern where the controllers mediated between views and models. All we have in SwiftUI is a state and a view derived from the state. As soon as the status changes, SwiftUI reconstructs the interface taking these changes into account.

Those that follow are our personal travel notes, during the study of this new and, to some extent, mysterious framework. We thought it useful to share this information with all of you in the hope that it will be a starting point for learning something truly exciting.

--Have a good trip!

TextField and UIViewRepresentable

2019-06-28T00:00:00Z

At a glance, when I first tried SwiftUI after the WWDC19 introduction, one of the biggest concern was certainly related to the TextField object: there was no way to dispose the keyboard, nor a way to move the focus from one TextField to another.

probably, some details were not yet ready during the initial presentation.

iOS13 beta2, along with many other improvements, seems to solve at least in part the problems related to the TextField: when the enter key is pressed, the keyboard is now dismissed correctly. There are no clues, however, about a mechanism to change the focus between multiple TextField(s) within the same View container. Unfortunately, we must also report an important bug in beta2 that affects the call mechanism for the onCommitHandler closure when the keyboard is dismissed: the latter is never called at all.

In this article we will try to work around all these problems by creating a custom TextField taking all the good that is currently in SwiftUI and UIKit. The smartest readers, probably, will already figured out where I want to go:

We will build a custom component in UIKit that uses the old fashioned and perfectly functioning UITextField and we will expose it in SwiftUI through the UIViewRepresentable protocol.

UITextField and delegates

UIKit provides an object called UITextField which take advantage of the delegate technique in order to offer a fluid and effective keyboard experience.

What we will do is creating a class that inherits from UITextField and, simultaneously, adopts the UITextFieldDelegate protocol. This way we will have a single object to expose for integration with SwiftUI.

The first thing to do is to declare our class, which we will call WrappableTextField:

Swift

class WrappableTextField: UITextField, UITextFieldDelegate {
    var textFieldChangedHandler: ((String)->Void)?
    var onCommitHandler: (()->Void)?
    
    func textFieldShouldReturn(_ textField: UITextField) -> Bool {
	...
    }
    
    func textField(_ textField: UITextField, shouldChangeCharactersIn range: NSRange, replacementString string: String) -> Bool {
	...
    }
    
    func textFieldDidEndEditing(_ textField: UITextField) {
	...
    }
}

The code above shows the skeleton of delegate methods we will implement to complete the Wrapper class.

As anticipated, our class extends UITextField, adopting the delegated protocol UITextFieldDelegate. We also added two local variables that contain two custom optional closures. Respectively:

The closure textFieldChangedHandler, will be invoked whenever there is a change of the UITextField.
The closure onCommitHandler, will be invoked at the end of editing by pressing the Enter key.

Let’s see now, step by step the individual method implementations that will be added to our class.

textField:shouldChangeCharactersInRange:replacementString:

The delegate method shouldChangeCharactersInRange:replacementString: is automatically invoked by the system whenever we type something on the keyboard. It allows us to perform checks on the content, returning a boolean value depending on whether the content entered is allowed or not by our validation policies.

Swift

func textField(_ textField: UITextField, shouldChangeCharactersIn range: NSRange, replacementString string: String) -> Bool {
    if let currentValue = textField.text as NSString? {
        let proposedValue = currentValue.replacingCharacters(in: range, with: string)
        textFieldChangedHandler?(proposedValue as String)
    }
    return true
}

In our case, it will be suffice to compose the new string resulting from the insertion of the user input and the one currently present on the UITextField. For simplicity, we convert the String type into a foundation NSString, which provides all the tools to communicate directly with the NSRange object supplied as an input parameter by the method.

Once the string has been converted, we apply on it the transformation proposed through the method:

replacingCharacters(in: range, with: string)

Passing the two values supplied as input by the method as parameters. Respectively, range and the string entered by the user. The result will be the composition between the input provided by the user and the current content of the UITextField.

This value will be the one we will provide in input to the closure defined previously:

textFieldChangedHandler?(proposedValue as String)

textFieldDidEndEditing:

The implementation of this method, triggered by the system to complete the editing phase, is very simple: it will only have to invoke our custom closure defined previously. This way we will be able to execute an arbitrary chunk of code every time the editing is completed.

Swift

func textFieldDidEndEditing(_ textField: UITextField) {
    onCommitHandler?()
}

textFieldShouldReturn:

The last method we have to implement is textFieldShouldReturn. Its implementation will allow us to build a very simple mechanism to move focus from our TextField into other similar classes contained within the same container view. Let’s see how it works.

The first thing we do is to ask the current textField element a reference to its own superview?.superview? following a pattern similar to the one depicted in the following schema:

If a valid object is returned, we will invoke its viewWithTag method, passing the current tag incremented by one. This way we have managed to create a very elementary scaffolding workflow, that allows us to go back up to the container and ask it for other views with a specific tag.

Swift

func textFieldShouldReturn(_ textField: UITextField) -> Bool {
    if let nextField = textField.superview?.superview?.viewWithTag(textField.tag + 1) as? UITextField {
        nextField.becomeFirstResponder()
    } else {
        textField.resignFirstResponder()
    }
    return false
}

If the returned value exists and is of type UITextField, then we have found another UITextField and we can pass the control to it. Otherwise, we will simply dismiss the keyboard.

Our Wrappable class is ready. Now, we just have to plug it into SwiftUI.

UIViewControllerRepresentable

SwiftUI provides a very useful protocol called UIViewControllerRepresentable allowing us to expose all those UIKit objects that, to date, have not been natively integrated into SwiftUI.

By adopting this protocol it is possible to construct an object that exposes the content of an UIView natively to SwiftUI. It require to implement just two methods:

Swift

struct SATextField: UIViewRepresentable {

    func makeUIView(context: UIViewRepresentableContext<SATextField>) -> WrappableTextField {
	...
    }
    
    func updateUIView(_ uiView: WrappableTextField, context: UIViewRepresentableContext<SATextField>) {
	...
    }
}

The first method is responsible for the creation of our UIView as well as providing it to SwiftUI in a compatible some View format allowed by the SwiftUI protocol as we saw in the previous tutorials.

The second method will be invoked whenever our UIView needs to be updated to reflect a change in the user interface (a bit like the body property we saw in SwiftUI native objects).

Finally, let’s add some local variables to our object that we will use to drive the behavior of the WrappableTextField class previously declared:

Swift

struct SATextField: UIViewRepresentable {
    private let tmpView = WrappableTextField()
    var tag:Int = 0
    var placeholder:String?
    var changeHandler:((String)->Void)?
    var onCommitHandler:(()->Void)?

    ...
}

These variables will be the required parameters to create the SwiftUI object. They will be passed to the previously instantiated Wrapper class and express respectively: the value of the tag to be associated to the TextField, the closures necessary to manage the user input changes, the end editing and the value to associate to the placeholder of our UITextField.

The content of the makeUIView method, just associates the parameters entered by the user during the SwiftUI object creation with the corresponding parameters exposed by the WrappableTextField class.

Swift

func makeUIView(context: UIViewRepresentableContext<SATextField>) -> WrappableTextField {
    tmpView.tag = tag
    tmpView.delegate = tmpView
    tmpView.placeholder = placeholder
    tmpView.onCommitHandler = onCommitHandler
    tmpView.textFieldChangedHandler = changeHandler
    return tmpView
}

The updateUIView method will set the hugging priority of our UITextField to adapt to all available space within the Container View, consistently with all the other objects:

Swift

func updateUIView(_ uiView: WrappableTextField, context: UIViewRepresentableContext<SATextField>) {
    uiView.setContentHuggingPriority(.defaultHigh, for: .vertical)
    uiView.setContentHuggingPriority(.defaultLow, for: .horizontal)
}

Wrap it up: a real world example

Let’s try using our brand new SATextField in a practical example:

Swift

struct ContentView : View {
    @State var username:String = ""
    @State var email:String = ""
    
    var body: some View {
        VStack {
            HStack {
                Text(username)
                Spacer()
                Text(email)
            }
            SATextField(tag: 0, placeholder: "@username", changeHandler: { (newString) in
                self.username = newString
            }, onCommitHandler: {
                print("commitHandler")
            }).padding(EdgeInsets(top: 8, leading: 8, bottom: 8, trailing: 8))
            SATextField(tag: 1, placeholder: "@email", changeHandler: { (newString) in
                self.email = newString
            }, onCommitHandler: {
                print("commitHandler")
            }).padding(EdgeInsets(top: 8, leading: 8, bottom: 8, trailing: 8))
        }
    }
}

All done folks! In a few lines of code we have created a TextField object responsive to the focus changes and the end editing completion, waiting for the next beta of iOS13 to solve the current problems of the native TextField object.

A TicTacToe game in SwiftUI

2019-06-18T00:00:00Z

Today we will try to build a TicTacToe game in less than 160 lines with SwiftU Apple’s new declarative framework that promises to supplant its brother UIKit in the near future. Let’s open Xcode.

In these hours the beta2 came out together with macOS catalina beta2. I strongly advise you to install both of them, since we have noticed an overall remarkable improvement in performance as well as an improved Xcode responsiveness in all respects.

Once opened Xcode, we will create a new project, let’s name it TicTacToe and make sure that the tick in SwiftUI is enabled. Press next and choose a folder to store your new project.

Once the initialization phase is complete, Xcode shows the skeleton for the pre-generated project. Move to ContentView.swift and let’s start immediately shaping the logic of our game.

In the TicTacToe game, the two opponents challenge each other, each taking an X or O mark, in a 3x3 board. The winner is the one who is the first to line up three identical signs horizontally, vertically or diagonally.

The first thing to do, therefore, will be to create a model that reflects what has just been said.

Let’s write an enum that reflects the status of a box. This may be empty, occupied by us or by the computer.

Swift

enum SquareStatus {
    case empty
    case visitor
    case home
}

To play we will need a 3x3 chessboard. So, try to define the model for a single square in the board:

Swift

class Square: BindableObject {
    let didChange = PassthroughSubject<Void, Never>()
    
    var status: SquareStatus {
        didSet {
            didChange.send(())
        }
    }
    
    init(status: SquareStatus) {
        self.status = status
    }
}

The Square class adopts the BindableObject protocol. Objects that adopt this protocol are objects that notify subscribers in the SwiftUI framework when one or more properties in it change.

To do this it is necessary to adopt the protocol correctly, adding an instance that publishes an event when an object changes. This instance is called didChange:

Swift

let didChange = PassthroughSubject <Void, Never> ()

PassthroughtSubject is a class made available by the Combine framework, which allows us to publish a notification to all applicants. The notification has two parameters, the output and a possible error.

For now, all that we want is to notify all applicants that something has changed into the Square object. So, since we are not interested in any of the two parameters, we will pass Void for the first parameter and Never for the second. The first indicates that we do not pass any output. The second indicates that there is no possibility of error.

Next, we define the property status of our box and, inside it, we’ll add a mechanism that sends a notification when we change its value:

Swift

var status: SquareStatus {
    didSet {
        didChange.send(())
    }
}

We can move, next, on to the actual Model that define the game and the chessboard. We will call it ModelBoard:

Swift

class ModelBoard {
    var squares = [Square]()

    init() {
        for _ in 0...8 {
            squares.append(Square(status: .empty))
        }
    }

We start with the declaration of the array variable that will host the individual pieces of the board. In the init function we are going to add 9 elements of type Square all with status .empty

At the end of the game we will need a method to bring the game back to its initial state:

Swift

func resetGame() {
    for i in 0...8 {
        squares[i].status = .empty
    }
}

Now we need to have a way to check if the game is over.

A game ends if there are no more boxes available or if one of the two players align three symbols before the other.

Swift

var gameOver: (SquareStatus, Bool) {
    get {
        if thereIsAWinner != .empty {
            return (thereIsAWinner, true)
        } else {
            for i in 0...8 {
                if squares[i].status == .empty {
                    return (.empty, false)
                }
            }
            return (.empty, true)
        }
    }
}

The getter variable thereIsAWinner will simply check all winning occurrences:

Swift

private var thereIsAWinner:SquareStatus {
    get {
        if let check = self.checkIndexes([0, 1, 2]) {
            return check
        } else  if let check = self.checkIndexes([3, 4, 5]) {
            return check
        }  else  if let check = self.checkIndexes([6, 7, 8]) {
            return check
        }  else  if let check = self.checkIndexes([0, 3, 6]) {
            return check
        }  else  if let check = self.checkIndexes([1, 4, 7]) {
            return check
        }  else  if let check = self.checkIndexes([2, 5, 8]) {
            return check
        }  else  if let check = self.checkIndexes([0, 4, 8]) {
            return check
        }  else  if let check = self.checkIndexes([2, 4, 6]) {
            return check
        }
        return .empty
    }
}

The checkIndex function takes an array of integers (indexes) as input and returns an optional SquareStatus: .home or .visitor if there’s a winner; nil otherwise:

Swift

private func checkIndexes(_ indexes: [Int]) -> SquareStatus? {
    var homeCounter:Int = 0
    var visitorCounter:Int = 0
    for anIndex in indexes {
        let aSquare = squares[anIndex]
        if aSquare.status == .home {
            homeCounter = homeCounter + 1
        } else if aSquare.status == .visitor {
            visitorCounter = visitorCounter + 1
        }
    }
    if homeCounter == 3 {
        return .home
    } else if visitorCounter == 3 {
        return .visitor
    }
    return nil
}

We need a way to make a move. For our human player we will check if the selected square is empty. If yes, then we will change its status to .home

Since, we’re only implementing a Human vs Machine game, we also need to trigger the computer move at the end.

Swift

func makeMove(index: Int, player:SquareStatus) -> Bool {
    if squares[index].status == .empty {
        squares[index].status = player
        if player == .home { aiMove() }
        return true
    }
    return false
}

The move of artificial intelligence is really simple: we only collect a random index, check if it is empty and if this’s the case we will fill it with the .visitor flag.

Swift

private func aiMove() {
    var anIndex = Int.random(in: 0 ... 8)
    while (makeMove(index: anIndex, player: .visitor) == false && gameOver.1 == false) {
        anIndex = Int.random(in: 0 ... 8)
    }
}

Now that the model is ready, we need to interact with SwiftUI in order to build a View that could respect the Square Model. Let’s call it SquareView:

Swift

struct SquareView: View {
    @ObjectBinding var dataSource:Square
    var action: () -> Void
    var body: some View {
        Button(action: {
            self.action()
        }) {
            Text((dataSource.status != .empty) ?
                (dataSource.status != .visitor) ? "X" : "0"
                : " ")
                .frame(minWidth: 60, minHeight: 60)
                .background(Color.gray)
                .padding(EdgeInsets(top: 4, leading: 4, bottom: 4, trailing: 4))
        }
    }
}

First of all, we add an @ObjectBinding property wrapper in front of the Square datasource.

This way we’re telling to SwiftUI that the SquareView is interested in changing notifications from the model. When a change will come, SwiftUI will automatically trigger a new body for the SquareView.

Inside the body we’re conditionally check if there’s a status other than .empty. If so, we write X or O accordingly.

.frame, .background and .padding are all cosmetic adjustments related to the Square.

Finally, we need to modify our ContentView in order to house the chessBoard by creating a private var for that purpouse, naming it checker:

Swift

struct ContentView : View {
    private var checker = ModelBoard()
    @State private var isGameOver = false

We also define a @State property for checking if the game is finished; we need to define it as a @State property, since we would like to refresh the ContentView body once the game is completed.

Since every SquareView is the same and it’s behaviour change only based on index, we define also a buttonAction method:

Swift

func buttonAction(_ index: Int) {
    _ = self.checker.makeMove(index: index, player: .home)
    self.isGameOver = self.checker.gameOver.1
}

This way, every SquareView will invoke the method with its specific index and the relevant code is executed with respect to the specified position.

Finally, we can build the whole body, reflecting the 9x9 SquareView(s):

Swift

var body: some View {
    VStack {
        HStack {
            SquareView(dataSource: checker.squares[0]) { self.buttonAction(0) }
            SquareView(dataSource: checker.squares[1]) { self.buttonAction(1) }
            SquareView(dataSource: checker.squares[2]) { self.buttonAction(2) }
        }
        HStack {
            SquareView(dataSource: checker.squares[3]) { self.buttonAction(3) }
            SquareView(dataSource: checker.squares[4]) { self.buttonAction(4) }
            SquareView(dataSource: checker.squares[5]) { self.buttonAction(5) }
        }
        HStack {
            SquareView(dataSource: checker.squares[6]) { self.buttonAction(6) }
            SquareView(dataSource: checker.squares[7]) { self.buttonAction(7) }
            SquareView(dataSource: checker.squares[8]) { self.buttonAction(8) }
        }
    }

One last thing, is regarding a feedback for the user: we want to notify the user with a popup when either the game is end or someone will win.

To make this, we could use the .presentation View modifier. In it’s simple form it takes:

A conditional boolean to discern if it should appear or not
A message parameter with a Text for the body of the alert
A dismissButton: with an Alert.Button

Swift

.presentation($isGameOver) { () -> Alert in
    Alert(title: Text("Game Over"),
          message: Text(self.checker.gameOver.0 != .empty ?
            (self.checker.gameOver.0 == .home) ? "You Win!" : "iPhone Wins!"
            : "Parity"), dismissButton: Alert.Button.destructive(Text("Ok"), onTrigger: {
                self.checker.resetGame()
            }) )
}

That’s all folks! As promised, in less than 160 lines of code we have a fully working TicTacToe game. If we Build and Run our code our application will looks like the following:

iPadOS, Catalyst and Sidecar

2019-06-17T00:00:00Z

I had decided not to comment on the new iPad Pro from the day it first came out. After all, I thought it was just one more commercial move by an Apple led by Tim Cook, a skilled businessman and only remotely a visionary, aiming at profit and sales in a market segment that is by now saturated. No, talking about it would only have fed the buzz of blogs and fanatics, one way or another.

I was wrong. This product deserves all our attention, for a number of reasons I will try to explain.

Let's take it in order. The tablet market is saturated and in steep decline. KGI claims that, together with iPhone, it will contribute to an unprecedented drop in iOS device sales over the 2016/2020 period. That may well be true, but it does not mean there is no room to innovate.

The average user will probably notice these innovations late, or maybe not at all, but that does not mean Cupertino is not trying to innovate. What we expect from a tablet, as Phil Schiller theatrically explained during the presentation of 21 March 2016, is the ability to replace our old personal computers in all our daily activities. Since the first iPad Pro, Apple has claimed that the new iPad is the ideal replacement for the “boring” PC of the 1980s. Better still, it is the modern interpretation of how we express ourselves, create, study and have fun. Is that true?

Taking advantage of the news presented at WWDC 2019, I decided to run an in-depth test with an iPad Pro to understand the state of the art and how close the claim above is to reality. I did not use the keyboard sold as an accessory, for a simple reason: it can only be used in a forced position (so no extreme typing on the couch or in bed) and it costs a fortune. For this week of testing I chose a far more capable and comfortable Apple Bluetooth keyboard, so I can move and sit however and wherever I want. Besides, when I am on the move I really do not see what I would do with a physical keyboard at all.

Apple Pencil, on the other hand, is spectacular. Using a pencil is so deeply rooted in our modern culture that using one with an iPad feels almost more natural than using our fingers (for some activities fingers are still better, in terms of effectiveness and feedback).

The new revision of the pen has also come a long way since the first version, which had a cap hiding the charging connector (practically lost before you even opened the box), no place to store the pen safely on the iPad and, a detail I would gladly skip, a truly controversial charging mechanism.

We are certainly at a turning point, but saying that the new iPad replaces the personal computer is at the very least a stretch. My job is writing applications as well as coordinating a team of developers. I call all of these operations “complex”, not because of their content but because of the way they are carried out. Picture a typical day with a hundred emails to answer, twenty phone calls to take notes on, two or three Xcode projects open for code review and an endless number of documents to consult, annotate and write. I am absolutely convinced this job is bad for one's mental and physical health, but it is too late to change course now and, deep down, I like it a lot.

Clearly, with these premises, the iPad Pro cannot possibly replace my MacBook Pro: too many things are more cumbersome and less precise. At the same time, some things are extremely simple, fast and effective. Taking notes, answering email, writing this article and communicating are disarmingly easy.

Don't get me wrong, this is not about power: the new iPad has plenty of it, and a quick search turns up hundreds of power comparisons between iPad and MacBook. In terms of technology we are looking at a gem that has nothing to envy a high end laptop.

Fortunately for us, the problem lies elsewhere. It is clear that iOS as we know it shows its limits. Anyone who used and worked with the first version of iOS cannot help noticing the incredible changes and effort of the past years. iOS 7 changed the way we think about interfaces; iOS 8 showed us that it is not a matter of how many apps you can keep open at the same time but of how you make them talk to each other; iOS 9 consolidated communication between devices, making it a pleasure for the mind to move from one device to another. iOS 10, 11 and 12 were a continuous refinement of details of stability, style, usability and experience, which few others in the software world have had the courage to pursue over such a long period: it takes courage not to flood every new release of the operating system with half-tested, hard to use and poorly thought out features.

Something was still missing to close the circle. Microsoft tried, in its own way, to represent that missing piece with Windows 10 and Microsoft Surface. Google has been trying for years with the idea of a converging web (and browser) where you can do everything, while waiting for Fuchsia.

Apple, instead, with a surprise move, showed its vision of the long awaited convergence between devices. I am talking about iPadOS and Catalyst.

Being a big company is not easy. It confines you to a difficult position where everyone always expects “something more”. Apple therefore had to express this concept in a different way: Think different, as someone would say.

No Apple user would have been satisfied with having the desktop and the Finder bar on their iDevice. After all, Apple users are known to be a bit more demanding and creative.

And so here comes iPadOS. It is not a new operating system but simply an extension of the iOS we have grown used to and love. Extensions that enable new, never seen features: Multitasking, Desktop and interconnection features we had all only dreamed of. Taking a close look at the APIs available with iOS 13, you can see an endless supply of new resources for building drivers and USB communication and interface mechanisms. Fantastic.

I do not think we will get a flat, obvious convergence like the one Microsoft showed and talked about. I do not think my MacBook's screen will ever become touch. At the same time, though, I see that bringing a native iPad application to macOS is child's play and that my iPad's screen can become the long desired tactile surface for talking to my computer through Sidecar.

Apple will try to show that style and an overall vision, above all, can be the start of a subtle and elegant change, no less effective for that, in the way we talk to machines.

In my personal view, this June WWDC presented a lot of great news, among them the introduction of iPadOS, Continuity and Catalyst.

It will probably be an event that goes down in history and marks an epochal passage for everyone who still needs the old desktop and the Finder bar to work. If you do not believe me, try connecting a keyboard to the new iPad Pro and press ⌘+Tab.

SwiftUI programming

2019-06-13T00:00:00Z

SwiftUI certainly marks the beginning of a new era in Apple’s programming history. In the last years we have witnessed the proliferation of frameworks based on the concept of declarative interfaces and reactive programming; the web is a prime example of this phenomenon, but there are other notable examples in the field of mobile development. We are constantly amused with marketing messages that state how:

maintaining a single codebase for all platforms is the best way to increase business productivity and provide effective solutions to our customers.

React Native (Facebook) and Flutter (Google) are an excellent example of this proposition. It is not the purpose of this article to make a comparative analysis of these technologies; the point for which these two examples have been cited is to show how the software trend of recent years is moving in different directions from those we have been used to, up to now.

The discrete nature of imperative languages is in great difficulty, compared to the sense of continuity and fluidity imposed from new interface paradigms.

Apple has always been a very conservative company (Objective-C continues to operate and compile quite well) in relation to its development environments and, in general, with respect to its entire ecosystem.

The introduction of Swift, 5 years ago, with its new paradigms and its burst of modernity had already been a big sign of change by Cupertino. But it was clear that it was not enough. So, surprisingly for everyone, here comes Apple’s response to the other giants of the web: SwiftUI.

SwiftUI is a declarative component-oriented framework. Let’s forget, therefore, the MVC pattern where the controllers mediated between views and models. All we have in SwiftUI is a state and a view derived from the state. As soon as the status changes, SwiftUI reconstructs the interface taking these changes into account.

In a series of post, I’ll try to share my thoughts and personal travel notes, during the study of this new and, to some extent, mysterious framework.

I thought it could be useful, in the hope that it could be a starting point for learning something new and truly exciting.

-Happy Coding!

WWDC18: ARKit2 a 2D tracking performances comparison

2018-06-18T00:00:00Z

One of the most interesting tech trend of the last year was for sure Augmented Reality. All the big have done something related to it, including Apple. They spent a lot of resources and time dealing with this topic and as Tim Cook said:

…Augmented reality could be the next big thing…

If 2017 was the milestone year for the introduction of a complete framework that deals with AR, the 2018 is for sure the maturity year for this technology following the introduction of ARKit2.

A lot of things have changed in favour of usability, maintanability and simplicity: all things that could help a lot spreading a technology to the mass. The rest of the article is about my personal experience with the new ARKit framework underlining the improvements and differences between iOS11 and iOS12. As any good dev article, we need a case study to deal with in order to better explain the topic. So, here it is.

We will create a simple Application that uses Augmented Reality to show you special offers and additional information when pointing out business cards.

Optionally, the application will load the required information from a remte JSON and then will show to the user the corresponding visual enhancements when needed.

The first thing is opening Xcode and create a new AR project filling all the relevant stuff:

By default, Xcode creates for use a starting scene that is completely useless for the such of this article. Remove it and open the ViewController.swift file automatically created for us.

Since we don’t care anymore about the automatically generated scene, we will modify the viewDidLoad method to reflect this behavior. All that we need is to instruct the sceneView outlet with the right delegate instance as well as some funcy stuff for debugging purpouses.

Swift

override func viewDidLoad() {
 super.viewDidLoad()
 
 sceneView.delegate = self
 
 sceneView.showsStatistics = true
 sceneView.autoenablesDefaultLighting = true
 sceneView.automaticallyUpdatesLighting = true
}

ARSCNView class is the entry point for any AR app. It mixes virtual contents with the real word seen throught the camera device. It is also responsible for many other really interesting stuff like mapping touches to real world coordinates. ARSCNView relies on a delegate approach. By implementing its ARSCNViewDelegate, we can add virtual contents to any real object that is automagically detected by ARKit.

As you may guess ARKit is the framework responsible for Augmented Reality. In order to work, it should be correctly initialized first. Let’s add a method to do it:

Swift

func resetTrackingConfiguration() {
    guard let referenceImages = ARReferenceImage.referenceImages(inGroupNamed: "Photos", bundle: nil) else { return }
    
  var configuration:ARConfiguration!
    if #available(iOS 12.0, *) {
        configuration = ARImageTrackingConfiguration()
        (configuration as! ARImageTrackingConfiguration).trackingImages = referenceImages
        (configuration as! ARImageTrackingConfiguration).maximumNumberOfTrackedImages = referenceImages.count
    } else {
        configuration = ARWorldTrackingConfiguration()
        (configuration as! ARWorldTrackingConfiguration).detectionImages = referenceImages
    }
    
    let options: ARSession.RunOptions = [.resetTracking, .removeExistingAnchors]
    sceneView.session.run(configuration, options: options)
}

The resetTrackingConfiguration method is responsible to create and return a correctly working ARSession instructed by an ARConfiguration.

ARSession is a singleton shared object that manages the device camera as long as the device motion sensors to give us a full augmented experience of real life. Camera movements are melted down with camera tilt and shift sensors as well as other sensors, in order to give a quick and consistent orientation of the artificial world into the application. ARSCNView instance created for us by storyboard contains already a reference to the default shared ARSession, so we don’t care about initializing it. Instead, we need only to create a valid ARConfiguration.

ARConfiguration is an abstract class and we don’t deal directly with it. Instead, we will use istances of ARWorldTrackingConfiguration and ARImageTrackingConfiguration that are implementation of the former one. There are other implementations that deals with tracking the device orientation only (AROrientationTrackingConfiguration) and faces and facial expressions (ARFaceTrackingConfiguration) but they are not relevant for this discussion.

ARWorldTrackingConfiguration is the main class available for World-tracking session. Firstly introduced with iOS11, it can detect and track a lot of interesting elements in our real world, including 3d objects, infinite planes and 2d images. The former one is interesting for our topic; however, iOS12 introduce a brand new specialization for the ARConfiguration abstract class named ARImageTrackingConfiguration.

As its predecessor it is able to track 2d images but with a lot improvements such as real time tracking and automatic handling when the image disappears from view. We will come back to this topic in a few moments.

Since we would like to support both iOS11 and iOS12 for a comparative performance, we need to go in deep with custom configurations for both ios versions. If is available iOS12 we will use the new ARConfiguration implementation:

Swift

if #available(iOS 12.0, *) {
 configuration = ARImageTrackingConfiguration()
 (configuration as! ARImageTrackingConfiguration).trackingImages = referenceImages
 (configuration as! ARImageTrackingConfiguration).maximumNumberOfTrackedImages = referenceImages.count
}

otherwise we will use the standard one:

Swift

else {
 configuration = ARWorldTrackingConfiguration()
 (configuration as! ARWorldTrackingConfiguration).detectionImages = referenceImages
}

in both cases we will instruct the shared session to use the crafted configuration for the rest of the discussion:

Swift

let options: ARSession.RunOptions = [.resetTracking, .removeExistingAnchors]
sceneView.session.run(configuration, options: options)

Now that we have correctly configured the ARSession, we need some images to use against the ARCamera tracking engine. Select the Assets onto your project:

and right click on the left side, creating a new AR Resource Group:

Name it Photos and add some cards to it. Here the most important thing is to add the relative estimated dimensions for each card. It is important since the 3d engine need this information to estimate correctly the object in the 3d world.

As you may notice one of the card has a warning signal. Let click on it:

Xcode is warning us that the histogram and constrasts on the card is not optimal for image recognition. Lets ignore it for the moment.

Our toy app should be able to track 2D images and map them to real world objects by using anchors. An ARAnchor is the class responsible for real-world position and orientation, mapping the detected object in an AR scene. Along with other interesting properties it contains a matrix_float4x4 used for defining the anchor’s rotation, translation and scale in world coordinates.

Swift

open var transform: matrix_float4x4 { get }

When used along side with ARWorldTrackingConfiguration or ARImageTrackingConfiguration, ARKit creates automatically for us the relative anchors as long as a match with our reference images is found in the scene. All we have to do is implemeting the relative delegate, in order to add the corresponding object in the form of SCNNode to the new anchor.

Swift

func renderer(_ renderer: SCNSceneRenderer, nodeFor anchor: ARAnchor) -> SCNNode? {
    if let imageAnchor = anchor as? ARImageAnchor {
        let node = SCNNode()
        node.name = anchor.identifier.description
        var labelNode:SCNNode?
        
        switch imageAnchor.referenceImage.name {
        case "card1":
            labelNode = self.addLabel(text: "Hi, Costantino!\nYour loyalties points are 2032.", anchor: imageAnchor)
        case "card2":
            labelNode = self.addLabel(text: "Last tweet from Costantino:\n#WWDC18 #ARKit2 rocks!", anchor: imageAnchor)
        default:
            break
        }
        
        if let labelNode = labelNode {
            node.addChildNode(labelNode)
            
            node.opacity = 0.0
            
            DispatchQueue.main.async {
                node.runAction(SCNAction.fadeIn(duration: 3.0))
            }
            
            return node
        }
    }
    return nil
}

SCNNode is the basic lego brick for all AR based apps. It wraps together 3d coords with scene objects such as lights, camera and other displayable contents. As for UIViews, SCNNodes follows a tree hierarchy that allow us to nest them in a fancy way by using simple primitives such as

Swift

open func addChildNode(_ child: SCNNode)
open func removeFromParentNode()

renderer:nodeFor: method is called in response to a new detected correspondance between our images dataset and the real world. Since this method is also called in response to any new ARAnchor added to the scene (detected planes, 3d objects and so on) we should test against ARImageAnchor in order to be sure that all things are working right:

Swift

if let imageAnchor = anchor as? ARImageAnchor {
   …
}

next, we create a new SCNNode that will contain all the relevant stuff and we switch against the detected image name; this is the main business logic in order to distinguish between images from our dataset.

Swift

switch imageAnchor.referenceImage.name {
    case “card1”:
    …
    case “card2”:
    …
    default:
    …
 }

then, if we successfully create a valid node, we add it to the hyerarchy and return the main node:

Swift

if let labelNode = labelNode {
 node.addChildNode(labelNode)
 
 …
 return node
}

to give a professional touch, we would like to add some fadein/fadeout animations to the entire workflow. Since the rederer:nodeFor: is called on the main thread we should async the runAction, in order to be sure that no crappy animations will occur.

Swift

DispatchQueue.main.async {
    node.runAction(SCNAction.fadeIn(duration: 3.0))
}

For the more curious

addLabel is a support method used to generate a valid 2D spritekit object. Since we are dealing with 2D tracked images, we would like to add 2d virtual contents on the scene to give the user the feel that additional informations are added just above the real object.

Swift

func addLabel(text: String, anchor: ARImageAnchor) -> SCNNode {
    let plane = SCNPlane(width: anchor.referenceImage.physicalSize.width,
                         height: anchor.referenceImage.physicalSize.height)
    
    let planeNode = SCNNode(geometry: plane)
    planeNode.eulerAngles.x = -.pi / 2
        
    let skScene = SKScene(size: sceneSize)
    
    skScene.backgroundColor = UIColor(white: 0.0, alpha: 0.0)
    
    let substrings: [String] = text.components(separatedBy: "\n")
    for aSubstring in substrings {
        let lbl = SKLabelNode(text: aSubstring)
        lbl.fontSize = 20
        lbl.numberOfLines = 1
        lbl.fontColor = UIColor.white.withAlphaComponent(0.85)
        lbl.fontName = "Helvetica-Bold"
        let y = CGFloat(substrings.index(of: aSubstring)! + 1) * lbl.fontSize
        lbl.position = CGPoint(x: 20, y: y)
        lbl.horizontalAlignmentMode = .left
        lbl.yScale *= -1
        skScene.addChild(lbl)
    }
    
    let material = SCNMaterial()
    material.isDoubleSided = false
    material.diffuse.contents = skScene
    plane.materials = [material]
    
    return planeNode
}

We firstly create a SCNPlane with the physycal size of the detected image. SCNPlane is a rectangular 2d plane geometry object responsible to hold our bidimensional text. However, since we are in a 3D world we need to wrap it against an SCNNode.

Swift

let planeNode = SCNNode(geometry: plane)
planeNode.eulerAngles.x = -.pi / 2

We should also rotate the resulting planeNode since, by default, they are generated perpendicular to the root. At this point no 2d objects nor text are still created. To accomplish this we need to create a SprikeKit Scene.

SKScene is the counterpart of SCNScene on the 2d world handled by SpriteKit. It represents a 2d scene content and it has nothing to display since, as its 3d paritetic, is merely a wrapper. To generate the 2d text we will use the SKLabelNode. It works quite similar to the UILabel UIKit counterpart: we configure text, font and other parameters in a very straightforward way.

Swift

 let lbl = SKLabelNode(text: aSubstring)
 lbl.fontSize = 20
 lbl.numberOfLines = 1
 lbl.fontColor = UIColor.white.withAlphaComponent(0.85)
 lbl.fontName = “Helvetica-Bold”

Sadly, there is no native support for multilines wrapping by using the carriage return (\n) so we need to recreate it by our own. To accomplish this we use a simple string tokenization with the original string as parameter.

Swift

let substrings: [String] = text.components(separatedBy: “\n”)

for aSubstring in substrings {
    …
}

The most interesting part here, is how we map the 2d spritekit in the 3d world. To achive this we use the SCNMaterial. SCNMaterial is a class responsible to define the appearance of a 2d geometry when rendered in a 3d world. As of any 3d engine, our SCNScene has lights and materials that respond to it when rendered. We need simply to specify to our SCNMaterial that we would like to use the content of the previously created SKScene as material.

Swift

let material = SCNMaterial()
material.isDoubleSided = false
material.diffuse.contents = skScene

isDoubleSided property is set to false, since we don’t care about the backward side of our text. the diffuse property is a SCNMaterialProperty class. It is simply a container for the texture of our material. Fortunately for us it could contains almost anything including a whole SKScene. At the end we instruct our previously generated plane to use the just crafted custom material as source.

Swift

plane.materials = [material]

If you have followed all we have done right now and run what we have so far on iOS12, all things will work like a charm and you will be delighted by an impressive and accurate 2d tracking. However, if you run the same code on iOS11 you will be disappointed about poor tracking performances.

Moreover, there is a really crappy bug that leave the detected 2d images on the 3d world for ever. If you recall, at the very beginning of this article I said that

one of the most interesting new features of ARImageTrackingConfiguration is related to the new handling capabilities with disappeared objects from the screen.

Since we don’t have such things on iOS11 we need to create a workaround by ourself. We will use a private struct to hold all the required information:

Swift

struct SANodeAnchor {
 var date:Date
 var node:SCNNode
 var anchor:ARAnchor
}

declaring it as a private array on our ViewController. We also need a periodic polling of the scene, in order to purge trashed objects

Swift

private var lastUpdate = [String:SANodeAnchor]()
private var scheduledTimer:Timer?

our viewDidAppear method will be responsible to define the above timer

Swift

override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    
    if #available(iOS 12.0, *) {
        
    }
    else {
        if let scheduledTimer = scheduledTimer {
            scheduledTimer.invalidate()
        }
        scheduledTimer = Timer.scheduledTimer(withTimeInterval: 3.0, repeats: true) { [unowned self] (timer) in
            for (_, nodeStruct) in self.lastUpdate {
                if Date().timeIntervalSinceNow - nodeStruct.date.timeIntervalSinceNow > 3 {
                    nodeStruct.node.removeFromParentNode()
                    self.sceneView.session.remove(anchor: nodeStruct.anchor)
                }
            }
        }
    }
}

We only need to refresh the lastUpdate cache array when new or already detected objects are correctly parsed on the scene. For this task, we will use another delegate method of ARSCNViewDelegate:

Swift

func renderer(_ renderer: SCNSceneRenderer, didUpdate node: SCNNode, for anchor: ARAnchor) {
    if let identifier = node.name {
        let aStruct = SANodeAnchor(date: Date(), node: node, anchor: anchor)
        lastUpdate[identifier] = aStruct
    }
}

This way even on iOS11 we can successfully stop tracking unwanted 2d objects from the screen.

The complete project is available on Github. As I’m writing a bug is afflicting Xcode10 that prevents using dataset images when deploying to iOS11 devices.

as result, on iOS11 the app will not detect any 2d images when deployed from Xcode10. To workaround this, you should run the above project on Xcode9 when you deploy on iOS11 device, commenting the unknown symbols related to ARImageTrackingConfiguration.

Loading remote datasets

A final note about loading dynamic dataset. The above code rely on a static dataset that we have stored into our dataset. However it could be better to dinamically load the dataset from a remote server. I’ve crafted a really simple JSON example for the purpouse.

Code

[
 {
  "imageURL" : "https://www.sofapps.it/card1.jpg",
  "name" : "card1",
  "width" : 0.096
 },
 {
  "imageURL" : "https://www.sofapps.it/card2.jpg",
  "name" : "card2",
  "width" : 0.058
 }
]

Lets fetch this json from our app:

Swift

func loadRemotedataset(fromURL: URL, _ completion: @escaping ([Card]?, Error?)->Void) {
    URLSession.shared.dataTask(with: fromURL) { (data, response, error) in
        if let error = error {
            DispatchQueue.main.async {
                completion(nil, error)
            }
        }
        else if let data = data {
            var retArray = [Card]()
            do {
                if let json = try JSONSerialization.jsonObject(with: data, options: .allowFragments) as? [[String:Any]] {
                    for aRow in json {
                        if let aString = aRow["imageURL"] as? String,
                            let anURL = URL(string: aString),
                            let aName = aRow["name"] as? String,
                            let width = aRow["width"] as? CGFloat
                        {
                            retArray.append(Card(url: anURL, name: aName, width: width))
                        }
                    }
                    DispatchQueue.main.async {
                        completion(retArray, nil)
                    }
                }
                else {
                    throw NSError(domain: "JSON parse error", code: -1, userInfo: nil)
                }
            }
            catch {
                DispatchQueue.main.async {
                    completion(nil, error)
                }
            }
        }
    }.resume()
}

and load the cards dinamically:

Swift

func createDataset(_ completion: @escaping ([ARReferenceImage]?, Error?) -> Void) {
    self.loadRemotedataset(fromURL: URL(string: "https://www.sofapps.it/sampleDataset.json")!) { (response, error) in
        if let error = error {
            print("something happened in the way to heaven...", error)
            completion(nil, error)
        }
        else if let response = response {
            var retArray = [ARReferenceImage]()
            for aCard in response {
                let response = URLSession.shared.synchronousDataTask(with: aCard.url)
                if let error = response.2 {
                    print("something happened in the way to heaven...", error)
                }
                else if let data = response.0, let anImage = UIImage(data: data) {
                    var orientation = CGImagePropertyOrientation.up
                    switch anImage.imageOrientation {
                    case .up:
                        orientation = .up
                    case .down:
                        orientation = .down
                    case .left:
                        orientation = .left
                    case .right:
                        orientation = .right
                    default:
                        orientation = .up
                    }
                    if let cgImage = anImage.cgImage {
                        let aReferenceImage = ARReferenceImage.init(cgImage, orientation: orientation, physicalWidth: aCard.width)
                        aReferenceImage.name = aCard.name
                        retArray.append(aReferenceImage)
                    }
                }
            }
            completion(retArray, nil)
        }
    }
}

our resetTrackingConfiguration method should also be adapted to take into account the loading at runtime:

Swift

func resetTrackingConfiguration() {
    self.createDataset { [weak self] (referenceImages, error) in
        if let error = error {
            print("oops!, something happened on the way to heaven...", error)
        }
        else if let referenceImages = referenceImages {
            var configuration:ARConfiguration!
            
            if #available(iOS 12.0, *) {
                configuration = ARImageTrackingConfiguration()
                (configuration as! ARImageTrackingConfiguration).trackingImages = referenceImages
                (configuration as! ARImageTrackingConfiguration).maximumNumberOfTrackedImages = referenceImages.count
            } else {
                configuration = ARWorldTrackingConfiguration()
                (configuration as! ARWorldTrackingConfiguration).detectionImages = Set(referenceImages.map { $0 })
            }
            
            let options: ARSession.RunOptions = [.resetTracking, .removeExistingAnchors]
            self?.sceneView.session.run(configuration, options: options)
        }
    }
}

At this point the app should work on both iOS11 and iOS12, loading dinamically the dataset content from the server.

-Happy coding!

References

Custom CloudKit sharing workflow

2018-06-02T00:00:00Z

CloudKit has a strong emphasis on users privacy and security. Since one of the main concern for my last work - Lookii - was about users privacy, it was a good chance to investigate in deep about the real potential of the framework.

As of iOS10, CloudKit comes with a built-in feature related to sharing private data among participants on a container, namely CKShare. Unfortunately, there are very few articles about this topic on the internet and Apple documentation does not go in deep with advanced topics. All the relevant articles that I cited in the footnotes cover the basic flow of CloudKit sharing with some interesting variants that, however, didn’t fit exactly my case. I will not cover the basics, for that I will remand to the footnotes. Instead, I will focus on a specific and more advanced workflow that would be useful for someone else.

The use case

Suppose that you have an application that shares users information. Some of those need to be private and shared only among friends, while others should be publicly accessible from every participants in the container.

Let’s suppose that our CKRecord type is MyUser containing the following public information:

Swift

firstName: String
lastName: String
thumbnail: Data
privateShareUrl: String

some others data will not be flagged as public due to privacy concerns. For these we will use another CKRecord that we will call PrivateInfo, containing the following:

Swift

phoneNumber: String
email: String

This time, the record will not be part of public database. Instead, it will be saved on the private one — accessible exclusively from the owner of the record— and marked as part of a RecordZone that will be shared with selected participants.

A general scheme for the described use case could be something as follow:

CloudKit general workflow and limitations

As stated above, one of the main concern in using CloudKit sharing default workflow was related to the very basic UI customization options. Specifically, the basic workflow uses a very rigid schema:

Who share should be in charge of:

Create the CKShare
Pass it to a specific UICloudSharingController
Create a URL to share using third party apps

Users that want to be added need to:

Click on the link for accepting the shared url
Implement some delegates on the UIApplication

Even if its straightforwardness makes it super easy to integrate, this approach lacks some advanced features. For example, I wouldn’t bother users with complicated flows that interrupt the natural experience of the app. Instead, I would like to run the workflow much as in the background, freeing source and destination from useless dialogs and app context switching.

It would be great, if I could select receivers of my private information by simple tapping the users icon in my app.

Implementation

The first thing that we need to do is enabling userDiscoverability among app users, otherwise the rest of the process will not work due to privacy constraints.

Thanks god, Apple designed a very easy approach for this task and it requires only a simple access to user permission that you can manage to add in the early stage of your app:

Swift

//ask for userDiscoverability otherwise you will obtain nil each time you try to search for him
CKContainer.default().requestApplicationPermission(CKApplicationPermissions.userDiscoverability) { (status, error) in
    switch status {
    case .granted:
        print("granted")
    case .denied:
        print("denied")
    case .initialState:
        print("initial state")
    case .couldNotComplete:
        print("an error as occurred: ", error ?? "Unknown error")
    }
}

Once the user granted his permission we are ready to go. Let’s create a very basic user CKRecord (the one that will be public):

Swift

func createPublicRecord() {
    let aRecord = CKRecord(recordType: "MyUser")
    aRecord.setObject("John" as CKRecordValue, forKey: "firstName")
    aRecord.setObject("Appleseed" as CKRecordValue, forKey: "lastName")

    let container = CKContainer.default()
    let publicDatabase = container.publicCloudDatabase
    
    publicDatabase.save(aRecord, completionHandler: { (record, error) -> Void in
        if let error = error {
            print(error)
        }
        else {
            print("record saved successfully")
        }
    })
}

Next, as part of the initial process, we need to create a specific zone that we will use to expose a view of our private records to selected users (our favorite friends):

Swift

func createFavZone(completionHandler:@escaping (CKRecordZone?, Error?)->Void) {
    let container = CKContainer.default()
    let privateDatabase = container.privateCloudDatabase
    let customZone = CKRecordZone(zoneName: "FavZone")
    
    privateDatabase.save(customZone, completionHandler: ({returnRecord, error in
        completionHandler(returnRecord, error)
    }))
}

Finally, we will create a private record containing all our valuable information:

Swift

func createPrivateRecord() {
    let container = CKContainer.default()
    let privateDatabase = container.privateCloudDatabase

    let recordZone: CKRecordZone = CKRecordZone(zoneName: "FavZone")
    let aRecord = CKRecord(recordType: "PrivateInfo", zoneID: recordZone.zoneID)

    aRecord.setObject("+393331112223" as CKRecordValue, forKey: "phoneNumber")
    aRecord.setObject("john@appleseed.com" as CKRecordValue, forKey: "email")

    
    privateDatabase.save(aRecord, completionHandler: { (record, error) -> Void in
        if let error = error {
            print(error)
        }
        else {
            print("record saved successfully")
        }
    })
}

Note that the record is tied to the CKRecordZone created early.

As you could point out, we still haven’t written the privateShareUrl field that is part of the public record; this is the crucial part of the whole approach described in this article. The standard behaviour, in fact, is based on the UICloudSharingController that will prompt the user with a dialog containing what and how to share the information. The result of the dialog is an URL that we need to use with third party apps such as Message, Email or whatever in order to communicate our intention to share something.

To make things even worst, on the other side, the receiver needs to click the link that, in turn, will open our app calling a corresponding UIApplocation delegate method. The latter, at the end, will give us a CKShareMetadata instance that we can use to fetch shared information.

Our approach

Since our application already contains users, I would like to bypass this workflow by using the privateShareUrl field as an entry point for everyone that needs to fetch private information from a specific user.

Apple states that the share url for CKShare is stable and will not change unless you change the root record associated with it.

My plan is to simulate the basic sharing workflow by using the privateShareUrl field that we have on the public database for each user. This field will contain the original CKShare url. This way, every user that would like to fetch private information from a specific participant will access the url and check if he/she have access permission to the private fields exposed.

On the other hand, users that would like to share their private info with friends can simply add them to the share url, without bothering the receivers with third party apps and messages. Sounds great!

The first thing that we have to do is to create a default none access to our private information. This way, in the initial state no one can access our private data. Only when we add someone to the share, he would be able to access data. Apple, states that the default CKShare public permission is already configured for none access.

Swift

func createDefaultShareProfileURL() {
    let container = CKContainer.default()
    let privateDatabase = container.privateCloudDatabase
    
    let query = CKQuery(recordType: "PrivateInfo", predicate: NSPredicate(format: "TRUEPREDICATE", argumentArray: nil))
    let recordZone: CKRecordZone = CKRecordZone(zoneName: "FavZone")
    
    privateDatabase.perform(query, inZoneWith: recordZone.zoneID) { (results, error) -> Void in
        if let error = error {
            print(error)
        }
        else if let results = results, let ourRecord = results.first {
            let share = CKShare(rootRecord: ourRecord)
            
            let modOp: CKModifyRecordsOperation = CKModifyRecordsOperation(recordsToSave: [ourRecord, share], recordIDsToDelete: nil)
            modOp.savePolicy = .ifServerRecordUnchanged
            modOp.modifyRecordsCompletionBlock = { records, recordIDs, error in
                if let error = error  {
                    print("error in modifying the records: ", error)
                }
                else if let anURL = share.url {
                    let container = CKContainer.default()
                    let publicDatabase = container.publicCloudDatabase
                    let query = CKQuery(recordType: "MyUser", predicate: NSPredicate(format: "TRUEPREDICATE", argumentArray: nil))
                    var myPublicProfile:CKRecord?
                    
                    publicDatabase.perform(query, inZoneWith: nil) { (results, error) -> Void in
                        if let error = error {
                            print("error: ", error)
                        }
                        else if let results = results {
                            for aRecord in results {
                                if aRecord.creatorUserRecordID?.recordName == "__defaultOwner__" {
                                    myPublicProfile = aRecord
                                    break
                                }
                            }
                        }
                        if let myPublicProfile = myPublicProfile {
                            myPublicProfile.setObject(anURL.absoluteString as CKRecordValue, forKey: "privateShareUrl")
                            publicDatabase.save(myPublicProfile, completionHandler: { (record, error) -> Void in
                                if let error = error {
                                    print("error: ", error)
                                }
                                else {
                                    print("all done, folks!")
                                }
                            })
                        }
                    }
                }
            }
            privateDatabase.add(modOp)
        }
    }
}

Now, every time an user would like to see private info shared by someone else will check the deisgnated privateShareUrl for the pertinent user:

Swift

func refreshUserInformation(_ userRecordID: CKRecordID) {
    let container = CKContainer.default()
    let publicDatabase = container.publicCloudDatabase
    
    publicDatabase.fetch(withRecordID: userRecordID) { (record, error) in
        if let error = error {
            print(error)
        }
        else if let record = record {
            let firstName = record.object(forKey: "firstName") as? String
            let lastName = record.object(forKey: "lastName") as? String
            
            //do something with firstName and lastName, updating UI
            
            if let shareURL = record.object(forKey: "privateShareUrl") as? String {
                let sharedDatabase = container.sharedCloudDatabase
                let anURL = URL(string: shareURL)!
                
                let op = CKFetchShareMetadataOperation(shareURLs: [anURL])
                op.perShareMetadataBlock = { shareURL, shareMetadata, error in
                    if let error = error {
                        print(error)
                    }
                    else if let shareMetadata = shareMetadata {
                        if shareMetadata.participantStatus == .accepted {
                            let query = CKQuery(recordType: "PrivateInfo", predicate: NSPredicate(format: "TRUEPREDICATE", argumentArray: nil))
                            let zone = CKRecordZoneID(zoneName: "FavZone", ownerName: (shareMetadata.ownerIdentity.userRecordID?.recordName)!)
                            sharedDatabase.perform(query, inZoneWith: zone, completionHandler: { (records, error) in
                                if let error = error {
                                    print(error)
                                }
                                else if let records = records, let firstRecord = records.first {
                                    let phoneNumber = firstRecord.object(forKey: "phoneNumber") as? String
                                    let email = firstRecord.object(forKey: "email") as? String
                                    
                                    //do something with private infos
                                }
                            })
                        }
                        else if shareMetadata.participantStatus == .pending {
                            let acceptOp = CKAcceptSharesOperation(shareMetadatas: [shareMetadata])
                            acceptOp.qualityOfService = .userInteractive
                            acceptOp.perShareCompletionBlock = { meta, share, error in
                                if let error = error {
                                    print(error)
                                }
                                else if let share = share {
                                    let query = CKQuery(recordType: "PrivateInfo", predicate: NSPredicate(format: "TRUEPREDICATE", argumentArray: nil))
                                    let zone = CKRecordZoneID(zoneName: "FavZone", ownerName: (share.owner.userIdentity.userRecordID?.recordName)!)
                                    sharedDatabase.perform(query, inZoneWith: zone, completionHandler: { (records, error) in
                                        if let error = error {
                                            print(error)
                                        }
                                        else if let records = records, let firstRecord = records.first {
                                            let phoneNumber = firstRecord.object(forKey: "phoneNumber") as? String
                                            let email = firstRecord.object(forKey: "email") as? String
                                            
                                            //do something with private infos
                                        }
                                    })
                                }
                            }
                            container.add(acceptOp)
                        }
                    }
                }
                op.fetchShareMetadataCompletionBlock = { error in
                    if let error = error {
                        print(error)
                    }
                }
                container.add(op)
            }
        }
    }
}

Simple and effective. I have assembled a toy application with a complete use-case, available on GitHub.

-Happy Coding! 🖖🏻

Stored properties and extensions: a pure Swift approach

2018-03-28T00:00:00Z

One of the most common question regarding swift extensions is about stored properties. How many times have you wished a stored property within your last-super-cool extension in order to parametizer some behaviours?

As you may know Swift does not allow stored properties into extensions. That’s by design: “Extensions may not contain stored properties.”

The most common error is try to overcome the above by implementing something as follow:

Swift

extension UIViewController {
    var myStoredProperty:Bool {
        get {
            return self.myStoredProperty
        }
        set(newValue) {
            self.myStoredProperty = newValue
        }
    }
}

Even the above code will compile with no errors, you will realize sooner that it is completely wrong; in fact, the cycling reference to the computed property will loop your code until the heap will be saturated by almost identical calls.

The second common approach is googling around. You will stumble across some nifty workarounds in order to add something that resemble the stored properties concept to use inside extensions (see References).

One of the most (ab)used workaround consist of relying into Objective-C runtime, by adopting a solution based on objc_getAssociatedObject and objc_setAssociatedObject functions.

Even if there is nothing wrong in these solutions it would be much more elegant a pure swift approach. That’s the reason about this post: attempting to create a pure swift extension with support for stored properties.

The proposed solution is very simple. It is based on the assumption that extensions don’t accept stored properties but computed ones. By elaborating and digging around the by-value Structs concept, we eventually hack the extensions design adding, in fact, the concept of stored properties. Completely in Swift.

A proof-of-concept is a lot more useful than thousands of words. So here we go:

Swift

import UIKit

extension UIViewController {
    struct Holder {
        static var _myComputedProperty:Bool = false
    }
    var myComputedProperty:Bool {
        get {
            return Holder._myComputedProperty
        }
        set(newValue) {
            Holder._myComputedProperty = newValue
        }
    }
}

The Holder struct will contain the private value that our computed property will expose to the world, giving the illusion of a stored property behaviour instead.

29/03 — Update

As outlined by Paolo, even if the above approach is working, it should be reviewed at least in two parts in order to solve the following:

Private scoping for the Holder struct (actually, everyone can access the service static Structs changing the value without further controls).
Multiple instances of the extended class. The proposed approach suffer of a very nasty problem: if you create multiple instances of the extended class, every instance will share the same static value from the Holder struct. The problem is related to the nature of the static keyword: Every instance of the extended class will share the same static value from the Holder struct. We can use a little bit of imagination in order to be creative and solve the issue.

The following should do the trick:

Swift

extension UIViewController {
    private struct Holder {
        static var _myComputedProperty = [String:Bool]()
    }
    
    var myComputedProperty:Bool {
        get {
            return Holder._myComputedProperty[self.debugDescription] ?? false
        }
        set(newValue) {
            Holder._myComputedProperty[self.debugDescription] = newValue
        }
    }
}

Here, we exploited some sort of hash table in order to hold all the possible different values belonging to different class instances. Please note that self.debugDescription is a really “raw” approach and we should elaborate a more concise and smart way to distinguish between different references of different classes. But, in any case, it seems working as a poc.

30/03 — Update

I couldn’t imagine that there was a so huge interest on this topic! Many thanks to all. There is still a margin of improvement in this approach and after a very kindly discussion with my friend Davide, I decided to give a follow up to the article in order to include some of his suggestions as well as to improve the hash table. Since we use a static var to emulate an hash table, there is no reason to still rely on the Struct approach. Agree. Definitely, this will save a lot of lines of code. Also, I would like to improve the hash table key mechanism by using memory address like pointers. The new version of the approach is as follow:

Swift

extension UIViewController {
    private static var _myComputedProperty = [String:Bool]()
    
    var myComputedProperty:Bool {
        get {
            let tmpAddress = String(format: "%p", unsafeBitCast(self, to: Int.self))
            return UIViewController._myComputedProperty[tmpAddress] ?? false
        }
        set(newValue) {
            let tmpAddress = String(format: "%p", unsafeBitCast(self, to: Int.self))
            UIViewController._myComputedProperty[tmpAddress] = newValue
        }
    }
}

Much, much better! …there is still a minor issue regarding “memory leaking”…but this is another story…

--Happy swifty coding! 🖖🏻

Building a HomeKit accessory

2018-02-01T00:00:00Z

This article is meant as a short introductory guide to building a HomeKit compatible accessory using reused, open source components. If you follow all the steps correctly, by the end you will have a remote control for your automatic home gate that you can operate with Siri / HomeKit. As a bonus, you can add an ambient humidity/temperature sensor.

Ingredients:

1x Raspberry Pi 3
1x Arduino YUN (optional)
1x 433MHz RF remote for an automatic gate
1x NPN transistor
1x 2.2k resistor
1x A few wires
1x DHT22 (optional)
5x Patience

Background

HomeKit is the Apple protocol that developers and companies making home automation hardware must adopt if they want to be compatible with the Siri voice assistant and the Home app installed by default on every new iOS device.

HomeKit is a protocol, that is, a set of rules and specifications that services must follow to be integrated quickly and easily with Apple devices. The protocol (in its non-profit developer version) can be downloaded and studied freely, provided you first accept the attached Apple license. For more information, go here:

developer.apple.comApple Developer documentationUsing the HomeKit Accessory Protocol Specification

Conceptually, to build something that works (and is useful) with HomeKit you need two macro components that talk to each other:

A bridge or gateway that speaks the HomeKit protocol and converts all our analog and digital input / output signals into characteristics exposed to the HAP protocol.
One or more accessories able to talk to the server.

Typically, accessories are very simple, elementary objects (light bulbs, switches, temperature sensors, etc.). For reasons of cost and compactness, it is hard to implement on them the logic needed to talk to the server as well.

The most common solution, adopted by most manufacturers, is to add one more layer of indirection, called a HUB, that "collects" several elementary devices under a single collector, which then has the logic needed to talk to the server; IKEA's and Philips's smart living lines work on this principle. As a result, accessories are lighter and cheaper, at the price of one more object in the chain. That is not a big complication or problem, considering that it noticeably lowers the overall cost of the final objects.

Fortunately, for the gateway there has been a stable and modular open implementation for some time. It is based on node and implements all the features and specifications the HAP protocol requires to build a gateway for HomeKit accessories.

github.comGitHub HomebridgeHomebridge is a lightweight NodeJS server you can run on your home network that emulates the iOS HomeKit API.

How it works is very simple. A configuration file declares the accessories supported by the gateway. These accessories are nothing more than software plugins, each representing a particular exposed characteristic. The configuration file is a plain JSON file and the accessories are JSON objects belonging to an array. Some parameters of each accessory are mandatory, others are optional and depend on the specific implementation, since they are initialization parameters.

Implementation: Gateway

First we will set up our gateway. For this I decided to use a Raspberry Pi 3 on which I had previously installed Raspbian JESSIE:

raspberrypi.orgOperating system images: Raspberry PiThe Raspberry Pi is a tiny and affordable computer that you can use to learn programming through fun, practical projects. Join the global Raspberry Pi community.

To install homebridge, just follow the instructions on the project's GitHub page. I ran into no difficulty.

Once the installation is complete, we can launch our gateway with the homebridge command. On first start, the server warns us that no accessories are configured, so the gateway is not very useful yet.

There is a very active community on npm and you can find a plugin for almost any need you can imagine. In our case we will build an accessory to open an automatic gate, that is, to drive a "stateless" switch of an RF remote. If we want, we will also add a humidity and temperature sensor that gives us useful information (at practically zero cost) in the room where we place our HomeKit hub.

Before building our sensors and configuring our HUB, we need to complete the gateway setup by adding two modules that can talk properly to the sensors described above:

npmjs.comhomebridge-http-temperature-humiditySupports https devices on HomeBridge Platform.

npmjs.comhomebridge-http-switch Pluginhomebridge-http-switch is a Homebridge plugin with which you can configure HomeKit switches which forward any requests to a defined http server.

once installed, they are available right away. We only need to configure homebridge's config.json file accordingly.

JSON

{
  "bridge": {
    "name": "Home1bridge",
    "username": "CD:32:D2:E1:CC:33",
    "port": 50800,
    "pin": "031-43-153"
    },

  "description": "This is an example configuration file.",

  "accessories": [
    {
      "accessory": "HttpTemphum",
      "name": "Soggiorno",
      "url": "http://yuji.local/arduino/temp",
      "httpMethod": "GET",
      "humidity": true,
      "cacheExpiration": 60
    },
    {
      "accessory": "HTTP-SWITCH",
      "name": "Cancello",
      "switchType": "stateless",
      "onUrl": "http://yuji.local/arduino/switchOn"
    }
  ]
}

Apart from trivial parameters such as the name and the room, each module expects to talk to an HTTP address and receive certain responses for the requested operations; we only need to implement this simple logic to complete the job. The gateway takes care of everything else needed to talk correctly with Apple's HAP protocol.

Implementation: HUB and sensors

To build our HUB, which groups the sensors and talks to them, I decided to use an old Arduino YUN that I had bought for another project and left in a drawer. If you prefer, though, you can use the same Raspberry Pi you used to build the gateway. You just need to adapt the concepts I am about to describe.

Our HUB must implement an HTTP server that answers the endpoints specified in the homebridge configuration file above, returning the values read from our sensors, which are connected to the input/output pins of the Arduino microcontroller.

Before writing the code for our Arduino, though, let's take a break and enjoy a bit of electronics, building what we need to turn an ordinary RF remote for automatic gates into one driven by Arduino.

First we need to find the pins of the remote's open button and solder two short pieces of wire to them.

Meanwhile we will have placed our N-P-N transistor on a breadboard, suitably configured with a 2.2k resistor on the control line.

The base of the transistor goes to Arduino pin 7. The emitter goes to one of the wires we just soldered onto the remote. The collector is connected to one end of the remote's button and to Arduino's ground.

This way we create a normally open circuit that closes (effectively pressing the remote's button) only when a pulse above a certain threshold arrives from the digital pin. What remains is to encode all this in a language our microcontroller understands.

Arduino YUN is a very interesting hybrid platform made of a Linux server, a WiFi module and an AT microcontroller (very similar to the one used on the Arduino Uno). Arduino's strength, compared to other competitors, is being absolutely simple and effective at handling analog/digital input/output, with a programming language based on C that is quick to learn. To energize our pin 7 above, a few lines of code are enough:

C++

digitalWrite(7, HIGH);
delay(2000); 
digitalWrite(7, LOW);

to the above we need to add the logic for the HTTP server. Arduino YUN already includes a mini HTTP server/client platform, exposed very simply through two library objects called ClientBridge and ServerBridge. The server bridge listens for requests coming from the outside world and the client is used to write our replies to whoever called us.

C++

/*
  A simple HomeBridgeHub example for HomeBridge
  Author: Costantino Pistagna
*/

#include <dht.h>
#include <Bridge.h>
#include <BridgeServer.h>
#include <BridgeClient.h>

dht DHT;

BridgeServer server;
String startString;

#define DHT22_PIN 7
#define REMOTEDOOR_PIN 4

void setup()
{
  pinMode(REMOTEDOOR_PIN, OUTPUT);
  digitalWrite(REMOTEDOOR_PIN, LOW);

  Bridge.begin();

  server.listenOnLocalhost();
  server.begin();
  Process startTime;
  startTime.runShellCommand("date");
  while (startTime.available()) {
    char c = startTime.read();
    startString += c;
  }
}

void loop()
{
  BridgeClient client = server.accept();
  if (client) {
    String command = client.readString();
    command.trim();       
//    Console.println(command);
    if (command == "temp") {
      int chk = DHT.read22(DHT22_PIN);
      switch (chk)
      {
        case DHTLIB_OK:
        client.print("{ \"temperature\":");
        client.print(DHT.temperature-2);
        client.print(", \"humidity\":");
        client.print(DHT.humidity);
        client.println("}");
        break;
        case DHTLIB_ERROR_CHECKSUM:
        client.println("{ \"status\" : \"Checksum error\"");
        break;
        case DHTLIB_ERROR_TIMEOUT:
        client.println("{ \"status\" : \"Timeout error\"");
        break;
        default:
        client.println("{ \"status\" : \"Unknown error\"");
        break;
      }
    }
    else if (command == "switchOn") {
      client.println("{\"status\" : \"OK\"}");
      digitalWrite(REMOTEDOOR_PIN, HIGH);
      delay(2000);      
      digitalWrite(REMOTEDOOR_PIN, LOW);
    }
    client.stop();
  }
  delay(50);
}

What remains is the temperature sensing. The DHT22 is a digital sensor that is excellent for this purpose: inexpensive and digitally accurate, it needs no calibration and can be used with one of the many available libraries for DHT devices.

github.comDHTlibArduino library for DHT temperature and humidity sensor. AVR optimized

pin 1 is the power pin
pin 2 is the pin where data is modulated and serialized
pin 3 is unused
pin 4 is ground.

we will connect pin 2 to pin 4 of our Arduino YUN.

reading temperature and humidity is also very simple here:

C++

int chk = DHT.read22(DHT22_PIN);
switch (chk)
{
    case DHTLIB_OK:
    client.print("{ \"temperature\":");
    client.print(DHT.temperature-2);
    client.print(", \"humidity\":");
    client.print(DHT.humidity);
    client.println("}");
    break;
    case DHTLIB_ERROR_CHECKSUM:
    client.println("{ \"status\" : \"Checksum error\"");
    break;
    case DHTLIB_ERROR_TIMEOUT:
    client.println("{ \"status\" : \"Timeout error\"");
    break;
    default:
    client.println("{ \"status\" : \"Unknown error\"");
    break;
}

Conclusions: wrapping it up

Good. It is time to put all the pieces together. Once the sketch is running on our Arduino, let's check that all the commands work correctly:

/temp

/switchOn

At this point we just need to start homebridge and configure the Home app by scanning the QR code that appears on screen and following the steps shown by Apple's Home app. In the end we will have something like this on screen:

and the ability to talk to our beloved device by asking it:

What's the temperature at home?

or:

Open the gate

Final thoughts

homebridge is a very flexible open platform that lets you talk to Apple's HAP protocol quickly and effectively through small modules and simple HTTP based technologies.