When I started learning Kotlin, I found that there is a Result type included (since Kotlin 1.3), but to my dismay you cannot (by default) use this class as a return value for a function.

I have never been happy with Kotlin’s built-in version of the Result type, anyway. Having to check if isSuccess or isFailure, null-check if the success or failure value exists or use the fold function seems archaic and not really necessary in neither Kotlin or Swift thanks to their generics.

So I set out to create my own version of Result in Kotlin, and to do that I used Kotlin’s closest equivalent to Swift’s powerful enums, a sealed class:

The use of generics here looks quite verbose (and a bit overwhelming), but it’s required, since the way sealed classes work is by creating subclasses of the sealed class. Here’s how you’d use this new Result type:

In the above code, we have two functions. One function that returns a Result with a Success type of String, and another function that returns a Result with a Success type of Int. Both functions return a Failure type of Error, which is just another sealed class that implements Throwable (since our Result’s Failure type requires a type that is Throwable):

sealed class Error : Throwable() {
    object CouldntDoSomethingElse : Error()
}

Although the declaration for the Result class looks complicated with generics, we only need to explicitly define the Success and Failure type once when declaring the return type of each function.

When it comes to actually returning either Success or Failure, you can just pass the appropriate value and Kotlin handles the rest.

Why use sealed classes?

Sealed classes are the closest match to Swift’s awesome and powerful enums. You can use an instance of a sealed class in a when statement like you would a switch statement in Swift, and if you’re using the result of the when statement, Kotlin will make sure you’ve either handled every branch (Swift calls these cases), or added a fallback else branch (like Swift’s default fallback):

And that’s all there is to it really. Here’s the default Kotlin equivalent for comparison:

That code actually won’t compile without jumping through some hoops because you can’t use Kotlin’s Result type as a return value anyway, but comparing it, I feel like my version of the Result type is cleaner and allows you to use a when statement, which is very common to see across a Kotlin codebase. If you needed fold for functional programming it would be trivial to add an extension onto my Result class:

Another bonus of my Result type is you know what type the Throwable will be, because you’ve explicitly declared it in the return type. If you need it to be less restrictive/more generic like the built-in Result type (which doesn’t let you specify the type of Throwable at all), you can still just declare the Failure type as Throwable:

fun doSomething(): Result<String, Throwable> {
    return Result.Failure(IllegalStateException("Now I can use any Throwable here!"))
}

Enjoy!

Sticky UI in Android bottom sheets

Over the past few months I’ve been working on porting one of my native iOS apps to Android, and I’ve been learning a lot about how Android works as a platform.

I’m now far along enough into development that I’m starting to work on refining the UI, and one of my challenges has been to create a bottom sheet where some UI appears to “stick” to the bottom.

After a bit of research I couldn’t find a simple solution so ended up coming up with my own. I’m pretty happy with the result, and it paves the way for more complicated UI in the future too!

In this post, I’ll show you just how easy it is using the new and glorious MotionLayout.

Setup

Before we can continue we need to add a couple of dependencies to our module’s build.gradle file (in this simple case, the module is just the app itself):

// For MotionLayout
implementation 'androidx.constraintlayout:constraintlayout:2.0.0-rc1'

// For CoordinatorLayout
implementation 'com.google.android.material:material:1.2.0'

At the time of this post, the latest version of the constraintlayout library that includes MotionLayout is 2.0.0-rc1, so that’s what we’ll use for this tutorial.

Layout

The next step is to update our layout file to add a bottom sheet with a button inside. Since this is a simple example, we’ll just add this to the MainActivity’s activity_main.xml layout file:

<?xml version="1.0" encoding="utf-8"?>
<!-- Set the root layout to be a Coordinator Layout. -->
<!-- In my actual app, it's not the root layout, but in this simple example it can be. -->
<androidx.coordinatorlayout.widget.CoordinatorLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">

    <!--  Add a MotionLayout as the bottom sheet with a BottomSheetBehaviour  -->

    <androidx.constraintlayout.motion.widget.MotionLayout
        android:id="@+id/bottom_sheet"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:background="@android:color/darker_gray"
        app:behavior_hideable="true"
        app:behavior_peekHeight="56dp"
        app:layoutDescription="@xml/activity_main_scene"
        app:layout_behavior="com.google.android.material.bottomsheet.BottomSheetBehavior">

        <!--  Add a button to the layout which will be sticky unless the sheet is hidden -->

        <Button
            android:id="@+id/button_sticky"
            android:layout_width="0dp"
            android:layout_height="0dp"
            android:text="My Sticky Button" />

    </androidx.constraintlayout.motion.widget.MotionLayout>

</androidx.coordinatorlayout.widget.CoordinatorLayout>

The first thing we’ve done above is set the root layout to be a CoordinatorLayout, this is required so a view with a BottomSheetBehaviour inside acts correctly as a bottom sheet.

Then we add a MotionLayout as the actual bottom sheet, giving it a BottomSheetBehaviour, with a peekHeight of 56 and make it hidable. Note that if you add this yourself without adding layoutDescription, you’ll get an error that a layoutDescription is needed. Android Studio will create this for you if you use the quick fix shortcut, which is awesome.

Finally, we add a Button inside the MotionLayout which is what will be sticky. This could be any UI you want, but in this case we’ll just use a Button as an example.

NOTE: Even though MotionLayout is a subclass of ConstraintLayout, we haven’t provided any constraints, that’s because it all happens inside the generated activity_main_scene.xml file.

Setting the constraints

If we open up the layout description file that the MotionLayout references (in this case, activity_main_scene.xml), we can update it so that it has the constraints for how we want the Button to be when the bottom sheet is collapsed or expanded:

<?xml version="1.0" encoding="utf-8"?>
<MotionScene xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto">

    <!-- Indicates the start and end states of the transition -->

    <Transition
        app:constraintSetEnd="@id/end"
        app:constraintSetStart="@id/start" />

    <!-- The actual start state of the transition -->

    <ConstraintSet android:id="@+id/start">
        <Constraint
            android:id="@+id/button_sticky"
            android:layout_width="match_parent"
            android:layout_height="56dp"
            app:layout_constraintTop_toTopOf="parent" />
    </ConstraintSet>

    <!-- The actual end state of the transition -->

    <ConstraintSet android:id="@+id/end">
        <Constraint
            android:id="@id/button_sticky"
            android:layout_width="match_parent"
            android:layout_height="56dp"
            app:layout_constraintBottom_toBottomOf="parent" />
    </ConstraintSet>
</MotionScene>

The key parts to note here are the start and end ConstraintSets. Traditionally, these are used to indicate the constraints of views at the start and end of a transition, which you can animate between. We’re going to use these two states to keep the Button stuck to the bottom of the bottom sheet instead!

In our case the start state is equivalent to our bottom sheet’s collapsed state, and the end state is the expanded state. So we’re saying, when collapsed, pin the button to the top of the sheet, and when expanded pin to the bottom.

We also need to set the height and width values we want. I tried setting this just in the activity_main.xml file but it didn’t work, so we’ll just add it twice here. We’ll match the peekHeight of the sheet with a value of 56dp, and let it fill the width of the sheet.

Make it stick!

If you run the app now, it still won’t stick. We need to hook into the expanding and collapsing of the bottom sheet so that we can update our MotionLayout’s progress, which is what gives it the effect of being pinned to the bottom of the sheet.

We do this in code, so we’ll add this code to our MainActivity.kt file:

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        
        // Get a reference to the MotionLayout, which is acting as our bottom sheet
        val motionLayout = findViewById<MotionLayout>(R.id.bottom_sheet)
        
        // Get a reference to the layout params
        val layoutParams = motionLayout.layoutParams as CoordinatorLayout.LayoutParams
        
        // Get a reference to the BottomSheetBehaviour
        val bottomSheetBehavior = layoutParams.behavior as BottomSheetBehavior
        
        // Add a callback to the bottom sheet so we can get the slide offset
        bottomSheetBehavior.addBottomSheetCallback(object : BottomSheetBehavior.BottomSheetCallback() {
            override fun onSlide(bottomSheet: View, slideOffset: Float) {
                // When the slide offset changes, set it as the progress of the motion layout.
                // This "transitions" between the start and end sets of constraints as the user slides the sheet.
                motionLayout.progress = slideOffset
            }

            override fun onStateChanged(bottomSheet: View, newState: Int) {}
        })
    }
}

Essentially what the above code is doing is adding a callback to the BottomSheetBehaviour we set in the layout file, and whenever the slideOffset changes (as the user slides the sheet), we set that as the progress of the MotionLayout.

Since the slideOffset can be between -1 and 1 (0–1 between collapsed and expanded, -1–0 between hidden and collapsed), and MotionLayout accepts values between 0 and 1, as the user expands and collapses the sheet it perfectly transitions between the ConstraintSets we set earlier to give it the appearance of being stuck to the bottom of the sheet.

Since the slideOffset when hiding is between -1 and 0, MotionLayout ignores that value so it doesn’t try to transition the constraints, making the button appear no longer stuck and hides as the sheet hides.

Final thoughts

There are other ways of achieving this, like setting offsets manually on views but this feels extremely convenient to me, and as mentioned earlier this paves the way for more complicated UI that can transition as the user expands and collapses the sheet, something that would get very messy if we had to handle all the offsets ourselves.

If you want to follow along with my journey into Android dev, follow me here or on Twitter and I’ll keep sharing what I learn, as I learn it!

Let me start off by saying I absolutely love Swift Package Manager and I think it’s the future of dependency management on iOS, so-much-so I’ve written posts on what we can do with it.

But I also want to use this opportunity to highlight a potential risk with using it that I became aware of today. I initially thought there was no issue tracker for Swift Package Manager since there isn’t one in the GitHub repo, but I’ve since reported this issue on the Swift bug tracking Jira instance (SR-13346).

I’ve found a way to run any code I want when you use one of my Swift packages (providing you don’t check the Package.swift file before hand), and it’s a lot simpler than you might think. Let me show you how.

The hack

It’s a very, very simple hack, making use of anonymous closures to lazily load the Package instance defined in the Package.swift file for a package.

UPDATE: After writing this post and filing a bug with the Swift team I realised even this is more complicated that it needs to be. You can simply create a function that returns anything that the Package instance needs (like a string for the name) and execute any other code you want before returning.

First, let’s look at a normal, simple Package.swift file that gets generated when you run swift package generate:

When you add this package as a dependency, Swift Package Manager does some magic by looking for the package instance in this file.

Since this file is just a regular Swift file, we can write any Swift code we want in here, including tricking Swift Package Manager to call a function whenever the package instance is referenced:

The code above has hardly been changed, but can now be used to run any code we want in doSomething(). Let’s add some code to doSomething that makes your Mac speak out loud (yes really!):

In the above code, we’ve updated doSomething so it now runs an executable file called say which speaks out any words you give it as an argument (included in every Mac by default).

Notice how we’re able to literally execute a programme that is stored in usr/bin. To do this we have to use a Process instance, which is part of AppKit, which we have no problems importing into our Package.swift file, because it’s just Swift code running on a Mac.

If you add our package as a dependency to another package, or as a dependency in an Xcode project, you’ll hear your Mac say “hello world” whenever the package is resolved. In fact, you only have to save the Package.swift file to test it and it’ll speak.

This gets more worrying when you add this package as a remote dependency in Xcode (11 or 12), because the code runs as soon as you add it as a dependency:

By the time you get to that screenshot above in Xcode 11 or 12, the function has already been called and your Mac has said “hello world” out loud.

Going further

Just being able to import AppKit opens up the possibility of so many things, both malicious and not. As an example, with AppKit you can get a list of running apps, terminate them and launch new processes with NSWorkspace.

We can import other macOS frameworks too, like Collaboration, which lets us get information like the full name of the current user, and more alarmingly, test to see if a password is the correct password:

If “notmypassword” happens to be your actual login password for your Mac, the above code will speak out:

“Hello [your name], notmypassword is your password”

Even without importing AppKit or any of the other macOS frameworks, we can import Foundation which allows us to make any network requests we want:

The above code uses a DispatchGroup to make the thread wait until the network call has completed. This network call could be used to download any data from any site, and upload any data anywhere.

If that wasn’t enough, since you can access FileManager from Foundation, you can also write any data to disk, as well as read directly from the filesystem, or delete files. In theory, you could delete the entire user directory (although I was too chicken to try!).

The above code iterates through the entire filesystem, logging each item to the console. Thankfully in Catalina you do have to give Xcode permission to access some directories, but that just confirms that you’ll be able to run code in any privileged way that Xcode does. I’m also subconciously trained to just accept any permissions requests that Xcode throws up at me.

These are just a few examples off the top of my head of what we can do with this, I’m sure there are plenty more that cleverer people can think of.

Mitigations

What can you do to protect yourself from people who want to abuse this vulnerability?

Well, unfortunately you can’t entirely, but you can help protect yourself by checking each 3rd party Package.swift file before using it, and make sure you target a specific version in a remote repo rather than always resolving the latest version of a branch. Remember though there’s nothing stopping someone from changing the code that a tag in a remote repo references.

Additionally, you should only use packages from developers you trust. Unfortunately this could be an unfair disadvantage for new developers with something cool they want to share via Swift Package Manager, and in any case there’s still a risk (albeit small) reputable developers could have their repositories compromised.

Hopefully, GitHub will be able to add some vulnerability checks for Swift packages like they do with other language dependencies in the future, and of course hopefully the Swift developers find a way to plug this properly without impacting the usefulness of either Swift Package Manager or system frameworks.

In the interests of fairness, I should also point out that Cocoapods has a way of running scripts as the framework is being built, however they at least choose to log warnings to developers so it’s not completely silent. And they expose it as an official feature so people are more aware of it.

You should also make sure you’re not storing anything sensitive on disk outside of the Keychain, that means no storing passwords in unencrypted text files, no leaving private keys or certificates on the desktop etc.

Additionally, although I was able to write code that retrieves private keys from the keychain (or references to keys, more specifically), I wasn’t able to actually use the key to sign data without a permissions prompt coming up:

This is why it’s important not to blindly allow permissions for things that pop up, even if they seem like they’re coming from the system. For example, using some keychain code I was able to get this popup to appear while trying to use private keys:

That one is particularly worrying because it doesn’t mention my package name anywhere, and since it’s saying macOS wants to make changes I would be tempted to allow it if I didn’t know it was my code that caused it. I don’t know what entering my username and password does in this case, because again I was too chicken to try (maybe I can set up a demo machine so I can properly try this stuff without worrying!).

It’s not all bad

If you’ve read this far you might be worried (and rightly so), but it’s also worth pointing out that although this can be used for evil, it can also be used for good.

This sort of thing could enable code generation (which is why I thought of this in the first place), or providing some required automatic setup for users of libraries that have a difficult setup process (like adding build phase scripts for Firebase).

Sadly, we live in a world where bad actors ruin things and That’s Why We Can’t Have Nice Things™️.

How can the Swift team fix it?

I’m honestly not sure the best way for the team to fix it, if Swift code is going to be allowed in full then this will always happen. Perhaps disallowing imports or functions when parsing the Package.swift file could work.

I’ve created an example repository which you can check out if you want to see it for real.

Last year, after Apple released the first beta of Xcode 11 with native support for Swift Package Manager (SPM) built in, I wrote a post on how we can leverage this to build modular apps with Swift Packages.

In it, I touted that it would make it possible to ditch Cocoapods as a dependency manager, but what we ran into quickly was a limitation with being unable to include resources in a Package, like colour assets, fonts, storyboards/xibs etc.

Thankfully, Xcode 12 includes the latest version of SPM which now allows Packages to include any resources, by including a new static property on Bundle named .module. This Bundle instance references the current module, rather than just being able to reference the current target.

In this post, we’ll update our project from last year to include some assets which we can expose from the Package for use in any other module or target!

Step 1

To continue, first follow the steps in last year’s post, then come back here and we’ll carry on from there.

NOTE: You’ll need to use Xcode 12 instead of Xcode 11. Since you’ll be using Xcode 12 and a new version of SPM, you may encounter some slight differences in how to set up a module from last year’s post.

Notably, you’ll have to provide a package name as well as a product name when declaring dependencies in FantasticFeature. You can just use the same value for both.

Step 2

Welcome back! If you’ve followed along and got the project building from last year, you should have:

• A workspace named AmazingApp;
• A project also named AmazingApp;
• A Swift Package representing a feature module called FantasticFeature;
• Another Swift Package representing a shared module called Common

Make sure you’ve opened the workspace (not the project), and in the Common module we’ll add a new asset catalogue for our colours that we want to use across our app.

In the workspace, create a new file (command + N) in [Common] ➡ [Sources] ➡ [Common,] choose Asset Catalogue and click Next:

Since you can have multiple asset catalogues in any module, lets call this one Colors.xcassets in case we add others for images etc in the future.

Step 3

You should now have an empty asset catalogue called Colors.xcassets:

Let’s add some colours to it! Click the plus icon (not the one in the workspace, the one in the catalogue), and then click Color set:

Name your colour something like primarySurface (which we’ll later expose in code), and then set whatever colour values you want for light and dark appearances:

Step 4

Now we can expose this in code, so in the Common module create a new Swift file called Colors.swift and create a public extension of UIColor to expose the colours from the catalogue:

You might get the error above about using a UIColor initialiser that is only available in iOS 11, since the Common module doesn’t yet declare a specific platform. You can fix this by opening up the Package.swift file in the Common module and explicitly setting the platform to iOS 11 or newer:

Looking back at Colors.swift, you can see we’re creating a static constant on UIColor (line 5) named primarySurface, which creates a UIColor by name from the Colors.xcassets catalogue.

The most important part of that code is the .module which is a static constant on Bundle representing our module.

In effect, that line of code is saying “create a UIColor from a colour named "primarySurface", defined in an asset catalogue in this module and store it in a static constant also called primarySurface“.

Step 5

Now we’ve exposed our colour in code, we can use it in code in this or other modules. As an example, let’s use it to change the background colour of the view controller that is shown when we run the app in the simulator.

In ViewController.swift, in the viewDidLoad function, set the view’s backgroundColor to our newly exposed primarySurface colour:

You’ll need to import Common at the top of the file, and once you do that you can run the app and the view’s background colour will be whatever colour you chose in Colors.xcassets:

As an added bonus, because we defined both a light and dark variant of that colour, the system automatically knows how to select and change to the right one. You can test this by clicking the Environment Overrides button in Xcode and changing the Appearance:

Unfortunately, you can’t set the colour directly in a Storyboard or Nib unless the colour is defined in the same module as the Storyboard/Nib, but that’s the same when using regular Xcode projects as modules instead of Packages.

Final thoughts

I love how quick it is to create a new module using SPM, and although this example is fairly simple and just exposing a colour, that is only possible because a Package can now include and references resources just like legacy Xcode projects.

In a matter of moments, you can create a new module, declare its dependencies which Xcode will automatically resolve for you, and now include Storyboards, assets, fonts and anything else you want.

There are still some downsides to using SPM, like clearing derived data requiring your packages be re-resolved (which also means cloning any remote repos like Alamofire again). But personally, I would take these small annoyances over the pain of creating and managing Xcode projects as modules.

SPM is fast becoming the only dependency manager you’ll need for developing Swift apps and libraries, without the need to manually run any commands in Terminal or manage a bunch of Xcode projects in a workspace or worrying about dealing with Xcode project file conflicts when creating a pull request.

Modern Modular Apps With Xcode 12 and Swift Package Manager was originally published in Kin + Carta Created on Medium, where people are continuing the conversation by highlighting and responding to this story.

I recently started my journey into Android development after creating iOS apps for 5 years, and there are a few things I wish I knew that tripped me up at the start.

In this post, I’ll go over 5 of them, so if you’re learning (or thinking about learning) Android as well, I hope this post helps you!

1. Views & ViewGroups

On iOS, views are represented as UIView subclasses, similarly on Android views are represented as View subclasses.

On iOS, you can add a UIView as a subview of any other UIView. On Android, you can only add a View as a subview (technically, child view) inside a ViewGroup (even though ViewGroup is actually a subclass of View).

A ViewGroup is typically something like a LinearLayout, ConstraintLayout etc, and is designed to display multiple views (hence “group”). You can add other ViewGroups to a ViewGroup, which is how you build up a layout or hierarchy.

2. Activities & Fragments

On iOS you use a UIViewController to represent a whole screen, or part of a screen by embedding a child UIViewController into a UIViewController's root view.

On Android, you can use an Activity to represent a whole screen, or you can embed one or more Fragments inside an Activity to represent an entire screen or parts of a screen (hence, fragment).

Unlike a UIViewController, an Activity always uses the full screen. Since you can transition multiple full-screen Fragments in an Activity, it's completely possible to have a single Activity for your entire Android app.

3. The Lifecycle

On iOS, you typically have an app lifecycle like this:

- App launched <--------------|
- App enters foreground <--|  |
- App becomes active       |  |
- App resigns active       |  |
- App enters background    |  |
- App suspended >----------|  |
- App terminates >------------|

And then during the app’s life you can also have lifecycles of individual view controllers:

- init
- VC view did load
- VC will appear <----|
- VC did appear       |
- VC will disappear   |
- VC did disappear >--|
- deinit

An Android app has its own lifecycle too, but it’s mostly linked to the current activity or fragment (this is a simplified version of both, check out the links for a detailed explanation):

- onCreate
- onStart <---------|
  (visible)         |
- onResume <----|   |
  (interactive) |   |
- onPause >-----|   |
  (not interactive) |
- onStop >----------| 
  (not visible)
- onDestroy

Additionally, the app itself has a couple of lifecycle events:

- onCreate
- onTerminate

Generally, you’ll just care about the lifecycle of the current activity or fragment.

As a user navigates around your Android app (or the system), any of these events can happen.

An activity (or fragment) is visible when it’s started and interactive when resumed. It can be paused if it’s obscured by something else like the Notification Drawer, or if the app is in split screen and no longer the “active” app.

The most important thing to know is that an activity can be recreated at any time by the system, which means that you cannot rely on state stored inside your activity (or any fragments it contains), since it will be a new instance! An example of when this can happen is when you rotate the device.

You can use ViewModels in your activities and fragments to hold state that persists between instances as needed. The system will manage whether to create a new view model for you, providing you create the ViewModel correctly.

It’s also worth mentioning that onDestroy and onTerminate aren’t guaranteed to be called (same as how applicationWillTerminate is not guaranteed to be called on iOS).

4. Contexts

In my opinion, this is the biggest difference between building an iOS app and an Android app.

On Android, you’ll often find many classes and functions requiring you to pass in this mystical object called a Context.

A Context is really just a class that provides access to app resources (like strings and images), system services (like Bluetooth adapters and notification managers), send Intents and information about the current environment.

Typically, you can just pass a reference to the current activity as the context, (which you can access from within fragments inside activities), and if you really have to, you can also use the application context.

Since you will find yourself passing around contexts quite often, it can be tempting to store a reference to a context in your custom classes and view models. It’s best to avoid this as much as possible, since it can cause memory leaks (for example, if the activity passed as the context was destroyed by the system, your class would still hold a permanent reference to it).

The concept of a context doesn’t really exist on iOS, although UITraitCollections are similar in that they provide information about the current environment, and can be accessed through UIViewController or UIScreen instances.

5. Backwards compatibility

I was going to include memory management as number 5, but given that’s more language specific than platform specific I changed my mind and went with backwards compatibility as the final thing you should know.

When you create a new iOS app, the general consensus is you should support the last two major versions of iOS, because the iOS platform has a great track record of getting users onto the latest versions of iOS, and Apple keep releasing new versions of iOS for older iOS devices.

When creating an Android app, you’ll straight away notice that when creating the app in Android Studio, it’ll ask you what versions of Android you want to target. As you change your selection, Android Studio will show you an estimate of how many devices that can be installed on.

If you choose the last two major versions like you would for iOS, you’ll likely be disappointed by the number Android Studio estimates.

It’s not as bad as you might think though, because of a difference between the way iOS and Android handle frameworks and backwards compatibility.

On iOS, all frameworks are bundled with the system, which means that you need people to be on the latest versions of iOS to use some APIs. On Android, it’s different. Some frameworks are added as dependencies to your app as needed, and Google put a lot of effort into creating support/compatibility frameworks which make APIs backwards compatible, like AndroidX, part of the Android Jetpack libraries.

During development of your Android app, and while looking at tutorials, you’ll see a lot of *Compat references, like SwitchCompat, and these provide backwards compatibility onto versions of Android that don’t support the standard versions like Switch.

Even with AndroidX, you’ll still want to balance supporting very old versions with how much testing you’re willing to carry out. Since there’s such a huge array of Android devices, the older you go, the harder it is to test your app well. Personally, I’ve added support to API level 26 (Android 8.0/Oreo), which means my app will run on roughly 61% of devices.

I can choose API level 26 keeping my user base in mind, since I know most people who will use my app (which connects to another device) will likely have newer phones.

What next?

Now that you know these 5 important things, there’s nothing left to do but start coding!

Download Android Studio (it’s free, and you don’t even need to create an account to use it!), create a new project and get going. Feel free to reach out to me if you have any questions. I’m still learning too, so we can learn together!

If you want to learn more about memory management on Android, this post is a great primer.

As with anything, it’ll feel alien at first, but in no time it’ll all start to click together and your biggest issue will be having to remember when to type let or val depending on what platform you’re developing for.

5 things every iOS developer learning Android should know was originally published in Kin + Carta Created on Medium, where people are continuing the conversation by highlighting and responding to this story.

While Apple and Google work on a new cross-platform contact tracing API to help tackle the COVID-19 pandemic, we’re starting to see some countries release bespoke apps built using just the existing Bluetooth APIs on each platform.

What we’re quickly seeing in the media about these solutions is that the iOS app has some limitations while in the background (i.e. not the visible and active app), and as a result the creators of these apps are often recommending people leave the iOS app in the foreground, or that they work better if Android devices are nearby.

IMPORTANT: This post is not designed to call out any specific implementation by any country, nor should you as a reader be worried about downloading any of them! Although the general consensus is it’s better if countries used the Apple|Google framework, we should still use what is currently available until something potentially better is available.

What we’re not really seeing in the media is a high level technical explanation of exactly why bespoke iOS Contact Tracing apps seem to be so ineffective while running in the background, and why Android doesn’t have the same limitations. I aim to cover exactly that in this post at a high level. You do not need to be a developer to read this post!

TL;DR: It’s because of the way iOS restricts developers running apps in the background to protect privacy and battery life, which is very different from how Android allows apps to run in the background.

I really recommend you read the whole post though, you’ll learn lots about how both iOS and Android work, and more specifics about why this means bespoke Contact Tracing apps have issues on iOS, and a whole bunch more interesting stuff!

What is a Contact Tracing app

Before I go any further, you might be wondering what a Contact Tracing app is actually for. In simple terms, it is designed to keep track of people you have been in close proximity to, and if any of those people are diagnosed with COVID-19, you can be notified so you can self-isolate or get tested, and other people you’ve been close to can do the same. For that to be effective, it needs to be installed on a lot of devices!

Contact Tracing apps on iOS and Android use something called Bluetooth Low Energy (LE), which I’ll just call Bluetooth throughout this post. I’m writing this post as someone who’s developed and released two iOS apps that use Bluetooth while in the background reliably, and I’ve ported one of those apps to Android which has taught me a great deal about the differences between the two platforms when it comes to running the code reliably while the app is not the foreground (visible) app.

COMMENT: I can tell you straight off the bat, lots of people don’t like leaving apps running. Since my users don’t even like leaving my apps running in the iOS App Switcher, they definitely would not use my app if it meant leaving the app running in the foreground (so the app is visible) at all times!

Now we know what a Contact Tracing app is, let’s talk about exactly why the creators of these apps are recommending that people leave their iOS apps running in the foreground to make them more reliable, and why it’s not a problem on Android.

The iOS App Lifecycle

Let’s start with the basics, since understanding the general lifecycle of an iOS app is important before continuing.

When we create an iOS app, by default it cannot run in the background at all, even when it’s showing in the iOS App Switcher. When you leave the app to go to the Home Screen, or a different app, the system “freezes” the app after a few seconds and puts it into what’s called a “suspended” state. At this point, the app is no longer in the foreground, and no longer the active app.

NOTE: It’s important to understand, your app isn’t using any battery while in the suspended state. Even though it’s showing in the App Switcher, it’s not doing anything!

While in the suspended state, if another app (or iOS itself!) needs more memory (RAM) then the suspended app can be terminated. As a user, you’d still see the app in the App Switcher, but it’s just an image of the last state of the UI before it was suspended.

Of course, things have changed since iPhone OS 1.0 and iOS apps can now perform certain tasks while in the background, including continuing to play audio like Spotify, track your location (with permission) like Strava, and also use Bluetooth (again, with permission), like Contact Tracing apps.

For this to happen, when we’re making our iOS app we have to declare to the system (iOS) that our app wants to do certain tasks while in the background. We declare this by enabling one or more “background modes”.

Once we enable a specific background mode, we can then use special APIs that allow these tasks to be carried out. Each background mode has different APIs and rules, and has a different impact on your device’s battery life. For this post, all we care about are the Bluetooth ones.

The Bluetooth LE background modes

To use Bluetooth in the background on iOS, we need to enable one (or both) of two different background modes for our app (more on the difference between them later).

Once we’ve enabled the right background mode(s), our app can continue to use the relevant Bluetooth APIs while not the active app, however there are some really nuanced rules around how this works and what we’re able to do.

But, before I can go into that, I need to explain to you the two different types of Bluetooth APIs that an iOS app can use! In Bluetooth LE, there is a concept of a Central and a Peripheral.

A Central is typically something like a phone or laptop. You can think of this as the client.

A Peripheral is typically something like a heart rate monitor, or some device like an electric skateboard. You can think of this as the server.

The Peripheral (or server) has data, and the Central (or client) wants to read that data. The Peripheral advertises itself, and the Central can scan for it, connect to it once it finds it, and read some data. The concept of advertising and scanning is important to remember for later in this post.

iOS and Android apps can act as both the Central and the Peripheral at the same time, which makes them (almost) perfect for use as a Contact Tracing app.

How Contact Tracing apps use Bluetooth LE

At an extremely high level, the way a Contact Tracing app could work, is every iOS and Android device with the app installed allows the app to act as both a Central and a Peripheral.

This means each device simultaneously advertises itself to other devices to be discovered and connected to, as well as scans for other nearby devices to discover and connect to.

When they discover each other, they can connect, transfer a small amount of data to identify that device, then use that information to be able to say those two devices have been near each other.

NOTE: I’m not going to go into specifics about privacy or cryptography here, that’s a whole different topic!

For it to work well, this needs to happen regardless of whether a user is currently using your app in the foreground, whether they have the phone locked, or whether they’re just using another app.

For that to happen in our iOS app, we’d need to enable the two background modes I mentioned earlier that allow the app to continue to use Bluetooth APIs as both a Central and a Peripheral while no longer the active app.

Once we have those enabled, if we start advertising as a Peripheral, and scanning for other Peripherals as a Central, that will continue to happen when our app is no longer the active app and our app is in the background.

Even though we’ve now enabled the background modes and are advertising and scanning, our app will still enter the suspended state after a few seconds of being in the background. The system itself actually takes over the scanning and advertising, while our app is completely frozen.

NOTE: This is one of the reasons Bluetooth LE apps use such little power on your iPhone!

Only when a Bluetooth event happens (like discovering another Peripheral) will our app get resumed (unsuspended) in the background to handle the event, shortly becoming suspended again after a few seconds.

The system will carry on doing this for us as long as our app is in the App Switcher (and the iOS device is not restarted), even if our app is terminated in the background to free up memory for another app by the system.

If a Bluetooth event arrives after our app is terminated by the system, our app is re-created so we can handle it, and then it will be suspended again.

This all happens in the background, so to a user it’s seamless and seems as though our app is doing all the work. This is the magic of background execution on iOS.

IMPORTANT: Up until iOS 13.4, if we remove our app from the App Switcher, the system will no longer advertise and scan on our behalf, and we’ll have to wait until the app is next launched by the user to start again.

In iOS 13.4 that behaviour seems to have changed and it will continue to stay connected after removing the app from the App Switcher, but that change is undocumented and shouldn’t be relied on.

So what’s the problem?!

That all sounds great, right? Looking at the above, it seems like iOS will continue to do the work we need for us to create our bespoke Contact Tracing app!

So why do the creators of bespoke Contact Tracing apps recommend that people leave the iOS app in the foreground, or do other things to keep the app working reliably?

Well, remember earlier I said that there are some really nuanced rules around how the iOS Bluetooth background modes work? This is where that comes in.

iOS Peripherals in the background

Let’s first talk about the Peripheral background mode, because this is the main issue.

When our app is in the background and we want to let the system take over advertising for our app, it will only allow us to advertise in a way that lets other iOS devices discover it.

This means that other Android devices scanning for nearby devices cannot find an iOS device while the iOS app is in the background (although there is an undocumented way to do it, it’s never a good idea to rely on undocumented behaviour, especially when it comes to Bluetooth).

Additionally, I ran a test where I kept an iOS device locked with a simple Contact Tracing example app running in the background, after 30 minutes I installed the same app onto a different iOS device, and they couldn’t discover each other until I brought the app into the foreground on one of the devices.

NOTE: During my testing, I also found occasions as well where an iOS device couldn’t discover another iOS device that was locked, until I just woke the screen while it was still locked. Sometimes that was less than 30 minutes.

On iOS, Peripheral advertising performance while our app in the background can also be impacted based on whether the iOS device has other apps acting as a Peripheral as well. iOS decides the performance on our behalf, and it’s not something we have any control over.

iOS Centrals in the background

Let’s also talk about the Central background mode. While our iOS app is in the background, the system will likely slow down the rate of scanning for nearby devices to save battery.

Although this isn’t a dealbreaker, it will definitely reduce the usefulness of scanning for nearby Peripherals which may be missed because you walked past someone while it wasn’t actively scanning.

Bluetooth LE on Android

Now that we’ve learnt the restrictions the iOS system has on developers using Bluetooth while in the background, and why they’re a problem for Contact Tracing apps, we can talk about why these aren’t problems on Android.

The Android system has a very different approach when it comes to letting apps continue to operate while they’re not the “active” app. Instead of background modes like on iOS, Android uses something called “services” to allow us to continue to run code reliably while the app is not the active app.

Specifically, these are called “foreground services”, and to use them as developers we must show a user-visible notification in the Notification Drawer.

The user is always able to terminate these services if they wish, although to do so they might need to force-stop the app from within System Settings.

Unlike an iOS app, an Android app does not have to be in the “Recents” app list (the equivalent of the iOS App Switcher) for the service to continue to run.

When we create a service, we declare it to the system in our app’s manifest file (a file the system uses to know what your app can do), and then we are free to run whatever code we want in there, potentially indefinitely.

This makes it perfect for running long-running Bluetooth code, acting both as a Central and a Peripheral, with very few restrictions. Exactly what our Contact Tracing app needs!

This is why Android Contact Tracing apps aren’t recommended to be kept in the foreground by their creators, because there’s no need.

Additionally, the Android Bluetooth APIs give us more options for scanning for Peripherals, which allows for an (undocumented) workaround for scanning for iOS Bluetooth apps that are only meant to be discoverable by other iOS Bluetooth apps.

NOTE: This workaround is quite technical, and it’s exactly what the smart developers who created the NHSX Contact Tracing Android app have done.

It involves scanning for nearby devices with very specific data encoded in an undocumented way on iOS devices. Very clever!

The tradeoff for this freedom on Android, is that we run the risk of using more battery than is necessary, and the system can start to suggest to our users that our app is using more battery than it thinks we should be. Ultimately though, the Bluetooth code is still running the same as if the app was the active app.

Also, unlike iOS, you have significantly more control over whether to advertise and scan more aggressively for increased performance, or conservatively to reduce power consumption. This means our Android Contact Tracing app is far more likely to discover passers by in time if we choose to.

Having worked with Bluetooth on both platforms, I can say there are pros and cons to each.

iOS is clearly more restrictive, but the API and hardware is more stable, because Apple have full control over it all. Android gives us far more freedom and power, but the API is more difficult to get up and running with, and some older hardware just doesn’t work as well.

NOTE: At the time of writing, the official Android documentation for getting started with Bluetooth LE uses deprecated APIs!

Ultimately, using the existing Bluetooth APIs available, Android apps are better at performing the role for a Contact Tracing app.

How is the Apple|Google cross-platform framework different on iOS?

The reason the Exposure Notification framework currently being built by Apple and Google is better on iOS than just using the existing Core Bluetooth APIs is because Apple can avoid the previously mentioned restrictions with apps using Bluetooth in the background.

Because Apple are making the framework, they can automatically give the Exposure Notification framework priority on the system, ensure that it isn’t abused by developers, and balance power consumption correctly specifically for Contact Tracing.

Footnote

I have validated my claims with online documentation and by writing and testing some sample code which you are welcome to download and nose about in if you want!

I’m on Twitter if you want to ask me any questions about this post, or sample code. Alternatively, you can open an issue on GitHub and as a question there.

Some useful documentation if you want to read more on the APIs available:

• iOS Core Bluetooth Programming Guide
• Core Bluetooth API documentation
• Android Bluetooth Low Energy Guide
• Android Bluetooth API documentation

Additionally, the NHSX team have open sourced their iOS and Android Contact Tracing apps and they’re a very good example of how to use Bluetooth on both platforms.

Stay safe! ❤️

Why bespoke Contact Tracing apps don’t work so well on iOS was originally published in Kin + Carta Created on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is a relatively new concept in iOS, since generally the sandbox environment apps run in gives you total control over everything that happens.

In this post I’ll focus specifically on a way to manually test HealthKit, which is especially useful if your app responds to events that other apps write to the shared store in the Health app on iOS (and watchOS).

Let’s make a HealthKit app!

Every good post comes with an example.

Let’s start by creating a simple HealthKit app. Fire up Xcode and choose [File] > [New Project] > [iOS] > [Single View App] and then name it FallDetector:

Our app is going to detect when a user falls over (while wearing an Apple Watch), so we can take some action to help them and make sure they’re okay!

Before we can use any HealthKit APIs, we first need to tell Xcode that our app will use it, so click on [Signing & Capabilites] and add the HealthKit capability:

Additionally, we’ll also need to provide a reason for reading from the Health store, so click on the [Info] tab and add a new entry called NSHealthShareUsageDescription with a string value of We want to help you if you fall!:

NOTE: If you’re using Xcode 11 for this example you’ll need to delete the `Application Scene Manifest` entry in the Info.plist for this tutorial.

Next, open AppDelegate.swift and replace the existing code with the following:

In the code above, we request permission to read falls when the app launches, and then set up a query that will be called whenever the Health store detects a new fall is added.

Note: In our example, you have to open the app to receive the event after a fall is detected. HealthKit provides a way to automatically notify and launch our app in the background if a fall is detected, but that’s out of the scope of this post!

Go ahead and run the app and accept the permissions to read falls.

Now let’s test it!

So, how do we actually test this?! For an Apple Watch to detect if a user falls, you’d need to either actually fall over (which might be fun the first one or two times), drop your watch and hope the fall algorithms detect it, or maybe smack your hand on the table so hard it hurts.

None of these are a very robust (or safe!) way of testing if a user falls, so what else can we do?

Remember I said that any app can write to the Health store on iOS? We can use that to our advantage!

It might not be immediately obvious, but you can add more than one app target to an Xcode project or workspace, so we’re going to add a new app target (which will be a very simple app) that can run independently of our main app, and use that to write to to the Health store.

In Xcode, click on the FallDetector project in the navigator, then under Targets, click the + to add a new iOS Single View App. Call it FallDetectorTestHelper and click finish:

Now we have two separate apps in the same Xcode project, we can run them independently.

We’re going to keep our FallDetectorTestHelper very simple for this example and just make it write a new fall to the Health store every time it is launched.

Because it’s a real app, we’ll need to give it the same HealthKit capabilities that the FallDetector app does, and also give it a privacy usage description for NSHealthUpdateUsageDescription:

Once you’ve done that, open the AppDelegate.swift for FallDetectorTestHelper and then add the following code:

Now go ahead and run the FallDetectorTestHelper app and accept the permissions. You’ve now written a new fall to the store, so swap back to the FallDetector app and get the alert that a fall was detected!

NOTE: You can actually add entries manually in the Health app, but this changes between iOS versions and is super fiddly to do. By creating our own super simple helper app we’re in full control, which means our testers can just get on with testing the app’s behaviour, without having to worry about different iOS versions etc.

Wrapping up

This very simple example could be expanded so that the FallDetectorTestHelper app can have some simple UI that allows testers to add different values and types to the Health store, depending on what your app responds to.

Additionally, this could be used for UI testing. Since you can interact with multiple apps with XCTest UI testing, so you can automate HealthKit interactions too.

Since both apps share the same codebase, you can also share code between them so that you’re not duplicating code. This is even easier if you’re splitting your code up into modules, which is something we use extensively at TAB.

Manually testing HealthKit was originally published in Kin + Carta Created on Medium, where people are continuing the conversation by highlighting and responding to this story.

Okay, so I’m a bit behind, but how amazing are @propertyWrappers in Swift 5.1?!

Recap

Formerly called “property delegates”, property wrappers are just that. They’re a wrapper around a property, and they’re simpler to set up than you might expect.

A property wrapper is just a type annotated with @propertyWrapper :

@propertyWrapper
struct Wrapper {

  var wrappedValue: Value

}

And you use it on any property that has a type matching the wrappedValue type:

struct Thing {

  @Wrapper
  private var value: Value

}

It’s as simple as that, now when value is changed, it’s actually the wrappedValue that changes. This becomes powerful when you know that you can set a specific get and set, to be called when the wrapped property is retrieved or set.

Even better, if you create an initialiser for Wrapper, you can pass an argument in when wrapping a property:

@propertyWrapper
struct SomeWrapper {

  var wrappedValue: SomeValue

  init(_ argument: Argument) {}

}

struct Thing {

  @Wrapper(Argument())
  private var value: Value

}

Sanitising user input

There are a few good examples of how this can be used already, like writing to UserDefaults, or my personal favourite; clamping a value between a range, but another nice idea is to use it to sanitise user input.

First we need to create a Sanitized property wrapper:

@propertyWrapper
struct Sanitized {

  var wrappedValue: String {
    get { value } // No need for the `return` in Swift 5.1 🎉
    set { value = newValue.removingOccurrences(of: allowed.inverted) }
  }

  private var value: String = "" // This holds our sanitized value
  private let allowed: CharacterSet

  init(_ allowed: CharacterSet) {
    self.allowed = allowed
  }

}

In this property wrapper named Sanitized, we’re requiring it to be initialised with an allowed CharacterSet. This is nice because there are already a few default CharacterSets, and you can also create your own.

When something tries to set the wrappedValue, we’ll use the newValue to sanitise it by removing the occurrences of any characters not in the allowed CharacterSet and storing in the private value property.

NOTE: removingOccurrences(of:) doesn’t really exist in Foundation, but you get the idea).

When something tries to get the wrappedValue, we’ll just return whatever the most recently sanitised value is!

Here’s a really simple example of how you could use the property wrapper:

final class SignUpController: UIViewController {

  @Sanitized(.alphanumerics)
  private var name: String

  @Sanitized(.decimalDigits)
  private var number: String

}

Here we have two private properties: name and number, representing the user’s input in a controller for signing up.

When the user enters a name or number you can set it in those properties and it’ll automatically be sanitised for you, with no need to call any extra functions yourself 🎉.

Property wrappers are also completely unit testable, since they’re just structs/classes:

func test_sanitized() {
  
  var sanitized = Sanitized(.alphanumerics)
  sanitized.wrappedValue = "a~"
  XCTAssertEqual(sanitized.wrappedValue, "a")

}

Pretty sure this is just scratching the surface of what we’ll be able to improve with property wrappers, but this gets me very excited for future development in Swift. I also really hope we also see more of these annotations like @propertyWrapper and @functionBuilder that allow us to create our own custom annotations in future versions of Swift.

NOTE: Xcode 12 improves Swift Package Manager support for creating modular apps, so I’ve written a follow up post with how to use it.

Xcode 11 beta 1 is out, and it is extremely exciting! Until now, the best way to manage dependencies was with Cocoapods or Carthage, but today that changes.

Xcode 11 and Swift Package Manager make it ridiculously easy to make modular apps; Xcode 11 automatically resolves dependencies when you build, and even gives useful error messages!

I’ll show you how easy it is.

Step 1

In Xcode 11, create a new Workspace from File > New > Workspace, name it AmazingApp and save it somewhere sensible:

Step 2

Create a new Project from File > New > Project. Choose Single View App, name it AmazingApp and click Next:

Step 3

Choose AmazingApp from the “Add to:” drop down, make sure the right location to store it is selected and click create:

Step 4

That’s your app and workspace created. Lets add a module!

From the bottom left of the workspace, click the + button and choose “New Swift Package”:

Name it FantasticFeature, make sure it’s being stored in the right place and click Create:

Step 5

Now you’ve created your module, you need to add it as a framework to your app so you can use it. Click on the AmazingApp project in the navigator on the left, choose your target (also called AmazingApp) and scroll down to Frameworks, Libraries, and Embedded Content:

Click the +, find your module’s name (FantasticFeature) and click “Add”:

Step 6

That’s it! You’ve added a new module and you can import FantasticFeature into any file in your main target. But it gets better! Let’s add Alamofire as a dependency to the FantasticFeature:

Find the Package.swift file for your module and open it:

In the root Dependencies array, add Alamofire as a dependency:

.package(url: "https://github.com/Alamofire/Alamofire.git", from: "5.0.0-beta.5")

Build your app and you’ll see Alamofire automatically get resolved as a dependency in the workspace 😍:

Step 7

You need to declare which target in the FantasticFeature uses Alamofire, so do that by adding .product(name: "Alamofire") to the array of dependencies specifically for the FantasticFeature target:

Step 8

If you build the app you’ll get no errors, hooray! But if you try to import Alamofire into a file in the FantasticFeature target (like FantasticFeature.swift) you’ll get an actually useful error saying “Compiling for iOS 8.0, but module ‘Alamofire’ has a minimum deployment target of iOS 10.0”.

Easy fix! Open up Package.swift again in your FantasticFeature module, and declare which platforms your module supports with platforms: [.iOS(.v13)]:

Save the file, build your app, and the error is gone! You can now use Alamofire in your FantasticFeature module, and you can import your FantasticFeature module into your main app.

Step 9

One last piece of the puzzle to figure out is how to create another module that can be imported into your FantasticFeature module. Thankfully that’s easy too!

Create a new Swift Package called Common, and declare it as a dependency for FantasticFeature:

And that’s it! Modern modular app architecture using nothing but Swift Package Manager built directly into Xcode 11. Not bad for a first beta.

Read my follow up post for how to go even further with Xcode 12 to use SPM to manage your modules completely.

Modern modular apps with Xcode 11 and Swift Package Manager was originally published in Kin + Carta Created on Medium, where people are continuing the conversation by highlighting and responding to this story.

Each year at WWDC, Apple unveil new features and APIs for their growing roster of platforms.

Some years are more exciting than others, but since this year is especially exciting and subjectively packed full of new stuff, I’d like to offer a plan for dealing with the overwhelming wealth of new information, not to mention chronic FOMO, and the feeling like you’re immediately lagging behind everyone so vocal on Twitter.

Unsurprisingly, the key is to be methodical and organised.

The Keynote

The public WWDC Keynote is fun to watch, but you don’t need to have FOMO if you don’t watch it live, or even watch it at all.

This presentation is primarily Apple’s PR platform to get everyone who isn’t a developer, or self-professed nerd, excited about the upcoming changes to their products. It’s always full of slightly tedious spiel about how well Apple are doing and that they’re the best at doing everything.

The real important stuff to watch is in the next scheduled event, the Platforms State of the Union.

Platforms State of the Union

This is where the juicy stuff is. While it can be fun to watch the main Keynote with friends and colleagues, I recommend settling down to watch PSotU on your own, somewhere that you can’t be distracted and with a good connection.

It’s also completely fine to not watch this live and focus on it when you get time.

If time is an issue, you can get away with not watching the main Keynote at all as a developer because PSotU will reliably cover all the big important announcements, with the benefit of being in a more developer-focused way.

Before going any further it’s a good idea to plug in any devices you want to dedicate to running the new betas of iOS, watchOS, macOS etc, as well as making sure they’re already running the latest releases of their respective platform. You should also kick off the downloads for any available beta software you want to install, because it can be slooooow, and you can forget about it while you’re watching PSotU.

When you settle down to watch the event, crack open your favourite note taking app and begin making notes about anything that piques your interest. At this point just keep it brief, but if you want to make it easier to find what you made a note about you can make a rough note of the time in the video as you make a note. This is when not watching it live will help because you can easily pause and rewind.

Once it’s over, I then like to take the time to tidy up my notes and start to prioritise them in the order I find most interesting.

API diffs

Chances are now you’ve got a good idea of what you want to learn about first, but before you do anything it’s a good idea to start installing any beta software that has finished downloading. It can take a while, and you can let that run while looking at the next bit.

After making my initial list of things to learn about, there’s a few other things I like to do; starting with checking out the API diffs.

If you mosey on over to the developer docs, you can get them to display the changes between the last version of Xcode and the new beta. On each page at the top it will give you a quick overview of anything modified (purple), new/added (green), and deprecated (red), as well as an indicator around each new item on the page.

On the “root” page of the list of frameworks you can see which frameworks are new or modified, and you can use that to drill down and learn about what has changed in any of the frameworks you’re interested in.

This step is important (and fun), especially if you’re already making and maintaining apps, because sometimes small changes here aren’t mentioned in any WWDC video.

As you drill down into frameworks and find new stuff, since it’s a web page you can grab a link and add to your notes.

Release notes

When you’re ready, the next step is to start to take a look at the release notes for the platforms you’re interested in, but also Xcode which can be a gem of a place to find unmentioned new features.

Release notes can sometimes take a while to show up, but by doing it at this stage they should be available.

They can be quite lengthy, so again I recommend adding anything you are interested in to your notes. It’s a good idea to make a note of any bugs that can affect what you’re working on or interested in learning about. Thankfully Apple provide bug numbers for everything so you can just make a brief note and include the bug number to quickly find it in the release notes later (as well as quickly find out if it’s been fixed in subsequent release notes).

One more thing

At this point you should have a nice prioritised and tidy list of notes and information to guide you to where to start. But there is one final thing I like to do, which is best done at this point now you have an idea of what you want to learn about.

Using either the official WWDC app (available from the App Store on iOS, iPadOS and tvOS), or the incredible unofficial app for macOS, you can go through all of the video sessions that are now available to browse and favourite the ones that are related to the stuff you’ve identified as areas you want to learn about.

You now know where and when that information will be available, and you can start to plan your learning time accordingly.

If you’re not actually at WWDC, although you don’t have access to the labs or the people, you do have the luxury of being able to watch all of the videos at a time that suits you, sometimes even before people in San Jose.

A footnote on Twitter

Twitter is a great place to watch stuff live with your followers and followees. It can be extremely distracting though and you can really quickly find yourself feeling like you’re falling behind because people have more time to spare than you to play around and explore.

It’s important to remember that you’re not a worse developer because you’ve got less time to spend on playing around with new stuff. (In fact I would argue you’re a better developer because you’ve actually got stuff to be doing 😉)

You cannot do everything at once, so pick what is most important to you and move onwards from there.

From WWDC information overload to information zen was originally published in Kin + Carta Created on Medium, where people are continuing the conversation by highlighting and responding to this story.