Swift Package Indexing

So I feel slightly outnumbered today on today's episode of the podcast,

because, well, for something a little novel that we used to do at the very beginning,

but we haven't done for a little while, is we have a guest on the podcast.

But before we introduce our guest, I'm actually going to pass the baton to Sven,

because I feel a little outnumbered in people who speak French today.

And I'm not going to attempt the pronunciation of our guest's name.

So, Sven, would you like to introduce our guest?

I was wracking my brain while you were talking, thinking,

what would Marc and I have in common?

And I'm giving away part of his name already.

It's Marc Brudomont, who's joining us today to talk about Swift on Android.

You've completely dumped this introduction on me, Dave. Thank you.

Well, I didn't want to embarrass myself with my attempt at the pronunciation,

because I am not a French speaker, unfortunately.

I wish I was, but I'm not.

Hello, everyone, and fantastic pronunciation, Sven.

It's better than I think I've ever heard it.

Thank you.

I was also very impressed.

I knew the reason I dumped it on Sven was I knew he'd do a good job with that.

But welcome. Thank you so much for joining us.

Yeah, thank you for having me.

So, I think the best place to get started is for you just to give a little introduction of who you are and what you do.

Yeah, okay. Well, my name is Marc Brudomont, as we would say in English.

And yeah, I am a developer.

I've developed in a wide variety of languages and technologies over my career.

But past, you know, 15 odd years, I've been predominantly an iOS developer.

And I've started a company a couple of years ago called Skip.

And the vision is to enable people to write their applications in Swift and be able to deploy them to both iOS and Android.

It's really nice to see Swift growing into multiple other platforms.

And it will be no surprise that we chatted with Marc before we added Android support to Swift Package Index,

which we did a couple of months ago now.

Because Marc and the Skip Tools team had made an independent website that was starting to test compatibility with Android packages

or Swift packages compatibility with Android.

And you were running that as a separate site, weren't you?

Yeah, yeah, yeah. It was a Swift Everywhere.

And it was just sort of running GitHub Actions that was more or less trolling through, you know, the popular packages

and seeing does this build for Android? And if not, what are the errors?

And then very often I would go through and I would try to resolve the errors and submit pull requests to the projects.

And it was kind of a personal project to be able to promote the usage of the Swift Android SDK

and be able to kind of build up more compatibility with some of the popular projects out there.

And as you can now see on the site, we do have, well, we actually added two platforms at the same time.

We added both Android and WASM compatibility checking.

But just to stick on the Android for a little bit, and we'll talk more broadly in a second,

but apart from checking the build logs that we do publish when we do all our platform builds,

so if you haven't seen this feature of the Swift Package Index,

if you look at the full build results of any package, you can then click through to the build log.

And if there was a failed build, we will attempt to show you the build log.

So apart from looking at those logs, is there anything that package authors can do

to help themselves become more compatible with Android?

Yeah, well, in general, the first step, so to step back a little bit,

the Swift Android SDK is a cross-compilation SDK.

So it's similar to the Static Linux, the MUSEL SDK and the WASM SDK.

And it's a SDK that adds on to the host tool chain in order to allow you to build on a host platform,

in other words, Mac or Linux or Windows, for another platform.

So for example, with the Static Linux SDK, you can build on macOS for Linux.

And with the Android SDK, you can build on macOS or Windows or Linux and cross-compile to Android.

And in general, building for Android, you run into a lot of the similar issues as you would building for Linux.

Very often, if there's like a low-level libc kind of function or something like that you're using,

where maybe you would import Darwin on macOS or iOS, you would need to import glibc on Linux.

That's usually with a conditional like if can import Darwin, if can import glibc.

Android adds another one to that, which is Android.

So you can cover a huge swath of those sorts of issues by just doing, you know, if can import this, if can import that,

and then conditionally importing them.

Generally speaking, if your package can compile for Linux, it's almost certainly going to be a pretty short,

you know, small amount of work in order to get to build for Android.

You're actually getting at a question that was sort of forming in my head as you two were talking,

is how different is the Android SDK to Linux actually?

If you were to boil it down, it sounds like it's almost as if there was a different kind of,

you know, we have this Muzzle and glibc types of Linux.

Is Android sort of, could you consider it to be a variant kind of like those?

Yeah, yeah. So Android is Linux. It's just not GNU Linux.

They have a different libc, they call it bionic.

Yeah.

And it's pretty compatible. Like they have almost all the same functions.

You know, you can call abs and cosine and, you know, fopen, fclose, things like that.

But generally speaking, it is not exactly the same.

That's why you have a different set of headers that you import for the kind of low-level stuff.

And so, yeah, it's very similar to sort of the difference between the static Linux SDK

and actually compiling for Linux, where in one you import glibc and another you import Muzzle.

And so, I mean, was there a particular itch you wanted to scratch yourself

when you started delving into Swift on Android?

What was sort of the motivation for you to try and do this?

Well, the overarching goal is essentially to be able to, you know,

the holy grail of mobile app development is to be able to use the same language

to build an application for both platforms.

And this is something that, you know, I have always been dissatisfied with the current state of affairs.

You know, there's been a lot of iterations of this sort of thing, you know,

in the olden days we had, you know, like Cordova and things like that

that were just sort of like, you know, web views that you can code in JavaScript.

More recently, the popular packages are things like Flutter and React Native

where you, you know, write your app in Dart or JavaScript.

But these all have, you know, a tremendous number of shortcomings

that I think are pretty well understood.

And they don't really embrace the native platform APIs.

So, you know, the very high level goal was we want to allow you to write an application

in a single language.

And we love Swift. Swift is a fantastic language.

We think it's ideal for application development.

You know, they say it's, you know, all the ease of Java with all the efficiency of C.

It's really ideal for this scenario.

So that's really where we come from is we want to enable people to build their applications

for the two major mobile operating systems out there.

And everything else is really a result of that.

You know, the whole joining the Android workgroup and all our iterations on the SDK

and the tool chain and all of that is in service of this larger goal.

And how practical is that today?

It's very practical.

People are using skip to build and ship applications, you know, currently.

It does all work the sort of official--

So we ourselves, skip, are publishing our own tool chain right now, our own SDK,

that is essentially the exact same SDK that is eventually going to be the official one

that's published on swift.org.

And we also have a lot of tooling that is built on top of it

because just having a cross-compilation SDK is only one small real piece

of the whole picture of actually building an application with, you know,

graphical elements and integration with system APIs and things like that.

Of course, yeah.

But, yeah, no, it's up and running today.

Things work really well.

There's kind of two modes that we run in.

We have something called skip light, which was our first iteration before we had

the whole Android tool chain, where instead of actually compiling your Swift on Android,

we transpile the source language to Kotlin,

which is Android's sort of its own native development language.

Right.

And then that has really evolved into the current offering,

which is called skip fuse, which takes those two concepts,

the transpilation in order to integrate with Kotlin APIs,

plus the native Android SDK, and bridges them all together

so that you have one-- you have all the benefits of writing all your applications

on Swift, but you can still talk to all of the Android APIs,

which are all in Java and Kotlin.

Right.

So actually-- and I wanted to clarify that.

When you use Swift on Android to develop an app, you are actually--

like the GUI is a native GUI, right?

It's not like Qt on Mac that sort of has UI elements that look Mac-like

but aren't actually-- to my knowledge.

Last I checked, it was sort of a different--

it was made to look like Mac UI but wasn't truly Mac,

was redrawn effectively.

But this you're saying is actually-- this is using actual Android native UI elements.

Is that right?

Yeah.

So these are sort of genuine native user interfaces on both platforms.

And that's the thing that we feel like no one has really succeeded with.

You look at Flutter apps and things like that,

and they draw the pixel, they paint the pixels onto a canvas,

and they kind of mimic iOS with their Cupertino theme,

and they mimic Android with their Material theme.

But pretty quickly, even a non-technical user identifies the scrolling is not--

Yeah, you can always tell.

--right, the little delay, the font rendering.

I mean, just a million things that are so obviously apparent,

maybe not from screenshots, but the minute you start using an application.

Yeah.

And so that was really a hard requirement for us

is that it needs to be actually native on both platforms.

And I think it's the right requirement as well

because I think it is really just very important for that platform look and feel,

especially the feel, actually, more than the look,

that it is using the native libraries.

And it's an approach that Salim used with the Windows integration libraries.

They were--when I first saw that project,

I kind of assumed that it was going to use SwiftUI

and then kind of mock up the SwiftUI on Windows,

but actually it's not that at all.

So the Swift WinRT packages hook into the native Windows APIs

rather than trying to do cross-platform UI.

Yeah, exactly.

And we just feel that, you know, you look at all the best-in-class applications,

even the ones made by Google and Facebook

who run the Flutter and React Native projects respectively,

they all write their applications twice,

once in Swift and Objective-C for iOS

and another time in Java and Kotlin for Android.

Because of that, you just cannot get that premium feel

if you're not using the native toolkits.

And where, you know, Skip kind of has an easy time

is that on the iOS side, we're just using an intermediated SwiftUI.

Like, we don't stand in between you and, you know, real Swift

because we're not really doing anything on iOS.

It's on Android where we take your SwiftUI

and we translate that into the equivalent native calls

using what's called Jetpack Compose,

which is kind of Android's equivalent of SwiftUI,

and which is their recommended, you know, native toolkit

for building Android applications.

So we really only have half that problem to tackle,

which doesn't mean that it's easy.

It's actually extremely difficult in many ways.

But it means that we only have that side of it

to really have to, you know, nail down all the features

and all the polish.

Right, and that sounds like there's a bit of gluing together

that you need to do in instrumenting the APIs, right?

And that sort of leads me to the question,

how ready is--are there any types of apps

that this is particularly suited for?

Are there any gaps you still have to sort of, you know,

fill in, or what's the overall state

and what kind of apps you could be targeting?

Yeah, yeah, so we have a very large percentage

of the SwiftUI API covered where we, you know,

translate it into the equivalent Jetpack Compose

and native Android UI.

If your app can use primarily stock SwiftUI components,

you know, things like line of business applications,

you know, things like that,

then you're going to have a really good experience

because you don't really have to go off the rails.

You can just write it as if you're writing your iOS app

and then Swift takes, you know,

Skip takes over and handles that for Android.

It's when you have a lot of sort of custom components.

If you need to drop down to, like, UIKit

or need to use a lot of Apple-only frameworks,

that's where you need to sort of delve into

some of Skip's extensibility options

for being able to implement some of that yourself.

And that's when you need to start thinking about

doing a little bit of your own work in Kotlin,

which is kind of a leap in terms of the complexity

of integrating this stuff.

Right, and it sounds like you have escape hatches,

so you're not lost.

You don't have to abandon your product

if there's stuff you can't do.

You can still escape hatch out on the Android side

into native Kotlin and obviously on the SwiftUI side.

Escape hatch out into the UI and still have the same app.

You probably just if-def it somehow.

I guess you have a mechanism to--

Yeah, exactly.

We have a series of sort of escape hatches

that go in incremental complexity degrees,

but the simplest one is the one that we're most proud of,

which is you can just type, you know, #ifskip

and just drop some Kotlin right into your Swift.

Oh, nice, okay.

And then, you know, else if not.

And then the Xcode build plugin will handle taking that,

extracting it from your Swift,

putting it out in the Kotlin,

and then building the bridge for you

so that the native Swift is able to communicate

back and forth with the custom Kotlin

that you drop into your code.

And then you can use that as the entry point

to accessing the whole ecosystem of Kotlin libraries

that exist in the Android world.

You mentioned SwiftPM plugin there.

Is there some machinery that is particularly useful

from the whole compiler and SwiftPM tool chain

that makes this possible at all

without a lot of extra instrumentation?

Yeah, yeah, no, the full build plugin system,

you know, Skip wouldn't be possible without it

because the way Skip works is, you know,

you just work in Xcode and you develop your app

and you build and run it

and it launches it on the iOS simulator as normal,

but it also launches it side by side

on the Android emulator.

So you can iterate on these two things side by side

and you don't have to really--

you don't have to launch any other tools,

you don't have to do anything,

and it's the magic of the build plugin that does all this.

You know, every time you change any of your Swift,

the build plugin picks it up,

it does all the necessary bridging,

it writes out, you know,

any additional massaging it needs

to be able to launch the Android tool chain

to build it natively,

packages up your application,

puts it on the device or the emulator

and then runs it.

That's really all handled by the build tool plugin.

So without that, it really would not have been--

it would not have been nearly as smooth a process.

You'd need to be having extra steps

where you go to the command line

and launch external tools and things like that.

- That sounds great.

- And coming at this from the other side,

there is, of course, Kotlin Multiplatform.

How do you feel about Kotlin Multiplatform?

- Yeah, so we've worked with it actually quite a bit.

Skip, in some modes,

does actually integrate somewhat with Kotlin Multiplatform,

but for the most part, you can kind of view Skip

as the inverse of Kotlin Multiplatform

where they have a mechanism where, you know,

they take Kotlin and they build and, you know--

it's just your regular Kotlin in the Android development side,

so it's not doing anything there,

but when you deploy on iOS, what it does is

it creates essentially Objective-C wrappers

around that Kotlin, and it compiles it for iOS,

and then you sort of have an XE framework

that you hand off to your iOS developers,

and you can use it to implement

sort of the business logic of your application.

You'll still be writing the two user interfaces separately,

one in Android Studio and one in Xcode,

but you'll be able to share a lot of the low-level logic.

So in many ways, Skip is kind of the inverse of that process

when all you're using Skip for is sharing business logic.

But then in addition to that, you can also use Skip

for the whole sort of vertically integrated

user interface side as well,

which Kotlin Multiplatform doesn't have

quite the same experience around.

Sure.

I think the other thing we wanted to talk about today

was the recent announcement and founding

of the Swift on Android workgroup,

which is, is it yet an official?

I know originally it started as a community workgroup.

Is it now an official Swift workgroup?

Yeah, yeah, it is.

And I should sort of rewind and say that, like,

we at Skip did not invent this idea of Swift on Android.

People have actually been working on it for over 10 years.

Ever since Swift came out, people have been thinking,

"Oh, you know, you can kind of tinker

with the Android native development toolkits."

You know, LLVM and things like that.

And you can get Swift running on it.

So it's been kind of evolving with disparate groups of people

with different, you know, needs and levels of hobbyists

versus professional needs.

And it's been progressively evolving,

but it never really came together in a cohesive whole

where everyone was sharing ideas and implementation efforts.

And that's something that we started back in February

with what we called the community workgroup.

And that was a bunch of us,

Ioannis Andri from Reedle,

who's been deploying Swift on Android

with the popular Reedle Spark mail application

for quite a long time.

He's one of the people that really has done a lot of work

on getting the Android SDK working.

Ifina Golfin, who has been just devoted, you know,

to it for a long time.

So this sort of group has all come together and decided,

"Okay, we're just going to, you know, pool our resources

and we're going to focus on this."

Oh, and of course, Salim from the browser company there,

they're also working on this.

And so we formed the community workgroup

and then, you know, pretty quickly proposed

that it be made official,

which it was a couple of months ago in June 25th.

So almost exactly two months ago,

it became an official workgroup.

And the goal there is, you know,

the goal there is not as ambitious

as any of our individual projects,

which are using Swift on Android, you know,

for our own, you know, individual needs.

Skip, obviously, to enable people to build applications

for both platforms, but other people just to include

in their own individual applications.

It's really more to get an official Android SDK

kind of published alongside these other cross-compilation SDKs,

like the MUSEOL and the WASM SDKs,

and establish it as an officially supported platform

for Android.

That's great.

Yeah, is there, like, in the workgroup,

is there anything in particular you have on your sort of to-do list

that you feel like you need to tackle?

Any specifics there that you can share,

that you want to share?

Yeah, yeah. I mean, so there's a lot.

So, you know, the first sort of deliverable

that we're on the verge of getting out there

is an official SDK, where you can, you know,

just like you can cross-compile from macOS to static Linux,

you'll be able to cross-compile to Android.

But that's really only a single piece

of the whole Android story, right?

What do you get out of that?

You can get an executable Hello World application

that you can just, you know, run on Android,

or you can, you know, create a shared object file,

which you can then embed in your Android application

and then access.

But filling in the rest of the story

is a pretty large, you know, sort of next step.

For example, how do you handle resources on Android?

You know, it's different than resources on Darwin.

How do you handle bridging?

You know, the reality, you know, of Android

is that it is a Java-based platform.

You know, almost all the APIs that you need

to talk to the system, to the device sensors,

you know, to Bluetooth, to GPS,

are implemented in Java.

So you can't just do that with C bridging.

You need to bridge across to Java and Kotlin,

which is, you know, a pretty complex topic,

you know, to begin with,

and then on top of it, doing it efficiently,

you know, for a mobile application

is an additional complexity.

So we've actually been working with the Swift Java team,

mostly Conrad, on starting to come up

with some baseline interoperability standards

and recommendations for how Java is going to integrate

with Android, along with the other deployment scenarios

for Swift Java, which is, you know,

largely server-side integration.

So that's a really big one.

And then just the whole story around, you know,

packaging, ID integration, debugging.

There's a whole world of kind of next steps

in order to complete the project.

Now, we sort of at Skip have our own solutions

for a lot of these things.

You know, we integrate with Xcode.

We handle bundling in our own way and things like that.

But the more that we can get that, you know,

worked out in a standardized way

where everyone who's using Swift on Android

will kind of do it in the same way,

really only helps, you know, all of the community

in order to have, you know, the right way to do this.

- And how has feedback from the community

been to the work group?

- Great. You know, people are really excited.

There is a lot of, you know, sort of

what next kind of questions, because, you know,

as I mentioned, the output of the current SDK

is here's your shared object file, you know,

you know, go at it.

And then people are like, well, how am I supposed

to talk to this from my Android app and things like that?

But it also has, I mean, there have been

a tremendous response to the announcement.

It's been a lot of people have joined in the, you know,

the work group meetings with feedback

on what they want to use it for,

what they are currently using it for.

A lot of people we had never heard of

who have been sort of using it in their applications

in various ways have cropped up

and had really good suggestions and contributions.

- So your work group meetings are open to the public, are they?

- Yep, yep. They're open.

If you look at the, you know, Swift work group charter,

we have the schedule there

and people can just, you know, drop in

and, you know, ask questions or offer contributions.

It's been a really good process so far.

- That's great. How often do you meet?

- We meet every two weeks.

- So quite a good cadence to see new stuff happening

in the Swift on Android ecosystem.

- Yeah, actually we have another meeting tomorrow.

- I keep going back in my head to my earlier question

how Swift on Android is sort of different from Linux.

And as you talk and keep talking about then Java stuff,

it feels like it's almost like this isn't the right,

it's like on the Apple side, this was Swift for iOS, right?

Because you immediately associate with Android

and Android app is a mobile app, right?

It's not the Linux kind binary.

As you said, the shared object file doesn't give you anything.

It's like if on iOS you had a,

I mean, there is no terminal, but you know,

like had a little binary that ran without any UI.

That is not an app in the sense that is useful for the platform.

So it's kind of makes it obvious what a big task it is

to have not just the plumbing to get the code on there,

but there's all the user facing stuff that needs to be there

and that needs to happen. That's super interesting.

- Yeah, yeah, definitely.

Like, you know, sort of on Linux, you can imagine,

I know there's a project to have bindings to GTK,

one of the popular Linux graphical toolkits.

And, you know, with that, you can just build an executable,

you know, and link it to those bindings

and then you can have an application come up on the screen.

You know, it's all in C.

And so you're going to be able to kind of access the world that way.

But Android applications are sort of the mirror of iOS applications.

They're packaged in a very specific way.

They're launched in a very specific way.

It's not just an executable.

It's a whole, you know, there's resources that are bundled

with certain conventions.

There are, you know, derived resources like translation files

and things like that.

So it's really more of an application environment

that you need to think about how you're going to integrate with.

And that's where it really gets tricky.

And to do it in a way where it doesn't feel like

you're force fitting some alien technology into, you know, into Android.

And that's why, you know, it's all done using the fairly standard,

you know, Android native development toolkit mechanism

that's used by any application that uses any native code,

which is, you know, largely games, but, you know,

many, many applications have some requirement for native code

because it's just faster and you can avoid the, you know,

garbage collection hangs and things like that.

Yeah, I mean, the whole thing, it's like, despite next year

being the year of Linux on the desktop,

the command line is sort of a very default user interface for Linux apps.

So having just that, which is what Swift gives you by default,

you know, server-side Swift, that's all of it.

That's a huge ecosystem on Linux, right?

And, you know, the bindings you mentioned, there's not even,

you even have to, there is no default UI binding for Linux, right?

There's GTK, there's QT.

I'm not sure what the sort of, in quotes, market share is for either.

And there's more than those two.

It's on Android as on iOS and Mac OS, the story is different, right?

There is a default user interface that everyone thinks of

if you talk about an app on those platforms.

And I find it fascinating how they have different aspects there.

Yeah, yeah, absolutely.

And so, you know, so, you know, on Linux,

I think Qt and GTK have more or less half and half kind of distribution,

you know, one being the default for GNOME

and one being the default for KDE.

But you have the benefit of it can just be a self-contained binary.

And as you say, command line tools are also, you know,

probably the majority of Linux applications that you wind up running.

And so you kind of, Swift has a very natural fit there

because you can just sort of pull in all these packages.

And your user interface is the Swift, you know, argument parser, really.

Great.

Well, we should probably move on to some package picks for the week.

We asked Mark to bring along a couple of picks.

And my only question is, is your first pick Android compatible?

Yes.

So, yeah, my first pick is it's Uncertain by Matt Thompson,

@ttt.

And it's a Swift implementation of an old Microsoft library,

not old, but a Microsoft paper from around 10 years ago.

I saw this package, yeah.

Oh, yeah.

So it's about sort of rigorously treating uncertainty in a data type.

It's just uncertain, you know, generic across T.

And it's really neat.

It lets you, rather than, you know, in your own code,

when you're saying, "Oh, is this GPS coordinate, like, close enough?

Is it within or without?

I'll just pick 10 yards or something like that,"

and then go with it and then iterate down the road,

it allows you sort of to encode the concept of uncertainty into your data type.

And so you can kind of treat it in a rigorous way

and you can compose it with other uncertain variables.

It's a really neat idea.

Yes, it does build on Android.

Yes, I saw it fly past.

It was a few weeks since it's been released, I think.

It looks like--oh, yeah, it looks like it's been in development for a month.

So I think it was a couple of weeks since I saw it fly past,

and it did catch my eye.

It's kind of a--it's slightly fun, but also--

it's not a frivolous package, but it is a slightly fun package.

Yeah, no, absolutely.

And he has a great little Mac application that you can run

that uses Swift charts

and visualize various uncertainty algorithms

and parameters to it, which is pretty neat.

Oh, that's great. I hadn't seen that.

I had seen the package, but I hadn't seen the companion.

I need to check that out again.

That's a great package suggestion.

I will go next with my first package pick for this episode.

And it's Swift Complexity by Fumiyaka Tanaka.

And this is a brand-new tool rather than a code library

for testing a couple of metrics against your Swift source code.

So it tests for cyclomatic complexity in functions

and cognitive complexity in functions,

which if you've--I haven't seen this done for Swift before,

although it may have been done.

I just may not have come across it.

But I certainly have seen it in both the JavaScript ecosystem

and the Ruby ecosystem.

So cyclomatic complexity is a measure of how many paths

through a function there are.

So if your function is lots of if statements,

you're going to have a very high cyclomatic complexity.

And there's also a measure here of cognitive complexity,

which is not something I've come across before,

but apparently it measures how difficult it is

for humans to understand code.

And this is a tool that will give you a representation

of high cyclomatic and cognitive complexity

in functions that you've written in your code.

So you can run it as a tool against the single Swift file

or an entire project if you would like.

I tested this, and as is any tool that takes source code,

I always point it at the Swift package index source.

And I don't think it's designed for projects of that size

because it didn't manage to process the entirety

of the package index server source.

It gave up after about 10 minutes.

Also, you've got to think about how you'd actually

use the results of this.

You probably don't want to know about every single

cyclomatic complexity issue all at once.

And so one of the things that they do mention in the readme

for the package is that you can integrate this into,

for example, a CI testing scenario.

So you could, for example, do a quick CI process

that diffs the pull request, finds out what files have changed,

and then runs it past each of those files individually

and maybe gives that report or something like that.

But I thought it was an interesting little package

and one worth mentioning.

Did it suggest just to break the package index down

to smaller components like the Swift compiler does?

No, I may still have the error message in my console here, actually.

Instead, it told us we had illegal hardware instructions.

Ooh, all right.

Yeah, I can see.

In the past, working with Java libraries,

I've seen cyclomatic complexity analysis that would be used,

like you said, in pull requests,

and would compare the cyclomatic complexity

before and after the pull request and then say,

"Oh, this really increases it by this amount.

Maybe that should be a red flag."

And I don't know how this cognitive complexity analysis works,

but that sounds like it'd be a really interesting additional application.

It's like, "Your pull request just made this a lot more difficult to understand.

Maybe you should consider simplifying it."

Yeah, I'm not sure I'd ever see any of these.

And certainly in Ruby code, where there's a tool called Rubocop,

which will happily tell you about your cyclomatic complexity problems,

it's the kind of thing that quite often you'd look at it and go,

"Actually, I'm kind of okay with that code,

but yes, here there was a problem that we need to fix."

So it's not something that I'd expect to see be a blocker to merging a pull request,

but as an indicator of maybe you've gone too far in this function.

Right. My turn, I guess.

It certainly is.

And my pick is SQL Cipher by Micah Moore of Zetetic.

Zetetic is the company behind SQL Cipher,

and this is the official Swift package for the project.

I first learned about SQL Cipher when I was working for a bank quite a number of years ago now.

And what it does is it is a fork of SQLite, of the official SQLite database library,

and adds 256-bit AES encryption of database files.

And then it obviously is immediately obvious why banks might be interested in that in particular,

because they have strong requirements on data security, like on-device encryption, all that sort of stuff.

And so this is what this gives you effectively, a SQLite store that is encrypted and has the normal SQLite APIs,

so you can use it with all your normal processes, your APIs and packages and stuff,

and this is sort of taking care of making sure that the file at rest is encrypted.

I'm not sure to what extent it is encrypted in memory.

It's quite extensive.

There's a good documentation about what they actually do, how far this goes.

Obviously, you need to consider how you handle your passphrases,

because if you have a binary that encrypts the file, but then you have the passphrase sort of in your binary,

that's not super secure, right?

That is, I think we talked about this in the past with a package recommendation to deal with secrets in your code.

But, you know, it is certainly better than just leaving the file unencrypted entirely.

So if you have those needs, that's a great package to look at to deal with that.

And it's probably one of the standard mechanisms actually to deal with encrypted database files on iOS devices.

Interesting.

And bonus, according to our compatibility matrix, it is compatible on all of them.

So that includes the Apple platforms, Linux, Wasm, and Android.

There we go.

So I've actually worked with them a little bit on this,

and it's not actually compatible with anything but Darwin platforms right now,

because they're shipping binary XC frameworks, which I think is not triggering it to fail.

It was somewhat urgent for them to get something out the door,

because previously they had been distributing things via CocoaPods,

and with CocoaPods sort of imminent, CocoaPods is really winding down.

They needed some other way to ship SQL Cipher support for Darwin platforms.

But I am working with them actually on getting Android support via ideally having a source build.

I've been working actually on this for a while, both with them and with Gwendolyn Roof with the GRDB project,

whose SQL Cipher integration also relies on the older CocoaPods binary integration.

So hopefully we will have a better cross-platform story with that right now,

because it really is a de facto sort of gold standard for SQLite encryption support.

Applications like Signal use it to keep their local database of chats encrypted and things like that.

Yeah, I just realized now that you say that.

We do indicate that a package includes binary-only targets,

and I suppose our compatibility check fails in the sense that all it does is fetch the binary target

and then does nothing with it, I suppose.

I just checked. We have no error messages, but yeah, that's a gap definitely that we have there in our checking.

There you go.

Yeah, fortunately on the horizon, we will potentially have support for binary frameworks for non-Darwin platforms

in the not-too-distant future as static archives, right?

Because there is no ABI stability for non-Darwin platforms yet.

But even a static archive for a package like this would be sufficient.

Even if they will only ship a binary distribution,

there is a potential for compatibility with multiple platforms in the not-too-distant future.

Fantastic. Do you want to give us one last package recommendation or pick, Mark?

Yeah, I'm going to go with Lottie by Airbnb.

That's a framework for rendering vector animations that have been exported from Adobe After Effects,

which is kind of the industry standard for creating really fancy vector animations.

And Lottie is a fantastic application, super efficient.

If you ever see really cutesy kind of animation-driven applications,

one of the notable ones being Duolingo,

those are almost exclusively driven using Lottie exported animations.

They're very compact, they're vector-based, so they're always sharp on whatever screen.

They're never blurry and things like that.

And most importantly, you don't have to worry about the creation tool because there are...

I mean, the most famous one is After Effects to create the animations,

but the format that it goes into, I think it's...

What's the intermediate format?

It's adjacent. They call it Body Move-In, the expert plugin, I think.

That's it, yeah.

And so the biggest part of creating animations like that is how do you actually create them?

And so it completely sidesteps that, letting other people do it,

which I really like about this package and this technique.

Yeah, yeah, yeah. It's a great package.

And you asked if the other one I mentioned built on Android.

This actually does not build on Android because it uses...

Sorry, my brain is...

Core Animation for its implementation of animation,

which of course is an Apple-only framework.

But there is a Kotlin side to it, it's Lottie Kotlin,

that implements them using Android's canvas vector rendering animation.

And that's actually one of the popular packages for Skip,

is one that bridges between these two so that you can...

With your Skip application, you can ship a Lottie animation,

and on iOS, it will use the Lottie iOS Core Animation package,

and on Android, it will use their equivalent Kotlin implementation.

Well, that's great. I have a feeling...

I didn't stop you because I wasn't 100% sure,

but I have a feeling we have had Lottie on the podcast before.

Oh, okay. I did go through the past 20 or 30 and I didn't see it.

It was ages ago.

But I didn't exhaustively go through them all.

Well, there are some that have been lost to time.

Yeah, we started this as Twitter Spaces,

back when Twitter Spaces were a thing.

And so I think we managed to capture some of the recordings from those,

but certainly not all of them.

So you are absolutely forgiven.

Plus, this is episode 61,

and so I think it's high time that we highlighted Lottie again.

Real-time follow-up. It was in episode 17,

so that is in the distant past.

It is well worth a re-mention.

Sure. Yeah.

Well, and with that, we shall call it another episode.

So I'd like to thank Mark so much for your time

coming on and talking about the Android Workgroup and Skip Tools.

And we will be back in a few weeks with more Package Picks

and some news from Package Index, I guess.

Thanks for having me.

Thanks, Mark, and see you in two weeks or next time, rather.

Bye-bye.

Thank you. Bye-bye.