The new iPhone will probably be out in a month, and iOS 18 will be out a week later after that. A lot of us are gearing up for a successful Day 1 release, and I created a checklist for myself to ensure everything goes according to plan.

As an indie developer, I know how important it is to be ready when a new iOS version drops. As Jordan Morgan said, “You only launch once.”

The opportunity to seize and shine on the App Store is right in front of you. So, let’s dive into the checklist that I have created for a smooth iOS 18 app release of Meshing.

This post focuses on the app itself, and the subsequent ones will be about App Store Connect and press.

Polish Your Feature Set

The main thing. Creating a delightful app for users to enjoy. The one that works flawlessly before release. We all can dream, right?

As my app is iOS 18+, I am rigorously testing on the iPhone 14 Pro Max and XR to work with different screen sizes. I know a buggy app can quickly lose users, no matter how innovative the features are, so the core features should work well, and that is why I decided to have a TestFlight early on:

Valuable Onboarding

As soon as the user opens the app and sees the onboarding screen, they should feel that this is the app that will solve all of the life problems! Oh, I wish there was an app that worked that way.

The app should solve the problem they are looking to solve, and the onboarding gives a glipmse of it. It has enough guidance to get users started, but not so much that it becomes overwhelming. I hate those personalised never ending onboarding screens.

I plan to have a single screen onboarding, highlighting the core features. For my app, it is simple: you create a mesh gradient, you export it, or copy it to clipboard. And the cherry on top is Meshing AI for prompt based gradients. Quick, and to the point.

Implement iOS 18 Features

Apple loves to feature apps that showcase their latest iOS capabilities. I look for good ways to add the shiny new iOS 18 features into my app. We have the Control Widgets, and the custom translation in the Translate framework.

I want to make sure it feel natural, not forced.

Set Up Analytics

Not as brutal as big companies, but enough to know what the user are generally using. Keeping privacy as atmost priority. I have been using TelemetryDeck for a few years and happy with it tracking the key metrics.

In the early stages, I need this data to support the priority list for future updates and features.

Feedback-Friendly Settings Page

While I have not even created a settings page yet, I want to include an option for users to provide feedback. I am not a fan of buried contact forms, either so this will be a simple “Bug!” or “Feature Request” button within the settings that opens up mail.

I used something similar for Gradient Game and it is casual, friendly, and somewhat screams “I want to hear from you!” And it worked. User feedback is gold for us indie devs.

An Effective Paywall

Ah, time to print.

And pay bills.

Nope, not a paywall that opens every launch to bombard me with “BUY NOW!” sheets with insane weekly pricing. My paywall is going to be clear, upfront, and offer value. I am thinking of “Meshing Pro” version that unlocks export feature and Meshing AI. It is difficult to balance what should be under the free version, and what all is worth upgrading for. Meshing AI is for sure worth it, and I have to pay OpenAI, too.

The templates are an investment too because I manually create them, and it provides immediate value to the user who wants quick gradients.

Should export be under a paywall? Maybe a few free exports and then show the paywall? I want users to upgrade because they love the app, not because I have annoyed them into submission.

As I am writing this post during RevenueCat’s Ship-a-ton, I will use their new Paywall editor to come up with a subscription model. My plan is:

• 3 dollars a month
• 20 dollars a year
• 30 dollars for lifetime access

I have to think harder on the pricing. I do want tonot to undersell my work, while providing enough value to the user, too.

Performance and Leaks

When I saw the animated mesh gradients takes a whopping 10–12% and 100 MB on my phone, I was shocked. Creating a simple mesh gradient tool is harder on performance, and who knew pretty colors could be such resource hogs?

Here is my plan:

1. Use Xcode Instruments to find the bottlenecks, especially when animating
2. Keep an eye on memory usage.
3. Move some computations to background threads.
4. Compress images without losing quality.

A smooth app is a happy app leading to happy users!

Errors??

Working with APIs like OpenAI, or my backend means that everything and anything can go wrong. Error handling to gracefully manage issues is one of the least enjoyable work for me.

But we live in the LLMs era! I can handoff this work to Claude, and also use the ContentUnavailableView for consistency. Apart from user-friendly error messages and I want to at least add suggestions for resolving the issue.

Accessibility Check

I have to run through my app using VoiceOver and VoiceControl. And ensure the UI works well for extra large font sizes.

By running through all of this, I want to make sure Meshing is an app that everyone can enjoy, regardless of how they interact with their device. It is a bit of extra work, sure, but worth to know that anyone who wants to create beautiful mesh gradients can do so with ease.

Localization

While English is widely used, I have already localized the app for Simplified Chinese because I got some great feedback from a designer and I wanted to appreciate their efforts. My plan is to localise for the following languages:

I am using Localizable.xcstrings and Claude to translate the initial versions giving it the content of the app, so it can localise better. Then, I have friends who can look over the final translation to let me know if I am on the correct path!

Moving Forward

A lot of work is left. And I need to stay focused and adaptable. Here is my plan moving forward:

• Focus on core features and iOS 18 integrations first while testing thoroughly.
• Take in the feedback and suggestions from the X community and implement them.
• Work harder on the paywall structure and pricing tiers.
• The app should be accessible to everyone.
• Finalize translations and verify their accuracy.
• Start planning App Store presence and press outreach.
• And finally, take good care of myself.

Happy shipping!

This is a chapter from my book on Exploring Freelancing: https://rudrank.gumroad.com/l/freelance-journey

I still chuckle when I think about it. I have talked about this in numerous podcasts about how I started with iOS development in the first place.

2018, sophomore year of college. I was enjoying my sleek MacBook Air, feeling like the coolest kid on the block. That was until some classmates decided to have fun at my expense. “Hey, bet that fancy MacBook cannot even run a single game our Windows machines can!” they teased. Well, maybe they had a point. But my ego got hurt anyway, and I considered that a challenge.

Instead of sulking, I thought, “What could this MacBook do that their Windows machine cannot?” That is when I stumbled upon iOS development and an Udemy course by Angela Yu. The more I got into it, the more I felt like I had found my thing. An escape from reality instead of boring college courses. Writing in the Swift language felt flawless. Late nights were spent exploring the courses and tinkering with baby apps for the thrill.

I bumped into this senior who was doing something called as freelancing — someone whose Google Chrome had numerous tabs with the names of sites like Fiverr and Upwork. He was hustling, making some good dollars on the side by offering his Alexa skills. For me, he was living proof that fun hobbies could also bring in the money to help me get my next materialistic need: a MacBook Pro.

That was an eye-opener. My MacBook might not have played games as theirs did, but it sure played a different kind — a game that could potentially set the stage for my future!

The Learning Curve

When I first dipped my toes into iOS development, I was lost. The course I started with was comparatively easy initially, so I stopped going to college and binged the videos, locking myself around the four walls. A lot of code and mistakes, and nights where I would find myself staring blankly at my MacBook screen or a single error mocking me for hours. Syntax ones, logical ones, you name it, and I probably made that mistake. So much banging my head on the network calls and APIs, UI constraints, and everything in between.

However, every time I felt like giving up, I remembered the jests of my classmates. Call it spite-driven development. Each hurdle taught me something new; with every mistake, I wanted to improve at making apps.

Did I feel like giving up? Absolutely. More times than I would like to admit. But you know that the thing about hitting rock bottom is that you can only go up from there. Each setback became a stepping stone, each frustration more of a lesson.

If I wanted to freelance like my senior, I had to persist, and I realised creating apps for Apple devices was fun if I was paid handsomely for it.

Tapping the Resources

Angela Yu’s Udemy course was my starting point, but I slowly moved to more books and courses to explore. I picked up “The Swift Programming Language” by Apple Inc. It is the bible for Swift language used to develop Apple Platforms. Easy to understand and direct. I can spend hours crafting a better solution or search on my best friend: Stack Overflow. Someone there solved it, so sometimes it is not worth reinventing the wheel.

The Reality Check

After setting myself on many different freelancing accounts, I found myself mostly glued to the screen instead of college assignments, mindlessly refreshing the screen in anticipation of that first gig offer after applying to endless contracts. It felt like standing in a virtual auditorium, resume in hand, waiting for someone to call me onto the stage.

Except no one did. The days turned into weeks, and there was not a single offer or even a message.

The reality sunk in: the freelancing world is less welcoming than I had imagined. I had zero experience. The dreams of echoing my senior’s success seemed to drift farther away from me every day as I started giving up hope. Now that I look back, it is obvious that it was a loop of no experience and no offer and no experience because of no offer and no offer because of no experience. Still, I was foolish enough to let doubts and impatience cloud my thoughts, and finally, I decided — freelancing was off the table.

It was a hard pill to swallow, especially after witnessing firsthand someone who had turned it into a profitable lifestyle.

The Internship Insight

It was around this time when internships caught my eye. Unlike freelancing, where the vast sea of competition can be disheartening, internships provided a more structured environment for honing my skills. Plus, there was the appeal of steady income and mentorship, which felt like a safer bet for a still-green developer like myself.

I applied to a few places, leveraging the projects I had built while following Angela Yu’s course and other tutorials. One of the college seniors reached out to me as I was the only iOS developer around, and soon, I found myself interning at a small start-up working on some cool iOS projects. As it was a small one, I was their iOS intern and the iOS lead, starting two iOS apps from scratch.

It was not freelancing; I did not control my time or the project, but it was something. The income was mediocre but enough for my materialistic endeavours. I remember the joy of unboxing the new headphones I had longed for — bought from my internship earnings.

Though my jump start into iOS development took a different turn with internships, the idea of freelancing did not entirely leave me. The internship experience was a good step toward becoming a more experienced developer. Working with a backend developer, an Android developer, and a designer as a team gave me a more rounded skill set. Despite the initial hurdles and missteps, it confirmed that iOS development was the right track for me.

While my MacBook may not have been a gaming powerhouse, Xcode (Apple’s IDE to develop apps) became a tool for my ambition and dreams and a game I was more than willing to play.

If you liked reading this chapter, checkout my book on Exploring Freelancing: https://rudrank.gumroad.com/l/freelance-journey

When I was working on the Gradient Game, I used to get a lot of feedback and product requests via mail. I usually got overwhelmed and never got to work on them, and unfortunately not capitalise on it either. I want to change that with my newest app, Fusion.

Fortunately, I stumbled upon Martin’s WishKit! It helps to capture and analyse product feedback and feature requests in one place. And that’s what I want!

I have already implemented more than a few in the app and have a lot of happy TestFlight users! I am improving and customising the UI of the WishKit screen, so I wanted to pen down my experience using it in my app! In this article, I walk you through getting started with WishKit and configuring it to fit your app’s needs.

Introduction

WishKit lets you easily add feature request functionality to your app, allowing users to suggest and vote on new features. This is what my current screen looks like for using the framework in my app:

Adding WishKit as a Dependency

The first step in getting started with WishKit is to add it as a dependency in Xcode. When managing via Swift Package Manager, add WishKit as a dependency by adding it to the dependencies value of your Package.swift:

dependencies: [
 .package(url: “https://github.com/wishkit/wishkit-ios.git", .upToNextMajor(from: “4.0.0”))
]

Configuring WishKit with your API Key

Once you have added WishKit as a dependency, you must configure it with your API Key. You can find your API Key in your admin dashboard on wishkit.io. In the first view of your app, add the following code to configure WishKit with your API Key:

@main
struct FusionApp: App {

  init() {
    WishKit.configure(with: "<#App-API-Key#>")
  }

  var body: some Scene {
    WindowGroup {
      // Your app's content here
    }
  }
}

Using WishKit in Your Views

Now that you have configured WishKit, you can use it in any of your views. Simply import the WishKit framework and use WishKit.view. This is how I am using it in my app:

struct SettingsView: View {
    var body: some View {
      NavigationStack {
        List {
          Section("Make a Wish! ✨") {
            NavigationLink(destination: WishKit.view, label: {
              Label("Request feature", systemImage: "wand.and.stars")
            })
          }
        }
      }
    }
}

Note: If one of the parent views does not have a NavigationView/NavigationStack, you must call withNavigation() on WishKit.view.

Configuring WishKit UI Elements

WishKit provides several configuration options to customise its UI elements. You can configure options such as the status badge, description display, segmented control, drop shadow, comment section, and more. Here is an example of how I am using some of these options:

// Show the status badge of a feature request (e.g. pending, approved, etc.).
WishKit.config.statusBadge = .show

// Shows full description of a feature request in the list.
WishKit.config.expandDescriptionInList = true

// Remove drop shadow.
WishKit.config.dropShadow = .hide

// Change the corner radius.
WishKit.config.cornerRadius = 12

Feel free to experiment with other configuration options WishKit provides to further customise the UI elements according to your app’s needs. Explore the static property config to know more about them.

Theming WishKit

You can also theme WishKit to match your app’s colour scheme. Another example of how I am theming the view for my app:

// Set the primary color for WishKit theme
WishKit.theme.primaryColor = .primary

// Set the text color for the Add button
WishKit.config.buttons.addButton.textColor = .set(light: .white, dark: .black)

// Set the text color for the Save button
WishKit.config.buttons.saveButton.textColor = .set(light: .white, dark: .black)

By setting the primary colour for the WishKit theme, I customise the overall colour scheme of WishKit to match my app’s primary colour.

Additionally, by setting the text colour for the Add and Save buttons, I ensure that the text is visible and readable against the background colour of the buttons. Similarly, you can also update the colour of the upvote button.

Feel free to adjust these colours according to your app’s design and colour scheme.

Conclusion

With WishKit, I can easily add feature request functionality to my app and engage with the users.

I hope this small introduction will encourage you to use it in your app, too! Make sure you actually work on the feedback gathered from your users and iterate on your app’s features. Share your experience with WishKit and tag Martin on X (formerly Twitter). Happy coding!

This post is an excerpt from my upcoming book “Exploring Technical Writing”.

You can pre-order the book at 50% discount — https://rudrank.gumroad.com/l/technical-writing/pre-order

“When I was young I thought that money was the most important thing in life; now that I am old I know that it is.” — Oscar Wilde

After publishing the first article on Medium in 2019, I learned that Medium has a program that pays you for the views from the paid members. This was a new opportunity that changed my perspective on writing. Get paid to write about what you love! I yearned to earn my first dollar online via writing.

During my college end-semester exams, I wanted to do everything except study. I decided to channel this energy into writing. I started writing a few more articles. At that time, I did not know what to write, and I was exploring many open-source projects and libraries for my app. So, I created a few curation articles instead of focusing on a particular topic or a tutorial. Like “5 SwiftUI Open-Source Projects to Use in Your Next App”.

Joining the Medium Partner Program

The program, called as the Medium Partner Program, probably commenced in November of 2019. I joined on November 20th just to try out my luck and hope to earn some bucks for my coffee addiction at college. Little did I know that this decision would lead to my first taste of online money. Under the Medium Partner Program, I wrote my first article, “Playing with Combine: Grid Layout in SwiftUI.” This article became eligible to earn money and was included in the metered paywall, allowing readers to pay for access or view it as part of their monthly subscription. And subsequently, I made my other articles eligible under the metered paywall.

These posts were a hit. I still do not know why, but I can guess that developers do not want to do the hard research and are happy to have a post that curates the popular tested projects. This way, they save time on the research and cherry-pick the project they like. The impressions on these articles, plus the Google SEO effect, were huge, with tens of thousands of views.

The Disappointment

However, my excitement was short-lived when I received an email on December 13th stating they could not pay me for my earnings. The reason was that Stripe, the payment processing platform, was still under preview for India. I did not have anything to lose despite the disappointment.

The Unexpected Twist

Surprisingly, Medium made a one-time payment through PayPal for the money I had earned. However, it was a temporary solution before shutting down the Medium Partner Program in India. I made $92.73 from Medium in the first month of writing!

That was a lot of money for me as a college student in India. That was a month of food and coffee expenses for me. I know people from NYC cannot comprehend this, but this taste of online money from writing was delicious.

This experience opened my eyes to the possibilities of earning income through my passion. While it has been four years since the Medium Partner Program shut down, I am grateful for it for providing a platform for writers like me to showcase our work and earn recognition. It turned out to be a stepping stone towards realising the potential of online writing and its opportunities.

This post is an excerpt from my upcoming book “Exploring Technical Writing”.

You can pre-order the book at 50% discount — https://rudrank.gumroad.com/l/technical-writing/pre-order

“I write to discover what I know.” — Flannery O’Connor

Have you ever had an idea late at night that would not let you sleep, and you just did not know where to share it? Back in 2019, I came across a new framework introduced by Apple called Combine. It intrigued me, and I decided to learn more by picking up a book. Little did I know that this decision would lead me to an idea for my first post on Medium.

Discovering the Gap in SwiftUI

Around the same time in 2019, Apple also introduced another framework called SwiftUI, which allowed for declarative development for Apple platforms. However, as it was in the initial stages, something was missing from the framework. It lacked a native view for creating grid layouts with multiple rows and columns. This sparked an idea while reading about the Combine framework late at night.

Innovative Solution Using Combine

I thought of using two loops to create the desired layout while emitting values through the stream. To simplify, imagine you have a photo album with spaces for pairs of photos. You have six pictures of landscapes: mountains, beaches, forests, deserts, lakes, and valleys. You want to arrange them in the album so that every page shows two landscapes side by side:

Mountains | Beaches

Forests | Deserts

Lakes | Valleys

That is what I aimed to do, using the Combine framework. It seemed like a breakthrough, and I wanted to share it with others. However, when I searched the internet for similar approaches, I could not find any content related to it. I was amazed because no one else seemed to have this idea?

This led me to the dilemma of where to post my idea and the solution. I did not have a blog or want to invest in a domain. After using WordPress before, it was not the option I was looking for either. That is when I discovered Medium.com.

From Idea to Validation

I saw popular developers posting on Medium and gaining recognition, which motivated me to choose it as the platform for my first post. I wanted to share my idea and hopefully receive some claps as validation (haha!) and engagement from the community.

So, I went about writing my first post on Medium! I started with “Playing With Combine: Grid Layout in SwiftUI”, creating a playful but not click-bait title. At that time, the developers working with SwiftUI knew about the absence of a grid layout; for them, it was an instant click.

In the introduction, I briefly explained the context of my idea and how it came about. I mentioned Combine and SwiftUI and the lack of a native grid view in the framework.

Next, I explained my idea of using two loops to create the grid layout. I provided step-by-step instructions and code snippets to demonstrate implementing this solution in SwiftUI.

After explaining the solution, I shared the results, including the screenshots or images to visually showcase the grid layout created with multiple rows and columns.

Writing the first post on Medium over a night was nerve-wracking. I was too excited to share my idea and implementation as if I achieved the fusion of some nuclear elements. And people loved it! I went back to check the statistics, and the post has almost twenty thousand views and 830 claps over four years! Half of the views are from Google, meaning Medium’s strong domain authority did its magic.

This experience taught me that sometimes the best ideas come when you least expect them. Sharing my opinion on Medium and seeing it resonate with many people boosted my confidence. The initial writing success motivated me to explore, learn, and share more in the future!

This post is an excerpt from my upcoming book “Exploring Technical Writing”.

You can pre-order the book at 50% discount — https://rudrank.gumroad.com/l/technical-writing/pre-order

“Writing is the painting of the voice.” — Voltaire

Reflecting on my writing journey, I cannot help but giggle at the memories of my early days as a kid blogger. I was just 14 or maybe 15, so I prefer to embrace the innocence of the term “kid” instead of a teenager, finding joy in the little things.

Embarking on a Journey

It all started a decade ago when I had a “Freeze the Seconds” photography blog on WordPress dot com. I used to go on trips and take lots of pictures. I felt each picture had a story, and I would write creative captions for them. It was my little corner of the internet to express my creativity and share my experiences with others. I was a young shutterbug, and this blog was a way to express my love of capturing moments.

I loved taking pictures, capturing moments, and sharing them with the world. People liked what I was doing. I remember one comment that made me beam with joy. Someone said, “Great pictures! You surely seem to be having a thing for imagination. :)” It was one of my favourite moments!

But, for some reason, I cannot remember, I deleted that blog. It was either at the end of 2012 or the beginning of 2013. It was an impulsive decision, and I said goodbye to “Freeze the Seconds.”

Starting that blog was the initial part of my journey as a writer. It helped me express myself and connect with others, even though it was a few lines of captions.

Finding My Voice

In 2014, a new chapter of my writing journey began. There was a classmate of mine who was super good at writing complex English sentences. Everyone thought he was the superstar of the class! I felt envious and wanted to be cool like him.

But for me, writing was more about sharing my thoughts and feelings, a means of self-expression and cherishing being in my little world of reality. A virtual escape from the reality of high school, where I could vent out my thoughts and feelings. At that time, my life mostly revolved around solving homework and the constant dread of attending school.

So, I started a blog called “Husk of Abandoned Dreams”. I still do not know why I chose that name, but it sounded heavy. This blog became my getaway where I could be myself without any judgment.

My first blog post was a raw introduction to who I was. I wanted to be real, to be me. It was unfiltered and perhaps too honest. I introduced myself as a “screwed 17-year-old teenager, science student [LOL].” I shared my love for music how I enjoyed playing the guitar and piano, and writing songs. I was candid about my views and scepticism towards friendship and love and how gaming and music were my lifelines. I ended my post with a quote by Justina Chen,

“You raze the old to raise the new.”

Those words were powerful. It reflected my mindset: to break free from my past and build a new future!

I was an introvert, and sharing my thoughts with the world was not something I was comfortable with. I was putting myself out there, all my thoughts and feelings, for the world to see. It was scary. At that time, I did not even consider myself a blogger. I mentioned in my post that blogging was not my game. But I was so tired of feeling unheard, so I poured my heart out on my blog, even if nobody seemed to care. I wrote about everything disturbing my mind, from personal experiences to social issues to my mistakes.

I did not have a specific topic or theme for my blog, though. It was a way to process my thoughts and emotions and connect with others who might relate to what I was going through.

The Power of Words

As time passed, I received feedback and comments from readers who resonated with my posts. It was a small but supportive community that encouraged me to continue blogging. I realised that my words had the power to impact others and create a sense of connection.

Looking back, I realise how much I have grown since then. My thoughts have evolved, my writing has improved, and my understanding of the world has broadened. But one thing has remained constant — my love for writing. It was my first step into the writing world and paved the way for my journey as a technical writer.

TipKit is a framework to help you easily present helpful tips and educational cues to users, guiding them through the features of an app at the right moment. Designed for SwiftUI, UIKit, and AppKit, this article will specifically focus on SwiftUI.

In this post, I will refer to creating a tip for my app, Fussion, where you get Spotify’s Blend-like features for Apple Music. I want to create numerous tips to guide users to either add feature request, or learn how to use the app’s features.

Tip Protocol

Let’s delve into the protocol Tip, which conforms to both Identifiable and Sendable. This protocol acts as the foundation for creating, defining, and shaping tips.

@available(macOS 14.0, iOS 17.0, tvOS 17.0, watchOS 10.0, xrOS 1.0, *)
protocol Tip: Identifiable, Sendable { }

The Tip protocol has several instance properties that allow for different tip customisation. We start with the context of MyFirstTip, a simple tip, to explore how to set up the content of a tip.

struct MyFirstTip: Tip {
  var title: Text {
    Text("Testing a tip!")
  }
  
  var message: Text? {
    Text("It is working!")
  }

  var image: Image? {
    Image(systemName: "star")
  }
}

Understanding the Properties

The foremost property is the title, a non-optional attribute and the main requirement for a tip that conveys the benefit of your tip. In the example of MyFirstTip, the title is "Testing a tip!". Well, it is the first tip; we start with some testing, hah. This sets the stage and is often the first thing the user will read.

var title: Text { get }

Although optional, the next attribute, the message, works with the title to deepen user understanding. In MyFirstTip, this is presented as "It is working!" adding a layer of confirmation to the title that we are testing!

var message: Text? { get }

Then, we have the image, another optional property that provides visual context to the tip. It makes the tip more engaging while offering a quick, intuitive cue for users to grasp the essence of the tip. For MyFirstTip, this image of a star complements the title and message, making me happy about the testing process.

var image: Image? { get }

Each property — title, message, and image— serves its role in forming a valuable tip. The title catches your eye and grabs attention, the message makes things clear, and the picture adds a fun touch — these work together to create a helpful and easy-to-understand tip for the user.

Creating a Tip

A tip should be more than just informational — it should encapsulate the essence of the feature it’s guiding the user toward. I have created a WishKitTip tip to guide users on adding a "wish" or feature request within my app.

@available(macOS 14.0, iOS 17.0, tvOS 17.0, watchOS 10.0, *)
struct WishKitTip: Tip {
  var title: Text {
    Text("Add a Wish!")
      .font(.tipTitle)
  }
  
  var message: Text? {
    Text("Upvote or create your feature request for me to work on.")
      .font(.tipMessage)
  }
  
  var image: Image? {
    Image(systemName: "wand.and.rays.inverse")
  }
}

Notice how I use SwiftUI’s built-in .font() modifier directly within the tip's title and message properties. This demonstrates the advantage of TipKit's full integration with SwiftUI—you can employ any SwiftUI modifiers for Text to make your tips customisable.

• title: Text: The title here is "Add a Wish!" with a font style set to .tipTitle. This aligns with the feature it discusses—adding a wish or feature request.
• message: Text?: The message serves as a secondary guide. It specifies what actions the user can perform—either upvote an existing wish or create a new one.
• image: Image?: The image uses the system symbol wand.and.rays.inverse, visually supporting the "wish" concept. An image can speak a thousand words, and here, it quietly but effectively tells the user that my coding magic to implement their favourite feature is just a click away. 🤪

Configuring TipKit

Before we show our first tip to users, we need to get TipKit ready. To do that, we use the Tips.configure() method. It configures an app’s tips.

@available(macOS 14.0, iOS 17.0, tvOS 17.0, watchOS 10.0, *)
@frozen public enum Tips {
  public static func configure(_ configuration: [Tips.ConfigurationOption] = []) throws
}

Usually, you do this setup right when your app starts. For UIKit, this would be in the AppDelegate. For SwiftUI, you can do it directly in the @main App struct.

Here’s how I do it for my app, Fussion:

@main struct FussionApp: App {
  init() {
    do {
      try await Tips.configure()
    } catch {
      print("Failed to configure TipKit: \(error)")
    }
  }
  
  var body: some Scene {
    WindowGroup {
      ContentView()
    }
  }
}

With the initial setup done, we are ready to help us display useful tips to our users using SwiftUI.

Displaying the Tip

The TipKit team created TipView, making placing the views easier. We can add this TipView to any part of our app. I have a new tip in place — this time, I let the users know they can long-press to play a station.

@available(macOS 14.0, iOS 17.0, tvOS 17.0, watchOS 10.0, *)
struct PlayStationDirectlyTip: Tip {
  var title: Text {
    Text("Play the station!")
      .font(.tipTitle)
  }

  var message: Text? {
    Text("Long-press the cover art of the station to play it directly.")
      .font(.tipMessage)
  }

  var image: Image? {
    Image(systemName: "radio.fill")
  }
}

Smart move, and it makes the navigation even simpler in Fussion:

ScrollView {
  LazyVGrid(columns: columns) {
    NavigationLink(destination: ///)
    })
    .buttonStyle(.plain)
  }
  .padding(.horizontal)

  if #available(macOS 14.0, iOS 17.0, tvOS 17.0, watchOS 10.0, *) {
    TipView(PlayStationDirectlyTip(), arrowEdge: .top)
      .padding(.horizontal)
  }
}

And there you have it! This way, the users are guided and enriched with features they might have missed.

Conclusion

TipKit provides a straightforward yet powerful way to offer timely, context-sensitive tips in your apps. It supports all of Apple’s platforms and integrates cleanly with SwiftUI, UIKit, and AppKit. Properly setting the framework significantly improves your app's user onboarding and feature discovery.

So, implement TipKit in your app and help users understand new features seamlessly. Happy coding!

Exploring TipKit: Creating Your First Tip was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s 18th December already. I can’t believe that 2021 is almost over. It was like March a few days ago, and now it’ll be Christmas in a few days.

This year has been different for many of you, including me — a wild ride.

I went from getting offers to work as a full-time iOS engineer to rejecting them and risking working as a freelancer and a technical writer. And the biggest challenge — battling for life with COVID. The year ended on a good note when I decided to switch paths a little and land a role as a Developer Relations Engineer.

Rudrank on Twitter: "Some professional news: I joined @codemagicio as the Developer Relations Engineer! 🥳 / Twitter"

Some professional news: I joined @codemagicio as the Developer Relations Engineer! 🥳

I didn’t tick a single goal I planned for myself in the 2021 roadmap, and I’m glad it went that way. I slowly realise that life isn’t a to-do list to tick your goals and be happy about it. I did that in 2020, got my “dream” internship at Apple, and then it felt aimless.

Daniel Vassallo on Twitter: "2021 Year In ReviewAlmost nothing that I'm doing now I could have predicted to be doing this time last year. / Twitter"

2021 Year In ReviewAlmost nothing that I'm doing now I could have predicted to be doing this time last year.

I’ve learned about myself how I love to take ambitious challenges. Let’s refactor the whole codebase! Let’s push this big feature that’ll double the revenue in a week! Let’s write this blog post in a day!

I never succeeded in any of them and failed miserably instead.

I messed up the refactor.

The big feature broke in production because I wrote the code quickly.

And I intended to complete that post in a day? Well, that took me a month.

Continuous Improvement in 2022

Advocating for a CI/CD platform made me realise how I need a continuous integration process in my life too. Instead of refactoring the whole codebase, let’s take one non-crucial screen to refactor, send a pull request, make sure it works, and then move on to the next small thing. Instead of writing a post in a day, let’s focus on writing one section in a day. Achievable? Without any doubt.

It isn’t easy to maintain consistency, and it should be. This habit of trying to achieve everything at once has taken months to develop, and it’ll take months to break too.

Ed Latimore on Twitter: "Be consistent for 1 year and you'll surpass even your wildest ambition. / Twitter"

Be consistent for 1 year and you'll surpass even your wildest ambition.

Journaling

I used to write (like using a pen and paper) a lot a few years ago to curate my thoughts and emotions into bits and pieces of paper. It definitely helped me to understand what my mind hopes and what the reality is.

MIDE✦OLADELE on Twitter: "How to stop lying to yourself:Start journaling.Our minds avoid difficult conversations to remain comfortable.Write on your:* Thoughts* Emotions * Current situation You'll be able to review your thoughts and bring yourself to reality / Twitter"

How to stop lying to yourself:Start journaling.Our minds avoid difficult conversations to remain comfortable.Write on your:* Thoughts* Emotions * Current situation You'll be able to review your thoughts and bring yourself to reality

Early Conclusion

I’m still evaluating what value this newsletter provides and how to proceed further in 2020.

Do people like ramblings instead of newsletters filled with tech? I don’t know.

All I know is I want to be consistent with it, and if you loved what I wrote above, share it with your friends!

If you didn’t, do let me know your feedback, and if you want, you can unsubscribe.

Happy weekend!

1. Continuous Improvement in 2022 was originally published in Random Ramblings on Medium, where people are continuing the conversation by highlighting and responding to this story.

Working with the station is straightforward. Apple Music API has a dedicated endpoint, and we can use MusicKit to parse the station data.

User’s Personal Apple Music Station Endpoint

To fetch the current user’s personal Apple Music station, we use the following endpoint:

https://api.music.apple.com/v1/catalog/{storefront}/stations?filter[identity]=personal

The following endpoint returns an array of stations, and we can get the station data we want.

For example, this is what my station response looks like:

{
    "data": [
        {
            "id": "ra.u-04bcab05bb818ecf1abb70ff757",
            "type": "stations",
            "href": "/v1/catalog/in/stations/ra.u-04bcab05bb818ecf1abb70ff757",
            "attributes": {
                "isLive": false,
                "name": "Rudrank Riyam’s Station",
                "mediaKind": "audio",
                "artwork": {
                    "width": 2400,
                    "height": 2400,
                    "url": "https://is1-ssl.mzstatic.com/image/thumb/Features124/v4/7b/1d/f0/7b1df048-0017-8ac0-98c9-735f14849606/mza_7507996640781423701.png/{w}x{h}bb.jpg"
                },
                "url": "https://music.apple.com/in/station/rudrank-riyams-station/ra.u-04bcab05bb818ecf1abb70ff757",
                "playParams": {
                    "id": "ra.u-04bcab05bb818ecf1abb70ff757",
                    "kind": "radioStation",
                    "format": "tracks",
                    "stationHash": "CgoIByIGCIDRuo8f",
                    "hasDrm": false,
                    "mediaType": 0
                }
            }
        }
    ],
    "meta": {
        "filters": {
            "identity": {
                "personal": [
                    {
                        "id": "ra.u-04bcab05bb818ecf1abb70ff757",
                        "type": "stations",
                        "href": "/v1/catalog/in/stations/ra.u-04bcab05bb818ecf1abb70ff757"
                    }
                ]
            }
        }
    }
}

We can see that the data contains an array of Station objects. To use this in your Swift project with MusicKit, we use MusicDataRequest to decode it to MusicItemCollection<Station> structure.

Get User’s Personal Apple Music Station with MusicKit

We define an enum for potential errors, we might encounter:

enum PersonalStationError: Error {
  case invalidURL
  case notFound
}

This enum includes two cases: invalidURL and notFound, which represent possible issues we might run into while fetching the personal music station.

Next, we fetch the current country code which we use as a storefront:

let storefront = try await MusicDataRequest.currentCountryCode

After we have the storefront, we build the URL request using URLComponents and append the storefront to the path and include a query item to filter the personal station:

var urlComponents = URLComponents()
urlComponents.scheme = "https"
urlComponents.host = "api.music.apple.com"
urlComponents.path = "/v1/catalog/\(storefront)/stations/personal"
urlComponents.queryItems = [URLQueryItem(name: "filter[identity]", value: "personal")]

Then, we use the MusicDataRequest that handles both the authorisation and music user token for us:

guard let url = urlComponents.url else {
  throw PersonalStationError.invalidURL
}

let request = MusicDataRequest(urlRequest: URLRequest(url: url))
let response = try await request.response()

After getting the response, we decode the data into a collection of MusicKit’s Station:

let stations = try JSONDecoder().decode(MusicItemCollection<Station>.self, from: response.data)

Lastly, we get the first station from our stations list:

guard let personalStation = stations.first else {
  throw PersonalStationError.notFound
}

debugPrint(personalStation)

That’s it! This fetches your personal Apple Music station using MusicKit.

Printing the station to the console, I get the following for my station:

Station(
  id: "ra.u-04bcab05bb818ecf1abb70ff757",
  name: "Rudrank Riyam’s Station",
  isLive: false,
  url: "https://music.apple.com/in/station/rudrank-riyams-station/ra.u-04bcab05bb818ecf1abb70ff757"

Play User’s Personal Apple Music Station with MusicKit

To play this station, you need to set the queue of the player and play it:

do {
  guard let station = station else { return }
  ApplicationMusicPlayer.shared.queue = [station]
  try await ApplicationMusicPlayer.shared.play()
} catch {
  debugPrint(error)
}

Conclusion

Using MusicKit for fetching a user’s personal Apple Music station is simple. However, remember to handle potential errors appropriately and give clear feedback to your users.

Happy coding, and keep the station playing!

I introduced myself to the world of dynamic text sizes back in August 2019. My country’s popular food delivery apps didn’t change the text size when changing the system font size. (they still don’t) I wondered what APIs are required to increase the text sizes and alter the view accordingly.

In SwiftUI, using the system font text style automatically changes:

Text("Something cool goes in here.")
  .font(.body)

It also adjusts the view and the constraints accordingly when the size increases or decreases. But, as you increase the text size to the accessibility sizes (huge text), the view may truncate and look unreadable. You may have to create another different view structure to solve this.

Old Way — ContentSizeCategory

SwiftUI provides us with an environment ContentSizeCategory. Here’s an example from my app where I change the layout from a grid to a list when the size increases:

struct HomeGameTypeView: View {
  @EnvironmentObject var preferences: Preferences
  
  @Environment(\.sizeCategory) private var category
  
  var body: some View {
    if category >= .extraExtraLarge {
      ScrollView {
        LazyVStack {
          list
        }
      }
    } else {
      LazyVGrid(columns: [.init(), .init()]) {
        list
      }
    }
  }
  
  var list: some View {
    ForEach(GameTypeOption.allCases) { type in
      HomeGameTypeRow(selection: $preferences.gameTypeSelection, type: type)
    }
  }
}

New Way — DynamicTypeSize

In iOS 15, the ContentSizeCategory is deprecated and replaced by DynamicTypeSize. Rewriting the above example:

struct HomeGameTypeView: View {
  @EnvironmentObject var preferences: Preferences
  
  @Environment(\.dynamicTypeSize) var size // <- NEW
  
  var body: some View {
    if size >= .xxLarge { // <- NEW
      ScrollView {
        LazyVStack {
          list
        }
      }
    } else {
      LazyVGrid(columns: [.init(), .init()]) {
        list
      }
    }
  }
}

This can also limit the text sizes to a particular size (not recommended, in my opinion) or a range of sizes.

var content: some View {
  Text(item.name.uppercased())
    .font(.title)
    .dynamicTypeSize(..<DynamicTypeSize.accessibility1) // <- RANGE
    .foregroundColor(.primary)
}

I know that the title text style is large enough, and I don’t want it to go beyond the accessibility medium size.

DynamicTypeSize in Previews

To test different sizes in previews, you can add a constant size as an environment to the preview:

struct IntroductionView_Previews: PreviewProvider {
  static var previews: some View {
    IntroductionView()
      .environment(\.dynamicTypeSize, .accessibility1) // <- CONSTANT
  }
}

Large Content Viewer

If you’re constraining the text size, you can add the method accessibilityShowsLargeContentViewer(). When the user is on an accessibility text size, a long tap on the view shows an enlarged text size:

var body: some View {
  Button(action: action) {
    content
  }
  .buttonStyle(HomeButtonStyle(isSelected: false))
  .padding([.bottom, .horizontal], 8)
  .accessibilityShowsLargeContentViewer()
}

Although, note these words from the documentation:

Rely on the large content viewer only when items must remain small due to unavoidable design constraints. For example, buttons in a tab bar remain small to leave more room for the main app content.

Don’t use the large content viewer to replace proper Dynamic Type support. For example, Dynamic Type allows items in a list to grow or shrink vertically to accommodate the user’s preferred font size. Rely on the large content viewer only when items must remain small due to unavoidable design constraints.

Conclusion

Dynamic Type helps your users use your app for any text size, providing them with an exceptional experience. Using SwiftUI makes it easier to add Dynamic Type and structure the views accordingly.

I know it gets tougher as the views get more complex, but you can still try your best to make your apps accessible for at least xxxlarge sizes.

Want to Connect?

If you have a better approach, let me know on Twitter!

Using the New iOS 15 DynamicTypeSize in SwiftUI was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.