The code generated by Codex up to now was successful to invoke the Google Books API for a valid ISBN (which the application gets either by scanning a barcode or letting the user manually enter) and transfer the information obtained to a newly created Book object, using a mapping Codex created for this person. However, it was not yet using the Author information coming from Google Books, since the application used a complex mechanism which involved Person objects which stored information for any author, translator etc. and Contributor objects which mapped Person to Book (many-to-many).

However, Codex asked whether the next step should be taken.

Here I gave Codex a quite detailed instruction on how to implement the first function, referring to actual class names in the code.

Here we see Codex using the reasoning mode and analysing the given task and sub-dividing it into several subtasks.

Note that the Coding Assistant (using Codex for our case) has several reasoning modes (minimal, low, medium, high, available based on your ChatGPT subscription level, I suppose).

Once I confirmed, Codex went ahead with the implementation and described the results.

I must say I am really impressed at the level Codex can read the code and infer complex relationships between different entities in the code and how they are used to implement a specific functionality. It was also able to use existing methods, existing persistence mechanisms and did not implement anything unless it was required.

Best of all, the code compiled the first time and it seemed to work.

There were also some additional improvement suggestions, which I will implement but will not include in this post for brevity. I must also note that the suggestions all made sense, based on existing code available to Codex.

I wanted to try out how Codex could help in design work, given that using SwiftUI gives us a chance to embed the design in the code already. I wanted to check whether it would be possible to improve the look and feel of the application, aligning better with the latest Liquid Glass concept.

This is how the main Books view looked like before the changes.

After I rebuilt the application with the changes Codex suggested, this is how the same screen looked like.

Obviously there are some major issues with the interface now, given that some icons have disappeared, there are excessive background colours and so on, but this is not something I expected Codex to be abşe to do automatically and the description of the changes clearly shows a way ahead to investigate.

The changes described in these posts were implemented through a short dialogue with Codex within the space of an hour or two. As we get more an more experienced with the use of the Coding Assistant, things should get better. It is already impressive and much better than my expectations.

Please also note that Codex with GPT 5.3 was just released and several improvements were reported.

Subscribe now

Apple has enabled the use of coding through AI in Xcode 26. I wrote about it in this article. The novelty in this solution, as compared to using an AI system outside the coding environment was that the LLM-based AI system was able to see and understand the context on screen and was able to produce relevant code, rather than generic code to solve a problem.

Apple and OpenAI have gone one step further in the latest version of Xcode (currently beta 26.3). You can now configure Agentic AI to code for you. Currently this works for OpenAI GPT and Claude code models, but Apple also allows you to link other AI tools provided that they support the MCP protocol.

Since the previous support from LLMs was simple and relied on the developer to provide detailed prompts, I was looking forward to the possibility of AI agents autonomously coding, using the already developed code to base it on within the context of the project.

Setting up the agent was quite simple. I had already configured Xcode to use ChatGPT as a coding assistant, but now there are new settings in Xcode.

You add providers and select the tools to use. OpenAI tools are ChatGPT and Codex, which you enable by providing your OpenAI user ID and password.

The same can be done for Claude, but I did not set it up.

Once the setup is done, the Coding Assistant button launches a ChatGPT pane which can now understand context and use Codex as an agent to autonomously code for you. I wanted to try my hand at a task I had previously started but did not have the knowledge and time to complete. My book management application (Atheneum), which relies on entering a lot of information, would benefit from an interface to Google Books, which would enable quick entry of information.

The dialog is very reasonable and the suggested approach is fine. Note that Codex saw that I already had a button to activate the Google and used that to activate the functionality. Codex first adds the Codable models to be able to get the information from Google Books.

Codex not only created the structures to fetch the information, but also improved on the existing implementation (switched from a serial to an asynchronous implementation).

What I also like is that Codex described what it implemented and what has changed in the code. It also added a progress indicator as good practice.

Another good feature is that Codex has an understanding of typical parts of an algorithm and suggests to complete the implementation. This includes mapping the structure read from Google Books to our internal Book structure, using the persistence mechanism.

After listing what it could do, Codex proceeds with the first of the additional functions and asks the developer if it should do the implementation.

Once we approve, Codex explains how it will implement the mapping.

Once we approve, Codex implements the mapping and, as usual, explains how it did the implementation. Then it asks specific information about our own model and persistence mechanism, while providing a template implementation.

The information we provide to Codex is really minimal and to-the-point. Codex is able to implement persistence using the provided model and persistence mechanism.

(to be continued…)

Writing Tools

Writing Tools is the implementation of text generation Apple introduced in the previous WWDC.

In the new version, Writing Tools can invoke ChatGPT if your OS is configured to use it. I observed this “free” feature by recompiling my library management application and asking Writing Tools to generate a summary for a book that I have in my library.

This is basically free since you do not have to do anything in coding, as long as you use a standard SwiftUI (or UIKit) text view.

In this specific case I am running this on an empty text, but if I had text in the field already, I could have used the text and the options in the Writing Tools pop-up menu to generate something using existing text. In this case the application is going to ask if it should invoke ChatGPT, since my OS is already configured to use ChatGPT when necessary.

Once you approve ChatGPT use, it is invoked and the result comes back shortly. The speed and quality of the response depends on your (the user’s) ChatGPT membership if any.

ChatGPT also offers various improvement suggestions on the Writing Tools window and you can further refine the result. At the end, the text field takes the text from the response subject to any refinements you might have selected.

Xcode - Coding Intelligence

Xcode 26 Beta 7 has introduced some improvements to the use of AI in Xcode (named Coding Intelligence by Apple)

The first one is the setting of ChatGPT 5 as the default Intelligence tool within Xcode. The extent to which it can be used, the quotas etc. depend on your membership level with OpenAI.

It is also possible to set up Claude as the Coding Intelligence option. It should also be noted that there is a parameter to set up other external models, thus this list of two models should be extensible in the future.

I tried ChatGPT 5 to check on code that has given me some problems since I updated to iOS 26.

This was code I had moved to due to some navigation classes becoming obsolete by iOS 18, but implementing the recommended changes resulted in erratic behaviour in my book man-agement application Atheneum. I asked ChatGPT how to improve it.

This was actually impressive. In addition to the navigation problems I encountered, the suggested code also solved the issue of deleting objects from a filtered list, which caused some problems with SwiftData, and this was solved by the second part of the suggestion from ChatGPT.

So, my first trial of the new Coding Intelligence function using ChatGPT ended positively, however I will have to use this extensively to be able to evaluate it objectively. The final code is simpler and works well.

I will work on the new Foundation Models introduced and try to use it productively in a new project of mine, in the next instalment of this series.

Subscribe now

Xcode and Coding Assistant

The basic structure of Xcode coming with the new Beta MacOS 26 is similar to the previous versions, but there are some improvements, as always. Since there was a lot of hype about coding with AIs lately, I wanted to use the new Coding Assistant that is embedded to Xcode. I had previously used ChatGPT itself, which has added the ability to work with windows on screen, thus enabling us to ask ChatGPT to use the code in Xcode windows to improve or whatever we want to do.

This implementation is just the opposite, namely you invoke ChatGPT from within Xcode, or if you do not prefer to use ChatGPT, then you can use Apple’s own internal on-device model.

While re-compiling some of my existing code to see how my software would look under the new Liquid Glass interface introduced in iOS 26, macOS 26 and iPadOS 26, I decided to ask the new Coding Assistant to improve some code (shown below).

As you can see from the dialog, ChatGPT is already aware of what code is active on screen and analyses it. It is also clear that it checks other source files as well (it refers to which other classes or functions it will check).

It correctly identified the redundant use of findPersonWithID in the implementation and even suggested a - good - implementation that gets rid of the redundancy.

The second suggestion is more subtle, since it is based on a more complex analysis. Detecting that the function property is used as an integer and is used as an index for a string array, it suggested an alternate implementation.

The third suggestion is also fine, with the fourth suggestion being a minor UI fix.

The rest are minor suggestions as well, but it is still useful.

At the end of the session, ChatGPT suggests to apply all the suggestions. I did not do that, but it is obviously a time saver when a lot of changes are applied.

Performance

This was mentioned ion the Platforms State of the Union talk on the first day of WWDC. I do not have any metrics, but I realised that my Library application in preparation suddenly started to perform 2-3 times faster when I recompiled it with Xcode 26. My application heavily uses SwiftUI and SwiftData. I still have to check what has actually improved, but the performance with close to 6000 book records and several thousand authors and publishers, the application is quite snappy now.

(… to be continued)

When I got the announcement from OpenAI, I immediately tried to use this capability. The way to activate it is to start Xcode and open the file you are interested in analysing or editing. Then you activate ChatGPT by pressing Option-Space Bar. The first time you do this, the familiar chat window opens, with a document reference being used to install ChatGPT support. Clicking this results in launching System Settings with the intent to let ChatGPT to control your computer (Now this looks suspiciously similar to what they did in Terminator before everything went haywire, but well… I guess we are not there yet).

Once the setup is complete, the ChatGPT chat window shows the name of the active source file as a document reference.

Now you can interact with ChatGPT. It has the context for what is on screen and can apply your request to it. To start easy, I asked it to comment on the Swift code.

First it provided some general comments on the code and then started going into deeper analysis.

So far, so good. Then I started looking into the detailed comments and suggestions. Note that it gives me the chance to copy each suggested code change and paste it manually to Xcode as required. At the end of the chat it also asked me whether it should implement any of its suggestions directly on code. I was too afraid to let it do this, since I was working on my actual code and not on a sample.

The first item is more of a warning. This is indeed a concern, since this view would retrieve everything given it has no filtering predicate.

The second item is basically a minor point. In this particular view I do not want any animation, thus using the constant makes sense. However it could have been designed differently, which I will admit.

Here things start to get a bit messy. The comment is not appropriate, since pulsate is defined as a state variable in the beginning of the file and is initialised.Although it is not really changed within the view, this would be possible later with some changes in the user interface, so in a sense this comment contradicts with the previous one.

Now, this one is debatable. It is true that in theory the creation of a SavedChat object (newChat) could fail (albeit very unlikely). The second comment is a bit strange. It refers to the possibility of a delay in saving, however the newly created object is added to the collection immediately even if the saving may be done later (especially if the SwiftData property for autoSave is set to false). Since the check is done on the container (an array, basically), it would always work.

ChatGPT has not understood what this - very typical - Swift code is trying to do. It is trying to delete only the lines that have been marked for deletion using the swipe action (typical action for iOS or MacOS users) and not to delete all lines. ChatGPT basically provides code that would delete all lines. It removes all references to offset, again a standard way to get all lines in a List that have received the swipe action. Warning bells…

I then tries to use it for some stylistic support. I am not the best designer around, so I always need help to come up with visual elements that are more appealing. So my next request reflected this.

This resulted in some suggestions which were clearly generic but applied to the code at hand. So, this could be quite useful to try out.

The suggestion is debatable, especially if there is little screen real estate available, but is a legitimate one.

This is really generic, but in this particular case it might work, given that the icon used is a question mark and can be in a rounded button for sure.

This is indeed a good suggestion, but eventually one has to check the aesthetic appeal of the final result.

This is indeed a good suggestion and can be used on MacOS.

These are also interesting suggestions to try out. I’ve also noted that it provides explanations for the reasons for each snippet it suggests.

I am more hopeful about stylistic suggestions, but I suspect ChatGPT might be missing the context in large codebases. However, this is my first foray into coding with an LLM and I will certainly experiment with it further and will report it later.

Subscribe now

Apple has released new developer betas (Beta 2) for iOS 18.2 and MacOS 15.2 last week. After the lukewarm reception of iOS 18.1 and MacOS 15.1, due to the fact that there are only a few Apple Intelligence features, the next batch of releases delivered some neat AI stuff. I covered these in two posts the last two weeks.

One of these neat AI features is the release of the Image Playground application. This is basically an image generator built on top of an on-device model (a diffusion model). The model can only generate animation and illustration styles for the time being, but my expectation is that this will change in the future.

I wanted to find out what we can do with the image generation model through the use of the Apple APIs.

It looks like Apple has released a new Image Playground API with this new beta. Since I am a SwiftUI developer, I am familiar with how to use this in SwiftUI code, but I’m sure the same can be done with UIKit-based (or AppKit-based) code as well.

What I had in mind was a simple one-screen application that lets the user provide textual prompts and generate images with the on-device model that Image Playground uses.

When Image Playground was first launched, I had to put my name on a waiting list and until that request was approved, Image Playground just told me I was on a waiting list and gracefully exited. Once I was approved, I was able to use Image Playground.

Apple has done a good job in providing this API (ImagePlayground) to the developers. I also realised during this coding session that the whole Image Playground functionality was basically captured in a simple API and the Image Playground application we saw consisted of a single call to the API. We’ll look into this in a minute.

I started by creating a SwiftUI application. I did not want any storage at this point, so any generated images will not be saved.

One thing we must first do is to check whether ImagePlayground is supported or not. As you will recall, Apple Intelligence features are supported on iPhone 15 or above, MacOS with an Apple Silicon chip and on iPads with Apple Silicon chips. This is the first availability check. ImagePlayground is available on iOS 18.2 or MacOS 15.2 beta versions. This is the second availability check. If your device and OS to run this application fits the description, then the environment variable shown here (supportImagePlayground) will be set properly and you will be able to use the API.

I defined a prompt variable (promptText) that will store the user prompt and gave it a default value. I also defined two optional variables to store the generated image and the URL where this generated image is stored by the API. showGeneratedImage controls when the ImagePlayground interface is going to be activated.

I wanted to define a very simple interface which consisted of a VStack storing all the elements on screen. I put a title declaring that this is the Image Playground Test application. Then I put in a label for the prompt and the input field for the prompt with a TextEditor structure enabling the use of long, multi-line prompts. I also appended the TextEditor with a .writingToolsBehaviour modifier to enable the use of Writing Tools, as it is a good idea for prompts. This would even give us ChatGPT support, enabling much more complex prompts to generate the image.

Now we have to add the other interface elements. If the device/OS supports Image Playground then we define a button that will be used to generate the image using the API. We add the modifier to the button with two simple parameters. The first one is a Boolean which determines whether we should activate the ImagePlayground generation sheet (set to true whenever the user presses the button) and the second one passing some parameters already (in this case we pass the default text prompt).

If the device/OS does not support ImagePlayground, then we display a ContentUnavailableView to tell the user that ImagePlayground is not supported. If the sheet produces an actual image, then we set generatedImageURL to url which is returned by the sheet.

One issue I had was that I could not make this work on an iOS simulator. Although the simulator I used was an iOS 18.2 simulator with Apple Intelligence enabled, it did not have Image Playground and I did not see a way to force the simulator to download it (most likely because we do not go through the waiting list etc. for the feature to be enabled). In this case the application, as expected and programmed, displayed a warning that the feature was not available.

This next section covers the display of the generated image. We get the image from the URL and display it on screen.

The activated sheet basically has the full ImagePlayground application interface. We can update the generated image by providing additional prompts (in this example I added skates and Santa clothes).

Once an image has been selected, it is returned from the API and can now be displayed on the application screen.

I also noticed that any image generated through the API and returned to the main application gets stored, so that the Image Playground application itself will also have the images. Thus the API not only gives you the functionality, but the storage (through iCloud) for the generated images.

Exporting the Image

Now we attempt to export the image generated through the API. It is already on screen, displayed by the ASyncImage call.

An easy way to export images (or other documents) to the iCloud Drive is to use the FileDocument structure available in SwiftUI. I need a subclass of FileDocument that can handle images.

ImageDocument handles jpeg images. You see some code variant on whether we run iOS or MacOS.

The only thing we have to implement is the initialiser which basically prepares the data and puts it into the required variables inside the document structure and a fileWrapper function which actually writes the image into the file (in jpeg format, in this case). We define an array of these structures, although we will export only one image at this time.

Using this structure, we will add the export button and the functionality to the main code. We group this export button with the AsyncImage previously implemented, in a VStack.

If there is a valid URL, then we display a button to export the image. When the user presses the button, we invoke exportImage (shown below) and use the .fileExporter modifier that will export all ImageDocument structures (prepared by exportImage, but in our case there is a single image).

The export is done by using the url once again to get the contents and convert to a generic Data structure, then converting to a UIImage and adding it to the ImageDocument array we have declared earlier. (We would need something similar using an NSImage under MacOS).

I believe this API will be improved in future releases, along with the improvements in the Image Playground application itself.

Subscribe now

TabView

Another change with TabView is the way a TabView can be constructed. It has a simpler syntax and more customisation opportunities now.

In Tab mode, you get the requested items at the top in a row.

In Sidebar mode, you get the tab items with the assigned images on the sidebar.

If you want to add a Tab with the Search function, it is now very easy to do, namely by adding a specific role for the tab.

It is now possible to create sections when there are many tabs, to group the tabs.

This will result in tabs grouped in sections on the sidebar.

I had a problem in that using sections on the iPad resulted in all but the first tabs in each section to disappear when on Tab mode. This could be a bug on the Beta.

As usual none of this will have any impact on the iPhone where there is no sidebar. On MacOS, it is always in sidebar mode.

Subscribe now

I’ve started watching the WWDC 2024 videos, after I watched the Keynote and Platforms State of the Union presentations. There are significant changes to programming for Apple devices, even with the lack of AI-related features yet. Since I mainly develop with SwiftUI with Xcode, I will cover some of these changes - as relevant to my own development - in this post after trying the Beta versions.

SwiftUI - Sheets

One of the announced changes to SwiftUI was the handling of sheet sizes when using the .sheet modifier in any SwiftUI View. Sheets are views that come on top of other views with the intent of performing some additional work without losing where you are in a list or within another view. Previously, the .presentationDetents modifier was introduced and this enables the developer to select the relative size of the sheet that pops up, with .medium, .large and other complex modifiers to determine how large the sheet can get and whether the user can resize the sheet etc.

Apple has now set some default values for sheet sizes stating with the new releases and suggests the following (from iOS 18 and iPadOS 18 release notes):

SwiftUI sheets presented with the .sheet modifier now use .automatic sizing by default. .automatic resolves to .form or .form.fitted(horizontal:false, vertical: true) depending on the platform (see the symbol’s documentation for more). Platforms prior to iOS 18 and aligned releases used different, non-customizable default sheet sizing. iOS 17 and earlier used what is now called .page presentation sizing. macOS 14 and earlier used what is now called .fitted sizing. visionOS 1 used .fitted sizing. When linking apps against iOS 18 and aligned SDKs, audit your sheet presentations and pick the sizing best for you. Apply a .presentationSizing modifier to sheet contents

An example of this would be the following code. One can use .page or .form with the modifier .presentationSizing depending on how big a space they would like the sheet to occupy on the screen.

One issue I found was that when I re-compiled my book management application for iOS, my edit sheet just did not appear (apart from the buttons) on my iPad. It worked properly on the iPhone.

Once I added the presentation sizing, the sheet appeared with its designated size. I must note that this was not the case for all of the sheets I had, so I think this may be a beta issue.

Button defaults

I’ve noticed an unannounced behaviour change for SwiftUI buttons. I typically use a Save-Cancel button pair for editable views as seen in the code below:

The ‘Save’ button does some management of information on screen before saving and the ‘Cancel’ button typically dismisses without saving and does a rollback if necessary. The modifier .borderedProminent along with the button roles .destructive and .cancel makes sure that we have a prominent Save button (in red before iOS 18) and a regular Cancel button. See an example (with the buttons in Turkish corresponding to Save and Cancel shown in red and blue respectively)

However, this seems to have changed with iOS 18, as we see blue buttons for each case.

I haven’t seen an explanation for this but I’m hoping to discover the cause shortly.

TabView

TabViews can now use a sidebar for iPadOS, which can use the screen efficiently. The default for a TabView will be a tab floating on top of the view (also on iOS).

Changing this behaviour is easy. We add a modifier showing that this TabView is adatptable to the use of a sidebar. I also added a red tint, which you will observe to change most of the default UI colours to Red.

Now, this TabView can use a sidebar. The user has to tap the symbol that is leftmost on the floating menu to convert the view to use a sidebar.

This is now much more practical to use on an iPad. Note that this does work when run on an iPhone, thus the TabView stays as it is.

(to be continued…)

Subscribe now

onference will be Apple’s AI initiatives (I sincerely hope).

Apple has facilitated developers’ move from Core Data to SwiftData by providing some insights and they also note that “mixed mode” persistence, namely using Code Data and SwiftData side by side is possible.

I will look at some options in this conversion by converting a simple application.

This sample application has a single record of interest that is called Author, given that it is an authors’ database that the application is managing.

I created a Core Data project with the name Authors. Here is a snapshot of what the data design looks like.

As you can see, this simple table has an entity named Author, with properties named name, surname, birthyear, gender and a notes field. I set the entity with the option category/extension to be able to extend the Author class as required in code.

You can find the ContentView source partly below. It is a simple NavigationView with a list of authors displayed. When the user clicks on an author, then an EditAuthor view opens and enables the user to edit the data.

Running this and populating the data, we get a list of authors which are then stored in a CoreData database.

Let us now assume that we have a lot of authors in this database, say 5000. We want to transform our application to use SwiftData instead of CoreData. How can we do this without losing the data in our database?

We select the XCode model and go to Editor/Create SwiftData Code. We then see the list of all Core Data entities for which SwiftData code will be generated.

XCode then creates the Swift file(s) for the entities. In this case it created yet another Author.swift file which is the equivalent class for SwiftData.

Since this is the only thing XCode does for us to help this conversion, we still have a lot of work to do. We have to somehow populate the SwiftData database (which still has CoreData underneath with details hidden from us by the SwiftData layer) with the existing data.

Since we can not use the same name for a CoreData and a SwiftData class, we have to rename one. The easiest is to rename the new SwiftData class, so I rename it to AuthorRecord and provide a proper initialiser. While doing this, I also removed the optionals since SwiftData does not require them to be optional.

Now we add the initialization of the SwiftData model in the main application. Since we have only one class we only add AuthorRecord.

Now we can add a converter. I’ll do it by adding a button specific for this in the main view (ContentView). This button will trigger the conversion method (convert).

We import the context for SwiftData to the main view.

Here is what convert does. This view already loads all Author objects in CoreData. We then create a AuthorRecord object for each object stored in CoreData, copy all the properties from the old object to the new and save the new object to the new SwiftData database. In principle we do not need to explicitly save when we set the SwiftData database to have auto-saving. However, during my early work with SwiftData, I noticed that autosaving does not always work, so it is safer to actually do an explicit save.

Now we have the same data saved in the SwiftData database as well. However, our interface still uses the CoreData based data store. Thus we have to replace that part of the code to read from the SwiftData database. (By the way, if you do not specify any parameters when initiating the database, XCode uses an sqlite database stored as default.db).

We replace the FetchRecord structure in the main view with a Query macro used by SwiftData. It is much easier to work with objects with SwiftData, since we have simple arrays storing the objects retrieved from the database instead of complex structures like FetchedResults<AuthorRecord>.

With a few minor tweaks, we complete the code conversion, remembering to delete the full CoreData model from the XCode project. When we run the application, we have kept all of our data and work with SwiftData now.

,

Subscribe now

In this post, I’m going to cover how to convert text to speech, using the OpenAI API. OpenAI has developed two models for Text-To-Speech. These are tts-1 and tts-1-hd. The first one creates a lower-quality, whereas the second one can create higher-quality audio.

As I covered in earlier posts, there are some options the user can set for speech generation. The screen shot below shows these options (as part of the User Settings page).

The first option (model) lets the user to select one of the two speech models. There is a difference in quality and also the cost of generation. The Voice parameter lets the user select one of the preset AI voices that OpenAI provides. These are alloy, echo, fable, onyx, nova and shimmer. The last option is the recording speed, which lets the user record the generated speech in a speed that can vary between 0.25 and 4.0, where the higher number shows the faster speech. Default is 1.0, which is the normal speed.

This operation supports 57 languages and can generate in these languages.

When we select the Text-to-Speech operation we get a prompt window where we can insert the text to be converted into speech.

When you press the generate speech button, the application passes your text to OpenAI and generates the speech. The resulting window is something like what is shown below:

The generated audio record will be saved in a SwiftData class named GeneratedAudio as shown below.

As you can see, the audio is saved as a generic Data type in our data store. We also have to change the SavedChatLine class to make sure chat lines can store any generated audio files (here implemented as a relation).

For the time being, the speech endpoint only generated one audio file, but even if this changes in the future, our implementation will be fine since it can handle one or more audio files generated.

Here is the audio file that was generated from the prompt shown above.

When such a speech record has been generated we can export it to an audio file that can be exported. We do it via the - now familiar - .fileExporter modifier. We first define an AudioFileDocument structure to be able to use this modifier.

Now we modify the ChatLineView to be able to export the audio.

Let us see how we prepare the audio files to be exported by the .fileExporter. It is very similar to what we did for image files. For the time being we generate .mp3 files, but the OpenAI API supports “opus” for Internet streming and low latency; “aac” for digital audio compression preferred by YouTube, Android and iOS; “flac” for lossless audio compression; “wav” for the wav format and “ppm” to produce raw data samples in 24 KHz. We can support these additional formats in the future.

Let us now see how we send the actual request to the API.

We use the AudioSpeechQuery in the OpenAI API Swift package and use the model selected in the user settings, the text input given by the user, the voice selected by the user. We set the format to .mp3 for the time being. We also use the recording speed selected by the user.

When we get the response from the asynchronous call for audioCreateSpeech, the audio data is stored in the audioData property of the result if the query is successful. We then store the generated audio data in the chat line as a generic Data format. Thus the user can now see the generated audio data and play it in the chat line interface before deciding to save it or not.

This operation was made possible only after an update to the OpenAI Swift package in version 0.2.6.

We have a few more operations left from the OpenAI API to implement to get a full suite of tools, namely Generate Edited Image, Create Image Variations, Explain Image and a JSON request. I plan to cover these in some future posts.

In this post, we are going to look at how to take a speech audio file and either transcribe it to text in the original language it was recorded, or to translate its content into English.

First of all, let me note that the model we are going to use is “Whisper” which is OpenAI’s speech-to-text model. This model supports 57 languages.

The first thing to do is to get an audio file from the user, which is the case for both operations (transcribe or translate). We define a simple user interface that gets the file, a button that the user can use to listen to the audio file in order to prevent any erroneous uploads and a button that actually passes the audio file to OpenAI for processing. This code will be valid for both operations.

In order to do that, we use the .fileImporter modifier (similar to .fileExporter we used to export images)

This built-in SwiftUI modifier is triggered by a boolean variable that can be set up by pressing a button (loadingFrom File). The allowed content types for audio files are defined in the allowedContentTypes parameter and we can see mp3, mPeg4 Audio, WAV and a generic audio file as the options. We set allowsMultipleSelection to false, since we would like to process one file at a time. Also note that the audio file to transcribe or translate is limited to 25MB in size.

Let us see what the UI looks like on an iOS version of the application.

The user selects a file by pressing the button with an audio symbol on it. The application displays the file system (from iCloud).

If the user selects a file, then we get a list of file URLs and process them one by one. (We can only have one URL in this case). We get the selected URL and ask the user to confirm we can work on local or iCloud files through the startAccessingSecurityScopedResource call. The user only confirms once when this operation is attempted, then no more confirmation is required in subsequent uses of this function. If the approval is there, we get the contents of the audio file into a Data (generic) structure. Once this is done we release the file by calling stopAccessingSecurityScopedResource. We then pass the name of the file to an AudioPlayerViewModel that can be used to play the audio file, as the name suggests.

Once the user presses the Transcribe button, the application sends the audio file to OpenAI and displays the transcribed text.

Let us now look into how we pass the audio file to OpenAI. We use the AudioTranscriptionQuery structure and populate it with the audio data, the name of the file, the speech-to-text model.

Audio Translation is similar, in the sense that it gets a file name using the same .fileImporter modifier and passes it to a function for translation as seen below. The query used is the AudioTranslationQuery.

Text-to-Speech is somewhat different, so I will cover that in a future post.

To take the resulting text from the application, we do not have to do anything. We marked these selectable using the .textSelection(.enabled) modifier for text fields that we want to copy out.

However, for images, we need an explicit implementation. To do that, some refactoring is necessary. We first rename RunChatView within ChatListView to ChatDetailsView to reflect its proper function.

We will also revise ChatDetailsView to make sure it supports different actions. The OpenAI API supports chat, image generation, image editing, image variations, image explanation, speech generation, speech transcription, speech translation and “create JSON” modes.

We define an enum type ActionType that defines these different modes OpenAI API supports. We also use an ActionGroup type to group similar actions (e.g. image-related actions). ChatDetailsView will be our main view to select and execute these actions based on user selection.

The VStack in this section encloses the List which shows all the previous chat lines and then also the ActionView which will show the action options and will let the user select the action to perform, as seen in the screenshot below.

If “Image Actions” or “Speech Actions “ is selected, there will be a further selection of the possible actions in that group.

Let us now cover what is displayed in the ChatLineView. This view displays what was previously generated in that particular chat session

.We define an array of ImageDocument objects that will correspond to each of the generated images from a particular chat instance. Depending on what image model we use, we can have one or more images generated. With dall-e 2, we can generate between 1 and 10 images per chat prompt. However, please note that the number of images allowed depends on the rate limits OpenAI imposes. The first level allows up to 5 images at a time, so unless you’re using the OpenAI API a lot, you should stay at a number up to 5. If you’re using the more advanced dall-e 3 model, that only allows 1 image at a time. The Details button here is used to display some additional information about the chat line in question. An example is shown below.

When we are exporting generated images, we would like to store them to any location, but especially on our iCloud drive, which would be more suitable to store big files. Thus we use the .fileExporter modifier in SwiftUI.

If the chat line has generated images, then we present a button that allows the user to select the location to store the images. The .fileExporter modifier will store all selected image files in the array in the parameter documents. In this case, we are processing and preparing the images to be stored using the prepareImages method.

We loop over the generated images in the chat line and take each image, convert it to a UIImage, using the conversion from Data (stored in the memory objects for images. We remove special characters from the string to be used and use it as the document title. Then we create an ImageDocument using this title and the UIImage we created. Then we add the document to the allImages array. Once all images are added to the array as ImageDocument objects, fileExporter opens a dialog to let the user select the folder to save the images, then saves them to the selected folder (typically an iCloud folder and best of all, does this asynchronously in the background.

Lastly, let us look at the ImageDocument object that is used to store the images. It is a subclass we created, subclassing of the FileDocument class, which is a generic class that is used by file exporter (and fileImporter) to export any file.

We’ve used jpeg as the format for the image files, of course you can modify this for other output formats you may want. The only critical code here is the fileWrapper function which basically wraps your specific content to a FileWrapper object that fileExporter would recognize. We generate the wrapper by taking the image in memory stored in generic Data format, converting that to jPeg and using the title generated as the file name.

The images are displayed on the screen using the ImageGallery view just below the Prompt and Response fields we use for a general chat line. This is a quite straightforward view which displays all generated images on a horizontal scroller. Below you see this gallery from an iPad version of the application for better viewing.

In this post, we’ve looked at exporting images that we have generated in an OpenAI chat and storing them somewhere, most likely our iCloud drive. We will look at other action types in future posts.

I will implement UserSettings, which will store OpenAI parameters and use them in chats and image generation.

The first thing to do will be to define a class to store user settings. This will be an observable class so that we can trigger automatic UI updates when any of its properties change.

The first three settings correspond to the OpenAI models to be used for Chat, Image Generation and Speech Generation. OpenAI uses string variables for model names. The numImages parameter defines how many images should be created in a single prompt. The imageStyle parameter defines the style to be used in image generation, which can currently be either vivid or natural. The imageSize parameter shows the resolution of the images to be generated. The voice parameter shows the name of the voice to use in speech generation. There will be other parameters for other action types we will possibly cover in future posts.

We would like to store the user settings so that they survive between launches of the program and that they can be used across different devices. NSUbiquitousKeyValueStore is the key store to use for this purpose. We first check whether a setting for the chat model exists. If not, this means we are running the App for the first time, so we set defaults for each of these parameters. If this setting exists, then we read the setting and all the other settings from the key store and populate the properties of the class.

The userSettings object can be saved to the iCloud key-value store, thus enabling the sharing of the properties on iCloud.

This is all good to set defaults and save the settings, but we should now allow the user to edit these settings. The view OpenAISettingsView does exactly that. We create a copy of the user settings (which reads the latest saved values from the iCloud Key-Value store. All parameters will be in a form. Chat model selection is done through a Picker which has all the relevant values of OpenAI models that can be used for chatting.

The next set of parameters is about image models and number of images. The allowed image generation models are DALL-E 2 and DALL-E 3. We also make sure that the number of generated images is set to 1 for DALL-E 3 and can be set to a higher number for DALL-E 2.

The next setting is about the image style, which we get from a picker with “vivid” and “natural” as choices. The image size can have two sets of values depending on which image model we use.

The last two settings are about the speech generation model and the voice to use for speech generation.

When we use this code, we can see all the settings in a form and save revised values to the iCloud Key-Value store.

Since we can now use userSettings to store all settings, we should use it in our generation process. We revise ExecuteChatView to reflect this.

Here is what the Chat screen looks like:

When we type a prompt and send the text to chat, we use a revised version of the performChat function. It uses the chatModel parameter from the user settings.

For image generation we have more settings to use.

We use the imageModel, numImages, imageSize, imageStyle parameters when sending the query. We use the following screen to provide a prompt and to get an image back.

In subsequent posts, I will show how to save the generated images to your iCloud Drive and will also cover other actions such as Generate Edited Image, Speech Transcription and so on.

Let us first see how we will display chats when we have the options to have a textual chat and image generation. An individual chat is executed in RunChatView and can be seen later in the same view after the execution is done since all chats and chat results are saved. Here is a revised version of the view that includes images as well.

Apart from the textual display of the prompt and the possible textual display of the result, we also display any images that might have been generated, stored in chatLine.generatedImages. Any image stored there will be saved as data (Base64 encoding) and will be converted to a UIImage to be displayed through Image.

OK, now let us look at how to generate the image. We use the same interface but there is a separate button for the image generation, as shown in the code excerpt below.

Like most OpenAI API calls, the image generation call is also asynchronous, thus we wrap the action of the button within a Task block and run it asynchronously. The man functionality is captured in generateImage.

We prepare an ImageQuery structure (in contrast to the ChatQuery structure we prepared earlier for textual chat). I’ve used the DALL-E 3 model and used Base64 JSON as the image format, 1024x1024 as the size and “vivid” as the style. I found the OpenAI Swift package documentation as well as OpenAI’s API documentation a bit lacking and I had to do some trial-error to get the right approach. Once the query is executed, we get the results in the ImagesResult structure. The image is retrieved from the result in Base64 JSON format and is converted to generic data, which is then stored in our ChatLine structure. This code can be improved by making parameters user-selectable (e.g. using DALL-E 2 which is half as expensive to use etc.).

Once we run an image generation query, we can see the result on our Chat window.

This is a simple implementation of the image generation function. In the next post, I will implement the Save To File option to get the generated images to a file on the iCloud Drive. I will make some of the parameters user-selectable. I will also make sure that if more than one image is generated (e.g. when using DALL-E 2) all images are displayed and can be saved.

OpenAI’s Large Language Models (LLM) and the chatbot using these models (ChatGPT) have been the latest hype in the AI world, with lots of applications being developed to use these models.

OpenAI has an API that enables the use of these models and several open-source efforts have been launched to support the API in Swift. I’ve been able to use two such open-source libraries for a very simple application having a dialogue with OpenAI models through the API.

The first of these open-source libraries is OpenAISwift by Adam Rush. I found this to be quite easy to use, but had some problems with the GPT-4 based chat interfaces and also noted that the last time it was updated was around July 2023, namely before the final version of ChatGPT 4 was released. It seemed to be missing some of the newer interfaces.

The other open-source library to use ChatGPT with Swift is OpenAI by MacPaw. This library is a collaborative effort and has been updated recently, so I preferred to have my implementation using this one.

OpenAI has several endpoints for its API services. Some of their earlier models (e.g. GPT3.5) use the completions endpoint which allows you to provide a textual prompt and give back a textual answer. However, this endpoint is no longer used for GPT 4 and higher models, so we switch to the chat endpoint.

First of all, let us talk about the API key. Any application using the API needs a key to be pre-created and used in API access. Although ChatGPT 3.5 is free to use for the end user, the API is not free. You need to get an API key and load some credits to your OpenAI account (earlier, OpenAI used to give some free credits to each user when they first opened the account, but due to extensive demand, this is no longer possible). API use is per token, both on the input and on the output side. You can find some API pricing figures below. Note the pricing for text use of the API is per token, not per word. On average, a token count of 1,000 equates to about 750 English words.

One thing to keep in mind is that an API key that you would include in your application simplifies the process since it allows the end user to use your application without worrying about API keys and so on (I’m assuming you will charge the user for your application and/or for their use of ChatGPT or DALL-E). However, this creates a security risk, since it is relatively easy to get the API key from the application using certain tools. All charges will be done based on the key, so it is not a good idea to keep this key openly in the code of the application. We will follow up with several strategies for keeping your API key secure in a future post.

I had already got my API key from OpenAI and attached it to a global variable in my application.

I then initialise the API at a convenient place, before we run the chat interface.

I want to save any chats that I perform, so the first thing is to define the classes that would be used to save the chats. I will use SwiftData for persistence.

A saved chat record will consist of a single Chat object which stores one or more ChatLine objects. You will see the variable chatLines that shows the relationship between a chat and its lines. Each ChatLine is a prompt-response pair which shows the input and output of the chat. You will also see an array of generated images, which will store any images we will generate through a Chat, to be covered in a future post. We will concentrate on the textual chats first.

A simple navigation stack with a list of chats in it. The user can click on one of the chats to go to the RunChatView to continue any dialogue already executed before. The variable chats is queried through a SwiftData @Query statement so that previous chats are loaded when the application is launched and the ChatListView is displayed.

Let us now look into RunChatView, which will do the API work.

This is another navigation stack which displays all the chat lines for the particular chat in a vertical structure, with the prompt and result. The bottom of the page has a text field to get the user’s prompt and a button to send the prompt to GPT-4. Note that the button uses the Task statement to make sure it can run an asynchronous method. There is another button to generate an image, which we will cover in the future.

Since the API for Chat is asynchronous, we have to define an asynchronous function that will interact with the API. try await performChat does the asynchronous call.

While implementing performChat, we will need to create structures that will be used in the OpenAI API first. A ChatQuery (as defined in the OpenAI Swift Package) is a query structure we initialise with the model (we select .gpt4 here) and one or more messages in an array. Messages have a role and content (text), so we can prepare multiple messages with different roles (.system, .user, .assistant for the three chat roles and .function for function calling). But in this first sample, we will only prepare a single line, thus we put the text typed in by the user as the content for the single message.

Then we asynchronously call the openAI.chats method to start the chat and obtain the result. We then create a chat line, put the result (answer) in the chat line and add the chat line to the SavedChat object. SwiftData saves automatically, so we do not have to save explicitly.

That’s all there is to it. Once we use this, we will get the questions and the responses, to be saved for future reference.

In future posts, I will use the generateImage API call and see how we can save or exploit the generated images. I will also try to improve the user interface to make it more usable.

.

I had described a way to do effective search/filtering on SwiftUI applications using CoreData, then I applied the same principles for SwiftData. However, I noticed a few issues and searched for a way to optimise these.

I had defined a list view displaying dictionary entries, as shown below.

The query is executed automatically as this view is launched and all retrieved objects are put into an array called entries. The state variable wordFilter is used to dynamically filter items based on their names. We accomplished this by attaching a .filter closure to the collection entries.

The main problem with this approach is that the entries collection is retrieved once and filtered as the user types, so the list only shows the entries that satisfy the filter criterion and as such there is no direct way to find out how many entries are shown on the view. If this is part of the information we want to display, then we have an issue. It is possible to fix this problem by using an intermediate collection that contains only the filtered items.

Typical handling of CoreData objects in a list view is to include a static FetchRequest that will fetch all (or a filtered subset of) objects and would also dynamically change based on some state variables. Here is what it would look like for the Recipe class:

The corresponding SwiftData implementation is seen below.

CoreData uses the ViewContext (passed to relevant views in an environment variable) to create/update/delete objects. The static @FetchRequest statement defines a query that will be automatically executed when the view loads. The result is a FetchedResults collection which stores the retrieved objects. It is also required to define the sorting rule for the collection.

In contrast, SwiftData uses the ModelContext and the result of the query is an array or set of objects.

Creating and Saving

While creating an object to be persisted with CoreData (so, a subclass of NSManagedObject), we have to pass the context to the initialiser so that CoreData can already add the new object to the context (viewContext).

However, in SwiftData we do not need to pass the model context to the initialiser and would have to insert the object to the model context after it has been created.

One major difference is that you do not have to explicitly save the model context in SwiftData, since SwiftData saves automatically when required. This sounds tricky but I have not yet seen any drawbacks.

Observability

When we define classes with CoreData, we make sure these inherit from NSManagedObject. This allows us to deal with them using CoreData methods. Codable is a protocol we would frequently need classes to conform to.

When we move to SwiftData, objects no longer inherit from NSManagedObject. We can keep them at root level and annotate them with @Model and we can still use Codable if required.

There is an invisible benefit to using SwiftData. @Model also makes the class that it annotates to conform to Observable.

Under CoreData, objects can be passed to views in different ways. One way to do this is to pass the object with the @ObservedObject qualifier. The calling view would pass this as a parameter.

It also acts as a state variable, so any changes to the object would trigger updates in the view, if there is any part of the view dependent on the object. It would also be possible to pass this object further down in the view hierarchy or use it in any function that requires a binding to a state variable.

Since recipe is an ObservableObject, it can be passed to any view that requires a binding, using $recipe.

With SwiftData, there is no need to declare ObservableObject since all SwiftData objects are observable. However, if you need to use a binding with the object then you have to declare it as @Bindable. If the passed object is going to be used as read-only in the view or does not need a binding, then you can leave out the @Bindable marking.

Future

I expect Apple to introduce more API elements for SwiftData in the future, thus enabling developers to fine-tune queries or optimize retrieval for SwiftData-persisted objects.

I have not yet attempted to do SwiftData queries in a separate thread, but that is already possible with the ModelActor protocol, but I have to yet try it out. I expect optimisations in this area as well.

As to usability, I would say there is still a risk in full conversion of existing applications from CoreData to SwiftData, as it is a quite early implementation, but I would seriously consider using SwiftData in new development.

SwiftData as a replacement to Core Data

I have been using the Core Data framework for persistence on my iOS/macOS projects. Core Data is an interesting framework that links the Object-Oriented world within an application’s memory with a database or other data store to provide persistence. It is a tricky framework to learn, especially dor developers who are used to relational databases. Queries in Core Data do not use SQL or similar relational database languages but they have their own optimisation mechanisms. Apart from the bias towards relational databases, the difficulty with Core Data is that it needs a lot of setting up and using object classes to be used with Core Data puts a lot of burden on those classes/objects.

One positive side of Core Data is that - although it has originally been developed with/for Objective-C - it works well with Swift. The initial implementations of the declarative SwiftUI framework also worked well with Core Data, but it was tricky to dynamically change queries/filters with changes in the data. The SwiftUI Core Data interface has also been improved/simplified in the last few releases, but it is still an adventure. Thus some developers prefer other persistence libraries

Apple announced the SwiftData framework as part of the Xcode Beta development environment released with the first Beta of iOS 17 / macOS 14 as a much more usable persistence framework. I have followed the presentations about SwiftData at the World-Wide Developers’ Conference held in June 2023 and have done some test programming since then. As expected, the Beta releases for SwiftData have been quite buggy and it was difficult to attempt to convert a reasonably big program from Core Data to Swift Data. What caused the problems for me in Betas 1-7 was mostly to do with making the object classes to conform to the Codable protocol (e.g. for encoding/decoding objects to JSON) and using SwiftData with CloudKit (so as to be able to replicate the user data/databases to other devices through iCloud). Since most of my programs used CloudKit and also needed encoding/decoding with JSON, I was not able to much useful stuff. Beta 8 of iOS/MacOS changed all that, since most problems were resolved. I then attempted to convert a Diet Diary application that I am developing now from Core Data-CloudKit to SwiftData-CloudKit.

This article shows what I had to do for this conversion. I have been able to make the application work with SwiftData with minimal issues.

Caveat: Apple has sample programs explaining how to do this. One of their suggestions was to do the transition gradually, since Core Data and SwiftData can co-exist in an application. I did not follow their advice. I wanted to see how I can forcefully convert an application. I also did not have any issues with losing data, since my application is far away from release.

Subscribe now

Converting the Data Model

Core Data uses a separate Core Data model file (.xcdatamodeld file) in an application for the definition of all classes and their properties. We can let XCode generate all the Swift code from this model, but usually there will be need to add additional methods and non-transient properties, thus we typically extend the basic class Core Data generates.

You can see below a Recipe object model with attributes and relationships to other objects. XCode creates a Recipe class and populates it with all the attributes seen here. You can then populate a separate file with an extension to Recipe and add other attributes or functions.

Here I must note that there are some extra restrictions imposed by the CloudKit library. Since we would like all user data to be replicated to all devices for the same user (effectively a copy of the database on each device, to be synhronized when one of the databases changes). CloudKit requires all attributes to be optional. This creates a bit of difficulty in coding since we have to take care of the optional attributes constantly. I usually solve this by providing new computed properties in the class extension. For example, if longdescription_ is an optional string in the database, we define a computed property called longDescription which always returns a string, albeit empty. Thus it is easier to use this layer of computed properties instead of the original ones CoreData/CloudKit forces us.

One other complication is that CoreData requires us to state the properties of integer attributes, namely integer 16, integer 32 etc. to show the number of bits. This adds a layer of complexity since Swift is a strongly typed language and requires explicit conversions from one type to another.

This CoreData model will be converted by declaring the class and variables as they are represented in memory and annotating them with the new @Model macro. Let us look at what the Recipe object looks like under SwiftData.

@Model declares that the class it annotates should be persisted with the SwiftData mechanism. I’m using final in order to make sure this class will not be sub-classed, since SwiftData does not seem to be allowing inheritance at this time.

CodingKeys is used to develop custom encode/decode functions for the Codable protocol, I will use this to provide JSON import-export.

All attributes are just declared normally, but they have initial values. (This seems to be a SwiftData requirement.)

Relationships to other objects are declared via attributes and annotated with the @Relationship macro. I tried to use the .unique keyword for some of the attributes, but at this time it is not supported, so I introduced UUID attributes to classes that I wanted to be identifiable for SwiftUI views.

One-to-many relationships can be defined by making the attribute a collection (I used arrays). Many to many relationships are also possible by declaring the inverse of a relation as a collection.

SwiftData-CloudKit combination also forces us to declare all relationship attributes as optional.

Let us now check the RecipePhoto class to see how the relationship photos is matched in that class.

As you can see, we do not have to repeat the @Relationship macro for the inverse relation, since SwiftData takes care of it itself. So owner becomes the optional inverse relation showing which recipe this photo belongs to.

One improvement is that we can use normal swift attributes like Int instead of explicit sizing for CoreData attributes.

One problem you have to plan for is the fact that the structure of the class and the attributes will inevitably change and the backups (e.g. in JSON) may not be possible import, so be ready to convert existing data explicitly by letting CoreData and SwiftData co-exist in the transition period.

SwiftData setup

The whole Persistence code used by CoreData can now be removed from the project. SwiftData requires us to declare which objects will be persisted in the SwiftData container in views that require them. I preferred to do this in the application by passing this as an environment variable to ContentView, which is the root for all other views in my application.

We can change some of the features of the model container storing the objects (such as making it an XML file, setting its name etc.) but I used the default format, thus objects will be persisted in an SQL file named default.store. This will also be synchronised to other devices of the same user if they have this application installed. The name of the iCloud container to be used for sharing is defined in the iCloud Container Identifiers entitlement.

(to be continued…)

Apple has introduced a new framework named SwiftData with the Beta version of iOS 17. I have been monitoring it and writing some sample programs with it, but until iOS 17 Beta 8, it had too many problems to be seriously considered. With this Beta version, I found SwiftData to be a viable framework and I have converted a couple of applications from CoreData to SwiftData successfully.

I will publish an article on how to do this conversion, but just to complete our series on the use of .searchable, let us proceed. It turns out to be much simpler than the Core Data case. Here is what the code for the data object looks like:

The data to be persisted (in this case a class named Entry) is wrapped with the @Model macro to declare that SwiftData has to persist it. The rest is quite simple, you declare variables as you would in memory and SwiftData takes care of it. The storage is also taken care of by SwiftData, but we have to declare which objects we want to persist. We do it in the main program, but we could also do it in the relevant views.

This statement in the main application file is used to declare that SwiftData should arrange storage for an object called Entry. By default it is an SQL file called default.sql, but it is possible to use other alternatives.

Let us look at the list view that does the filtering.

Note that the environment variable that typically declared the ViewContext that CoreData uses to manage the transition between the memory is now declaring the ModelContext which does the same thing for SwiftData. The @FetchRequest macro is converted to a @Query macro for SwiftData and the resulting variable is an array in the right type, rather than a complex FetchedResults structure which is more difficult to process. Now let us check how the List looks like.

The filtering will be done by the use of the filter modifier that filters the collection (entries) based on the boolean condition in the closure. I had to use a conditional statement, since the filter did not take care of an empty filter case. The contains functions returns false when the parameter is an empty string, whereas I would expect any string to contain an empty string. Thus the need to separate that case.

The use of the .searchable modifier is simple, since it uses the binding to the filter variable.

One thing I did not mention is that you do not need to explicitly use the save function since SwiftData takes care of the right moment to save. So we just insert any new object to the modelContext, whereas updating is taken care automatically.

This is my first take on this with a Beta version of the software, but up to now I’m quite happy with SwiftData.

As you very well know, continuous improvement is a very important software concept and with the improvement in the operating systems continuously introduced, developers have to make the best of these improvements. iOS 15 came with a new version of SwiftUI which greatly improved things. The change that is relevant for this article is the simplification and expansion of the Core Data API for SwiftUI, which introduced dynamic changing of predicates and sorting criteria for Core Data queries on the spot.

I had covered an approach to enable the use of .searchable with SwiftUI in a previous article published on September 8 (link below)

Here is the revised, much simpler FetchRequest that is used to fetch all Entry objects:

As you can see, we do not have to explicitly define a Fetch statement or provide a predicate in this simplified syntax. (We completely remove the Fetch function). We provide a sort descriptor, stating which data field we use for sorting and whether the sorting is forward (ascending) or backward (descending).

Now we make a small change in the definition of the filter string.

You may notice that we changed the variable from a @Binding to a @State. We will be able to use this directly and thus no need to introduce this variable in the calling view (ContentView). Now, how do we make sure SwiftUI re-renders the view when the filter string changes? We do it by defining a Binding variable on this and dynamically changing FetchRequest parameters when that variable changes. Check the code below:

When filterString changes, this Binding is activated and it dynamically modifies the nsPredicate property of the FetchedResults variable entries. This triggers a fetch in Core Data and an updated list of objects are read and displayed. Obviously this is much simpler than the previous version. Similar changes can be made in sort descriptors as well (e.g. if there are sorting options on screen, changing these would trigger dynamic changes in the sort descriptor, which would trigger a re-rendering (but no new fetch). Also note that we define an extension to NSPredicate in order to be able to define our own predicate function that will provide the dynamic update of the query.

There is one small trick here. Since we can detect changes in wordFilter only through the Binding, we have to use the Binding on the .searchable modifier and not the original filter string (notice the lack of $, since this is already a binding variable).

As of iOS 17, previews are simplified through the use of a #Preview macro and as such require much less code. See below the old and new ways of defining previews of particular views.