Here’s the final project structure as of Part 9.

We have a shared Model folder containing the CoreData/CloudKit model and persistence classes.

We have an Apps/AppShared folder containing the App and its ContentView. The only reason the ListOfThingsView was pulled out was because I made a decision to keep interactivity only available on iOS due to expediency and my own lack of experience. There’s no real reason to split these views and so it could have been in AppShared too.

That leaves the Apps/JustOneThing and Apps/JustOneThingWatch folder – one for each target containing just configuration information – The Info.plist and per target entitlements.

On the Widget side, we have our Widgets/WidgetShared folder that contains our System and Accessory widgets, each of which can be used on multiple platforms, along with the widget bundle that collects them. A single TimelineProvider is there too, and all the assets. In the case of the Widgets (unlike the apps) we’re able to share the Info.plist. This folder also contains the Intent Definition file.

Each of the target specific folders for Mac, Phone and Watch widgets only contains the platform’s entitlements file.

I’ve been at pains to point out throughout that this is not really a full, complicated project. It’s still pretty close the templates Xcode generates, just coalesced into a single project. Xcode templates showed us how to use a CloudKit data store in a SwiftUI app. Xcode templates showed us how to make a Multiplatform app. Xcode templates showed us how to create configurable widgets for all three platforms.

It’s been fun to try and pull them all together and figure out where they overlap and where they differ. The end result, I hope, make it clear where we can save time (and maybe bugs) by changing code once, instead of multiple, repeated places.

Usual disclaimers apply, this is absolutely not production code, its purely a hacked together experiment to see what I need, don’t need, can combine or needs to stay distinct

So for this last commit we need to make a new ThingDataStore to provide a set of shuffledThings. I added this about ThingDataStore in JustOneThingProvider.swift

All it does is pull all the PersistentThings from the database and provide a way to return them shuffled. You’ll notice I map the results using a property asThing

I added this as PersistentThingExtension.swift and it provides a basic encapsulation. of the request (in case we want to filter in some way later) and a conversion from a PersistentThing (a CoreData ManagedObject) to a Thing, our value type struct. It also hard codes what to do if either is null.

So our ThingCoreDataStore provides a shuffled set of Things, just like the other store, only these are loaded from CloudKit.

With all that in place we can now switch the Provider over to using the new DataStore and we’re good to go!.

Lets make sure the app is using the right PersistenceController and we’ll commit.

That’s in the repo as “Part 9: Load the Things from CoreData”.

Here’s the widgets on a Phone screen…

and on the Mac Notification Center

One thing I have discovered and have not yet found a way round for, you’ll see in the iPhone screenshot above. If you add the same size widget multiple times and don’t have any ConfigurationIntent parameters to change, each displayed widget is coming from the same instance. It’s not possible to have each instance pull a different random Thing. In essence there’s only a single SystemWidget instance for each size, that single instance pulls a random Thing and then its view is just blotted as many times as necessary.

This was kind of a pain for me as I quite liked the idea of having a random thing on each page of my phone. I could work around it by adding a purely synthetic integer configuration parameter “widget number” and changing it for each widget so they all become distinct and pull a different random Thing, but that’s beyond the scope of this little exercise.

I hope its been useful!

I had to revisit the widget embedding to restrict the right widgets to the right platforms as Xcode had reset them to all platforms.

I added a simple AppIcon for visionOS. (two layers, 1024px @2x)

I also changed the ContentView where I had been restrictive in the else case (if iOS elseif tv | Mac | watch ) and made it just a straight if iOS else....

I assumed this would mean my editable list was still just iOS and vision would use the readonly list.

Apparently not.

I’m not clear why but it seems to prefer the iOS branch and shows the editable list

Anyway, I’ll be back on the main branch and the shipping Xcode for me later, this is just a little diversion at the xcode15-and-vision branch.

I made a new CoreData SwiftUI project and essentially stole the guts of that to make it work in my app. All it has to do, really, is show a big list of All The Things. It was relatively easy for me to add Add+Delete functionality on iOS so that’s what I did. iOS can create and delete Things, all the other platforms just show a read only list.

Environmental Context

The first step is making the shared context from our persistence controller available to the app. We do this through the SwiftUI environment.

Since there’s no way to add any items for display yet, You can see above I added back the preview version of the PersistenceController. Again this is just Apple’s template code unchanged apart from adjustments for my own Entities.

It provides an in-memory, disposable context with 10 Things in it so we can

We can swap the app property from PersistenceController.preview to PersistenceController.shared when we’re happy.

List Views

Next up I added two separate ListViews. The first is in AppShared and added to both app targets because it works across Watch and Mac+TV+Phone and I called it SimpleListOfThingsView

It’s dirt simple and just uses the environment context to fetch all the Things, sorted by oldest first, and displays them in a list.

Here’s how it looks on a Mac, TV and Watch.

Nothing to write home about but it works.

Next we’ll create the version for the iPhone. I’ve added this just to the Apps -> JustOneThing folder and just the app target as it’s specific to the Phone app. Its just called ListOfThingsView

Again this is just lifted directly from the new project I made. The top of the View looks basically the same as the SimpleListOfThingsView but it comes with the add and remove methods that Apple’s template provided.

Here’s the body. You can see the issue with using the CoreData entity directly since all its fields are optional I’m supplying default text everywhere for now. We’ll fix that when we add a translation layer between our PersistentThing class and our Thing value type later.

The addItem method just creates a PersistentThing with no user input (Apple’s sample unchanged).

and the deleteItems machinery is unchanged.

I tried to get the swipe deletion working on the Mac but gave up as (like I’ve said) I really don’t care about the app UI I just want to work on the widgets. Hence its just the iOS app that provides any kind of interaction.

On iOS the view looks like this and of course the edit button and swiping to delete works fine.

The last step it to use these two new views in the app. For that we make a change to the ContentView to load the right view on the right platform.

At this point we can test out both views on all the various simulators and when we’;re happy they work we can switch the PersistenceController in the app from .preview to .shared and try it all out. If you sign into iCloud on the various platforms and simulators you should be able to create things on iPhone and see them appear on tv, Mac and watch.

One issue I have been unable to resolve is that it can take some time for a first run of an app to download its initial set of data from iCloud, leading me to believe it hadn’t worked. I’d love some way to put up, if not a modal, then some kind of indicator that says “hold on while I do the first sync of data”. But because it’s all happening in the background and you’re not supposed to care, there doesn’t seem to be an easy way to be notified. (Happy to accept answers on a postcard).

Lets commit! It’s under “Part 8: A Quick and Dirty App UI” in the repo.

The first thing we need to do is add some capabilities to the apps and widget extensions. We’ll make them all part of the same app group, and then add background modes for push notifications, which CloudKit needs to keep our database up to date.

As I’ve mentioned before, it could be that SwiftData has added simpler ways to do these things but this is essentially documenting what I did earlier this year with CloudKit as the easiest way to share data between the widgets on all the platforms.

App Group

First we need to add all 5 targets (two apps, 3 widgets) to the same AppGroup. I started with the main app but you can pick any target to be first.

We’re going to select the target and the signing and capabilities target and you should see the app groups entitlement we added before. If we click the (+) we can add a new app group. I tend to use reverse DNS and since this is across multiple platforms I use .apps. between the domain name and the app name. Note that it has to start with group.

If you start with the main app make sure you see the app group in both the macOS and the iOS/tvOS sections.

Once that’s done we can go to each of the other four targets and just enable that new group by checking the apparently-disabled-but-not-really checkbox.

An odd note. First time I did this all was well. Second time I found I hit a problem with the Mac Widget extension and somehow I couldn’t access app groups in the UI. If this happens you can edit any of the other entitlements files as source and copy and paste the app groups section into the Mac widget entitlements. Its the same text everywhere.

Next we’re going to go back to each target in turn and add the “iCloud” entitlement.

We’ll choose CloudKit, and add a new container in one of the targets, and then select that container in all the other targets.

Now all the apps and widgets will talk to iCloud and all will share data.

I committed here to keep things tidy, and so the diff is more obvious about what each step does. Its “Part 7: Data Sharing Entitlements”

Background Modes

CloudKit works using silent push notifications to keep our data up to date, so we need to enable that for the two app targets (not the widgets). Add the Background Modes entitlement to the main app (twice, once for iOS, once for tvOS) and then again to the Watch app target.

In both targets we need to check Remote Notifications (twice in the main app, once in the watch app).

There’s another commit here – “Part 7: Background Modes”

That’s all the configuration. Now we need some more code.

CoreData and CloudKit

I shuffled the project structure around a little. I made a “new group WITHOUT folder” called Apps and one called Widgets just to pull the various folders together. Make sure its WITHOUT folder for this step otherwise the various paths we’ve set on the build settings stop working.

Drag the three widgets and the widget shared to the Widgets group. Drag the two apps and the app shared to the Apps group.

Next I make a new group WITH a folder called Model. This will hold all our persistence code that works across widgets and apps.

I hate this with-or-without-folder stuff as sometimes the specific path matters (like the entitlements) and sometimes it doesn’t. As a rule I try and have most things in folders that match the group structure and only use folderless groups at the very top level for collecting stuff together.

The first thing we’re going to add is a CoreData model, and we’ll add it to all targets. I’ve called it JustOneThingCloudModel which is a bit verbose but I want to clearly distinguish the CoreData persistent model entities from any ViewModel type classes or structs (like Thing). Maybe SwiftData will make this unnecessary but right now CoreData model properties all have to be nullable and @objc etc so lets leave the CoreData machinery isolated from our SwiftUI+Swift models.

In that model I’ve created one entity, PersistentThing, and added properties for the text and createdAt (just like the current Swift model) and a UUID for uniqueness. I don’t know for sure that I need that but old habits die hard and I was taught to give my database rows an explicit primary key.

One last step in this little journey and that’s to add some way for the apps and widgets to access the CoreData stack.

When you tick the CoreData+CloudKit box on creating a new project, you get a file called Persistence.swift that looks mostly like this. (it also has some stuff for a preview, but I’ve ignored that for now).

I’ve made a few changes to this as you’ll see. Some were required to used App Groups, then I discovered a problem with paths on tvOS and then I’ve done some refactoring just to make it clearer (imo) which bits are which.

First here’s my version of what’s above. Like the original we override the URL if we’re in memory. Unlike the original we also have to override the URL even in the default case because we are using App Groups.

The default, not-ideal error handling is just extracted to a separate method

And I added an extension on URL to build the store URL for the group. The key is FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: appGroup). You can also see here the change I had to make when I discovered that tvOS didn’t work.

I also pulled out some of the static convenience code into an extension.

All this code is in a file called PersistenceController.swift in the Model group.

The last thing we need to do here is add some code to initialise the Persistence controller in the App and Widgets and check it all build and runs.

All this is in another commit “Part 7: Simple PersistenceController”

In this part I’ll add a second type of widget and talk a little about different widget families and contexts. As usual my focus here is on trying to share as much code as I can and have a single project that supports all the different options in obvious ways.

This section is a lot of moving code around, really, but again it sets us up going forward for more flexible widgets.

Divide and Conquer

First I’m going to pull apart the JustOneThingWidget file. I’ve made a new ThingView.swift file and pulled the ThingView and the ThingEntryView out to it, to leave just the Widget-specific stuff in JustOneThingWidget.swift.

Lets also make a WidgetBundle.swift file and pull the WidgetBundle out to it.

That just leaves our JustOneThingWidget struct.

Next we’re going to rename the file and the struct to SystemThingWidget (and you’ll see I added some more descriptive text to the configuration display name and description. Also, crucially, I’ve added a .supportedFamilies modifier to specify only the .systemXXX families.

There’s also a .systemExtraLarge family but it’s only on iPad, which I don’t much care about. Having it there would mean more conditional checks so I just ignored it. Those three are available on iOS and macOS so all good.

The last thing you can see above is that I ended up just deleting ThingEntryView and going straight to ThingView. The EntryView wasn’t really doing anything useful and I didn’t need anything from the Entry but the Thing.

Next we’re going to add a new file and call it AccessoryWidget and copy and paste the whole SystemWidget into it.

I’ve renamed the struct and changed the configurationDisplayName and description just so we can tell it apart from the SystemWidget. I’ve also set the supportedFamilies to the .accessoryXXX options.

Now we have two widget types we need to make sure they are both in the WidgetBundle. This is where things get interesting.

Computer Says No

It turns out that (at time of writing) the system families are not supported on the Watch and the accessory families are not supported on the Mac, so we’ll need to help Xcode build and package the right things for the right platforms.

First we’ll see target memberships for the SystemWidget and AccessoryWidget files to only build them for the right platforms. SystemWidget is NOT for the watch and AccessoryWidget is NOT for the Mac.

Next, since the two widgets may or may not be available, we’ll need to help WidgetBundle out.

Once again, SystemWidget is NOT for the watch, AccessoryWidget is NOT for the Mac.

At this point everything. should build again and we have two distinct widgets for two different situations, though they both just show our ThingView text.

Lets try them out in the various simulators.

What do we have?

On the iPhone, we can see the Home Screen is loading the SystemWidget (the displayName is Just One Thing). If we add a widget to the Lock Screen we can see its using the AccessoryWidget (displayName is One Tiny Thing).

The watch is interesting too. It’s not immediately obvious we’re getting the AccessoryWidget because the watch doesn’t show the displayName or the description. Instead its showing the text from the recommendations method on the Provider (“My Intent Widget“).

Here we can see the accessoryRectangular, accessoryInline and accessoryCircular. Rectangular looks just like the SystemWidget, and we could have tried to make the SystemWidget support that family, but we’d have still had to deal with a more complicated situation around the availability of families on platforms. This way, there are two distinct widgets for different situations, but we know they are just simple wrappers round the ThingView, so even though we don’t share the Widget struct itself, there’s a single place we can make changes and have them be reflected in both platforms.

I notice that they accessoryInline view isn’t using my fonts or colours, just simple text. Not a problem for now, but something to be aware of if we change ThingView to be more complicated.

Lastly the accessoryCircular is still just a tiny version of the ThingView and we want to change that.

I’d like to quickly explain the recommendations situation first though.

If we got back to the Provider code and add second recommendation…

Then go back to the watch simulator to add a widget…

You can see how the configurations work. We have one single AccessoryWidget that (in this case) supports the accessoryInline family, but we offer the user two different configurations.

If you remember back a few posts ago, I explained that the IntentConfiguration stuff is to provide a way for a widget to be configured on the iPhone or the Mac. Perhaps we offer a way to change the number of Things, or the colour.

That complex UI is not possible on the watch and so we offer some suggested configurations like “One Thing, Random Colour“, “Two Things, Accent Colour” and the watch user can select which prebuilt configuration they want to add.

We’ll ignore this for now and leave the existing single recommendation as we have no configuration system yet. Let’s get back to making a slightly nicer circular complication.

Where the SystemWidget just uses a ThingView, the AccessoryWidget now has its own wrapper view, which checks the environment for the widgetFamily and returns something small and simple in the circular case.

When I hacked this together the first time I made the circular widget show a total number of Things, but since I haven’t built a real DataStore for this yet, I just went with the SFSymbol I’ve been using as an icon. Its not winning any awards, and its just a basic launcher rather than glanceable information, but it looks slightly better than the tiny text.

That’s a wrap for part 6. The commit is “Part 6: Separate Widgets”

I feel I’m still very much putting off data persistence and CloudKit, because its a bit involved and not massively exciting, and I’m also putting off a functional UI because I have zero SwiftUI skills and I expect it to look awful

Anyhoo, I sat back down this morning and the first thing I did was extract a ThingView from my ThingEntryView. Removed the slightly irritating Demeter violation and also means I have a simple ThingView to tweak and use in a bunch of places… maybe even migrate it from the Widget to shared with the App.

It probably looks a little pointless for the sake of a single dot-separator, but it feels like it’s worth doing now.

Maybe the ThingEntryView won’t carry its weight for long. The ThingEntry is just a timeline implementation detail and maybe nobody else (especially the View hierarchy) should care about it.

A Bigger Thing

I’d like the text in the Widget to be as large as it can be, and shrink if necessary. And I’d like to have some random colours so it catches my eye, so lets have a play with the ThingView.

For the colours I just hacked something together for now, though some better defined palettes might be better. Essentially if we’re in light mode the system background for widgets is white so give me a dark-ish colour if we’re in dark mode, reverse that.

Any View using the colour can access the environment variable colorScheme and then ask for a suitable foreground.

The font sizing was a little more involved. I honestly cant remember all the things I tried before and I cant remember how I ended up with this snippet, but the first time I hacked this app together this is what I ended up with:

In essence it lets me attach a view modified which calculates the largest font size for the area, given some line limit and minimum scale factor. Suggestions very welcome for a better way to do it.

Both of these are in a file in WidgetShared called InterfaceExtensions.swift

So, I changed my ThingDatastore to have some random, different-sized Things and here’s the result in dark and light modes in a variety of widget sizes.

So far so good. Random colours so it looks different enough that I don’t start to ignore it, and sized to make the best use of space.

Like the colours it would probably be better to have a standard “palette” of sizes to at least provide some consistency, but I’m not anticipating seeing multiple widgets together at once so I don’t mind one at 16 points and another at 17 points. There’ll be one widget on my phone Home Screen and one on my Mac sidebar. I have an idea to use the Configuration to maybe show two Things side by side in a medium widget, or stacked on top on a large widget, but that can wait for now.

One problem I noticed is only obvious if you play around with previews. I changed the preview Thing to be a longer text and I changed the preview context to accessoryCircular. You can see how tiny the text is there to the left of the clock. Perhaps we’ll want to do something different for an accessory widget (phone Lock Screen will be the same), but accessoryInline and accessoryRectangular both look fine on the watch

So that seems like a good place to commit (“Part 5: Fonts and Colours”) and start thinking about different kinds of widgets for different situations.

Now we’ve got our project structured how we (or rather I) like we can start adding something useful to it where required. I’ll be taking fewer screenshots and taking bigger steps now as is this is really just me trying to document what I actually wanted to build, rather than a tutorial for you. I’m far from experienced here, will be learning as I go and no doubt making a bunch of mistakes. If you want a more in depth tutorial on Widgets or Intents, you’ll find better options elsewhere

Anyhoo, if you recall, what I wanted to build was something to let me add some random, 2-3 word reminders and display them, one at a time, randomly on widgets across my phone, watch and Mac so I don t get overwhelmed with ALL THE THINGS and get gentle nudges about JUST ONE THING at a time.

Since I was making a Multiplatform app, it will work on an iPad (which I don’t really use) and the AppleTV (which doesn’t really have widgets). I’ll also remind you that I have minimal interest in the “data entry” part of the app. It will be as rough and simple as possible. The two keys (for me) were: (1) I enjoyed messing with the code structure that got us this far and (2) I just want the strings appearing randomly on the widgets.

a Thing

The beating heart of the Widget system is the timeline provider. Its job is to supply one or more configured entries with a particular timestamp for the OS to display as close to this times as it can.

The ConfigurationIntent part is essentially a supplied UI to configure each widget in a clear, constrained way. In my case I’ll eventually use it to allow a user to configure the large widget to show one very big reminder, or two smaller reminders, but for now we’ll ignore it and work just on the timeline.

Right now the template has supplied us with a ThingEntry:TimelineEntry and that just contains the required properties of a Date (for the timeline) and a configuration (as discussed above). What we don’t yet have is a model object so the first thing I want to do is make a Thing struct to represent the Things.

All it needs right now is a String to hold the text, but I’ll also add a created date as I suspect I might want to twiddle with the randomness to maybe show older ones more often.

For now I’m not worrying about persistence, or sharing between the apps and the widgets. I just want a struct for the timeline to provide and the widget to display, so I’ll put it in the WidgetShared folder. I also added a static placeholder I can use where required.

Next I’ll go make some changes around the Timeline and the Entry to use this new struct. I’ll rename Provider to ThingProvider and SimpleEntry to ThingEntry. This is mostly in the JustOneThingProvider file but there are a couple of changed in the JustOneThingWidget file. While I’m there, and just because its annoying me, I’ll rename JustOneThingWidgetEntryView (the templates default name) to ThingEntryView, because that’s what it displays.

Next we’ll change the ThingEntry to take a Thing, alongside its date and configuration. Wherever the compiler needs me to supply a Thing, I’ll just use a Thing.placeholder instance for now.

This seems a decent place to make a commit, its in the repo as “Part 4: Add a Thing struct“

ALL THE THINGS

So next up I’m going to work on the timeline to make a few actual Things. I’ll split up a simple data store array of things and the timeline building which add them at hourly intervals.

Eventually the data store will need to be persistent and it will need to be shared between the apps and widgets, but again for now I’ll just embed them in the Provider so I can keep working on the widgets.

First thing I did was make a new initialiser for the ThingEntry that provided defaults for the date and the configuration to make things a bit less verbose.

That lets me reduce some of the code in the placeholder and snapshot methods, and in the preview in the ThingWidget file. I’m not yet sure what they do exactly, but less code is better and I will figure it out later. The main timeline method still needs all three arguments but at least the Thing is first.

While I’m doing this I realise again that I am annoyed by ConfigurationIntent. It’s passed into something else called an IntentConfiguration in the widget file and the names are irritating close together, and opaque. This is a classname I can change, but it’s magically generated from the Intent Definition file. I’ll fix it later, cause I’m doing something else, but it bugs me and I should find how how to change it.

Now back to the Data Store.

A simple ThingDataStore that can give me back an array of Things, hardcoded for now. I’ve also added a way get them in random order. I’ll add a ThingDataStore instance to the provider to separate the “getting of things” from the “building of timeline entries”.

In the Provider we’ll change the timeline code to get all the shuffled things and return them as timeline entries 15 minutes apart.

While I was there I pulled the recommendations method out to an extension as it didn’t seem to belong with the rest of the “give me some entries” methods. Its only required on the watch so potentially I could move it to the WatchWidget folder/target in a separate file.

I didn’t like having to the keep the separate line to increment the running time when what I really needed was a method on date which incremented and returned self. So I added one.

That let me simplify my timeline method a little

Next, I want to update the ThingView to display the text of our Thing.

I was tempted at this point to make it a ThingView and just pass the thing rather than the whole entry, but we may want to access the configuration at some point and so for now lets leave it taking the whole entry and live with the Demeter violation.

OK! If we switch to the MacWidgetExtension target and do a clean build, and then run, we’ll load the widget up pin the WidgetKit simulator app where we can see the placeholders, snapshots etc, and most importantly our timeline!

The timestamp at the bottom of each widget is the timeline date from the entry and the text is the Thing.text. We can see as the timeline proceeds the widgets are displayed in a random order. W e’re done, right ? SHIP IT.

Well, we’ll at least commit. I’ve called it “Part 4: Show the Things”.

I’m tempted to stop here for now. It’s quite tiring doing a little programming and then stopping to show what I’ve done. Last thing I’ll do for now is make a little icon for the apps and choose an accent colour to make things a little more interesting.

I went with the systemOrange for a highlight colour and I used the excellent Bakery app to knock up a quick Icon. Bakery is pretty clear that it’s just an SFSymbol on a background and that means you cant use them for App Store submissions due to copyright issues, but it’s fine for development :-). It doesnt do the AppleTV as the icon there is layered and complicated, but it’ll be nicer on the Mac and Phone and Watch (my primary use cases).

A last commit – “Part 4: Colour and Icon” for the above, and then one more for some super simple AppleTV assets I knocked up in Acorn ( “Part 4: Apple TV Assets” ) and we’re done for now!

Step 11: Tidying up

The first thing I want to do is get the timeline code out of the widget file.

Create a new file, JustOneThingProvider.swift in the WidgetShared folder. Cut and paste the Provider and SimpleEntry structs over there. Change the imports to import WidgetKit and import Intents

we’ll also add the preview back in. Add this code to the bottom of the JustOneThingWidget.swift file to have a simple preview that works on on iPhone and Watch. Note you need to have one of the widget targets active for the preview to work.

We’re creating the EntryView with a simple entry and we use a different previewContext for watch, or iOS/macOS which share a set of families. I event seen the widget preview work on macOS. You need to run the extension and it opens in the widget gallery app.

If you pick one of the iOS or watchOS widget targets you should see an appropriate preview (its just a timestamp :).

The last thing I want to do in this step is rename the watch app target/folder etc because “JustOneThingWatch Watch App” is a bit redundant.

First rename the folder and remove the Watch App part. Dont forget to also remove the first space or you’ll be really confused later.

Then rename the entitlements file in the same way.

Now we need to go to the build settings for the watch app target and rename the target. Go into the settings and find the entitlements entry to make sure that reads JustOneThingWatchApp/JustOneThingWatchApp.entitlements

Lastly, just for good hygiene, we can rename the scheme used to build and run the watch app.

Use the Product->Scheme->Manage Schemes menu

and rename the scheme to match the target (delete the “<space>Watch App”)

OK, lets commit again!

At this point we have added no custom code of our own (aside from the empty app groups entitlement that we will undoubtedly need to share data between app and widget) and all we have is as if Xcode offered a “Multiplatform app and Widgets” template. The actual contents of the App, the ContentView, the Provider and the Widget are all still what Apple gave us, just with the duplication extracted. That seems a good place to leave things for this part. Next time I’ll walk through adding my actual widget contents and configuration.

Step 7: Adding Widgets

In the targets list in the project file we’ll add a “Widget Extension” from each of macOS, iOS and watchOS (no widgets on tvOS).

We name the widgets appropriately but otherwise accept the default. Configuration Intents are common for configuring widgets so we’ll say yes to those. We don’t need a Live Activity at the moment because my reminders don’t have any duration. Mac and Phone get default embedded in JustOneThing, watch gets embedded in “Just One Thing WatchApp”.

After we’re done the navigator looks like this.

So much duplication!

• Once again the Assets, Info.plist and Intent Definition File are identical so we should be able to share those.
• Only the Mac Widget project has an entitlements file.
• Only the iOS Widget project has a WidgetBundle tagged with @Main. Watch and Mac widgets have the @Main tag on the XXXWidget classes themselves.
• The XXXWidget.swift files differ only in the names, and watch has some “recommendations” since Watch Widgets don’t use a full configuration UI like Mac+iOS.

There’s a problem though. We’ll commit anyway, just for posterity, but the code won’t currently build as all three Intent Definitions care a ConfigurationIntent class and Xcode complains.

For purposes of this article I was tempted to rename all three to get to a “it builds” state for this step. We’d need to go change the timeline code in each widget to use the new individual name for the Intent. Since the goal in the end is to make them more the same, not more different, I’m just going to leave them as is, broken, and commit so I know a known “starting point” when I begin the surgery to unify it all.

Step 8: Extract a WidgetShared to MATCH AppShared.

First we’ll make a new Group (with Folder) called WidgetShared.

We can pick any one of the widgets (say Mac) and drag the Info. the Intent and the Assets to the WidgetShared folder and delete the other copies (from say Phone and watch).

We should check the intent definition is added to all three targets widget targets, and both app targets.

The assets file we’ll rename to WidgetAssets just so we’re clear its different from the app and make sure its added to all three Widget targets.

The Info.plist is more fiddly. We have to go into the build settings for each widget target and change the Packaging-> info.plist file to WidgetShared/Info.plist

Lastly we have the same problem we had in step 3 where the watch extension was being included in the Mac app. Here we need to ensure the iPhone and Mac widget extensions are only included in the relevant builds (remember this is supposed to be a single app, but we have to be aware of the distinct platforms when it comes to embedding).

For the main app target, make sure the Mac and iOS widget filters get set appropriately.

OK, it should all build for all platforms and we can go for another commit. We now have:

• App
  • a Mac+iOS+TV app
  • a watch app
  • an AppShared folder for the bulk of the sources.
• Widgets
  • a Mac Widget Extension
  • a Phone Widget Extension
  • a Watch Widget Extension
  • a WidgetShared folder for the bulk of the sources

Step 9: Just Like Step 6

In step 6 I asked you to trust me and we added an entitlements file for each target. We’re going to do the same for the widgets but its extra fiddly because Xcode puts them at the root of the project structure, so some manual move is required.

The Mac already has entitlements, so select first the Phone and then the Watch widget targets and add a new capability – App Groups.

These will be added to the root of the project (right at the top of the navigator) and so we’ll have to move them (and I renamed them too, because I think PhoneWidget and WatchWidget is quite enough).

Forst we can drag each entitlements file to the right Group, then we rename each by removing the word Extension from the filename.

We have to tell the build settings about our change too, so got to the target settings for each of the Phone and Watch widgets and use the search bar to find” entitlements”.

We’ll replace “PhoneWidgetExtension.entitlements” with “PhoneWidget/PhoneWidget.entitlements” and do the same for the watch.

Finally we are where we want to be. Each widget has its own entitlements and they are named consistently. Lets commit.

Step 10: Sharing Code

The work we’ve done on the widgets so far has shared configuration files and assets. Like we did on the App targets it would be nice to share as much code as possible.

I’m not going to draw it all out, you can look for yourself, but if you compare the swift files PhoneWidget.swift, WatchWidget.swift and MacWidget.swift they are essentially identical except for the different names, and two distinct differences.

Firstly, the Provider struct in the Watch widget has an additional method recommendations( ) that’s used for configuration on the watch where the UI is limited and a full configuration interface is not possible. In that situation the watch provides a few “pre-canned” configurations to choose from – the recommendations.

This is on the Provider, *not* the actual Widget, but still it doesnt hurt if that method appears on the Phone or Mac, its only Watch that needs it, so we’d be ok to pick the Watch version of Provider to share. Phone and Mac will just ignore the method.

The second difference is directly related to the Widget however.

On Mac and Watch, there’s a @main decorating the Widget struct. It s not there on Phone. Why not? On the Phone there’s an additional file WidgetBundle which as the @main.

WidgetBundle is used if the extension exports more than one kind of widget and it seems that Apple almost expect this of the Phone, but not of the Mac or Watch.

Oversight? Or maybe they’d prefer we make a new extension per widget on the Watch and Mac. In either case, the distinction is arbitrary and so again we can choose the Phone version to share – all platforms with have a @main WidgetBundle wrapping an non-@main Widget.

Lets get started.

First lets Drag the WatchWidget.swift file to WidgetShared. We’ ll pick that one just because it has the extra Provider method and will save us a few seconds.

Check its available in all three widget targets.

Delete the PhoneWidget and WatchWidget files,

Then rename the WatchWidget.swift file to JustOneThingWidget.swift and edit the contents to remove the preview (for now) and rename the WatchWidgetEntryView and WatchWidget to JustOneThingWidgetEntryView and JustOneThingWidget.

The last thing we are going to do in this stage is bring across the WidgetBundle to make it shared as well. We won’t need the file, but we’ll copy and paste the code.

First select the code in PhoneWidgetBundle.swift and copy it it over to the top of JustOneThingWidget.swift.

Replace the PhoneWidget parts with JustOneThingWidget

And we’ll need to remove the @main from the JustOneThingWidget struct below because we have it on the bundle now.

The last thing we need to do is delete the PhoneWidgetBundle.swift file because we don’t need it any more.

And that’s the end of Step 10! Like the App we now have moved pretty much everything to a shared folder and all that’s left as target specific are the entitlements files.

This will change as we add support for different widget types, but for now, we have a single widget that displays and works on all of our platforms (no widgets on TV).

Lets commit and then move on to Part 3.