If you've spent any time on YouTube, chances are you've seen those "Day In The Life Of A Software Engineer" videos. They're often staged portrayals of elaborate morning routines and luxury high-rise apartments with cinematography that rivals Hollywood.

These videos excel at portraying an idyllic day: from sunrise yoga classes to artisanal coffee brewing to rock climbing montages. However, for all their visual appeal, there's often a glaring oversight: a genuine perspective of what it's like to work as a software engineer.

Debugging, problem-solving, technical discussions, collaboration, code reviews, release planning, and other critical aspects of the job receive at most a passing mention.

So, over this past week, I've kept detailed records of my workday in order to provide a realistic view of a typical workweek as a Staff iOS Software Engineer at Turo.

It's likely more detailed than most people care to see, but when I was first exploring this career, this is the kind of play-by-play I was looking for.

I've replaced real project names with fake ones (movie names) just to be on the safe side and I've intentionally been a bit vague with the details in some areas.

I like my job and I want to keep it. 🤫

Monday

• 8 am: Rest day from the gym. Personal errands in the morning, apartment cleaning, quick grocery run, coffee, etc.
• 9 am: We still have some Objective-C in our codebase, so last Friday, I had started converting one of those classes to Swift. I picked that work back up and wrote new unit and snapshot tests.
• 9:40 am: Opened up a PR for the conversion and did a quick self-review.
• 10 am: I had another PR ready to go on Friday, but I was waiting for translations that, fortunately, came through over the weekend. So, I pulled in the new translations, addressed the final code review comments, and requested another round of review from the team.
• 10:15 am: [Backlog Grooming] We've got a new project - Interstellar - on the horizon and it involves a somewhat sensitive area of the codebase. While the details of the new project aren't finalized, I know that there's a couple of components that will need to be more reusable in order to support this new experience. So, I start looking into refactoring them and improving our code coverage for this area of the codebase.
• 11 am: A quick breakfast, more coffee, and a little reading on HackerNews and iOS News.
• 11:20 am: Continued working on the refactor.
• 12:20 pm: Taking a short break to address minor comments on the PR I opened this morning.
• 12:40 pm: Lunch and some code review.
• 1:40 pm: My main focus right now is Project Matrix. We're on the home stretch, so just working through some of the final bug fixes, TODOs, and release blockers.
• 3 pm: Came across some potential tech debt in the codebase. So, I started searching through Slack messages and older channels to try to better understand the expected behavior.
• 3:30 pm: This is looking more and more like a bug now rather than just tech debt. I pinged one of my Android co-workers to see if they're experiencing the same thing - no luck.
• 4 pm: I'm leading the small team spearheading Turo's move to SwiftUI. Just had a brief call with  a few of the other team members to discuss the status of the tooling (like linters and pre-commit hooks) and other helpers we're in the process of developing.

I'll be talking about this transition in more detail at an upcoming iOS conference. 😉

• 4:20 pm: Returned to investigating the tech debt / bug topic. After discussing with Product and Design team members, we decide that it's a low priority issue we can address after launching Matrix.
• 4:30 pm: Our release engineer just released the latest version of our iOS app which includes a major project I've been working on for the past few weeks. So, I started monitoring our metrics and logs for any new issues following the initial rollout of the feature.
• 4:40 pm: Back to Matrix now. Concentrating on some TODOs and writing documentation. I'm still checking the metrics and logs periodically and will continue to do so throughout the evening.
• 5:15 pm: 1:1 with a teammate I'm mentoring.
• 5:40: Signed off for the day.

Tuesday

• 6:30 am: Gym.
• 8:30 am: Shower, breakfast, coffee, etc.
• 9 am: Looking at a few code review requests that came in yesterday evening.
• 10 am: [Standup]
• 10:15 am: [Sprint Planning]
• 11 am: Continued working through the final release blockers for Matrix.
• 12:30 pm: Lunch and some code review.
• 1 pm: Still working on Matrix, but focusing on adding tests and addressing code review comments.
• 1:30 pm: Most Matrix release blockers are now resolved.
• 1:40 pm: Found an edge case on mobile clients for Matrix that would require changes to the API response. Set up a meeting with Android and backend engineers to discuss further.
• 2:30 pm: Ran into an offline data storage edge case that effects Matrix's implementation. Checked in with the Android team to see how they're navigating this issue. We align on similar solution for both platforms.
• 3 pm: I'm the technical lead for Interstellar. It's still in it's early stages, but met with Product and Design teams to provide initial engineering input on designs, project scope, and estimated development timelines.
• 4 pm: Matrix team meeting where everyone aligned their status on release-blocking issues, discussed pending analytics events, and reviewed our phased rollout strategy.
• 4:45 pm: Responded to comments on open PRs and successfully merged in a couple of them.
• 5:30 pm: Signed off for the day.

Wednesday

• 6:30 am: Gym.
• 8:30 am: Shower, breakfast, coffee, etc.
• 9 am: Code review (re-reviews mostly) and looked at a proposal (request for comments) from another member on the iOS team.
• 9:40 am: Left for the office.
• 10 am: Arrived at the office and continued working on Matrix. Mostly focused on implementing the changes from our launch discussion yesterday (updating analytics events, PR comments, and a bit more testing).
• 11 am: Learned that another coworker (on a different team) was modifying the behavior of an existing feature that Matrix relied on as part of an A/B test. Had a quick call to ensure that the new changes would still be compatible with both of our use cases.
• 12 pm: Catered lunch in the office and spent some time catching up with coworkers.
• 1 pm:  Stopped by a Valentine's Day event organized by the building with a few coworkers.
• 1:15 pm: Back to Matrix. Noted some small differences in how things were behaving across different platforms (Web, Android, and iOS), so I started a call with folks from Product, Design, and Engineering to make sure we were all on the same page.
• 2 pm: Guiding a coworker through a SwiftUI issue they were having and brought them up to speed on the SwiftUI transition team's recommend conventions and best practices.
• 3 pm: Discovered a bug in a recently launched feature and released a hot fix.
• 3:30 pm: SwiftUI transition team meeting. Talked through some of the development issues the larger iOS team was running into, how we wanted to prioritize the remaining work, and a presentation from one of the members about the newest design system components they had built out.
• 4:40 pm: Heading home.
• 5 pm: Some misc. tasks: updating some analytics events, a couple SwiftUI questions from coworkers, and sending out a new internal build for Matrix testing.
• 6 pm: Signed off for the day.

Thursday

• 6:30 am: Gym.
• 8:30 am: Shower, breakfast, coffee, etc.
• 9 am: [Engineering All-Hands / Tech Update] Company-wide engineering updates and presentations from other engineers about new tooling, initiatives, or other developments they're working on.
• 10 am: [Standup]
• 10:15 am: Updated portions of the Matrix project's UI to use the new design system components.
• 12 pm: Discovered a potential release blocker for Matrix on the backend. Meeting with product, designers, and other engineers on the team to triage and align on a solution.
• 12:30 pm: Engineering only meeting to delve deeper into the implementation details of the new solution.
• 1 pm: Group code review session - we split into small groups of 3-4 engineers to collectively review PRs. It's hands down my favorite meeting of the week and where I feel I learn the most.
• 2 pm: Back to Matrix.
• 2:30 pm: Quick call with a coworker to help them debug a SwiftUI issue.
• 2:45 pm: Back to Matrix.
• 3:30 pm: Starting today, I'm also supporting Project Spectre. We gathered to go over requirements and to start the handoff to my team. (I usually don't work on these many projects at once.)
• 4:30 pm: Back to Matrix.
• 5 pm: Encountered a bug that affects the entire app, not just Matrix. So, I put together a tentative solution as a starting point for discussion. I don't love the solution, but I'm hoping - with the team's help - we can come up with something more refined.
• 5:45 pm: Created a proposal (RFC) and requested feedback from the team.
• 6 pm: Addressed some feedback on an open PR and merged it in.
• 6:30 pm: Signed off for the day.

Friday

• 6:30 am: Gym.
• 8:30 am: Shower, breakfast, coffee, etc.
• 9 am: Looking at a few code review requests that came in yesterday evening.
• 10 am: Team "coffee meeting" over Zoom. With many of us working remotely, taking a little time to just chat and hang out helps us feel more connected as a team.
• 10:30 am: Had a meeting with the other engineers on my team to work through the spikes, tasks, and API definitions needed for Spectre now that it's officially assigned to our team.
• 11 am: Doctor's appointment.
• 12:15 pm: Over lunch, I brought Matrix's integration branch up to date with the main line (mostly resolving merge conflicts) and addressed some open PR comments.
• 1 pm: iOS team meeting (discussed improvements to our snapshot testing setup, had a coworker present on DocC, and reviewed a new internal developer tool).
• 2 pm: SwiftUI Office Hours. Myself and other members of the SwiftUI transition team dedicate time every week to assist engineers encountering SwiftUI development challenges as we navigate this transition from UIKit.
• 3 pm: More code review.
• 3:30 pm: A coworker reached out a SwiftUI issue they were having. After some debugging, it seems like a dead end until we can drop iOS 15 support. We find a workaround for now, but it's something I'll have to bring up with the full transition team next week.
• 4 pm: Back to Matrix. Addressed the remaining TODOs and opened up the final PRs. 🚀
• 5:15 pm: Helped a coworker plan out their new feature's implementation in SwiftUI.
• 6 pm: Signed off for the day.

My evenings usually follow a familiar routine. After work, I'll usually work on side projects like writing books, blog posts, newsletters, or indie app development. Occasionally, I'll also enjoy a bar trivia night or happy hour during the week too. 🍹

Hopefully, this deep dive has provided you with a clearer picture of what a typical work week is like for a full-time software engineer. As you can see, every day is different - new problems, new solutions - and that's all part of the fun. 🚀

If you're interested in more articles about iOS Development & Swift, check out my YouTube channel or follow me on Twitter.

And, if you're an indie iOS developer, make sure to check out my newsletter! Each issue features a new indie developer, so feel free to submit your iOS apps.

Ace The iOS Interview

The best investment for landing your dream iOS jobHey there! My name is Aryaman Sharda and I started making iOS apps way back in 2015. Since then, I’ve worked for a variety of companies like Porsche, Turo, and Scoop Technologies just to name a few. Over the years, I’ve mentored junior engineers, bui…

Gumroad

Indie Watch

Indie Watch is an exclusive weekly hand-curated newsletter showcasing the best iOS, macOS, watchOS, and tvOS apps from developers worldwide.

Indie WatchIndie Watch

As someone who loves staying current with iOS Development changes, my week is basically a marathon of scrolling through blogs, podcasts, newsletters, and YouTube videos.

But, let's be real, I'll inevitably miss out on some cool content. There's no easy way of staying on top of everything.

So, to solve the problem for myself and other developers,  I'm excited to introduce a space that brings together everything you need for iOS Development—all in real-time.

From insightful blogs to engaging podcasts, curated newsletters, new package releases / updates, and YouTube videos, you'll find everything you need here:

iOS Development News

Stay up to date with the latest iOS Developments news

I took a Computer Graphics course during college, and I've been revisiting the subject. During this recent exploration, I came across something interesting: Bresenham's Line Drawing Algorithm. It's a straightforward and extremely clever method for drawing lines on a pixel-based display.

Let's take a closer look at how the algorithm works and we'll even implement it from scratch in Swift.

Overview

Bresenham's algorithm - a fundamental method in Computer Graphics - is a clever way of approximating a continuous straight line with discrete pixels, ensuring that the line appears straight and smooth on a pixel-based display.

The algorithm calculates which pixels to color in order to create a straight line between two points. Since it works exclusively with integer arithmetic, it avoids the need for costly floating-point calculations and is better suited for hardware-constrained environments. Not to mention, it's also more accurate than simply rounding coordinates to the nearest pixel.

Algorithm

Imagine you have a grid of square pixels, and you want to draw a line between A and B.

The line intersects pixels at odd angles which makes it a challenge to determine precisely which ones to color for the most accurate straight-line representation.

A is at X = 1, Y = 2. B is at X = 4, Y = 4.

At a minimum, it's safe to assume that we should color our starting pixel. So, let's proceed and do just that:

Now, for our next step, we need to decide whether to move only along the X-axis or if we should also move diagonally (horizontally and vertically) towards B.

Bresenham's algorithm uses the slope of the original line along with a value called the "decision parameter" (which we'll explore shortly) in tandem to help us choose the pixels that create the most precise straight-line approximation between these two points.

We'll begin by calculating the slope of the line between A and B:

Slope = Rise / Run = ΔY / ΔX = (4 - 2) / (4 - 1)
Slope = 2 / 3 = 0.66

The key point to note is that ΔY = 2 and ΔX = 3 - we'll use these values again shortly.

We'll use the slope value in the edge cases section.

Decision Parameter

Our goal is to select pixels in a way that keeps them as close as possible to their positions on the original line. In other words, as we start filling in pixels, we want to minimize the error between the actual line position and the nearest selected pixel position at each step.

This is exactly the problem the decision parameter - P - helps us solve. It guides the algorithm's incremental decisions about whether to move horizontally or diagonally and which pixel to color next.

As the algorithm progresses, we'll continuously update the decision parameter based on whether P was positive, negative, or zero in the previous iteration. This constant refinement helps us minimize the deviation from the original line. If this seems a little abstract, don't worry - it'll make more sense as we work through an example.

This iterative process ensures the line maintains its correct path and has a smooth appearance on the pixel grid.

The derivation of the decision parameter is extremely interesting and simple to follow. For those curious, you can find more info here and here.

Initial State

The formula for the initial value of the decision parameter is:

P = 2 * ΔY - ΔX

where ΔX is the difference in x-coordinates between A and B, and ΔY is the difference in y-coordinates. These values will stay the same throughout the algorithm's run.

We'll also create X and Y values to denote the current coordinate/pixel we're at and we'll initialize them with A's values (the starting point of the line):

X = 1
Y = 2

For All Other States

As we move from one selected pixel to the next, we'll make incremental decisions based on the value of P: if P is positive, we move diagonally, and if P is negative, we move only horizontally.

The decision parameter's formula changes slightly for all pixels after the starting one.

If P < 0, we choose the next pixel horizontally and update P using:

P = P + 2 * ΔY
X = X + 1

If P ≥ 0, we choose the next pixel diagonally and update P using:

P = P + 2 * ΔY - 2 * ΔX
X = X + 1
Y = Y + 1

If you want to better understand how we get these formulas, I highly recommend checking out the resources linked below.

As we make these decisions, we update the current position accordingly. For example, if we're moving horizontally, we increment the X-coordinate, and if we're moving diagonally, we increment both X and Y.

Example

Let's return to our starting state:

Let's initialize our decision variable and other starting variables:

P = 2 * ΔY - ΔX = 2 * 2 - 3 = 1
X = 1
Y = 2

We know that we'll at least be coloring in our starting pixel, so let's check that off first.

In our case, since P = 1, according to the rules from earlier:

If P ≥ 0, we choose the next pixel diagonally and update P using P = P + 2 * ΔY - 2 * ΔX.

So, we'll need to increment both X and Y and we'll need to update the value of P for the next iteration:

X = 2
Y = 3
P = 1 + 2 * 2 - 2 * 3 = -1

Now, we can incrementally create our pixel-based line by repeating this process:

1. Fill in the pixel at (X, Y).
2. Calculate the updated value of P.
3. Calculate the updated value of (X, Y).
4. Repeat until (X, Y) matches the line's end position.

Iteration 2

Let's color in the pixel we're currently visiting (2,3) :

Now, we just repeat the process with P < 0 this time:

P = P + 2 * ΔY
P = -1 + 2 * 2 = 3

And, following the rules we defined earlier since P is less than 0, we only move horizontally:

X = 3
Y = 3
P = 3

Iteration 3

We'll color the pixel at our new (X, Y) position just like before:

Since P > 0:

P = P + 2 * ΔY - 2 * ΔX
P = 3 + 2 * 2 - 2 * 3 = 1

According to the rules from earlier, we know that our  next move will be a vertical and horizontal move, so our values leading into our final iteration are:

X = 4
Y = 4
P = 1

Final Iteration

After filling in the pixel, we can terminate the algorithm since our X and Y values match the end position of the line.

The line was drawn using only basic mathematical operations like addition, subtraction, and multiplication by 2 (which can be efficiently done with bit shifting) - this is one of the key reasons why this algorithm is so fast and efficient.

Implementation

func drawLine(x1: Int, y1: Int, x2: Int, y2: Int) {
    let dy = y2 - y1
    let dx = x2 - x1
    var d = 2 * dy - dx
    var x = x1
    var y = y1

    while x <= x2 {
        print("Draw pixel at: (\(x),\(y))")

        x += 1

        if d < 0 {
            d += 2 * dy
        } else {
            d += 2 * (dy - dx)
            y += 1
        }
    }
}

// Input
drawLine(x1: 1, y1: 2, x2: 4, y2: 4)

// Output
Draw pixel at: (1,2)
Draw pixel at: (2,3)
Draw pixel at: (3,3)
Draw pixel at: (4,4)

Edge Cases

So far, we've only talked about situations where X1 (starting point) < X2 (ending point) and where the slope is between 0 and 1.

There are several cases we haven't handled:

• X1 > X2
• Slope < 0
• Slope > 1

Anusha's post provides a thorough explanation of these edge cases:

Bresenham’s Line Drawing Algorithm

Explanation of Bresenham’s Line Drawing Algorithm with examples

Geek CultureAnusha Ihalapathirana

Conclusion

Bresenham's algorithm excels in both speed and ease of implementation. However, it doesn't address aliasing.

As a result, many implementations opt for Xiaolin Wu's algorithm, which offers support for aliasing operations.

If you're interested in a deep dive into that, let me know!

If you're interested in more articles about iOS Development & Swift, check out my YouTube channel or follow me on Twitter.

And, if you're an indie iOS developer, make sure to check out my newsletter! Each issue features a new indie developer, so feel free to submit your iOS apps.

Ace The iOS Interview

The best investment for landing your dream iOS jobHey there! My name is Aryaman Sharda and I started making iOS apps way back in 2015. Since then, I’ve worked for a variety of companies like Porsche, Turo, and Scoop Technologies just to name a few. Over the years, I’ve mentored junior engineers, bui…

Gumroad

Build Switcher: Local Build Caching for Xcode

Introducing BuildSwitcher 🚀⚡ BuildSwitcher intelligently caches the latest builds across your most frequented branches. Now, you can switch between these builds instantly in the Simulator without having to wait for compilation or stashing your working changes when you change branches. Say goodbye t…

Gumroad

Sources

• https://en.wikipedia.org/wiki/Bresenham's_line_algorithm
• https://www.cs.drexel.edu/~popyack/Courses/CSP/Fa18/notes/08.3_MoreGraphics/Bresenham.html?CurrentSlide=2

Videos

• https://www.youtube.com/watch?v=RGB-wlatStc
• https://youtu.be/h3gDB89h0os?si=W0lPlftL7O-vw0tf
• https://www.youtube.com/watch?v=TRbwu17oAYY&t=1s&ab_channel=TheBootStrappers

Between my recent SwiftUI projects and YouTube content, animations have become a crucial part of my work. So, I've been down a bit of an animation rabbit hole lately...

We'll start with the basics - from linear animations to easing curves - and then we'll dive into creating custom animations from scratch. Whether you're a designer aiming for delightful user experiences or a developer focused on effective animation, this post has you covered.

Linear Animation & Linear Interpolation

At its core, linear interpolation (a.k.a lerp) smoothly transitions between two values over a fixed time, creating a consistent, constant-speed motion. This forms the basis of linear animation where objects move uniformly from A to B.

Let's see what this looks like in code:

• startValue is the starting value of the animation (i.e. alpha, x, width, etc.).
• endValue is the ending value of the animation.
• progress is a parameter that ranges from [0,1] and represents how much of the animation's duration has elapsed.

func lerp(startValue: CGFloat, endValue: CGFloat, progress: CGFloat) -> CGFloat {
    return startValue + (endValue - startValue) * progress
}

• When progress = 0, lerp returns startValue.
• When progress = 1, lerp returns endValue.
• When 0 < progress < 1, lerp returns a value between startValue and endValue proportional to the elapsed animation duration.

You can use this lerp function to interpolate between any numeric values in your Swift code; position, opacity, colors, etc.

Now, let's use our lerp function to animate a view linearly across the screen:

class LinearAnimationViewController: UIViewController {
    lazy var boxView: UIView = {
        // Create a blue box
        let boxView = UIView(frame: CGRect(x: 0, y: 200, width: 100, height: 100))
        boxView.backgroundColor = UIColor.blue
        view.addSubview(boxView)
        return boxView
    }()

    let animationDuration: TimeInterval = 3.0
    let frameRate: TimeInterval = 1.0 / 60.0 // 60 FPS
    var currentTime: TimeInterval = 0

    var animationTimer: Timer?

    override func viewDidAppear(_ animated: Bool) {
        super.viewDidAppear(animated)

        // Start the animation timer
        animationTimer = Timer.scheduledTimer(timeInterval: frameRate, target: self, selector: #selector(animateBox), userInfo: nil, repeats: true)
    }

    @objc func animateBox() {
        let startValue: CGFloat = 0
        let endValue: CGFloat = self.view.frame.width - 200

        // Calculate interpolated position
        let progress = CGFloat(currentTime / animationDuration)
        let newX = lerp(startValue: startValue, endValue: endValue, progress: progress)
        boxView.frame.origin.x = newX

        // Moves to the next frame
        currentTime += frameRate
        if currentTime > animationDuration {
            animationTimer?.invalidate()
        }
    }

    func lerp(startValue: CGFloat, endValue: CGFloat, progress: CGFloat) -> CGFloat {
        return startValue + (endValue - startValue) * progress
    }
}

I'll omit the setup code in future examples as it remains constant.

While this linear animation works, it's missing something. Not only is it a little boring, but very few things in the real world are linear in nature - usually, the rate of change of most things tends to be non-linear. For example, when you floor the accelerator in your car, in the first moment nothing happens and then the movement happens all at once.

So, in order to make our animations look more natural, we'll need to rely on non-linear animation curves.

Easing Functions

Animation timing functions, often simply called "timing functions" or "easing functions," define how the progress of an animation changes over time.

Timing functions are often depicted as graphs, with time on the horizontal axis and progress or value changes on the vertical axis.

For a more tangible example, consider a car's acceleration. Gentle gas pedal pressure leads to a smooth start, much like an ease-in animation. When you let off the gas before stopping, the gradual slowdown is akin to an ease-out animation.

Ease In

Both t and x range from [0, 1].

Easing functions frequently use quadratic or cubic equations because the output grows quickly with minor increases in the input value. This lines up perfectly with our aim of modeling a car's smooth start and then rapid acceleration.

// Calculate interpolated position
let progress = CGFloat(currentTime / animationDuration)
let newX = lerp(startValue: startValue, endValue: endValue, progress: easeIn(progress: progress))
boxView.frame.origin.x = newX

func easeIn(progress: CGFloat) -> CGFloat {
    pow(progress, 2)
}

When you use an easing function like easeIn, it takes a single parameter, progress, which represents the fraction of the animation duration that has elapsed and ranges from 0 to 1.

This easing function then transforms this input into an 'eased value' within the same 0 to 1 range. When we combine this 'eased value' with lerp, we can introduce a non-linear element to our interpolation between the start and end values of our animation.

Returning to our car analogy, you can see that gentle start and increased acceleration behavior in this animation.

Ease Out

// Calculate interpolated position
let progress = CGFloat(currentTime / animationDuration)
let newX = lerp(startValue: startValue, endValue: endValue, progress: easeOutQuad(progress: progress))
boxView.frame.origin.x = newX

func easeOutQuad(progress: CGFloat) -> CGFloat {
    1 - (1 - progress) * (1 - progress)
}

Ease In Elastic

// Calculate interpolated position
let progress = CGFloat(currentTime / animationDuration)
let newX = lerp(startValue: startValue, endValue: endValue, progress: easeInElastic(progress: progress))
boxView.frame.origin.x = newX

func easeInElastic(progress: CGFloat) -> CGFloat {
    guard progress != 0 || progress != 1 else {
        return progress
    }

    return -pow(2, 10 * progress - 10) * sin((progress * 10 - 10.75) * ((2 * CGFloat.pi) / 3))
}

Ease In Out Quint

Check out the piecewise approach in the implementation below.

You're not confined to using a single expression for the entire animation. Instead, you have the freedom to use different formulas for specific time segments, giving you creative control over each part of the animation.

// Calculate interpolated position
let progress = CGFloat(currentTime / animationDuration)
let newX = lerp(startValue: startValue, endValue: endValue, progress: easeInOutQuint(progress: progress))
boxView.frame.origin.x = newX

func easeInOutQuint(progress: CGFloat) -> CGFloat {
    if progress < 0.5 {
        return 16 * pow(progress, 5)
    } else {
        return 1 - pow(-2 * progress + 2, 5) / 2
    }
}

These easing functions aren't limited to just animating positions. We could apply the same approach for scaling, rotation, or opacity animations.

Here's the implementation for an opacity animation using the same easing function:

let startValue: CGFloat = 0
let endValue: CGFloat = 1

// Calculate interpolated position
let progress = CGFloat(currentTime / animationDuration)
let newAlpha = lerp(startValue: startValue, endValue: endValue, progress: easeInOutQuint(progress: progress))
boxView.alpha = newAlpha

No Right Answer

Finding the exact formula for specific easing curves can be challenging since there's no universal equation or standard for all easing functions. Easing functions are often created by designers and developers to achieve specific visual effects or animations, and the exact formula may vary depending on the software or library used.

Animations are a mix of math and artistry. For example, take a look at Lucas Garron's video below, where he builds his own "perfect" easing function from first principles.

To discover the exact formula for a particular easing curve, search for documentation related to the animation library or framework you're using. Some libraries provide mathematical equations for their built-in easing functions.

Additionally, some tools and websites allow you to visualize and generate custom easing curves graphically. While they may not provide the exact formula, they allow you to experiment with different easing curves and export them for use in your animations.

While understanding the math behind easing functions can be valuable for custom animations, predefined easing functions from libraries are often sufficient for achieving the desired visual effects in most projects. This deep dive was driven purely by curiosity.

The implementations above drew significant inspiration from Easings.net. If you're interested in learning more about easing functions, it's a fantastic resource to check out.

Conclusion

From linear ease-ins to quirky custom curves, animations add that extra flair to your user experience. So, the next time you're designing an app or website, don't forget to sprinkle in some animations. With the right timing, creativity, and a dash of experimentation, you'll transform your static screens into an immersive experience.

If you're interested in more articles about iOS Development & Swift, check out my YouTube channel or follow me on Twitter.

And, if you're an indie iOS developer, make sure to check out my newsletter! Each issue features a new indie developer, so feel free to submit your iOS apps.

Ace The iOS Interview

The best investment for landing your dream iOS jobHey there! My name is Aryaman Sharda and I started making iOS apps way back in 2015. Since then, I’ve worked for a variety of companies like Porsche, Turo, and Scoop Technologies just to name a few. Over the years, I’ve mentored junior engineers, bui…

Gumroad

Build Switcher: Local Build Caching for Xcode

Introducing BuildSwitcher 🚀⚡ BuildSwitcher intelligently caches the latest builds across your most frequented branches. Now, you can switch between these builds instantly in the Simulator without having to wait for compilation or stashing your working changes when you change branches. Say goodbye t…

Gumroad

Sources & Additional Reading

• https://easings.net/
• https://www.youtube.com/watch?v=CDDfXOeEJl0
• https://www.youtube.com/watch?v=YJB1QnEmlTs

⚡ Build Switcher intelligently caches the latest builds across your most frequented branches. Now, you can switch between these builds instantly in the Simulator without having to wait for compilation or stashing your working changes when you change branches.

Say goodbye to wasted time on resolving dependency versions, battling caching / DerivedData issues, and waiting for compilation during branch changes and demos.

Build Switcher: Local Build Caching for Xcode

Introducing BuildSwitcher 🚀⚡ BuildSwitcher intelligently caches the latest builds across your most frequented branches. Now, you can switch between these builds instantly in the Simulator without having to wait for compilation or stashing your working changes when you change branches. Say goodbye t…

Gumroad

🔍 Swift, Smooth Comparison: With Build Switcher, comparing your feature or bug-fix branches with main is a breeze. Safeguard against regressions and ensure that pesky bugs are truly squashed, all without the hassle of switching branches or recompiling.

🔄 Simpler Refactoring: Transitioning from Swift/ObjC to SwiftUI? Or, in the middle of a big refactor? Build Switcher’s got your back! Easily compare your current implementation against the original allowing you to ensure the expected behavior remains intact.

📊 Dazzling Demos, Zero Delay: Picture this — it’s the end of the week and you’re getting ready to demo your bug fixes and new features to your team. As you move between branches and wait for your project to recompile, your high-energy demo quickly becomes a time-sucking nightmare.

With Build Switcher automatically caching your builds across your recent branches, you can now easily restore builds in the Simulator without compiling, changing branches, or stashing any changes. Your demos just went from clunky to seamless. 🎉

🛠️ Easy Setup: Seamless integration into your workflow. A few taps, and you’re good to go! No rocket science, I promise. Plus, it’s compatible with all iOS and iPadOS projects. 🚀

👨‍💻 Developer-Tested, Developer-Friendly: I’ve put Build Switcher through its paces over a few on-call shifts and I’ve found it indispensable in my development workflow.

Calling all pickleball enthusiasts! It's time to celebrate because the Pickleball Score Tracker app has arrived. Crafted by a fellow pickleball aficionado, this game-changing app syncs seamlessly with your Apple Watch, transforming how you keep score and experience the game. Say goodbye to scorekeeping headaches and hello to a whole new level of gameplay.

Product Features & Highlights

Hey there, fellow pickleball enthusiast! Ever had those moments on the court when the score gets all tangled up? I've been there too, and that's why I created the Pickleball Score Tracker watchOS app.

📱Effortless Scoring

With the app's integration with your Apple Watch, tracking scores becomes as intuitive as your best shots. A quick twist of the crown, and you're all set. Your focus stays on the game, where it should be.

🌟Live Score Streaming

But the app doesn't stop there. I know the camaraderie pickleball brings. That's why I've added live score streaming. Now, you can share the excitement with your fellow players in real-time, enhancing the experience for everyone involved.

🏋️‍♂️ Workout Tracking

And for those fitness goals? Consider them covered. The app tracks your workout while you focus on your game. It's a win-win for your health and your pickleball skills.

🛠️ Personalize Your Gameplay

The best part? All these features are yours, for free. As an avid player myself, I want everyone to have access to tools that enhance the game.

Media

Download

‎Pickleball Score Tracker

‎Introducing the Ultimate Pickleball Companion: Pickleball Score Tracker Never lose track of the score again! Elevate your pickleball experience with the Pickleball Score Tracker app. Designed with passion for players, by players, this app seamlessly integrates with your Apple Watch to enhance your…

App StoreAryaman Sharda

Localization

• English (Default)

Contact Information

For more info or media inquiries, please message me at aryaman@digitalbunker.dev.