For years, ObservableObject and @Published were the standard way to connect your data models to your UI. With the release of iOS 17, Apple introduced the @Observable macro. This change simplifies how you write code while making your applications faster and cleaner.

The Old Way: ObservableObject

In the older system, you had to manually mark every property you wanted to track.

class ProfileViewModel: ObservableObject {
    @Published var name: String = ""
    @Published var age: Int = 25

    // Must mark every property manually
}

struct ProfileView: View {
    @StateObject var viewModel = ProfileViewModel()

    var body: some View {
        Text(viewModel.name)
    }
}

Drawbacks of this approach

• You must remember to mark every single property with @Published

• If you change the age property, the Text view for name still re-renders

• Boilerplate code increases as your models grow in complexity

• Managing @StateObject versus @ObservedObject can be confusing for beginners

The New Way: The @Observable Macro

The new system is smarter. It tracks which properties are actually being read by the view and only triggers a refresh when those specific values change.

@Observable
class Profile {
    var name: String = ""
    var age: Int = 25
}

struct ProfileView: View {
    @State var profile = Profile()

    var body: some View {
        VStack {
            Text(profile.name)
            TextField("Change name", text: $profile.name)
        }
    }
}

Benefits of @Observable

• All properties are automatically observed without extra keywords

• Views only re-render when a property they specifically use is modified

• You can use the standard @State and @Bindable wrappers

• It reduces memory overhead and improves app performance

Passing Data to Child Views: The @Bindable Wrapper

When you break your UI into smaller reusable components, you will inevitably need to pass your state down to a child view. In the legacy system, you would rely on @ObservedObject. With the new macro, the workflow changes slightly.

Here is exactly how you pass an observable object down the view hierarchy and create a two-way connection for editing.

@Observable
class UserSettings {
    var username: String = "Guest"
}

struct ParentView: View {
    // 1. Initialize the state in the parent
    @State var settings = UserSettings()

    var body: some View {
        VStack {
            Text("Welcome, \(settings.username)")
            
            // 2. Pass the object directly
            ChildEditView(settings: settings)
        }
    }
}

struct ChildEditView: View {
    // 3. Receive the object using @Bindable
    @Bindable var settings: UserSettings

    var body: some View {
        // 4. Use the $ syntax to create a two-way binding
        TextField("Edit Username", text: $settings.username)
            .textFieldStyle(.roundedBorder)
    }
}

How it works

Notice that ParentView creates the object using the @State wrapper. When it passes settings to ChildEditView, it simply passes the object instance directly.

Inside ChildEditView, we receive that object using the @Bindable property wrapper. This step is critical. The @Bindable wrapper does one specific job: it unlocks the ability to use the $ prefix. Without @Bindable, you could read the properties just fine, but you could not pass them to UI controls like a TextField or Toggle that require a two-way binding to modify the data.

ObservableObject vs. @Observable

Why Developers Still Use the Old System

Even though the new macro is superior, you will still see ObservableObject in many projects for a few key reasons. The most obvious is compatibility, since many apps still need to support iOS 15 or 16. Additionally, large legacy projects built on the Combine framework may require significant refactoring to switch.

A common strategy today is to keep your existing models as they are while using the @Observable macro for any new features you build. This allows for a gradual migration without breaking your entire codebase.

Switching to @Observable makes your SwiftUI apps cleaner and more predictable. It represents the modern approach to state management by removing the need for manually published properties and providing surgical precision for UI updates.

What’s Inside This Chapter:

• Decoding the Algorithm: How Apple and Google use Relevance, Quality, and Conversion to rank your app.

• ‘App Store vs Play Store’ Cheat Sheet: A side-by-side comparison of indexing rules, character limits, and metadata weights.

• Ranking Timelines: Why the App Store reflects changes in 24 hours while Google Play takes weeks.

• The 2-Week ASO Measurement Rule: A step-by-step framework to track organic growth and prove your strategy works.

• Keyword Indexation Secrets: Why your iOS description is for humans, but your Android description is for the algorithm.

If you feel confused about ASO terms and vocab, you can check out the ASO Dictionary from ASO Blueprint #2.

1. The Ranking Factors: Strong vs. Medium Influence

Not all data influences rankings equally. The algorithm prioritizes factors in a specific hierarchy.

STRONG Influence:

• App Title: This remains the single strongest ranking signal for both stores.

• Localized Product Page: Customizing your page for different regions significantly boosts visibility.

• Conversion (Installs per Keyword): If users search for a term and click your app, you win that keyword.

• Ratings: High star ratings are a gatekeeper for high volume visibility.

MEDIUM Influence:

• Download Velocity: The algorithm loves freshness and recent spikes in installs.

• App Performance: Stores actively downrank apps with high crash rates or battery drain issues.

• User Reviews: While important for conversion, they are a medium ranking factor on their own.

2. Apple vs. Google: The Indexing Split

The indexing rules determine how the store reads your app. You must treat them differently to succeed.

Strategic Takeaway:

• Apple App Store (iOS):

  • Focus: Title (30 chars), Subtitle (30 chars), and Keyword Field.

  • Strategy: Use unique keywords; do not repeat words from the title/subtitle in the keyword field.

• Google Play Store (Android):

  • Focus: Title (30 chars), Short Description (80 chars), and Long Description (up to 4,000 chars).

  • Strategy: Focus on keyword density (1 time per 250 characters is a safe bet). The algorithm is smarter and understands synonyms better.

3. The ‘Time to Impact’ Gap

The stores digest your metadata updates at different speeds. Patience is a necessary metric.

• Apple App Store: Changes are often visible and reflected in rankings the next day.

• Google Play: It typically takes one to two weeks for the system to re-index your app and adjust your position.

The ASO Blueprint Action Plan

1. The 2-Week Measurement Rule

The easiest way to see if your ASO worked is to compare organic downloads. Focus on two intervals. Look at the 2 weeks before your update and compare them to the 2 weeks after. If you see significant organic growth, your strategy is correct.

2. Focus on the Semantic Core

Users search for apps by describing features or services. Start your keyword selection with a semantic core rather than just suggestions. Use tools to find traffic indicators for your selected terms.

3. Maintain Technical Health

A buggy app will never rank first. Regularly check your developer console and Crashlytics for performance issues. Stable and fast apps are prioritized by the modern algorithm.

Mastering the basics of the algorithm is your foundation. See you next Sunday for the next part of the blueprint. We will explore the massive shifts in ASO Blueprint #5. The ASO in iOS 26 AI Era. We will learn how to rank when the AI is the gatekeeper.

If you need any further review or ASO consultancy, you can contact me directly at hello@sajidhasan.com

What’s Inside This Chapter:

• The Identity Pillar: Why Brand Defense is mandatory in 2026.

• The Discovery Engine: How to win Generic searches without a million-dollar budget.

• The Siphon Effect: Why big brands dominate and how you can pivot.

• The Action Plan: A step by step checklist for your next update.

Brand Keywords

Brand keywords are searches for your specific app name (e.g., "Instagram") or your company.

• User Intent: Navigational. They are looking for you.

• Conversion Rate (CVR): Extremely high, typically 50% - 80%.

• The Challenge: Competitors are getting aggressive. Even if you rank #1 organically, rivals will often bid on your name in Apple Search Ads (ASA) to sit directly above your result.

• The Strategy: Own your name in the Title, but don't waste characters repeating it in the subtitle or keyword field. Use those precious characters for features. Your brand "Defense" ensures that when someone looks for you, they find only you.

Generic Keywords

Generic keywords describe a problem, feature, or category (e.g., "AI Photo Editor," "Budget Tracker").

• User Intent: Exploratory. They have a problem, but haven't picked a winner yet.

• Conversion Rate (CVR): Lower than brand, typically 5% - 15%, but the volume is massive.

• The Strategy: Semantic Relevance. Modern algorithms now prioritize "Intent Clusters" over exact keyword matches.

  • Avoid the "Volume Trap": Don't chase high-volume head terms like "Fitness" if you're a new app. You’ll be buried by the giants.

  • The Pivot: Target Long-Tail Keywords (e.g., "HIIT workouts for busy moms"). These have lower competition and much higher conversion because the intent is specific.

Brand vs Generic Keywords: The Comparison

The "Siphon Effect" and How to Beat It

Big brands often "siphon" traffic from generic terms because of their massive authority. When a user searches "Music," Spotify usually wins, not because its ASO is necessarily better, but because its Store Authority is higher.

How to compete:

1. Niche Down: Instead of trying to rank for "Finance," target "Freelance Expense Tracker."

2. Visual Conversion: If you rank #5 for a generic term but your screenshots are significantly more engaging than the apps at #1-#4, the algorithm will eventually move you up because your Click-Through Rate (CTR) is higher.

If you feel confused about ASO terms and vocab, you can check out the ASO Dictionary from ASO Blueprint #2.

The ASO Blueprint Action Plan

To optimize your store listing this week, follow these three steps:

1. Stop Keyword Redundancy: Check your iOS keyword field or Google Play description. If your brand name is already in the Title, delete it from the other metadata fields. Use that space for a generic "Action" keyword instead.

2. The Subtitle Shift: Use your Subtitle (iOS) or Short Description (Android) to house your most important Generic + Long-tail phrase.

   • Bad: "The best app for your daily life."

   • Good: "Personal Budget & Daily Expense Tracker."

3. Analyze the Split: Look at your console data. If more than 90% of your downloads are coming from "Brand" searches, you have a Discovery problem. It's time to go on the offense.

See you next Sunday for the next part of the blueprint. We will be diving into the "Brain" of the app stores: ASO Algorithms 101, Understanding how app stores decide who stays on top.

If you need any further review or ASO consultancy, you can contact me directly at hello@sajidhasan.com

What’s inside?

• What SOLID really means in the context of Swift

• Practical examples you can relate to in iOS projects

• Common mistakes developers make while trying to “follow” SOLID

• How SOLID improves testing, scalability, and team collaboration

• SOLID iOS Interview questions to check your real understanding

Why SOLID matters in Swift projects

Swift gives us powerful tools: protocols, extensions, value types, generics. But without clear design principles, even modern Swift code can become messy.

SOLID helps you decide:

• When to create a protocol

• When to split a class

• How to structure dependencies

• How to make features easier to extend later

It is less about rules and more about writing code that survives growth. We need to use SOLID Principles for Better Swift Code in iOS Apps.

S: Single Responsibility Principle

A class should have only one reason to change.

In many iOS apps, ViewControllers often violate this. They fetch data, handle UI, manage state, perform navigation, and sometimes even format data.

When one class does too much, any small change risks breaking something unrelated.

Applying SRP in Swift often means:

• Moving networking to a service layer

• Using ViewModels for presentation logic

• Keeping ViewControllers focused on UI only

This separation makes the code easier to read, test, and modify.

Example:

Problem: One class is doing too many things.

class UserViewController: UIViewController {
    func fetchUser() { /* API call */ }
    func formatDate() -> String { /* formatting */ }
    func saveToCache() { /* caching */ }
}

Better: Split responsibilities.

class UserService {
    func fetchUser() { }
}

class DateFormatterService {
    func formatDate() -> String { "" }
}

class UserViewController: UIViewController {
    let service = UserService()
}

Now UI, networking, and formatting are separated.

O: Open/Closed Principle

Software entities should be open for extension but closed for modification. Instead of editing existing code every time a new requirement comes, you design it so new behavior can be added without touching old logic. In Swift, this is commonly achieved using protocols and protocol-oriented design.

For example, instead of modifying a payment class to support new methods, you define a PaymentMethod protocol and add new implementations as needed. Your existing code stays untouched, reducing risk.

Example:

Problem: Modifying existing class for every new case.

class PaymentProcessor {
    func pay(type: String) {
        if type == "card" { }
        else if type == "cash" { }
    }
}

Better: Extend with protocols.

protocol PaymentMethod {
    func pay()
}

class CardPayment: PaymentMethod {
    func pay() { }
}

class CashPayment: PaymentMethod {
    func pay() { }
}

class PaymentProcessor {
    func process(_ method: PaymentMethod) {
        method.pay()
    }
}

Add new payment types without touching old code.

L: Liskov Substitution Principle

Subtypes must be replaceable with their base types without breaking behavior. This issue appears when subclasses change expected behavior in surprising ways.

For example, if a subclass overrides a method but changes what it is supposed to do, parts of the app relying on the original behavior start failing.

In Swift, careful protocol design and avoiding unnecessary inheritance help maintain this principle. Favor composition over inheritance whenever possible.

Example:

Problem: Subclass changes expected behavior.

class Bird {
    func fly() { }
}

class Penguin: Bird {
    override func fly() {
        fatalError("Penguins can't fly")
    }
}

This breaks expectations.

Better: Design with proper abstraction.

protocol Bird { }

protocol FlyingBird: Bird {
    func fly()
}

class Sparrow: FlyingBird {
    func fly() { }
}

class Penguin: Bird { }

No broken assumptions.

I: Interface Segregation Principle

Clients should not be forced to depend on methods they do not use. Large protocols are common in iOS projects. A single delegate or manager protocol with many responsibilities forces conforming classes to implement unnecessary methods. Breaking large protocols into smaller, focused ones keeps implementations clean and reduces coupling. Swift protocols make this very natural when designed thoughtfully.

Example:

Problem: Fat protocol.

protocol Worker {
    func code()
    func test()
    func deploy()
}

Not everyone does all three.

Better: Split protocols.

protocol Coder {
    func code()
}

protocol Tester {
    func test()
}

protocol Deployer {
    func deploy()
}

Classes adopt only what they need.

D: Dependency Inversion Principle

High-level modules should not depend on low-level modules. Both should depend on abstractions. Instead of a ViewModel directly depending on a concrete API service, it should depend on a protocol.

This makes it easier to:

• Replace implementations

• Write unit tests with mock services

• Modify underlying systems without affecting business logic

This is one of the most powerful principles for testable Swift code.

Example:

Problem: Tight coupling to concrete class.

class UserViewModel {
    let api = APIService()
}

Hard to test and replace.

Better: Depend on abstraction.

protocol APIServiceProtocol {
    func fetch()
}

class APIService: APIServiceProtocol {
    func fetch() { }
}

class UserViewModel {
    let api: APIServiceProtocol

    init(api: APIServiceProtocol) {
        self.api = api
    }
}

Now you can inject a mock service for testing.

Common mistakes when applying SOLID

Many developers try to apply SOLID by creating too many protocols and abstractions too early. That leads to overengineering.

SOLID is not about adding layers. It is about removing unnecessary coupling and making future changes easier. Start simple. Introduce abstractions only when the need becomes clear.

How SOLID improves real iOS development

When SOLID is applied correctly:

• Features are easier to extend

• Refactoring becomes safer

• Unit testing becomes simpler

• Team members understand the code faster

• Bugs from side effects reduce significantly

Over time, the project feels organized rather than chaotic.

Frequently Asked SOLID iOS Interview Questions

If you truly understand SOLID, you should be able to confidently explain and apply these in real scenarios. Try answering these yourself.

• What problem does the Single Responsibility Principle actually solve in large iOS codebases?

• How would you apply the Open/Closed Principle using protocols in Swift?

• Can you share a real example where violating Liskov Substitution caused bugs?

• Why do large protocols become a maintenance issue, and how does Interface Segregation fix that?

• How does Dependency Inversion make unit testing easier in Swift projects?

• How do SOLID principles influence your choice between classes, structs, and protocols?

• Which SOLID principle do you think is most commonly violated in iOS apps and why?

Take time to articulate these answers from what you learned in this article. That exercise alone will prepare you far better than memorizing definitions.

SOLID is a survival guide for growing codebases. Swift gives you the tools. SOLID tells you how to use them wisely. When followed properly, your code stops feeling fragile and starts feeling scalable, readable, and future-proof.

For further guidance or consultancy, feel free to connect at hello@sajidhasan.com

When you dive into app marketing, you are immediately hit with an alphabet soup of acronyms and technical jargon. Knowing the difference between organic and motivated traffic, or understanding the nuance between an impression and a product page view, is what separates those who guess from those who grow. This article serves as your fundamental dictionary. It covers the core vocabulary you need to navigate the data and make decisions that actually move the needle.

What’s Inside This Post

In this article, we will break down the essential terminology into five distinct pillars:

• Traffic Types: Understanding where your users come from.

• Search Mechanics: How users see your app in the store.

• Keyword Strategy: The difference between short-tail and long-tail.

• User Metrics: Measuring loyalty, views, and unique users.

• Business Strategy: The financial and strategic side of ASO.

1. Decoding Traffic Sources

Before you can optimize, you must understand where your users come from. In 2026, Store algorithms heavily factor traffic source quality into ranking signals.

• Search Traffic

  High-intent users who find your app by typing a specific query into the search bar. This is the primary driver for utility and service apps.

• Organic Traffic

  The "holy grail." These are users who find and install your app naturally without clicking on a paid advertisement.

• Incentivized (Incentive) Traffic

  Paid installs where users receive a reward (virtual currency, points) for downloading. This traffic can temporarily increase download velocity, but modern algorithms may penalize apps if this traffic doesn't lead to genuine engagement.

• Browse (App Store) / Explore (Google Play)

  Discovery-based traffic. These users find your app via Top Charts, Category lists, or "Featured" placements (like the Today Tab).

2. The Mechanics of Search Visibility

How a user interacts with the Search Results Page (SERP) determines your app's success.

• Search Suggestions

  Predictive options are offered by the store as a user types. Optimizing for these "long-tail" suggestions is a key 2026 strategy.

• Impressions

  The number of times your app icon is seen in search results or browse lists. An impression is counted when your app appears on a store surface such as search results, charts, or featured placements.

• Product Page Views (PPV)

  The count of users who actually clicked your listing to view the full product page (description and screenshots).

• Apple Search Ads (ASA) Popularity Score

  A logarithmic scale (5–100) provided by Apple that indicates the relative popularity of a keyword compared to others in the store. Higher scores indicate relatively higher search popularity compared to other keywords.

3. Mastering Keyword Strategy

Keywords are the bridge between user intent and your product. They are specific words and phrases in textual metadata describing the application's function.

• The Semantic Core

  Your master list of all relevant search phrases that help people find your application.

• Short-tail Keywords

  Broad, 1-2 word phrases (e.g., "Fitness"). High volume, but extremely high competition.

• Long-tail Keywords

  Specific, 3+ word phrases (e.g., "Yoga for beginners at home"). Lower volume, but much higher conversion rates due to specific intent.

• Backlinks

  While primary for Web SEO, in Google Play, these external links primarily drive referral traffic and brand discovery, but are not a direct ranking factor.

4. User Behavior and Performance Metrics

Once a user finds you, the "ASO work" shifts to conversion and retention.

• Conversion Rate (CVR)

  In ASO, this specifically refers to Store Conversion. CVR measures how many Product Page Views convert into Installs.

$$\text{CVR} = \frac{\text{Total Installs}}{\text{Unique Impressions}}$$

• Install

  A successful download completion. Note: An "Install" is tracked by the store even if the user hasn't opened the app yet.

• Retention Rate

  The percentage of users who return to the app after a specific timeframe (typically measured as Day 1, Day 7, and Day 30).

• Sessions / Active Users (DAU/MAU)

  The industry standard for "Attendance." It measures how many unique users actually open and interact with the app daily or monthly.

5. Conversion and Business Strategy

Finally, we look at the metrics that impact the bottom line and the tools used to improve them.

• Creative Assets (Icon, Screenshots, Preview Video)

  These are the creative elements that drive conversion. Visual Assets include your App Icon, Screenshots, and Preview Video. They are the primary tools you have to convince a user to install after they have found you via search.

• A/B Testing

  This is the scientific method of optimization. A/B Testing involves showing two variations of your app store page (e.g., two different icons or screenshot sets) to different segments of users to determine which version results in a higher conversion rate.

• User Acquisition (UA) and CPI

  User Acquisition (UA) is the process of acquiring new users on an app or platform. A common model for this is CPI (Cost Per Install), where publishers place digital ads across channels to drive installs.

• Localization

  To scale globally, you need localization. This is the process of adapting all textual information (description, title, subtitle) from one language to another, taking into account cultural characteristics based on search traffic.

Mastering these definitions is the first step toward ASO proficiency. By understanding the difference between short-tail and long-tail keywords, or monitoring your conversion rate and retention alongside install growth, you can move from intuition-based decisions to data-driven growth. This ASO Dictionary: Key Concepts and Vocabulary to be an ASO Expert | ASO Blueprint #2 serves as your foundational guide as you continue to build your expertise.

See you next Sunday for the next part of the blueprint. We will be diving into the strategic side of growth: Where to focus for ASO success> Brand vs. Generic Keywords.

Need expert guidance?

If you need any further review or ASO consultancy, you can contact me directly at hello@sajidhasan.com

By Q2 2026, Google will stop releasing new versions of the Maps, Places, and Navigation SDKs via CocoaPods entirely. Version 11.0 and all future updates will be exclusive to Swift Package Manager (SPM).

Failing to migrate leaves your app stuck on an outdated SDK, missing new features, performance improvements, and vital security updates. Staying with old dependency managers poses both technical debt and security risks in the fast-paced iOS landscape.

What is Inside This Guide

• Strategic Audit: Deciding between a full or hybrid migration.

• Step by Step Execution: Stripping legacy files without breaking the build.

• Official Sources: Verified links to Google’s announcements and documentation.

1. Choose Your Migration Path

Depending on your project's complexity, you have two ways to handle this.

Option A: The Full Migration (Preferred)

Use this if all your dependencies support SPM. We highly recommend deleting CocoaPods entirely to reduce build overhead and simplify your CI/CD pipeline.

Run these in your terminal:

sudo gem install cocoapods-deintegrate cocoapods-clean
pod deintegrate
pod cache clean --all
rm Podfile Podfile.lock
rm -rf Pods/
rm -rf YourProject.xcworkspace

From now on, use your .xcodeproj file to manage the project.

Option B: The ‘Hybrid’ Approach

Use this if you have legacy pods that do not support SPM yet. You can keep CocoaPods for those specific libraries while moving Google Maps over to SPM.

1. Modify your Podfile: Delete only the Google Maps related lines (e.g., pod 'GoogleMaps').

2. Update your pods: Run pod install in the terminal. This removes the Google Maps binary while leaving your other pods intact.

3. Clean Cache: In Xcode, press Cmd + Shift + K to ensure no old headers remain.

2. Integration via Swift Package Manager

Now that the old SDK is removed, follow these steps to link the modern version:

1. Open your project in Xcode.

2. Navigate to File > Add Package Dependencies.

3. Enter the URL: https://github.com/googlemaps/ios-maps-sdk.

4. Set the Dependency Rule to Up to Next Major Version (target 11.0.0 for the Q2 release).

5. Select the specific SDKs your app needs.

CocoaPods vs. SPM for Google Maps SDK: The 2026 Breakdown

While CocoaPods served us for years, Google’s shift to SPM is required to unlock Version 11.0+

Official Sources and Documentation

For technical verification and deeper reading, consult these primary sources:

• Google Maps Release Notes: August 18, 2025 Announcement

• Official Migration Guide: Removing CocoaPods Dependencies | Google for Developers

• Official SPM Repository: Google Maps iOS SDK on GitHub

Need more guidance?

If your team is facing complex dependency conflicts or needs help refactoring a legacy map implementation, I’m available for technical consultation.

Reach out at: hello@sajidhasan.com

What’s inside?

• The 70% Rule: Why search is the dominant discovery engine in 2026.

• The Intent Gap: Why organic users stay 150% longer than paid ones.

• Strategy Shift: When to focus on Brand vs. Generic search.

Statistical Data Source: 42matters - App Store Statistics (accessed: 29 January 2026)

The SEO of the Mobile World

At its core, ASO is simply SEO for app stores. It is a process designed to do one thing: maximize visibility and conversion rates.

While paid user acquisition stops working the moment you stop paying, ASO is an investment in your app organic foundation. It is the most cost efficient way to acquire users because success depends totally on your effort, not just your budget.

The 70% Rule: Why Search Dominates

If you think most users find apps through social media ads, look at the latest data. According to official Apple Search Ads insights for 2026, 70% of App Store visitors use search to discover apps. Even more telling, 65% of all downloads happen directly after a search.

This means the vast majority of your potential audience is actively looking for a solution. If your app is not optimized to appear in those search results, you are invisible to nearly three quarters of the market.

The Intent Gap: Quality Over Quantity

Not all installs are created equal. One of the most critical metrics for any product manager is the Retention Rate.

Recent data reveals a striking difference: customers acquired through search have a 150% higher retention rate than users acquired through paid campaigns. Organic users discover your app because they have intent. They were searching for a specific solution, found your app, and chose it. This makes them more loyal and more likely to monetize over time compared to paid users who may have been interrupted by an ad.

Context Matters: Brand vs. Generic Keywords

Your ASO strategy depends entirely on your product type.

• The Brand Challenge:

  If you launch a new messenger app, you will struggle with generic search traffic because most users search for specific names like Facebook, Snapchat, or Viber.

• The Generic Opportunity:

  If you have a News, Music, or Dating app, you have massive potential to gain installs from generic keywords like dating app or music player.

We will have a dedicated, detailed Brand vs. Generic Keywords deep dive blog in a future ASO Blueprint to help you master this.

ASO is not just a marketing task. It is the backbone of your growth strategy. Whether you are an indie developer or leading a product team, optimizing your metadata and visuals is a must have to reach relevant users and drive sustainable downloads.

See you next Sunday for the next part of the blueprint. We will deep dive into the ASO Dictionary (key concepts and vocabulary we must know to be an ASO expert).

What’s inside?

This guide explores the 5 primary iOS notification architectures, comparing their technical triggers with high-level UX strategies to help you choose the right communication tool for your users.

Quick Strategy Comparison: Technical Choice vs. Business Value

1. Local Notifications: Optimizing for Offline Reliability

Best for: Personalized reminders and time-sensitive tasks without server dependency.

Local notifications are triggered by the device's internal clock. From a UX perspective, they are the most reliable way to provide value without requiring an internet connection.

• Key Use Cases: Medication trackers, daily habit reminders, and "Drink Water" alerts.

• Permission Requirement: Requires explicit UNUserNotificationCenter authorization.

• Example: “Don’t forget your 9 AM hydration goal!”

2. Remote (Push) Notifications: Driving Real-Time User Action

Best for: Connecting the user to external events and dynamic updates.

Sent via Apple Push Notification service (APNs), these are the gold standard for re-engaging users.

• Key Use Cases: Chat messaging, e-commerce order tracking, and breaking news.

• GEO Strategy: Ensure payloads are concise; high-relevance alerts reduce the likelihood of "Notification Muting."

• Example: “Your order has been shipped and is on its way!”

3. Silent Notifications: The Secret to Seamless Data Synchronization

Best for: Background updates that prevent "Pull-to-Refresh" latency.

Silent notifications (using content-available: 1) request a background wake to download data without alerting the user.

• UX Win: By the time the user opens the app, the content is already fresh. This creates a "premium" feel by eliminating loading spinners.

• Note: iOS uses intelligent throttling to protect battery life, so these should be used for non-critical data sync.

4. Rich Push Notifications: Increasing Conversion with Interactivity

Best for: Deep engagement and secure communication.

Rich notifications use Service Extensions to add images, GIFs, and action buttons.

• Strategic Advantage: They allow users to complete tasks (like replying to a message or approving a request) without leaving the Lock Screen.

• Security Feature: A key tool for End-to-End Encryption, as they allow for on-device decryption of sensitive data.

5. Custom In-App Notifications: Enhancing the Active User Experience

Best for: Real-time feedback while the app is in the foreground.

Using NotificationCenter for internal broadcasting, these alerts guide the user through their current journey without cluttering the system-wide Notification Center.

• Example: “Settings saved successfully”

Critical Alerts: The Exception for Urgent Communication

For apps in Health, Security, or Emergency services, Critical Alerts can bypass "Do Not Disturb" and the "Mute" switch. This is a high-trust entitlement from Apple used to ensure life-critical information is never missed.

Strategy Guide: How to Maximize Engagement Without "Notification Fatigue"

To ensure your notification strategy scales, follow these UX Best Practices:

1. Contextual Awareness: Don't send a Push if the user is in the app; use an In-App alert instead.

2. Reduce Friction: Use Rich Notifications so users can interact instantly.

3. Prioritize Privacy: Use Silent Notifications for background work to keep the UI clean.

4. Value-First Approach: If an alert doesn't help the user, it’s spam. Every notification should provide a "Next Step."

In 2026, the difference between a high-retention app and one that gets deleted is context. By leveraging the right mix of Silent syncs and Rich interactivity, you transform your app from an interruption into an indispensable tool.

…and then the brain hits pause:

• Should it be an open eye when the password is hidden?

• Should it be a closed eye when the password is hidden?

• What happens after the user taps?

Let’s unpack this tiny but surprisingly common UX debate.

Two Common Approaches

Option 1: Open Eye = Tap to reveal password

• Eye icon (👁️) = Password is hidden → tapping it reveals password

• Eye-slash icon (🙈) = Password is visible → tapping it hides password

Pros: Suggests the action.
Cons: Technically shows the opposite of the current state.

Option 2: Open Eye = You’re seeing the password

• Eye icon (👁️) = Password is visible

• Eye-slash icon (🙈) = Password is hidden

Pros: Matches the meaning of the icon.
Cons: May confuse users who assume the icon is a button to reveal the password.

Alternatives to Consider

• Use text: "Show" / "Hide" — like LinkedIn

• Use a checkbox with a label (☐ Show password) — like Google

• Use a toggle switch (less common but clearer)

• Skip the toggle if you're using Apple’s secure autofill

What Do the Giants Do?

\Checked on July 30, 2025.*

Google

• Uses a checkbox labeled Show password under the input field

• No icon, no visual toggle. Just plain and accessible.

LinkedIn

• Uses a text toggle button that says Show or Hide

• Appears inside the password field on the right side

Facebook

• Uses the Open Eye = You’re seeing the password approach

• No label or text, just the visual indicator

Apple & Microsoft

• Do not use any visibility toggle at all

• Prioritize security and assume passwords are masked for a reason

So... What’s the Standard?

Short answer: Both are technically acceptable.

Long answer: It depends on the UX logic you want to prioritize.

There’s no official Apple Human Interface Guidelines or Material Design guideline that mandates either approach, which is why different teams do different things.

However, the most intuitive and commonly accepted UX today is:

• Default: Crossed eye (password is hidden)

• Tapping shows password → icon switches to open eye

• Optional: Add a tooltip or accessibility label for extra clarity

There’s no absolute “standard,” but consistency and clarity should always win.

1. Optionals in Swift

Interviewers often start here to test your Swift fundamentals. You’re expected to know what optionals are, but your job is to show you understand why Swift has them and how to use them safely.

Your Approach:

• Start with the concept: An ‘optional’ is a type that can hold a value or be nil.

• Mention the real-world use case: Any situation where a value may or may not exist. For example: API response, user input, etc.

• Explain unwrapping techniques:

  • Optional Binding (if let, guard let): The preferred and safest methods.

  • Optional Chaining: For safely accessing properties or calling methods on an optional.

  • Nil-Coalescing Operator (??): Providing a default value if the optional is nil.

  • (Briefly mention force unwrapping (!) as something to largely avoid in production code, highlighting its dangers.)

2. Struct vs Class

This is a chance to demonstrate your understanding of Swift’s type system and memory model.

Your Approach:

• Set the stage:

  • Structs are value types (copied when passed or assigned).

  • Classes are reference types (passed by reference, meaning multiple variables can point to the same instance).

• Mention storage:

  • Structs are typically stored on the stack (for performance and simplicity)

  • Classes stored on the heap (allowing for shared instances and more complex object graphs)

• Examples: Provide simple, clear examples of when you would choose a struct (e.g., small data models, thread safety) versus a class (e.g., shared mutable state, inheritance).

• Key Features: Discuss features like inheritance (classes only), deinitializers (classes only), and mutability behavior.

Goal:

You’re not just showing that you know Swift. You’re showing that you make thoughtful architecture choices.

3. Memory Management in Swift

Every iOS app deals with memory. Interviewers want to see if you can keep your app healthy and performant.

Your Approach:

• Start with ARC: Swift uses Automatic Reference Counting to manage memory.

• Define how it works: Explain how ARC automatically manages memory by tracking strong references to instances. Each object has a reference count. When it drops to 0, it's deallocated.

• Talk about Strong vs Weak vs Unowned references:

  • Strong: The default, increments the reference count.

  • Weak: Does not increment the reference count. Used to break retain cycles when the other object has a shorter or equal lifetime (e.g., delegates). weak references are automatically set to nil when the object they point to is deallocated.

  • Unowned: Does not increment the reference count. Used when you're sure the other object will have the same or longer lifetime (e.g., capturing self in closures when self is guaranteed to exist). unowned references are not optional and are assumed to always have a value.

• Bring up retain cycles: especially in closures or between two objects that hold strong references to each other.

• Connect back to practice: Use [weak self] in closures, especially in view controllers and async tasks.

Goal:

Make the interviewer feel confident that their code is in good hands.

4. App Architecture

You’ll likely get a question about how you structure your codebase. This is your chance to show that you think about scalability and maintainability.

Your Approach:

• Acknowledge MVC (Model-View-Controller): Talk about its simplicity, and also its limitations (especially the "Massive View Controller" problem).

• Introduce MVVM (Model-View-ViewModel):

  • ViewModel separates logic from the ViewController

  • Easier to test, reuse, and reason about

  • Works well with Combine or SwiftUI

• Mention VIPER (View-Interactor-Presenter-Entity-Router) if relevant:

  • A more opinionated and rigid architecture, offering clearer separation of concerns

  • Use in large teams or modular projects

• Why a Specific Architecture?: Be prepared to discuss the pros and cons of your chosen architecture and why it's suitable for different project sizes or complexities.

5. Building a Feature

This is usually an open-ended question like “How would you build a chat screen?” It tests how you think, design, and communicate.

Your Approach:

• Step 1: Understand the requirement

  • Don't jump straight to coding. Take a moment to understand the requirements fully. Ask clarifying questions about scope, constraints, and dependencies.

• Step 2: Break down the components

  • UI: views, controllers, SwiftUI or UIKit

  • Data: models, persistence, networking

  • Logic: ViewModel, managers, business logic

• Step 3: Pick an architecture

  • MVC for simple

  • MVVM or VIPER for more structured needs

• Step 4: Mention tools and techniques

  • URLSession or Alamofire?

  • Local storage with Core Data or Realm?

• Step 5: Think of the user

  • Error handling

  • Loading states

  • Empty states

• Step 6: Talk about testing

  • Unit testing the ViewModel

  • UI tests for flow

Goal:

You are not just solving a problem. You are architecting a thoughtful, reusable, and user friendly solution.

Final Thoughts

Interviewers don’t just want the right answer. They want to see how you think. That’s why the best prep isn’t memorizing terms, but learning how to explain the why behind every decision you make.

By mastering these key areas, from fundamental Swift types and memory management to advanced architectural patterns and practical feature implementation, you'll be well on your way to acing your next iOS development interview.

Understand the core concepts. Practice explaining them simply. And always tie your answers back to real world usage. That’s how you stand out. Good luck!

Get prepared with my full iOS Interview Guide Blog Series:

https://blog.sajidhasan.com/series/ios-interview

iOS Interview Series covers essential topics for mastering iOS development interviews, from Swift basics to advanced concepts.

Clean code isn’t just about satisfying the compiler. It’s about writing something your future self and your team won’t dread revisiting. One easy win? Start by naming your boolean variables right.

This blog focuses on Swift, but these naming principles apply to any language.

As iOS developers, we spend a lot of time dealing with logic and states. Yet sometimes, our code reads more like cryptic commands than understandable sentences.

Like Steve Jobs once said:

“Simple can be harder than complex. You have to work hard to get your thinking clean to make it simple.”

So let’s simplify and make our code cleaner by prefixing booleans like we mean it.

The Boolean Naming Cheatsheet

Here’s a quick rulebook I follow and it works not just for Swift, but pretty much any language:

is — For states

Use is when you're expressing the current state of something.

Bad:

if active { ... }

Good:

if isActive { ... }

Now it reads like English. Is active?

has — For ownership or possession

Use has when referring to something your object holds or owns.

Bad:

if subscription { ... }

Good:

if hasSubscription { ... }

Does it have a subscription?

should — For expectations or conditions

Use should to indicate what ought to happen next.

Bad:

if retry { ... }

Good:

if shouldRetry { ... }

We’re no longer wondering if "retry" is a flag, a method, or a mood. It’s an expectation, and it tells us clearly what to do.

can — For capabilities

Use can when referring to permissions or abilities.

Bad:

if edit { ... }

Good:

if canEdit { ... }

It’s not just about editing, it’s about whether the user can edit. Huge difference in clarity.

Now read it like English

A good rule of thumb: your if statements should read like a sentence:

if user.canEdit && user.hasSubscription && !user.isBlocked {
    showEditor()
}

Clean, understandable, and super readable, even for someone new to the codebase.

Final Thoughts

Writing clean code is a habit, not a plugin. These boolean prefixes may seem small, but they can dramatically improve the readability and maintainability of your code, especially when working in teams or revisiting old projects.

Swift is beautiful. Let’s write like it.

Getting Started with Skip

1. Prerequisites

Ensure you have the following installed on your macOS system:

• Xcode (for iOS development)

• Android Studio (for Android emulator)

• Homebrew (for package management)

If Homebrew is not installed, you can install it from here: https://docs.brew.sh/Installation

2. Install Skip

To install Skip, run the following command in your terminal:

brew install skiptools/skip/skip

Once installed, verify the setup with:

skip checkup

This command checks for missing dependencies and ensures everything is ready.

3. Create a Dual-Platform App

To initialize a new Skip project, use the following command:

skip init --appid=bundle.id project-name AppName

• bundle id: Your app's unique identifier (e.g., com.example.myapp)

• project-name: The folder where your project will be created.

• AppName: The display name of your app.

Example Command:

skip init --open-xcode --appid=com.sajidhasan.testskip test-skip TestSkip

--open-xcode flag automatically opens the project in Xcode after initialization.

4. Preparing the Android Emulator

The skip init command generates a working template, but before building and running the app, you need to have an Android emulator up and running.

1. Open Android Studio.app.

2. Go to Virtual Device Manager (from the ellipsis menu on the Welcome screen).

3. Click Create Device and follow the steps to set up a virtual Android device.

4. Once created, Launch the emulator.

Ensure the emulator is running before building your app.

5. Explore and Build

Once your project is set up:

1. Open the Xcode workspace if it is not already open.

2. Write your Swift code as usual.

3. Use Xcode to build and run the app on both iOS and Android simulators.

Final Thoughts

And that’s it. You are now equipped with Skip. Explore more functionalities from the Skip documentation and discover what you can achieve with this tool. Happy coding!

I would love to connect with you on LinkedIn. Here’s my profile: https://www.linkedin.com/in/sajidshanta/

Before starting, ensure you have the required setup for Apple Intelligence: iOS 18.1 or later, iPadOS 18.1 or later, and macOS 15.1 or later. Now, Create a new SwiftUI project, and let’s get started.

Get the complete code from GitHub(click here) and follow the steps below to understand the implementation.

First, Import ImagePlayground and PhotosUI in ContentView.swift just after importing SwiftUI.

Next, create five variables:

1. An environment variable supportsImagePlayground to check if the device supports Image Playground.

2. An empty string imageGenerationConcept, will represent the user's prompt.

3. A Boolean variable to determine whether Image Playground is currently displayed.

4. An optional variable for an avatar image.

5. A variable for a photo picker item.

import SwiftUI
import ImagePlayground
import PhotosUI


struct ContentView: View {

    @Environment(\.supportsImagePlayground) var supportsImagePlayground
    @State private var imageGenerationCooncept = ""
    @State private var isShowingImagePlayground = false

    @State private var avatarImage: Image?
    @State private var photosPickerItem: PhotosPickerItem?

Now, build a profile UI, which includes a photo picker for selecting a profile picture, a name and title section, and a text field where users can enter a prompt for AI-generated avatars (if Image Playground is supported). A button allows users to trigger AI image generation, and the generated avatar updates dynamically.

Let's explain this step by step:

1. Structure and Layout

VStack {
    HStack {
        // code..
    }
}

2. Profile Picture Selection

Create a photo picker to select an image. Default to a system icon "person.circle.fill" if no image is selected. The image should be resizable, mint-colored, clipped into a circle, and set to 100x100 pixels.

PhotosPicker(selection: $photosPickerItem, matching: .not(.screenshots)) { 
    (avatarImage ?? Image(systemName: "person.circle.fill"))
        .resizable()
        .foregroundStyle(.mint)
        .aspectRatio(contentMode: .fit)
        .frame(width: 100, height: 100)
        .clipShape(.circle)
}

3. Name and Title

Display a name and job title.

VStack(alignment: .leading) {
    Text("Sajid Hasan").font(.title.bold())
    Text("iOS Developer").bold().foregroundStyle(.secondary)
}

4. Checking for Image Playground Support

If the device supports Image Playground, display a text field and a button for generating an AI avatar. If not, provide appropriate feedback.

if supportsImagePlayground {

5. Avatar Description Input

Create a text input field for prompts to generate images and a button to trigger AI avatar creation.

TextField("Enter avatar description", text: $imageGenerationCooncept)
    .font(.title3.bold())
    .padding()
    .background(.quaternary, in: .rect(cornerRadius: 16, style: .continuous))


Button("Generate Image", systemImage: "sparkles") {
    isShowingImagePlayground = true
}
.padding()
.foregroundStyle(.mint)
.fontWeight(.bold)
.background(
    RoundedRectangle(cornerRadius: 16, style: .continuous)
        .stroke(.mint, lineWidth: 3)
)

6. Handling Image Selection

When the image is selected from photo picker, asynchronously load the image and update avatarImage.

.onChange(of: photosPickerItem) { _, _ in
    Task {
        if let photosPickerItem, let data = try? await photosPickerItem.loadTransferable(type: Data.self) {
            if let image = UIImage(data: data) { 
                avatarImage = Image(uiImage: image) 
            }
        }
    }
}

7. Using Image Playground

Present Image Playground sheet with prompt string and selected image. After AI processing, it will return a URL of the generated image.

.imagePlaygroundSheet(
    isPresented: $isShowingImagePlayground,
    concept: imageGenerationCooncept,
    sourceImage: avatarImage) { url in

8. Updating the Avatar with AI Image

Loads the AI-generated image from the url and sets it as the new avatar image.

if let data = try? Data(contentsOf: url) {
    if let image = UIImage(data: data) {
        avatarImage = Image(uiImage: image)
    }
}

9. Handling Cancellation

Clear the description if the user cancels the AI avatar generation.

onCancellation: {
    imageGenerationCooncept = ""
}

10. Build Something Diffrent

I would love to connect with you on LinkedIn. Here’s my profile: https://www.linkedin.com/in/sajidshanta/

More related resources:

https://developer.apple.com/apple-intelligence/

https://developer.apple.com/documentation/imageplayground

https://youtu.be/fjtWpQGs5lU?si=u1-qLRRuK2WSQdSA

I've taken inspiration from Teal's website for this article. I believe it will be helpful to share my insights and create a guide to assist fellow iOS developers in their upcoming interviews. Let's get started!

Steps to Ace Your iOS Developer Interview

1. Master the Fundamentals

Ensure you have a strong understanding of Swift or Objective-C. Comprehend core concepts such as memory management, concurrency, and error handling. Stay updated by reviewing the latest iOS SDK and Apple's Human Interface Guidelines.

2. Understand iOS-Specific Technologies

Familiarize yourself with essential frameworks and APIs such as UIKit, Core Data, and Core Animation. Know how to work with RESTful APIs and understand networking concepts within the context of an iOS app.

3. Review Your Past Projects

Be prepared to discuss your previous work, the challenges you faced, and how you overcame them. Highlight any unique solutions or optimizations you implemented.

4. Practice Coding Challenges

Sharpen your problem-solving skills by tackling coding challenges on platforms like LeetCode or HackerRank, focusing on algorithms and data structures commonly used in mobile app development.

5. Prepare for System Design Questions

Understand how to design scalable systems. Be prepared to discuss architecture choices for hypothetical app scenarios, considering performance, maintainability, and user experience.

6. Stay Updated on Apple's Ecosystem

Keep up with the latest developments in the iOS world, including new features in the latest version of iOS, Swift language updates, and changes to the App Store guidelines.

7. Mock Interviews

Practice mock interviews focusing on technical, system design, and behavioral questions. Use feedback to improve your answers and presentation skills.

8. Prepare Your Portfolio

Have your portfolio of apps ready, preferably with links to the App Store or GitHub. Be prepared to explain your design and development process for each project.

9. Develop Questions to Ask

Prepare thoughtful questions about the company's tech stack, development processes, and culture. This demonstrates your interest in the role and helps you evaluate if the company is the right fit for you.

By following these steps, you will be prepared to address both the technical and non-technical aspects of the interview. Your preparation will enable you to confidently articulate your skills and experiences, thus making a strong impression on your potential employer. Best of luck with your interviews!

Get prepared with my full iOS Interview Guide Blog Series:

https://blog.sajidhasan.com/series/ios-interview

iOS Interview Series covers essential topics for mastering iOS development interviews, from Swift basics to advanced concepts.

Geometry Reader is a useful tool for any SwiftUI developer as it allows us to get the exact size and location of objects on the screen. Additionally, the GeometryReader is adaptive when the device rotates. It is the perfect helper if we want to resize our view when a user switches from portrait to landscape mode (or vice-versa).

Let's take a look at a basic example of how to use the Geometry Reader. We'll start with an HStack containing two rectangles, one coloured red and the other blue. By default, SwiftUI automatically resizes our objects to be the same size, but what if we want one rectangle to be two-thirds of the screen while the other is one-third?

Here's a code example:

HStack {
  Rectangle()
    .fill(Color.red)
    .frame(width: UIScreen.main.bounds.width * 0.66)

  Rectangle()
    .fill(Color.blue)
    .frame(width: UIScreen.main.bounds.width * 0.33)
}

However, we'll quickly run into issues with this approach when we rotate the device. The width of the red rectangle is still two-thirds of the width of the device, even though it's not taking into account the device's new height. This is where Geometry Reader can help us.

Using Geometry Reader, we can dynamically calculate the size and location of the rectangles based on the current screen's dimensions, ensuring that they are always the correct size and in the correct location. Here's how we can update our previous example to use Geometry Reader:

HStack {
  GeometryReader { geo in
    Rectangle()
      .fill(Color.red)
      .frame(width: geo.size.width * 0.66)
  }

  GeometryReader { geo in
    Rectangle()
      .fill(Color.blue)
      .frame(width: geo.size.width * 0.33)
  }
}

In this updated example, we're using two Geometry Readers to calculate the size of the rectangles dynamically. By passing in the geo parameter, we can access the size of the Geometry Reader and use it to calculate the width of each rectangle.

While the Geometry Reader can be a powerful tool for SwiftUI developers, it's essential to keep in mind that it can be expensive and slow down the UI when overused. It's best to try and build screens without using a Geometry Reader if possible, but if we do need to use one, make sure to use it sparingly.

In conclusion, the Geometry Reader is an incredibly useful tool for SwiftUI developers looking to add more dynamic animations and effects to their apps. With its ability to calculate the size and location of objects on the screen, we can make our apps more engaging and interactive, improving the user experience.

What is the iOS App Life Cycle?

The iOS app life cycle refers to the different states that an iOS app goes through as it is launched, runs, and eventually terminated by the user or the system. The app can be in one of 5 states: Not Running, Inactive, Active, Background, and Suspended. Let's explore these states in more detail.

1. Not Running State:

The Not Running state is when an app is not running at all. This is the app's initial state, and it's like when we haven't opened an app in a while or when we restart our phone. The app is not in memory and needs to be relaunched.

2. Inactive State:

The Inactive state is when the app is in the foreground but is not receiving events. This can happen when a phone call interrupts the app, and the app will move to the Inactive state, allowing the phone call to take precedence over the app.

3. Active State:

The Active state is when the app is in the foreground and is receiving events. This is the state in which an app spends most of its time, as it's actively being used by the user.

4. Background State:

The Background state is when the app runs in the background and executes code. This is the state where an app transitions to when the user presses the Home button or switches to a different app.

5. Suspended State:

The Suspended state is when the app is still in the background but is no longer executing code. The system can terminate the app in this state to free up resources.

Real-Life Examples:

Let's see some real-life examples of how the iOS app life cycle works.

Suppose you're using a messaging app, and you receive a notification from another app. In this case, the messaging app will move to the Inactive state, allowing the other app to display its notification. Once you're done with the notification, you'll go back to the messaging app, which will move back to the Active state.

Another example is when you're listening to music on your phone and then decide to browse the internet. As you switch to your browser, the music app will move to the Background state, and if you're not actively using the app for a while, it might move to the Suspended state.

Wrap-up

In conclusion, Understanding the iOS app life cycle is essential for developing efficient and effective apps. By knowing how an app transitions through its different states, we can optimize our app's performance and make it more user-friendly. With these tips in mind, we can create innovative apps that stand out in the crowded world of app development. With Steve Jobs' words in mind, "Innovation distinguishes between a leader and a follower," it's crucial to stay innovative and up-to-date with the latest developments in app development.

There are two methods to add documentation to our Swift code in Xcode: triple-slash (///) comments and block (/** */) comments.

Triple-slash Comment (///)

Triple-slash comments are typically used for concise, single-line documentation. They are displayed in the Quick Help panel in Xcode and are a quick way to add documentation for a specific piece of code.

Here is an example of triple-slash documentation for a function in Swift:

/// Returns the sum of two numbers.
///
/// - Parameters:
///   - a: The first number.
///   - b: The second number.
/// - Returns: The sum of `a` and `b`.
func add(a: Int, b: Int) -> Int {
    return a + b
}

Block Comment (/** */)

Block comments, denoted by /** */, are more suitable for longer, multi-line documentation. These comments are displayed as a standalone document in the documentation browser, allowing for more thorough explanations and examples.

Here is an example of block documentation for a class in Swift:

/**
 A class for representing a point in 2D space.

 This class has two properties, `x` and `y`, which represent the coordinates of the point. It also has a computed property, `distanceFromOrigin`, which calculates the distance of the point from the origin.
*/
class Point {
    var x: Double
    var y: Double

    /// The distance of the point from the origin.
    var distanceFromOrigin: Double {
        return sqrt(x * x + y * y)
    }

    init(x: Double, y: Double) {
        self.x = x
        self.y = y
    }
}

It's important to note that proper documentation is a key part of good coding practice, as it helps other developers understand the purpose and functionality of our code. Both triple-slash and block comments are useful tools for adding documentation to our Swift code in Xcode.

Last Words

In addition to describing the code itself, we can also use Swift documentation to include examples, notes, and other helpful information for users of our code. For example, we can include an example of how to use our function or class like this:

/// Returns the sum of two numbers.
///
/// - Parameters:
///   - a: The first number.
///   - b: The second number.
/// - Returns: The sum of `a` and `b`.
///
/// - Example:
///     let sum = add(a: 1, b: 2)
///     print(sum) // prints "3"
func add(a: Int, b: Int) -> Int {
    return a + b
}

we can also use special Markdown syntax to format our documentation in different ways. For example, we can use **bold** or *italic* text to emphasize certain words or phrases. We can also create lists using asterisks (*) or numbers like this:

/**
 A list of things to do:

 * Take out the trash
 * Water the plants
 * Feed the dog
 * Do the laundry
 */

In addition to these basic formatting options, we can also use Markdown to create tables, links, and other formatting elements. For a complete list of the Markdown syntax supported in Xcode documentation, you can refer to the "Formatting Your Documentation Content" documentation on the Apple Developer website.

If you are having difficulty understanding the comment examples in this blog post, don't worry. The primary focus of this blog is to understand the purpose of commenting. It is important for every good programmer to have a strong sense of when and how to comment on their code, and this blog aims to help you build that skill.

Jokes apart, let's discuss the Five Effective "when and how":

1. Explain the purpose of a function or method

When writing a function or method, it's important to explain its purpose in a comment clearly. This will help other developers understand the purpose of the function and how it fits into the overall application.

For example:

// Returns current date in 'dd/mm/yyyy' format
func getCurrentDate() -> String {
    // code to get current date
}

2. Explain complex code

If we have written a complex piece of code that may be difficult for others to understand, it's helpful to include comments explaining the logic behind it. This will make it easier for others to follow our thought process and understand how the code functions.

Here is an example of a complex piece of code in Swift with comments explaining the logic behind it:

func findLargestNumber(in array: [Int]) -> Int {
    // Initialize variables to track current largest number & index
    var largest = array[0]
    var largestIndex = 0

    // Iterate through array and update largest number and its index
    for (index, element) in array.enumerated() {
        if element > largest {
            largest = element
            largestIndex = index
        }
    }

    // Return the largest number
    return largest
}

In this example, the findLargestNumber(in:) function takes an array of integers as input and returns the largest number in the array. The comments above each block of code explain the purpose of the variables and the logic behind the for loop that iterates through the array and updates the largest number and its index. This will help other developers understand the code and follow the thought process behind it.

3. Comments to document changes

If we make changes to our code, it's essential to document those changes in comments. This will help other developers understand the reasoning behind the changes and how they may impact the overall application.

Here is an example of using comments to document changes in Swift code:

// MARK: - Lifecycle

override func viewDidLoad() {
    super.viewDidLoad()
    // Added setup code for new feature
    setUpNewFeature()
}

// MARK: - New Feature

func setUpNewFeature() {
    // Initialize and configure new feature
    let newFeature = NewFeature()
    newFeature.configure()
}

// MARK: - Changes Made

// - Added setUpNewFeature() to initialize and configure new feature
// - Added newFeature property to store the instance of new feature
// - Modified viewDidLoad() to call setUpNewFeature()

In this example, we have added a new feature to our view controller and made some changes to the viewDidLoad() method to initialize and configure the new feature. We have also added a property to store the instance of the new feature. To document these changes, we have added a comment at the top of the block of code outlining the changes that were made, including the addition of the new function and the modifications to viewDidLoad().

4. Keep comments concise and relevant

While it's important to include comments in our code, it's also important to keep them concise and relevant. Avoid writing long, unnecessary comments, as they can clutter our code and make it harder to read.

Here is an example of concise and relevant comments in Swift code:

// Calculate the distance between two points
func distance(x1: Double, y1: Double, x2: Double, y2: Double) -> Double {
    let dx = x2 - x1
    let dy = y2 - y1
    return sqrt(dx*dx + dy*dy)
}

// Check if a point is within a circle
func isInsideCircle(x: Double, y: Double, centerX: Double, centerY: Double, radius: Double) -> Bool {
    // Calculate the distance between the point and the center of the circle
    let distance = self.distance(x1: x, y1: y, x2: centerX, y2: centerY)
    // Return true if the distance is less than the radius, false otherwise
    return distance < radius
}

In this example, we have defined two functions: distance() and isInsideCircle(). Both functions have concise and relevant comments that explain their purpose and how they work. The comment for distance() explains that it calculates the distance between two points, while the comment for isInsideCircle() explains that it checks if a point is within a circle by calculating the distance between the point and the center of the circle and comparing it to the radius of the circle. These comments help clarify the code's purpose and function, making it easier for other developers to understand and maintain.

5. Use comments to improve readability

In addition to explaining the purpose of our code, comments can also be used to enhance the readability of our code. For example, we can use comments to separate code sections or highlight important points.

Here is an example of using comments to improve readability in Swift code:

// MARK: - Data Loading

// Load data from the API
func loadData() {
    // Make API call
    API.loadData { [weak self] result in
        guard let self = self else { return }
        switch result {
        case .success(let data):
            // Process and save the data
            self.processAndSaveData(data)
        case .failure(let error):
            // Handle the error
            self.handleError(error)
        }
    }
}

// Process and save the data
func processAndSaveData(_ data: Data) {
    // Convert the data to a model object
    let model = try? JSONDecoder().decode(Model.self, from: data)
    // Save the model object to Core Data
    try? CoreDataManager.shared.save(model)
}

// Handle the error
func handleError(_ error: Error) {
    // Log the error
    print("Error: \(error)")
}

In this example, we have a class with three functions: loadData(), processAndSaveData(), and handleError(). To improve the readability of the code, we have added comments to separate the different sections and to explain the purpose of each function. The MARK comment at the top of the block of code separates the Data Loading section from the rest of the code, while the comments above each function explain what the function does. These comments help to break up the code and make it easier to understand and follow.

Last Words

In conclusion, following best comment practices when working with Swift on iOS application development is crucial for maintaining clean, well-documented code. By explaining the purpose of our code, documenting changes, and keeping comments concise and relevant, we can make it easier for us and others to understand and work with our code.

For any queries or suggestions, connect with me here.