Tabs

I’d like to share the code so anyone can add such shortcuts to their apps. It’s fairly simple. I needed to use two modifiers for this: commands and keyboardShortcut. I’ll come back to these, but let’s start from the beginning. To switch tabs, we need a TabView first. TabView in my ContentView looks like this:

TabView(selection: $appState.selectedTab) {
    Tab("Timer", systemImage: "timer.circle.fill", value: .timer) {
        TimerView()
    }

    Tab("Projects", image: "moons.project.done", value: .projects) {
        ProjectsView()
    }

    Tab("Time Entries", systemImage: "list.bullet.circle.fill", value: .timeEntries) {
        TimeEntriesView()
    }

    Tab("More", systemImage: "ellipsis.circle.fill", value: .more) {
        MoreView()
    }
}

As you can see, I’m using $appState.selectedTab as the selection. This appState is an EnvironmentObject of a custom type AppState - an ObservableObject I defined in another file. It looks like this:

final class AppState: ObservableObject {
    enum Tab: Hashable {
        case timer, projects, timeEntries, more
    }

    @Published var selectedTab: Tab? = .timer
//    ...
//    Some other properties I need for other shortcuts.
}

In the AppState class, I have an enum called Tab and a Published var selectedTab of type Tab.

Basically, every time user switches a tab in the app (by tapping or clicking a tab), the value of selectedTab changes: .timer for TimerView(), .projects for ProjectsView() and so on. You can see this value in the Tab part of the code I showed you earlier:

Tab("Timer", systemImage: "timer.circle.fill", value: .timer) { // <- here
    TimerView()
}

Commands

To enable tab switching not only by tapping or clicking on the tabs, but also through the app’s menu, I needed to add the commands modifier to the WindowGroup in the Scene of the App struct.

var body: some Scene {
    WindowGroup {
        ContentView()
            .environmentObject(appState)
    }
    .commands {
        CommandGroup(before: .sidebar) {
            Divider()

            Button("Timer") {
                appState.selectedTab = .timer
            }

            Button("Projects") {
                appState.selectedTab = .projects
            }

            Button("Time Entries") {
                appState.selectedTab = .timeEntries
            }

            Button("More") {
                appState.selectedTab = .more
            }

            Divider()
        }
    }
}

What is happening here… In the commands modifier, I’ve added a CommandGroup, which is a group of controls that appear in the app’s menu. Notice the (before: .sidebar) part - it tells SwiftUI to place my custom commands before the Show/Hide Sidebar and Enter/Exit Full Screen.

This group contains four buttons, with a divider above and below them. Each button updates the value of appState.selectedTab.

Here’s a comparison of my app BEFORE and AFTER adding this code:

As you may have noticed, the new commands now appear in the View menu (before the Hide Sidebar and Enter Full Screen, as specified). However, there are no keyboard shortcuts yet.

Keyboard Shortcuts

To assign keyboard shortcuts to commands, we need to add the keyboardShortcut modifier to each button in the CommandGroup. Like this:

.commands {
    CommandGroup(before: .sidebar) {
        Divider()

        Button("Timer") {
            appState.selectedTab = .timer
        }
        .keyboardShortcut("1", modifiers: [.command])

        Button("Projects") {
            appState.selectedTab = .projects
        }
        .keyboardShortcut("2", modifiers: [.command])

        Button("Time Entries") {
            appState.selectedTab = .timeEntries
        }
        .keyboardShortcut("3", modifiers: [.command])

        Button("More") {
            appState.selectedTab = .more
        }
        .keyboardShortcut("4", modifiers: [.command])

        Divider()
    }
}

Since the ⌘Command key is the default modifier for keyboard shortcuts, we can also write it like this:

.keyboardShortcut("1")

// Instead of this:
// .keyboardShortcut("1", modifiers: [.command])

With the keyboardShortcut modifiers, my commands now have shortcuts assigned to them:

Alternative code (Optional)

Your code may be simpler than mine. I’ve created my ObservableObject AppState for other reasons. For example, I’ve added keyboard shortcuts to create a New Project or New Task with ⌘N and ⌘T, and I have some conditional logic as well.

However, if your app is simpler and all you need are keyboard shortcuts to switch tabs, you can just use a State variable along with a Tab enum:

enum Tab: Hashable {
    case timer, projects, timeEntries, more
}

Since we want to switch tabs using commands attached to the WindowGroup, we need to have a selectedTab variable in the App struct:

@State private var selectedTab: Tab? = .timer

The commands in the App would use this State variable and look like this:

.commands {
    CommandGroup(before: .sidebar) {
        Divider()

        Button("Timer") {
            selectedTab = .timer
        }
        .keyboardShortcut("1")

        Button("Projects") {
            selectedTab = .projects
        }
        .keyboardShortcut("2")

        Button("Time Entries") {
            selectedTab = .timeEntries
        }
        .keyboardShortcut("3")

        Button("More") {
            selectedTab = .more
        }
        .keyboardShortcut("4")

        Divider()
    }
}

In ContentView, we need to have a binding to the selectedTab variable:

@Binding var selectedTab: Tab?

And the Tabview would look like this:

TabView(selection: $selectedTab) {
    Tab("Timer", systemImage: "timer.circle.fill", value: .timer) {
        TimerView()
    }

    // Other tabs
}

So basically, we would use $selectedTab as the selection, not $appState.selectedTab.

And you would need to pass selectedTab value to ContentView in your WindowGroup, like this:

WindowGroup {
    ContentView(selectedTab: $selectedTab)
}

And that’s it! Now you know how to add keyboard shortcuts and commands to switch tabs in your iPadOS or macOS apps 🙂

Thank you for reading!

If you want to support my work, please like, comment or share the article.
And most importantly...

📱Check out my apps on the App Store:
https://apps.apple.com/developer/next-planet/id1495155532

☕ If you like what I do, consider supporting me on Ko-fi! Every little bit means the world!
https://ko-fi.com/kslazinski

Making the app available on Macs is a simple process. The first step is to add the correct destination for the app target in Xcode:

1. Select the app target (in my case, Wins).

2. Go to General tab and the Supported Destinations section.

3. Click the plus button.

4. Choose: Mac / Designed for iPad (or "Designed for iPhone" if the app is only for iPhone).

Now when I select My Mac (Designed for iPad) as the Run Destination and run the app, I can see how my iPad app looks on a Mac.

Mac and iPad apps are not the same

Let’c clarify something - an iPad app on a Mac doesn’t look exactly like it does on an iPad. It looks very similar, but there are some differences:

• UI components are a bit different on macOS (Search, pickers, etc.)

• animations are different (openine and closing sheets, for example)

• colors (list backgrounds, for example)

While most colors look the same, I am using Color(.tertiarySystemBackground) as the background color for some UI elements in my app. Why? Because I needed a white background in Light Mode and gray background in Dark Mode and thanks to system colors it’s easy to achieve without defining custom colors.

But… surprise, surprise - tertiarySystemBackground on macOS is not white 😅

To fix this, I needed to conditionaly change the background color to Color(.secondarySystemGroupedBackground), which on macOS is white in Light Mode and gray in Dark Mode - exactly what I need.

But I’ve encountered a small problem…

How to conditionally change the UI on macOS

My first reaction was to use Swift’s compiler directive #if, like this:

#if os(macOS)
.background(Color(.secondarySystemGroupedBackground))
#else
.background(Color(.tertiarySystemBackground))
#endif

But… since this condition runs at compile time and the iPad and Mac use the same build in this case, it doesn’t solve the problem.

Another idea I had was to use userInterfaceIdiom:

var backgroundColor: Color {
    if UIDevice.current.userInterfaceIdiom == .mac {
        Color(.secondarySystemGroupedBackground)
    } else {
        Color(.tertiarySystemBackground)
    }
}

// And later use backgroundColor in the modifier like this:
.background(backgroundColor)

But again, this doesn’t work. When an iPad app runs on a Mac, userInterfaceIdiom returns .pad, which means that backgroundColor would always be set to tertiarySystemBackground, regardless of whether the app is running on an iPad or a Mac.

Fortunately, there is another option: we can use the ProcessInfo class to handle this. Here’s how:

var backgroundColor: Color {
    if ProcessInfo.processInfo.isiOSAppOnMac {
        Color(.secondarySystemGroupedBackground)
    } else {
        Color(.tertiarySystemBackground)
    }
}

// And later use backgroundColor in the modifier like this:
.background(backgroundColor)

And now, colors in my app look the same as I wanted on both iPad and Mac 😍

App Store Connect

The last step was to set the availability on App Store Connect. I needed to check “Make this app available” on the Pricing and Availability page, under the section iPhone and iPad Apps on Apple Silicon Macs.

After I checked the “Make this app available”, I also needed to click the Verify Compatibility button. The prompt says: “(…) If you've tested your app on Apple silicon Mac, and it functions as intended, verify it below.”
So, it’s up to the developer to test whether the app works as intended. If it does, we simply need to confirm that we have verified compatibility, which removes the “Not verified for macOS” label on the App Store that you may see on some apps.

I set my app’s availability after my new build with the color corrections was approved, and the new version of my app was released and… Voilà! My iOS and iPadOS app now works on Macs with Apple silicon and looks as intended. Next step: native macOS app! 😀

Thank you for reading!

If you want to support my work, please like, comment or share the article.
And most importantly...

📱Check out my apps on the App Store:
https://apps.apple.com/developer/next-planet/id1495155532

☕ If you like what I do, consider supporting me on Ko-fi! Every little bit means the world!
https://ko-fi.com/kslazinski

Let's say we have two Doubles and a total value equal to the sum of them.

let value1: Double = 1
let value2: Double = 2
let total = value1 + value2 // 3

Option 1

Now, if we want to check what percentage of the total is value1 and display this percentage in SwiftUI with 0 fraction digits, we could do something like this:

Text("\(String(format: "%.0f", (value1 / total * 100)))%")

Option 2

Since iOS 15, there is another way, though, and you may find it more readable:

Text((value1 / total).formatted(
    .percent.precision(.fractionLength(0)))
)

Both options will result in the same text:
33% (for value1)
67% (for value2)

As you can probably guess, to change the precision to display 2 fraction digits in your percentages, you can modify both versions of the code as follows:

Text("\(String(format: "%.2f", (value1 / total * 100)))%") // %.2f

Text((value1 / total).formatted(
    .percent.precision(.fractionLength(2))) // fractionLength(2)
)

When you display fraction digits, you will notice another difference between both methods. The first one will always display percentage values the same way, as it's a hard-coded format (for example, 33.33%).

The second one, using the formatted() method, takes the user's locale into consideration. So the percentage value may be displayed as 33.33% or 33,33%, depending on the locale. The same applies to other locale-specific rules, like grouping separators (e.g., "10,000" in one country and "10 000" in another).

This means that the second option is not only more readable but also a better choice if the app is localized, as with the formatted() method, all the values will be properly formatted based on the user's locale.

UPDATE: Option 3

After I published this article, Łukasz Rutkowski reminded me on Mastodon about another similar method (which also formats numbers properly based on locale):

Text((value1 / total),
    format: .percent.precision(.fractionLength(0))
)

If you know another way to display percentages in SwiftUI, feel free to share it in the comments.

Thank you for reading!

If you want to support my work, please like, comment, share the article and most importantly...

📱Check out my apps on the App Store:
https://apps.apple.com/developer/next-planet/id1495155532

☕ If you like what I do, consider supporting me on Ko-fi! Every little bit means the world!
https://ko-fi.com/kslazinski

Credits

Thank you to Arnaud Joubay and Avery Vine for your input on app localization, and to Łukasz Rutkowski for suggesting Option 3.

To clarify, here is how Apple defines this metric on the App Store Connect where we can run such tests:

"The estimated percentage of users who download or pre-order the app after seeing this variant of the product page."

This basically means that I want to improve Moon's Product Page so that more people download the app. Whether these people decide to pay for the pro features later is a different story. Here, I simply want to increase the number of downloads to have more potential customers.

Hypothesis

My idea is simple. I will add some cool new image to my product page to make my app stand out from the crowd. This image will resonate with users on an emotional level, inspiring them to achieve their goals and boost their productivity. This will result in increased downloads and, ideally, more paying customers.

Simple and brilliant and the question is not IF but HOW EFFECTIVE it will be.

Creative Screenshots

Apple calls them Screenshots on the App Store Connect. But in the context of App Store Optimization, they are often called Creatives. Basically, they are images people see when they are searching for apps on the App Store.

I decided to get creative with my Creatives 🙃 And here's the result: an astronaut on the moon, a few catchy marketing slogans and a glimpse of my app's UI in the foreground. Pretty cool, isn't it?

I wanted to include this particular image in my creatives. Here's a comparison between my Original Product Page and Treatment A (this is Apple's term for sets of images used in AB tests, which you'll see in the results later in this article).

Why does adding or changing just one image matter? Because users typically see the first three creatives for each app in the search results. Therefore, to improve the initial step of my sales funnel - the search results - I've decided to test these two variants:

AB testing on family and friends

I showed this new creative to some friends and people in my family. I heard things like:

"Smart marketing!"

"Great idea! It tells people that with your app they can reach their goals. And anything is possible, even landing on a moon."

At this point I am a creative genius! And people believe in my success. Awesome!

AB testing on Social Media

Right before writing this article I posted my creative on social media and asked people post-factum:

"Can you guess by how much adding this one image to my Product Page changed my Conversion Rate?"

iOS dev community is really great! Full of positive and supportive people. I got many answers with numbers between +7% to +500%. Here are 2 of the comments I really liked:

"(...) I think the impressions/downloads rate must have gone up dramatically.
Perhaps even a few hundred percent.
Because seeing a plain more or less standard iOS screenshot doesn't stop people in their App Store scrolling tracks."
(Wow! That's so aligned with my hypothesis.)

"I’d say it increased a lot and mostly by people that want to go to the moon.🌙😂"
(Positive and funny. I love it!)

AB testing on the App Store

Now let's find out how did the App Store test go. My AB test was active for 64 days.

Day 1

That's strange 🤔 Conversion Rate lower by 68.09%? But no worries. It's just one day. Not enough data. It will look much better soon ☺️

Day 7

See? 😀 I was right! After one week we have a nice improvement! +10.22% to my Conversion Rate and +10 my business skills.

One day earlier I posted my first results on social media:

"🥸 I don’t want to brag, but… I managed to improve conversion rate of my iOS app Moons by 8.78% with a… 0.1% confidence 😅"

I got a lot of support from my wonderful indie dev community. Likes, virtual high-fives. And I am sure that CEOs of big app companies were getting anxious at this point. That's one small step for an indie developer, one giant leap for the whole indie community!

But I kept testing... Because everyone ignored one part of my post:

"(...) with a… 0.1% confidence 😅"

Which basically means that I didn't have enough data yet.

Day 51

"😱Noooooo! My numbers are going down!"

At some point my Conversion Rate went down by 15.32%. Breath, Kris! Don't panic. Stay calm and keep going.

Day 64

Now that's not funny anymore! 🥲 After the initial spike there were small changes, but overall my brilliant and creative Creative (AKA Treatment A) performs worse than the Original Product Page.

I decided to stop the test at this point. Especially that I released new version of the app with new localization and new screenshots and this would only skew my results at this point.

Please note, however, that these results are marked as Inconclusive.

Apple says:
"There is not enough data to determine whether this variant performs differently from the baseline."

And I will come back to this later. But the main question is... What went wrong?!

Remember this one comment?

"I’d say it increased a lot and mostly by people that want to go to the moon.🌙😂"

This person predicted that I will have positive results, but maybe the most interesting part is this one:

"(...) mostly by people that want to go to the moon."

Maybe my creative image would work great for an Earth to Moon transportation company but not for a time tracking app? But that's not the only problem.

Problems with AB testing

Here are some key takeaways:

• AB testing on friends and social media will not give you accurate results
  Definitely do it! It's motivating. You will hear great ideas. Maybe you will learn from someone who already did some tests before. But you simply won't have enough data. And also your family and friends are very biased. They care about you and wish you well, so their decisions are often influenced by emotions rather than financial considerations.

• Confidence matters
  Don't ignore this metric. My Conversion Rate increased by 10% after one week, but then decreased by 10% after two months. And yes, I am aware that my results are inconclusive. With a confidence level of 5.8%, there is nearly a 95% probability that the final results could differ significantly.

• You need a lot of data
  And that's the main reason why I stopped the test. I can't wait another 6 months for conclusive results. I need to get more impressions first (for example, using Apple's Search Ads) and I may run the same test again in the future.

• Not every change is a big change
  I want to run some other tests and check if making other changes will be more impactful. The bigger the change, the less data I would potentially need.

• Marketing images instead of app screenshots may or may not work

  I need to experiment more with this idea. Whole concept may be wrong. Or just the photo should be different. Or the text/message should be different. We won't know if we will not try.

• Your results may be completely different
  Using the same creatives, the same images and marketing slogans you could see completely different results. Different app. Different audience. Different keywords. There are so many factors. The only way to know what works for your app is to test it.

• Your gut and your data are two different things

  Many people say that you should trust your gut. And I agree. You should definitely hire James Gut in your company. He's such a creative guy! But if you understand his strengths and weaknesses, you will put him in the Hypothesis department along with your family and friends. You want Stephanie Data in your Business Decissions department.

Thank you for reading!

I hope you found this article useful or at least entertaining. Please follow me for more tips on how to decrease your Conversion Rate 😅

And if you want to support my work, please like, comment, share the article and most importantly...

📱Check out my apps on the App Store:
https://apps.apple.com/developer/next-planet/id1495155532

☕ If you like what I do, consider supporting me on Ko-fi! Every little bit means the world!
https://ko-fi.com/kslazinski

After exactly 2 years I am starting to understand what’s possible and how much time and effort it takes. And I hope that with this article you will see this as well. Important note, though - condition of the app business depends on many factors. I personally know many indie app creators that are more successful financially but also many folks that are not there yet. But I will share some insights and maybe this will give you some idea how the financial part of making iOS apps looks like if you are an indie developer.

The product - my apps on the App Store

Shoutout to future me with his 100 apps on all Apple devices. Poor guy needs a whole month and 3 AI assistants just to prepare screenshots for all of this.

But luckily, right now I still have only 5 iOS apps. And here they are with release dates - so if you want, you can compare this to my Proceeds charts to see how each of the apps affected my revenue.

• Moons - Time tracking and project management
  November 10, 2023

• Wins - Setting and tracking personal goals
  April 12, 2023

• Numi - Expense tracker
  December 22, 2022

• Emo - Emotional inventory and journaling
  October 10, 2022

• Skoro - Scoreboard app for sports and games
  February 26, 2022

Sales vs Proceeds

All the screenshots you will see here are from Apple’s App Store Connect - a platform for app developers. Apple shows us a lot of data there. Two of the many metrics are Sales and Proceeds.

Sales - this is how much money your apps generated.
Proceeds - Sales minus some country specific taxes and Apple’s fee. For most developers this fee is 15% or 30% of your Sales.
So in other words, Proceeds is what you will actually get from Apple.

Because I want to show you my real revenue as an app developer, all the screenshots you can see here show my Proceeds, not Sales.

2023

I made $1.270 on my apps in 2023. For some it's a lot, for some it's not. I always remind myself that it's not a sprint but a marathon. I am just starting and it takes time. And while I am aiming for better results in 2024, I am happy with the results so far.

2022 vs 2023

To give you more perspective, this is how last year compares to 2022 when I started.

There is some progress here, right? But it doesn't look super constant. There are ups and downs. But you know what? Something that I learned after 2 years - you can't focus too much on the short-term results.

Let's zoom in for a moment to see how my daily proceeds looked like.

Looking at daily results you might think that I had a 1 great day. Can we stop for a moment here? I just want to say that I appreciate you, November 10 🙌 I wish more days were like you 😅

But even though not all my days brought $109, the long-term results are made of many many small steps. So let's zoom out to see my Proceeds per Quarter.

Looks better, right? If we zoom out even more and you look at Proceeds by Year, this progress looks even better.

Again - someone will say it's a lot. For someone else it's not much. If you are building your business, you need to remember exactly this - it's YOUR business. And only you can decide if it's good or not.

And you definitely need some patience.
Step by step. Ooh baby! Gonna get to you... wealth.

January 2024

2024 started really good for me. I reached a new record: $217 in one month. Which is slightly better than November 2023 (my previous best).

But again, it's important how you look at your data. If we compare January 2024 to January 2023, the situation looks pretty good.

Will my proceeds keep growing? By 271% again? Slower? Or maybe faster? I do hope. I am definitely very excited to see where my app business will be next year. But you know, I am a bit biased 😉

Costs

Let's talk about costs for a moment. Having only the proceeds part doesn’t tell you the whole story and I want to be very transparent here.

I didn’t spend a lot. I pay $99/year for the Apple Developer account, so it’s $198 for 2 years. (There is also a Free account, but to distribute apps on the App Store you need the paid one). I tried Apple’s Search Ads a few months ago, but I only used the free $100 credit you get from Apple when you create your Ads account. And I turned off the ads few days after I used the free $100 so I spent maybe $10 of my own money.

And that’s it. I decided to not use any paid APIs in my apps. And so far I am not outsourcing any design or developer work. This could change if I would make more money and have the budget for this, but I wanted to be profitable since day 1, so right now it’s just me.

Who and what helped me

But to make it a "build in public", not a "brag in public" article, I would like to share some general info who and what helped me to get to this point.

• iOSdev community - many people helped me with their advice, emotional support. Sometimes someone helped me with some code, often people were offering their help with localizing my app.
  I would like to thank everyone collectively. I always do this individually anytime someone helpes me. I definitely need to write a separate article about all of you folks, because I wouldn't be here without you ❤️

• #buildinpublic - sharing what you know and how you build your apps wth others is not just a great marketing but it's also a great networking opportunity and a chance to learn from others.

• ASO - researching keywords with Astro

• Localizations - I localized my apps to many languages. And my keywords to even more languages.

• New apps - everytime I released a new app, it boosted my sales. But I don't think it's very scalable. More apps doesn't neccesarily mean more money. There are pros and cons of having many apps and I think it deserves a separate article.

To be honest, all of these things need a more in-depth articles. And I will try to share more soon. If you are interested in any of these topics or have some other questions, please leave a comment or contact me directly.

What's next

As many indie creators, I would like to change my app business into a sustainbale one. My focus is still on building useful apps with the best quality and User Experience that I can deliver right now with the knowledge and resources I have. But to make it possible for the long run I need improve the business aspect of this.

Here are some of my ideas how to get there:

• macOS versions of some of my apps

• More ASO experiments

• Submitting my apps to be featured on the App Store

• Experimenting with business models of my apps

• Trying Apple Search Ads again

Thank you for reading!

If you want to support my work, please like, comment, share the article and most importantly...

📱Check out my apps on the App Store:
https://apps.apple.com/developer/next-planet/id1495155532

☕ If you like what I do, consider supporting me on Ko-fi! Every little bit means the world!
https://ko-fi.com/kslazinski

Renaming variables and constants in your code is mostly not problematic at all. But when it comes to creating your data model, it is good to plan ahead. While of course, you can rename your entities, classes and attributes later and migrate your data model, it's just easier if you use good names from the start.

Core Data entities and attributes

Let's start with an example of an app that helps you manage your trips when you travel. In most tutorials for Core Data and SwiftData, you will see the following convention:

• Trip - for a Core Data entity or SwiftData class

• attribute - an attribute of the Trip entity

• trips - a collection of objects of type Trip

• trip - a single object from the "trips" collection

That's quite simple for a single word. Titlecase singular form for entity/class, lowercase plural name for an attribute and collection and lowercase singular form for a single object.

Now let's say that in your app you have another entity/class for booked hotels. For names made of few words you would use this:

• BookedHotel - entity/class

• otherAttribute - an attribute of the BookedHotel entity

• bookedHotels - a collection of objects

• bookedHotel - one object

Same as before, but with a camel case for multiple words.

Knowing the conventions, I started to use them in my apps. And it mostly worked. Mostly 😅 But I ran into a problem very quickly with my first ever data model in my app Numi, a finance app for tracking expenses.

For one of the entities I created in Numi, I used the name Transaction. My code wasn't working as expected and I spent many hours on debugging. At the time, I learned that there were already some Structs with the same name. Two examples are:

• in Swiftui - https://developer.apple.com/documentation/swiftui/transaction

• in StoreKit - https://developer.apple.com/documentation/storekit/transaction

When I was creating a transaction object, Xcode was sometimes mistakenly assigning it to the wrong Transaction type. Most likely it was clashing with the SwiftUI's Transaction struct.

let transaction = Transaction(context: viewContext)
// Or...
init(transaction: Transaction) {

As Xcode didn't tell me what was happening, it took me some time to find what was the cause of the problem.

I tried a few solutions to fix this issue. And honestly, I forgot about some of them as they didn't work. What fixed my problem was very trivial. I simply added a prefix to my Core Data entities.

CDE prefix

Since the problem with Transaction, I started using the CDE prefix for all my Core Data entities. For example, I renamed the Transaction entity to CDETransaction and boom! Suddenly my code works without any issues.

You can use another prefix, of course. One example would be MyAppTransaction with a MyApp prefix. But it is not as clear as with the CDE prefix that MyAppTransaction is a Core Data Entity. And also, what if at some point you will need to change the name of your app?

You can see that Apple recommends a similar naming convention to my CDE prefix in this article:
https://developer.apple.com/documentation/coredata/adopting_swiftdata_for_a_core_data_app

For example, when they give us an example of Core Data and SwiftData co-existing in the same app, they are using the class Trip for SwiftData:

@Model final class Trip {

But for the Core Data entity, they are using CDTrip (with CD prefix), like this:

class CDTrip: NSManagedObject {

And later, for adding a new Trip:

let newTrip = CDTrip(context: viewContext)

How SwiftData changed my approach

During WWDC2023, Apple introduced SwiftData as a replacement for Core Data. After watching Apple's WWDC videos and reading some SwiftData tutorials, it looks like SwiftData is in most cases simpler to use than Core Data. But there are 2 problems:

1. SwiftData is not mature enough in 2023. Which means there is still some functionality missing. And also there are fewer tutorials and documentation than for Core Data.

2. SwiftData works only with iOS 17 and up. With most people still currently using iOS 16, choosing SwiftData over Core Data would significantly limit my potential user base.

What's great is that migrating from Core Data to SwiftData looks fairly simple, so I can use Core Data for now and migrate to SwiftData in the future when I decide to drop support for iOS 16.

But what about my naming convention with the CDE prefix? It looks like CDE wasn't the best idea, because after the SwiftData migration, the CDE prefix will not be very on point with SwiftData.

I want to avoid potential problems like I had with my Transaction entity, so I would prefer to use a prefix. Just not the CDE.

I decided to name Core Data entities in my new apps using the DM prefix instead. DM as in the Data Model, to make it less likely to introduce problems of having no prefix at all. And also to more clearly differentiate my Core Data entities from other Structs and Classes.

During future migration to SwiftData, I won't need to change the names of my entities and the DM prefix will be a better fit for SwiftData than the CDE prefix.

New naming convention

So to summarize, that's how I am planning to name my Core Data entities, SwiftData classes and attributes:

• DMTrip - entity/class in my Data Model

• attribute - an attribute of DMTrip in my Data Model

• trips - a collection of DMTrip objects

• trip - a single DMTrip object

And for multiple words:

• DMBookedHotel - entity/class in my Data Model

• otherAttribute - an attribute of DMBookedHotel in my Data Model

• bookedHotels - a collection of DMBookedHotel objects

• bookedHotel - a single DMBookedHotel object

I'm not claiming that this is the best naming convention, but based on my experience, it's something that works for me. It helps me avoid potential problems and clearly marks my classes as part of my Data Model.

Thank you for reading!

If you want to support my work, please like, comment, share the article and most importantly...

📱Check out my apps on the App Store:
https://apps.apple.com/developer/next-planet/id1495155532

☕ If you like what I do, consider supporting me on Ko-fi! Every little bit means the world!
https://ko-fi.com/kslazinski

That being said, if you use something else in your workflow and would like to share this with me, please leave a comment. I would love to know.

Human Interface Guidelines

Link: https://developer.apple.com/design/human-interface-guidelines

This is one of the best places to learn about UI and UX design for Apple platforms. You will learn the basics and read about best practices and design patterns. If you are just starting or if you are a more experienced designer, this should be a place where you go to improve and update your design knowledge.

I recommend you read the whole documentation. But if needed, you can also search for specific topics. For example, "Color" alone is a long article about best practices, inclusive color, system colors, color management (with an example of sRGB vs Display P3 color spaces) and more. Also with color palette and RGB values for different variants of each color.

Fonts

Fonts for Apple platforms

Link: https://developer.apple.com/fonts/

Here you can learn more about Apple's default fonts and download font packages.

Maybe you already know this, but... The default system fonts on Apple platforms are San Francisco and New York (most apps from Apple use San Francisco). These fonts come with Apple's OSes and you don't need to do anything for your devices to display them properly in the apps you are using. However, if you want to design with these fonts and be able to use them in your design tools, you need to download the fonts from Apple.

It's all on the website I mentioned, but I want to emphasize this: SF Compact is the system font for watchOS. And SF Arabic, SF Armenian, SF Georgian and SF Hebrew are separate font packages if you need them.

Also, another important thing: you only need to download these fonts for design purposes. No need to embed them in your apps developed with Xcode.

Google Fonts

Link: https://fonts.google.com

There are many websites with fonts. Google Fonts is just an example. I chose it for a few reasons:

• It's a big library of FREE fonts.

• The filters are very good, so you can easily check if the font supports the language or group of languages you need.

• Google Fonts are very popular in web design. Very often you will also have a website about your app, so you could potentially use the same fonts in your app and on the website.

But... I would like to give you one piece of advice here. Try to use Apple's fonts first and go for other fonts only if you really need them (font as an important part of your brand, etc.). This will make your life easier. With Apple's fonts, you don't need to embed fonts in your app. You don't need to define custom font styles. And you don't need to worry about localization. With custom fonts (Google Fonts or any other fonts than San Francisco and New York) you need to take care of this by yourself. If you need custom fonts - plan ahead and choose fonts with support for all the languages you might need later.

Icons

SF Symbols

Link: https://developer.apple.com/sf-symbols/

I recommend you start with this: official icons from Apple. Used in every OS from Apple. Very easy to use in SwiftUI. If you need some custom icons, there's an easy way to make your own SF Symbols.

Using SF Symbols is not only easy, but it also helps with improving the UX of your apps. If you are using the same icons as in other apps (and also in native iOS apps), users will be familiar with them. They will recognize them faster.

FontAwesome

link: https://fontawesome.com

There are many other icon libraries, but I would like to show you FontAwesome icon library as an example. They have many icons in the catalog and many styles to choose from.

I really like and recommend these icons, but... I mostly use them for web design and web development. So while there are other options than the icons from Apple, personally, for my iOS apps, I like to use default SF Symbols and design my custom SF Symbols if necessary.

Component Libraries

Sketch Libraries

Link: https://developer.apple.com/design/resources/

Apple's official design resources for Sketch and a few other tools: Adobe XD, Photoshop and some resources for Apple's Keynote.

For your convenience, here are some direct links to a few most popular resources:

iOS and iPadOS: https://developer.apple.com/design/resources/#ios-apps

macOS: https://developer.apple.com/design/resources/#macos-apps

visionOS: https://developer.apple.com/design/resources/#visionos-apps

Licensing and Trademarks: https://developer.apple.com/licensing-trademarks/

Wait! But what about Figma?

iOS UI kit in Figma

Link: https://www.figma.com/community/file/1121065701252736567

This is just one example. iOS 16 UI Kit for Figma by Joey Banks. One of the best and most popular iOS design kits for Figma.

For a few years, Figma users were relying on such libraries made by the Figma community. It is also possible to import Sketch files to Figma (including Apple's Sketch libraries), but Figma design kits were just easier and better.

However, we now also have...

Apple's design library for Figma

Link: https://www.figma.com/community/file/1248375255495415511

During WWDC 2023 Apple finally released their official iOS and iPadOS Design Library for Figma. Great news for every Figma user designing for iOS.

But that's not all. We also have a few other libraries from Apple:

macOS Design Library

Link: https://www.figma.com/community/file/1251588934545918753

visionOS Design Library

Link: https://www.figma.com/community/file/1253443272911187215

App Icon Production Templates

Link: https://www.figma.com/community/file/1250144691121363237

App Screenshots

When we want to publish our app on the App Store, we need not only the app, metadata (app name, description, etc.) but also app screenshots.

Screenshot specifications

Link: https://developer.apple.com/help/app-store-connect/reference/screenshot-specifications

Let's start with Apple's screenshot specifications. Very detailed, but in my opinion also a bit confusing. After you'll read the Requirement for each screenshot size, you will realize that you don't need most of the sizes. At the time of writing this article, the minimal set of screenshots you need for an iPhone app is:

• iPhone 6.5" (for example, iPhone 14 Plus)

• iPhone 5.5" (for example, iPhone 8 Plus)

Apple's Product Bezels

Link: https://developer.apple.com/design/resources/#product-bezels

Here you will find the latest product bezels from Apple. Latest iPhones, iPads, Macs, and even Apple Watches and Apple TV. With those, you can create screenshots like in the image below - app screenshots on the iPhone screen with some promo texts.

However, as I previously said, we still need to provide screenshots for iPhone 5.5" (for example, iPhone 8 Plus). And while it's not a requirement to use iPhone 8 Plus bezels on those screenshots, this is something I am doing. If you want to do the same, you will find out that iPhone 8 Plus is not included in the official Apple Product Bezels. But...

Meta's Product Bezels

Link: https://design.facebook.com/toolsandresources/devices/

Thankfully, Meta's Design Team comes to the rescue. Their library is quite big. They have bezels of products from many brands and luckily for us, they also have Apple's iPhones, including iPhone 8 Plus.

Marketing

OK. Your app is ready. Your screenshots are ready. It's time to publish your app on the App Store and tell the world about it. It's time for some marketing and with Apple's resources, promoting our app is a bit easier.

Marketing Resources and Identity Guidelines

Link: https://developer.apple.com/app-store/marketing/guidelines/

Here you can learn a lot about Apple's recommendations. Few nice examples of what you can and shouldn't do with your marketing images.

App Store Marketing Tools

Link: https://tools.applemediaservices.com/app-store/

Find your app first and you will be directed to a page with marketing tools for your app, where you can generate a Short Link for your app, download App Icon, get "Download on the App Store" badges and even generate a QR code with a link to your app on the App Store.

Promote like a pro

Link: https://tools.applemediaservices.com/apple-app-store-promote

Again, start with finding your app. You will be redirected to a page with a wizard to generate nice-looking promo images for your app. Few different texts, a few color variations and a few different sizes to choose from.

Thank you for reading!

I hope that you found this article useful and maybe learned a thing or two about UI design.

If you want to support my work, please like, comment, share the article and most importantly...

📱Check out my apps on the App Store:
https://apps.apple.com/developer/next-planet/id1495155532

☕ If you like what I do, consider supporting me on Ko-fi! Every little bit means the world!
https://ko-fi.com/kslazinski

Without digit group separators, big numbers look like this:

10000

Thousands are not separated and the numbers are harder to read. With digit group separators the same number will look like this:

10 000
10.000
10,000

It depends on the users' locale. In iOS you set it in Settings / General / Language & Region / Region. It means that depending on the user's region, the user will see 10 000 or 10.000 or 10,000. Many non-English-speaking countries use periods as digit group separators. Most English-speaking countries use a comma. In some countries, it's just space. But thankfully we don't need to worry too much and remember which separator to use. We just need to specify which numbers should have the separator.

Text view

I needed to format numbers in 2 different places. The first one was the Text view.

The first thing I needed to do is to create and configure the NumberFormatter.

struct GoalView: View {
    // other properties

    private let numberFormatter: NumberFormatter = {
        let formatter = NumberFormatter()
        formatter.numberStyle = .decimal
        formatter.usesGroupingSeparator = true
        return formatter
    }()

    var body: some View {
        // body of my GoalView
    }
}

Previously, when I didn't use digit group separators, my Text in the body of the GoalView looked like this:

HStack(spacing: 4) {
    Text("\(goal.currently)")
    Text("/")
    Text("\(goal.goal)")
    Text(goal.currency ?? "USD")
}

To use digit group separators, my new code looks like this:

HStack(spacing: 4) {
    Text("\(numberFormatter.string(for: goal.currently) ?? "0")")
    Text("/")
    Text("\(numberFormatter.string(for: goal.goal) ?? "0")")
    Text(goal.currency ?? "USD")
}

We are using the string(for:) method on numberFormatter, so we are changing the number into a String and applying the style we previously configured for NumberFormatter.

TextField

I also wanted to format numbers using digit group separators when users type data in the TextField.

One way of doing this is to use TextField like this:

TextField("Goal", value: $goal, format: .number)

But one problem with this solution is that the text is changed to the number (and formatted) only when the user presses Enter. To format the numbers on the fly, when users edit the text in the TextField, I did something else.

First, we need to use NumberFormatter as before:

struct AddGoalView: View {
    // other properties

    private let numberFormatter: NumberFormatter = {
        let formatter = NumberFormatter()
        formatter.numberStyle = .decimal
        formatter.usesGroupingSeparator = true
        return formatter
    }()

    @State private var goal = 0
    @State private var goalString = ""

    var body: some View {
        // body of my GoalView
    }
}

One important thing here - I am using 2 properties per each TextField, for example goal (Int) and goalString (String).

My TextFields in the body of my AddGoalView look like this:

TextField("0", text: $goalString)
    .keyboardType(.numberPad)
    .onChange(of: goalString) { _ in
        goalString = goalString.filter { $0.isNumber }
        goal = Int(goalString) ?? 0
        goalString = numberFormatter.string(for: goal) ?? "0"
    }

The solution is very simple. I am using .onChange modifier. When goalString in the TextField changes, my app does 3 things:

1. goalString is filtered and we keep only characters that represent a number

2. goalString is converted to Int and assigned to the goal property

3. the value of goal is assigned to goalString as a string formatted as specified for numberFormatter

Limitations

Please mind that there are some limitations here. If the user copies and pastes 10,000.50, it will be converted to the Int value of 1000050 and this converted to 1,000,050.

That's because of this line of code I showed you before:

goalString = goalString.filter { $0.isNumber }

I solved this problem in my other app Numi - in Numi you can copy and paste numbers with decimal fractions and they are correctly formatted based on the user's locale. But Numi is an app for personal finances and decimal fractions are something very common when you work with money. In Wins I only use Integers, so I didn't need this.

In Numi I have more complex functions triggered when users edit the text in TextFields, involving properties like formatter.minimumFractionDigits, formatter.maximumFractionDigits and formatter.roundingMode. But this is a topic for another article :)
Just please be aware of this and rewrite the logic in .onChange modifier based on your needs.

Thank you for reading!

If you want to support my work, please like, comment, share the article and most importantly...

📱Check out my apps on the App Store:
https://apps.apple.com/developer/next-planet/id1495155532

☕ If you like what I do, consider supporting me on Ko-fi! Every little bit means the world!
https://ko-fi.com/kslazinski

At first, I tried to migrate my database following the solution by Donny Wals. In his book Practical Core Data, there is a separate chapter dedicated to this topic: “Chapter 6 - Sharing a Core Data store with apps and extensions”. If you work with Core Data, I highly recommend reading this chapter and the whole book. Donny is a great Core Data expert and his book helped me a lot with understanding this framework.

However, in his example, he is using NSPersistentContainer. And in my app, I am using NSPersistentCloudKitContainer, which means that I have Core Data with CloudKit support. When trying to migrate my database I ran into 2 problems:

1. My app was freezing during migration if iCloud was turned off (for example, if the user was not signed in to iCloud).

2. After migration, all my data was duplicated.

I spent many hours until I solved both issues. Using ChatGPT, reading Apple's documentation, and browsing through StackOverflow and Apple Developer Forums. As there wasn't one place with a complete working solution, I decided to write this article as it might help other iOS developers.

At the end of this article, I will show you my entire PersistenceController code. I want you to understand each part of the code, so let's have a look at each part of my PersistenceController. But first, a few words about App Groups.

App Groups

What are they and why do we need them? By default, when an app uses Core Data, the app's database is created in the Application Support directory of this app. And only this particular app has access to this folder (and database). App Groups are shared folders. When 2 or more apps have access to this folder, they all can use the same database.

You can read how to configure App Groups in this article from Apple:
https://developer.apple.com/documentation/xcode/configuring-app-groups

Some people recommend adding App Groups support to all new projects as doing this at the beginning is much easier than migrating an existing database to the App Group folder.

In this article, I will show you how I migrated my database to the App Groups folder. First, I will show you my whole code for the PersistenceController. After this, I will talk about each part and explain why I did something the way I did.

Full code

import CoreData

struct PersistenceController {
    static let shared = PersistenceController()

    // Create a database for Preview Canvas.
    static var preview: PersistenceController = {
        let result = PersistenceController(inMemory: true)
        let viewContext = result.container.viewContext

        for _ in 0..<4 {
            let newGoal = CDEGoal(context: viewContext)
            newGoal.type = GoalType.number.rawValue
            newGoal.date = Date()
            newGoal.icon = "trophy"
            newGoal.name = "Goal name"
            newGoal.goal = 1000
            newGoal.currently = 500
            newGoal.status = GoalStatus.planned.rawValue
            newGoal.color = "purple"
            newGoal.id = UUID()
        }

        do {
            try viewContext.save()
        } catch {
            let nsError = error as NSError
            fatalError("Unresolved error \(nsError), \(nsError.userInfo)")
        }
        return result
    }()

    let container: NSPersistentCloudKitContainer

    var oldStoreURL: URL {
        let appSupport = FileManager.default.urls(
            for: .applicationSupportDirectory,
            in: .userDomainMask
        ).first!
        return appSupport.appendingPathComponent("YourAppName.sqlite")
    }

    // We define new App Group containerURL.
    var sharedStoreURL: URL {
        let id = "group.com.yourDomain.YourAppName" // Use App Group's id here.
        let containerURL = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: id)!
        return containerURL.appendingPathComponent("YourAppName.sqlite")
    }

    init(inMemory: Bool = false) {
        container = NSPersistentCloudKitContainer(name: "iCloud.com.yourDomain.YourAppName")

        let description = container.persistentStoreDescriptions.first!
        let originalCloudKitOptions = description.cloudKitContainerOptions

        // Use the App Group store if migration is not needed (if default store without App Group doesn't exist).
        if !FileManager.default.fileExists(atPath: oldStoreURL.path) {
            description.url = sharedStoreURL
        } else {
            // Disable CloudKit integration if migration is needed.
            description.cloudKitContainerOptions = nil
        }

        description.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey)

        if inMemory {
            description.url = URL(fileURLWithPath: "/dev/null")
        }

        // Load persistent stores.
        container.loadPersistentStores(completionHandler: { (storeDescription, error) in
            if let error = error as NSError? {
                fatalError("Unresolved error \(error), \(error.userInfo)")
            }
        })

        // Perform the migration.
        migrateStore(for: container, originalCloudKitOptions: originalCloudKitOptions)

        container.viewContext.automaticallyMergesChangesFromParent = true
    }

// Function migrateStore. Migrates data store to App Group if needed.
func migrateStore(for container: NSPersistentCloudKitContainer, originalCloudKitOptions: NSPersistentCloudKitContainerOptions?) {
    let coordinator = container.persistentStoreCoordinator
    let storeDescription = container.persistentStoreDescriptions.first!

    // Exit current scope if persistentStore(for:) returns nil (migration is not needed).
    guard coordinator.persistentStore(for: oldStoreURL) != nil else {
        print("Migration not needed")
        return
    }

        // Replace one persistent store with another.
        do {
            try coordinator.replacePersistentStore(
                at: sharedStoreURL,
                withPersistentStoreFrom: oldStoreURL,
                type: .sqlite
            )
        } catch {
            fatalError("Something went wrong while migrating the store: \(error)")
        }

        // Delete old store.
        do {
            try coordinator.destroyPersistentStore(at: oldStoreURL, type: .sqlite, options: nil)
        } catch {
            fatalError("Something went wrong while deleting the old store: \(error)")
        }

        NSFileCoordinator(filePresenter: nil).coordinate(writingItemAt: oldStoreURL.deletingLastPathComponent(), options: .forDeleting, error: nil, byAccessor: { url in
            try? FileManager.default.removeItem(at: oldStoreURL)
            try? FileManager.default.removeItem(at: oldStoreURL.deletingLastPathComponent().appendingPathComponent("\(container.name).sqlite-shm"))
            try? FileManager.default.removeItem(at: oldStoreURL.deletingLastPathComponent().appendingPathComponent("\(container.name).sqlite-wal"))
            try? FileManager.default.removeItem(at: oldStoreURL.deletingLastPathComponent().appendingPathComponent("ckAssetFiles"))
        })

        // Unload the store and load it again with new storeDescription to re-enable CloudKit.
        if let persistentStore = container.persistentStoreCoordinator.persistentStores.first {
            do {
                try container.persistentStoreCoordinator.remove(persistentStore)
                print("Persistent store unloaded")
            } catch {
                print("Failed to unload persistent store: \(error)")
            }
        }

        // Set the URL of the storeDescription to the sharedStoreURL.
        storeDescription.url = sharedStoreURL
        // Modify the storeDescription to re-enable CloudKit integration.
        storeDescription.cloudKitContainerOptions = originalCloudKitOptions

        // Load the persistent store with the updated storeDescription.
        container.loadPersistentStores(completionHandler: { (storeDescription, error) in
            if let error = error as NSError? {
                fatalError("Unresolved error \(error), \(error.userInfo)")
            }
        })

        print("Migration completed")
    }
}

That's the whole code. Now let's look at each part and I will explain to you what's happening and why.

Create a PersistenceController

You are probably familiar with the first part of the code. Especially if you (like me) start with the default Core Data stack in Xcode. When we start New Project and choose "App" and later check "Use Core Data" and "Host in iCloud", we will end up with something like this. PersistenceController struct, static let shared for our app's data and static var preview for our Preview Canvas.

In the for _ in block I am creating some objects for my previews. This is not important in the context of database migration, so please don't worry about this part of the code. In your app, this block will be different anyway.

struct PersistenceController {
    static let shared = PersistenceController()

    // Create a database for Preview Canvas.
    static var preview: PersistenceController = {
        let result = PersistenceController(inMemory: true)
        let viewContext = result.container.viewContext

        for _ in 0..<4 {
            let newGoal = CDEGoal(context: viewContext)
            newGoal.type = GoalType.number.rawValue
            newGoal.date = Date()
            newGoal.icon = "trophy"
            newGoal.name = "Goal name"
            newGoal.goal = 1000
            newGoal.currently = 500
            newGoal.status = GoalStatus.planned.rawValue
            newGoal.color = "purple"
            newGoal.id = UUID()
        }

        do {
            try viewContext.save()
        } catch {
            let nsError = error as NSError
            fatalError("Unresolved error \(nsError), \(nsError.userInfo)")
        }
        return result
    }()
// More code...
}

Declare properties

We need to declare a few properties first. We will use the name container for our NSPersistentCloudKitContainer. We will assign a particular iCloud container to it later in the init method.

We also declare oldStoreURL and sharedStoreURL properties that we will use later to move our database to the proper App Group folder.

let container: NSPersistentCloudKitContainer

var oldStoreURL: URL {
    let appSupport = FileManager.default.urls(
        for: .applicationSupportDirectory,
        in: .userDomainMask
    ).first!
    return appSupport.appendingPathComponent("YourAppName.sqlite")
}

// Define new App Group containerURL.
var sharedStoreURL: URL {
    let id = "group.com.yourDomain.YourAppName" // Use App Group's id here.
    let containerURL = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: id)!
    return containerURL.appendingPathComponent("YourAppName.sqlite")
}

Create the container

We set our container as an NSPersistentCloudKitContainer with a name similar to "iCloud.com.yourDomain.YourAppName". One note here: while Apple suggests this naming convention, you can as well use a different one, for example, "iCloud.YourAppName". The most important thing is that this name must match the name of the iCloud container selected in the Signing & Capabilities tab of your app's target.

We also create a constant description that we will use later in the code. And a constant originalCloudKitOptions which we will pass to the migrateStore function later.

init(inMemory: Bool = false) {
    container = NSPersistentCloudKitContainer(name: "iCloud.com.yourDomain.YourAppName")

    let description = container.persistentStoreDescriptions.first!
    let originalCloudKitOptions = description.cloudKitContainerOptions

// Other code.
}

Check if migration is needed

In our code, we will check two times if the migration is needed. Here's the first time. We are checking if a database file exists at the oldStoreURL. This covers a situation when users run our app for the first time on some device. If so, the database doesn't exist yet on the device and we set the URL of our store to sharedStoreURL (App Group folder). Database migration won't be needed here at all.

init(inMemory: Bool = false) {
// Other code.

    // Use the App Group store if migration is not needed (if default store without App Group doesn't exist).
    if !FileManager.default.fileExists(atPath: oldStoreURL.path) {
        description.url = sharedStoreURL
    } else {
        // Disable CloudKit integration if migration is needed.
        description.cloudKitContainerOptions = nil
    }

// Other code.
}

As you can see, we also have an else statement. If a database file does exist on the device at the oldStoreURL, we disable iCloud sync by setting cloudKitContainerOptions to nil.

As I said earlier, my app was freezing during migration if iCloud was turned off on the device. With more detailed logging turned on, I saw that my app tries to connect to iCloud again and again and the migration code is not executed. The only solution I found is to turn off iCloud sync during the migration. So here in the code we are saying: if the database file exists at the oldStoreURL, turn off iCloud sync as we will perform the migration.

Load persistent stores and migrate data

We can migrate the database only if the persistent store was loaded, so we load persistent stores first and after this, we migrate the data.

init(inMemory: Bool = false) {
// Other code.

    // Load the persistent stores.
    container.loadPersistentStores(completionHandler: { (storeDescription, error) in
        if let error = error as NSError? {
            fatalError("Unresolved error \(error), \(error.userInfo)")
        }
    })

    // Perform the migration.
    migrateStore(for: container, originalCloudKitOptions: originalCloudKitOptions)

// Other code.
}

We perform the migration using the migrateStore function that we will write in a moment as part of our PersistenceController.

Function to migrate the store

In our PersistenceController we create a function named migrateStore which we execute at the end of our init method.

We will pass two arguments to this function: container and originalCloudKitOptions. We also declare the coordinator constant equal to container.persistentStoreCoordinator and storeDescription to make the part where we edit the container's options easier to read.

// Function migrateStore. Migrates data store to App Group if needed.
func migrateStore(for container: NSPersistentCloudKitContainer, originalCloudKitOptions: NSPersistentCloudKitContainerOptions?) {
    let coordinator = container.persistentStoreCoordinator
    let storeDescription = container.persistentStoreDescriptions.first!

    // More code.
}

Check if migration is needed (again)

We also write a guard statement to check for the second time if the migration is needed. Let's say that a user opened a previous version of our app on his device before. If persistentStore for oldStoreURL is different than nil, it means that the database at the default location exists and we need to migrate the data to the App Group folder. If it doesn't exist (which means that we already migrated our data), print "Migration not needed" and exit from the current scope (migrateStore function).

// Exit current scope if persistentStore(for:) returns nil (migration is not needed).
guard coordinator.persistentStore(for: oldStoreURL) != nil else {
    print("Migration not needed")
    return
}

Migrate database

With this code, we are migrating our database. But a more correct word would be replacing. And I will explain why in the next paragraphs.

// Replace one persistent store with another.
do {
    try coordinator.replacePersistentStore(
        at: sharedStoreURL,
        withPersistentStoreFrom: oldStoreURL,
        type: .sqlite
    )
} catch {
    fatalError("Something went wrong while migrating the store: \(error)")
}

We use the word "migrate" when we talk about changing one database to another (or when we change our data model). But this may lead us to one mistake. NSPersistentStoreCoordinator has 2 similar methods: migratePersistentStore and replacePersistentStore. There is one crucial difference between them:

As one anonymous Apple wrote on Apple Developer Forums:

migratePersistentStore is (...) creating a clean copy of all the data in your store file in a new location on the file system. Use replacePersistentStore instead to move the store to a new location.

I tested migratePersistentStore before knowing about replacePersistentStore and in the result I had duplicated data. With the replacePersistentStore method, no duplicates were created.

Delete old database

With the replacePersistentStore method, we replaced the store with our new store located in the App Group. Apple's documentation doesn't tell us much about it. It just says this: "Replaces one persistent store with another.". I thought this method will move one store to another place and will literally move the database files. But it doesn't. After running the code I noticed that a new version of the database was in fact created in the App Group folder, but old files were still present in the app support folder.

To get rid of old files, we need to delete them by ourselves. To do this, we will use destroyPersistentStore and removeItem methods.

// Delete old store.
do {
    try coordinator.destroyPersistentStore(at: oldStoreURL, type: .sqlite, options: nil)
} catch {
    fatalError("Something went wrong while deleting the old store: \(error)")
}

NSFileCoordinator(filePresenter: nil).coordinate(writingItemAt: oldStoreURL.deletingLastPathComponent(), options: .forDeleting, error: nil, byAccessor: { url in
    try? FileManager.default.removeItem(at: oldStoreURL) // Delete .sqlite file.
    try? FileManager.default.removeItem(at: oldStoreURL.deletingLastPathComponent().appendingPathComponent("\(container.name).sqlite-shm")) // Delete .sqlite-shm file.
    try? FileManager.default.removeItem(at: oldStoreURL.deletingLastPathComponent().appendingPathComponent("\(container.name).sqlite-wal")) // Delete .sqlite-wal file.
    try? FileManager.default.removeItem(at: oldStoreURL.deletingLastPathComponent().appendingPathComponent("ckAssetFiles")) // Delete ckAssetFiles.
    // ckAssetFiles files may be named like this: AppName_ckAssets
})

When I checked the Simulator's folder holding my database I saw 3 files there: .sqlite, .sqlite-shm and .sqlite-wal. I didn't see any ckAssetFiles files, but this may be due to iCloud being turned off in the Simulator. I decided to leave the last FileManager.default.removeItem as it was in the example. If there will be ckAssetFiles in the database folder, they will be deleted. If they are not there, nothing will happen.

I also need to mention that I tried to comment out coordinator.destroyPersistentStore and my files were not deleted. I tried to leave coordinator.destroyPersistentStore and comment out NSFileCoordinator and again - my old files were not deleted. We need both parts. We need to destroyPersistentStore first and later delete each file with FileManager.default.removeItem.

I found this solution on StackOverflow and I would like to quote a user named Jordan H who posted the solution:

In talking with an engineer in a WWDC lab, they explained it does not actually delete the database files at the provided location as the documentation seems to imply. It actually just truncates rather than deletes. If you want them gone you can manually delete the files (if you can ensure no other process or a different thread is accessing them).

Re-enable CloudKit

We moved our database. We deleted old files. Now we can re-enable CloudKit. As we can't change cloudKitContainerOptions on a running persistence store, we need to unload our current store, change storeDescription.cloudKitContainerOptions to the value previously stored in the originalCloudKitOptions constant and load the store again with these options.

// Unload the store and load it again with new storeDescription to re-enable CloudKit.
if let persistentStore = container.persistentStoreCoordinator.persistentStores.first {
    do {
        try container.persistentStoreCoordinator.remove(persistentStore)
        print("Persistent store unloaded")
    } catch {
        print("Failed to unload persistent store: \(error)")
    }
}

// Set the URL of the storeDescription to the sharedStoreURL
storeDescription.url = sharedStoreURL
// Modify the storeDescription to re-enable CloudKit integration
storeDescription.cloudKitContainerOptions = originalCloudKitOptions

// Load the persistent store with the updated storeDescription
container.loadPersistentStores(completionHandler: { (storeDescription, error) in
    if let error = error as NSError? {
        fatalError("Unresolved error \(error), \(error.userInfo)")
    }
})

print("Migration completed")

Final note

That's it. That's how I managed to migrate NSPersistentCloudKitContainer to App Groups. I tested this solution on Simulator and real devices. I tested with iCloud sync turned on and with iCloud sync turned off on the device. I tested if the data continues to sync after migration. And everything seems to work. However, I assume that it's not the best way of solving this problem. And also I am very far from being a Core Data expert, so please take this into consideration. Please double-check everything before using my code in your projects. Please test the results and make some changes if necessary. And if you know that something could be done better, please leave a comment and let me know about this.

Thank you for reading!

If you want to support my work, please like, comment, share the article and most importantly...

📱Check out my apps on the App Store:
https://apps.apple.com/developer/next-planet/id1495155532

☕ If you like what I do, consider supporting me on Ko-fi! Every little bit means the world!
https://ko-fi.com/kslazinski

Regular Tabs

The easiest and fastest way to add tab navigation to your SwiftUI app is to use TabView and SF Symbols from Apple.

When I'm writing this article, the current version of SF Symbols is 4. And it consists of 4,400 symbols. Many of them have 2 variants: regular (outlined) and filled. Please have a look at the pie chart example and notice differences in the icon and the name.

In SwiftUI, we use these icons like this:

Image(systemName: "chart.pie")
Image(systemName: "chart.pie.fill")

Here's an example of the TabView with 4 tabs using SF Symbols icons:

TabView {    
    TransactionsView()
        .tabItem {
            Label {
                Text("Transactions")
            } icon: {
                Image(systemName: "arrow.left.arrow.right.square")
            }
        }
        .tag("transactions")

    RecurringView()
        .tabItem {
            Label {
                Text("Recurring")
            } icon: {
                Image(systemName: "arrow.clockwise.circle")
            }
        }
        .tag("recurring")

    SummaryView()
        .tabItem {
            Label {
                Text("Summary")
            } icon: {
                Image(systemName: "chart.pie")
            }
        }
        .tag("summary")

    MoreView()
        .tabItem {
            Label {
                Text("More")
            } icon: {
                Image(systemName: "ellipsis.circle")
            }
        }
        .tag("more")
}

With this code we will get this tab navigation:

Did you notice something strange? In my code, I used regular variants of the icons, but in the app, they are filled. And this is a...

Default SwiftUI behavior

Since iOS 15 it just works this way. Apple decided to render TabItem icons as filled on iOS and outlined on iPadOS and macOS. The same code will result in a little different look on each platform.

Let's see how the same icons in Apple's Developer app look on iOS, iPadOS and macOS:

It's part of Apple's design and you can read more about Tab bars in Human Interface Guidelines here:
https://developer.apple.com/design/human-interface-guidelines/components/navigation-and-search/tab-bars/

And also about Icons here:
https://developer.apple.com/design/human-interface-guidelines/foundations/icons

Outlined tabs in iOS

But what if we want to have outlined icons in the tab navigation in iOS for some reason? The good news is that it is quite easy to do. We can add this one line of code to each Label in our TabView to tell SwiftUI not to change variants of our icons:

.environment(\.symbolVariants, .none)

Now let's add one variable in our view:

@State private var selectedTab = "transactions"

And let's use a ternary operator in our code like this:

Image(systemName: (self.selectedTab == "summary") ? "chart.pie.fill" : "chart.pie")

If you are not familiar with ternary operator syntax, this basically means:

If selectedTab is equal to "summary", use the chart.pie.fill icon. If not, use the chart.pie icon.

Let's see how the whole TabView code would look like with these changes:

TabView(selection: $selectedTab) {

    TransactionsView()
        .tabItem {
            Label {
                Text("Transactions", comment: "Tab view navigation item.")
            } icon: {
                Image(systemName: (self.selectedTab == "transactions") ? "arrow.left.arrow.right.square.fill" : "arrow.left.arrow.right.square")
            }
            .environment(\.symbolVariants, .none)
        }
        .tag("transactions")

    RecurringView()
        .tabItem {
            Label {
                Text("Recurring", comment: "Tab view navigation item.")
            } icon: {
                Image(systemName: (self.selectedTab == "recurring") ? "arrow.clockwise.circle.fill" : "arrow.clockwise.circle")
            }
            .environment(\.symbolVariants, .none)
        }
        .tag("recurring")

    SummaryView()
        .tabItem {
            Label {
                Text("Summary", comment: "Tab view navigation item.")
            } icon: {
                Image(systemName: (self.selectedTab == "summary") ? "chart.pie.fill" : "chart.pie")
            }
            .environment(\.symbolVariants, .none)
        }
        .tag("summary")

    MoreView()
        .tabItem {
            Label {
                Text("More", comment: "Tab view navigation item.")
            } icon: {
                Image(systemName: (self.selectedTab == "more") ? "ellipsis.circle.fill" : "ellipsis.circle")
            }
            .environment(\.symbolVariants, .none)
        }
        .tag("more")

}

This way selected tab will have a filled icon variant and other tabs will have a regular, outlined icon.

Accessibility

If you know anything about accessibility, at this point you may wonder: Is it better to override default iOS behavior and use the fill icon for the selected tab item and outlined variant for all the other tabs? And the answer is: Yes and No 🙃

In general, relying on only one thing to distinguish some items is not a good idea. In our case, this one thing would be color, if all the icons would be filled. The active tab item is blue. Other tab items are grey. Users with colorblindness might see all of them as grey. And it wouldn't be clear to them which tab is active. So it's good to mix outlined and filled icons, right? Right!

But... Apple does a great job with accessibility. iOS users can choose from a variety of different assistive technologies. One of the iOS features that could help you if you have colorblindness is Accessibility / Display & Text Size / Button Shapes. If this setting is ON, text buttons will be underlined and some other buttons will have a highlighted shape when it's necessary.

Here's an example of how this feature works with TabView without any custom changes. All the tabs have filled icons, but the active tab has an additional background.

Are we done? Almost 🙃 Because at this point we can also have a valid question: "Will all our users who would need this feature know about it?".

And the answer is: "I don't know" 😅

So? What should I do?

Every project is different. Every app has a different target audience. But if you don't know about any special requirements, I would do this:

1. Start as simply as possible. Use default components, don't override the default look and behavior and let iOS, iPadOS and macOS do their job.

2. If you'll get any user feedback suggesting that a custom tab bar would be better for some reason, make the necessary changes. And now you know how 😉

Thank you for reading my article 🙂 Any likes, comments and shares are highly appreciated.

Thank you for reading!

📱Check out my apps on the App Store:
https://apps.apple.com/developer/next-planet/id1495155532

☕ If you like what I do, consider supporting me on Ko-fi! Every little bit means the world!
https://ko-fi.com/kslazinski

As my friend Mateusz Jedraszczyk likes to say, User Experience without users is just some experience. Or in other words, there's no User Experience without users. UX design should always be an answer to people's needs. You can't just design new screens and user flows in isolation from users. You need to know what they need and what problems they have.

Two things I did to identify what changes I need to implement in my iOS app Numi:

1. Usability Tests.
I conducted them a few weeks ago with a few people. Remotely, using the FaceTime app.
Numi is an app for managing personal finances, in which you can record your income and expenses. And few of the testers told me that they want to be able to add new categories while adding transactions.
OK, so I knew it is one of the things I need to improve.

2. Direct Feedback from users.
My app has an implemented email link. This means that users can contact me directly by sending me an email from the app. And a few days ago one of my users did. He described how annoying it is to close Add Transaction screen, go to Settings, add New Category, and go back to Add Transaction again. Especially now, when he's new to Numi and didn't set up all his categories yet.
Now I knew. The ability to add new categories on the Add Transaction screen is not just one of the features I should add. It's one of the most important features I need to add. One cool thing is that it's also not something difficult to implement :)

And here it is, the current and the upcoming version of my iOS app Numi.

The main difference is added + button. Soon users will be able to add new categories not only from Settings but also on Add Transaction and Edit Transaction screens.

📱Link to Numi on the App Store:
https://apps.apple.com/app/id1636232810

Thank you for reading!

☕ If you like what I do, consider supporting me on Ko-fi! Every little bit means the world!
https://ko-fi.com/kslazinski