iOS Development on Ivan: Thinking

Ready Time's on TinyLaunch

Mon, 01 Jun 2026 16:20:24 -0700

Ready Time is moving up the ranks at TinyLaunch. Go give it an upvote!

Ready Time 3.3: Travel Time

Thu, 21 May 2026 10:21:57 -0700

I built Ready Time to take the guesswork out of leaving on time. You tell it when you need to be somewhere and it tells you when to start each step.

There was one part of setting up steps that’s always been tedious and annoying: travel time.

Drive to the doctor, bike to soccer, walk to dinner. I’d switch to Apple Maps, search for the address, get the travel time, come back, put in the step duration.

There had to be a better way.

I mean, I built Ready Time to save time and not have to do tedious work, right? Welp, here I was doing this tedious back and forth between the app and Maps and wasting my time.

What’s new

Ready Time 3.3 adds Travel to steps. When you edit a step, pick a place, choose driving, cycling, or walking, and the travel time becomes part of the plan. Change the destination or the mode and the rest of the plan adjusts. No more jumping back and forth between apps, needing to remember, or even entering the duration anymore.

One less thing to keep in your head, and one less reason to be running late.

Onward

I’d love to hear from you, especially if you find a use for this I didn’t think of. Drop me a note.

Next Chapter of Little Memory

Tue, 28 Apr 2026 21:17:59 -0700

I’ve been in the weeds getting Little Memory 2.0 ready. Well, honestly, it actually never had a proper 1.0 version!

One thing that’s bothered me over the years is having all these entries in my database. I’d rather have people’s memories storied on their own devices where they’re safe and accessible even when offline.

I have most of the bones of 2.0 ready, but if you’ve ever worked in software, you know that last 20% (and sometimes 5-10%) can be the trickiest to make sure everything’s buttoned up and ready. I think I’m at that stage now.

Soon, I’ll be asking some long-time users if they’d like to try out a TestFlight build to get some feedback. I’m excited to share it with the world.

Ready Time 3.2: Shared Plans and Daily Repeating Plans

Tue, 28 Apr 2026 14:39:12 -0700

This one’s been a long time coming. Ready Time 3.2 is here!

Shared Plans

Having a backwards planning tool has been great, and my wife and I use it all the time to make sure we get out the door on time. But we found it redundant to each have to setup our own plans, especially if we were going to be on the same flight or going to the same event together (which happens a lot).

We used to take screenshots for each others’ plans so we knew what our plan was. But we knew there had to be a better way.

Enter: shared plans. With shared plans, you can now coordinate using the same plan, and you both get alerts for each step along the way to the deadline. No more screenshots that cluttered our photo libraries. Just share a plan to someone and they’ll get notifications just like you, and if you update the plan, they’ll see the updates and their alerts will update too.

Daily Repeating Plans

We previously only had weekly repeating plans. This was useful for things like weekly meetings or regular appointments I had on a specific day of the week. But this wasn’t necessarily that helpful for plans where I wanted it to repeat every day of the week: morning routines, baby’s bedtime routine, workout routines. Now you can setup a plan to do every day without needing to have to duplicate or re-enter them each day.

Templates

For new users, some folks were finding it tricky to get started. We’ve got some more ideas turning in our heads on how to make this experience better, but our first stab at it now is to get you templates. With a template, there are pre-defined sequences of steps like “Catch a Flight” or “Dinner Party.” Some folks liked it so much that they thought it would be good to have it for everyone, not just new users. So now you can select a template to start new plans with.

Onward

We hope you enjoy the new features. We’re especially excited about shared plans, as it’s something we’ve been working toward for a long time. There were lot of pieces that had to come into play to make it work, so it’s been awesome seeing it all come together.

Feedback? Bugs? Comments?

As always, we love hearing from you!

Technology is not enough

Mon, 20 Apr 2026 16:47:31 -0700

Daring Fireball:

Either you know that software can be art, and often should be, or you think what I’m talking about here is akin to astrology. One thing I learned long ago is that people who prioritize design, UI, and UX in the software they prefer can empathize with and understand the choices made by people who prioritize other factors (e.g. raw feature count, or the ability to tinker with their software at the system level, or software being free-of-charge). But it doesn’t work the other way: most people who prioritize other things can’t fathom why anyone cares deeply about design/UI/UX because they don’t perceive it. Thus they chalk up iOS and native Mac-app enthusiasm to being hypnotized by marketing.

What I think also ends up happening is that good design is something that becomes invisible when it’s good. Simple/good designs disappear when they take practically no cognitive load; well, except for the times when you want to purposely introduce friction for the user to slow them down like confirmation dialogues when they’re doing something dangerous.

This “invisible” is akin to sysadmins who are never seen or considered until the system breaks down and everyone’s upset that things aren’t working. Well, no one was busy saying thanks when the sysadmins were keeping things running smoothly without any issues.

Moving along on Ready Time relaunch

Wed, 15 Apr 2026 22:33:19 -0700

Posted on r/SideProject. Had a little hiccup since my original post was filtered by reddit’s spam filter (boo!), but re-submitted a day later with fewer links in the post. I’d also been dormant on reddit for a while, so it may have smelled like spam with the initial post.
- Found out there’s an app by the name of ReadyBy with the same concept. After checking it out, it reinforces that I think my change from subscription to one-time premium upgrade makes sense (ReadyBy is a subscription model).
Published blog post about how Ready Time saved the day when wife went into labor. This has been a long time coming. Finally buckled down to write this thing out.
Submitted to Indie App Catalog.
Shared with some friends who’ve been giving me some feedback on the app.
Been warming up my profile on Indie Hackers.

It's like gonna have like this tab

Tue, 14 Apr 2026 11:30:37 -0700

Kids and Vibe Coding:

It’s easy for us to spot the issues. However, the bit that’s surprised me, though, is that they are…aware of it? Even as a 9 year old. Is this a potential byproduct of growing up in the digital age? They know it doesn’t feel right, and they can’t really say why yet, they just know it feels off.

That’s hardly surprising, as design and user experience are things that take years and years to develop.

Oh, what a fun thing to do with kids!

When I’m working on making an interface simple and easy to use, this “feels off” is something I often find myself bumping into. I know something is wrong, but I have to identify it and work out a solution. Oftentimes, once you figure out the right solution, it feels obvious. Then, when you show it to other folks, it can seem trite or overly simplistic about what the solution was.

You can throw all the skill files you want at an LLM (And you should! They’re great!), but they still have critical limitations. Take text, for example. What would you instinctively do if you have a view whose text was truncated, clipping, or otherwise not fitting into a container?

The layman would say, “Can you make this text not clip?” The hardened iOS veteran might say, “Apply a .minimumScaleFactor modifier to this text, and ensure you’re using a Text style and not hard coding the font size.”

Off the cuff? Visually, you may get the same result at first. But, well — if you know, you know. One is objectively better. And those of us who can speak the language will still be making the best apps.

I don’t fully trust Claude with interaction design (yet?), at least on a high level. Maybe it’s just that it doesn’t really understand the pain-points that humans have to go through when dealing with UX/UI. It seems to be able to tell me that some things are on screen and where they are, but deciding how an interaction feels or how it feels to use it seems less fluent about. We may get there, but at least right now I do a good amount of hand-holding to direct it with design rather than let it do too much of UX. I do, however, often ask it for design ideas, which I work together with Claude when brainstorming solutions.

Ready Time

Tue, 07 Apr 2026 16:32:03 -0700

We’re always underestimating how long things take:

It always feels like there’s enough time until suddenly there isn’t.

Ready Time works backward from your deadline. You add your steps: shower, pack lunch, get the kid dressed, drive. Then you set when you need to be done. It calculates when to start each step and sends you a notification when it’s time.

I built it because my family needed it: I liked getting to the airport super early, and my wife preferred to arrive just in time for departure. Originally, it was called Little Countdown, but folks kept thinking it was a countdown to new years eve ball drops, which wasn’t really what I was going for. And so, today we’re introducing the new name which better captures the spirit of the app: Ready Time.

I hope Ready Time can help you and your family too.

– Ivan

Available now in the App Store.

Getting Ready for Ready Time

Mon, 30 Mar 2026 20:53:39 -0700

Ready Time is the rebranded name for Little Countdown. Domain: check. Website: check. App update: almost.

Time Lock, New Premium Feature

Wed, 14 Jan 2026 06:11:12 +0000

Sometimes you need a task to happen at a specific time. Maybe you need to leave for the airport at exactly 3:00 PM, or you have a hard deadline to be at a meeting at 10:00 AM. Little Countdown normally schedules all your tasks backward from your deadline, but that doesn’t work when one task needs to happen at a fixed time.

Time Lock lets you set a fixed start time for any Task in your Countdown. When you lock a task to a specific time, Little Countdown schedules the rest of your timeline around it:

Tasks before the time lock are scheduled backward from your deadline (as usual)
Tasks after the time lock are scheduled forward from the lock time

This gives you the flexibility to plan around fixed commitments while still letting the app handle all the math for everything else.

Example

You have a flight tomorrow at 6:00 PM, and you need to leave for the airport at exactly 3:00 PM. Here’s how you’d set it up:

Create a Countdown with your flight as the deadline (6:00 PM)
Add your tasks: “Pack bags” (30 min), “Call Lyft” (5 min), “Drive to airport” (45 min), “Get through TSA” (30 min), “Find gate” (15 min)
Time Lock the “Call Lyft” task to 3:00 PM

Little Countdown will:

Schedule “Pack bags” to finish just before 3:00 PM
Lock “Call Lyft” to start at 3:00 PM
Schedule everything after (drive, TSA, find gate) forward from 3:00 PM to ensure you make your 6:00 PM flight

You get alerts for everything, and you don’t have to calculate when to start earlier tasks—the app handles it all.

Why This Matters

Time Lock solves a real problem we’ve heard from users: sometimes you need to work around fixed times in your schedule. Maybe it’s a carpool pickup time, a specific appointment slot, or a deadline that can’t move. Before Time Lock, you’d have to manually calculate when to start earlier tasks, which defeats the purpose of having Little Countdown do the math for you.

Now you can set that one fixed point in your timeline, and everything else falls into place automatically. It’s one less thing to worry about, which is exactly what Little Countdown is designed to help with.

Time Lock is available now as part of Little Countdown Premium. If you’re already a Premium subscriber, you’ll see the Time Lock option when editing any task (except the last one in your Countdown, since that’s already determined by your deadline).

We hope this makes planning your day even easier. As always, we’d love to hear your feedback!

Development login credentials in Xcode

Mon, 24 Apr 2023 12:08:51 -0400

Danijela Vrzan posted a very cool solution to streamlining entering login credentials in Xcode and the iOS Simulator using breakpoints. I’ll admit that I probably haven’t fully unlocked the full potential of Xcode breakpoints in my development workflow.

If you’re an app developer, no doubt you’ve run into the case where you’re tediously typing in your auth username and passwords every time you rebuild/relaunch the Simulator. It gets old pretty quickly when you’re trying to quickly make updates or fix a bug in your app.

You might consider hard coding some credentials temporarily in your code, but really, you know that’s not what you should be doing, as it clutters up your code and you run the risk of forgetting to remove that code before releasing the app (eep!).

I’ve setup my own solution on how I like to safetly handle this repetitive task in development and avoid needing to type in credentials with the Simulator keyboard.

Development Scheme

For every new project, I setup a dedicated scheme in Xcode for development. The way I set it up is:

I like to name this scheme something like Appname (dev) or, if I’m working against a staging environment, I’ll use Appname (staging).
In Run > Arguments, add environment variables with keys such as:
- AUTH_DEFAULT_USERNAME
- AUTH_DEFAULT_PASSWORD
Don’t select Shared so you don’t commit these values into git, especially if these are credentials for a production environment.
You could also have multiples of the above variables to quickly switch between different credentials. Xcode lets us choose which ones we want enabled by selecting the checkmark next to each variable.

Pre-filling the Auth Form

import SwiftUI

private var env: [String : String] { ProcessInfo.processInfo.environment }

struct LoginForm: View {
  @State private var username: String = env["AUTH_DEFAULT_USERNAME"] ?? ""
  @State private var password: String = env["AUTH_DEFAULT_PASSWORD"] ?? ""

  // ...
}

Build and Run

Now, with the development scheme you created above enabled, you can run the app and the login form should be pre-filled with the auth credentials in the environment variables.

Voila! No more tedious typing and no credentials stored in code.

As noted previously, you can add multiple credentials into a single scheme, or you could do something like create a new scheme for different environments as well.

Onward

I love seeing tips like the one Danijela has to speed up the develoment workflow. One plus of her method is that it doesn’t require you to make code changes like what we’ve done here. Her method’s certainly made me think more about working with breakpoints in my work.

If we can speed up and optimize the development/test cycle without too much hassle, I consider it a win.

I hope my little tip here can help you out in your own use of Xcode and app development. Let me know if you’ve got more tips like this or if it helped you out.

iOS Developer Resources

Tue, 04 Oct 2022 23:58:18 -0400

Developer News and Community

If I could give any advice to all new iOS developers, it’s that they should keep up with the ever-changing iOS ecosystem. Apple pushes out a new version of iOS every year, so it’s important (and exciting!) to keep up with the latest going on in the world of iOS Developmenet. I like to keep my ears on the ground with these resources.

Developer Blogs

There’s a lot of noise on the web with developers asking questions on how to write code for iOS. Be wary of code you see on Stack Overflow: often it feels like the blind leading the blind there. These blogs are sources I’ve consistently found to have good and useful patterns that have helped me out and to improve my own skills.

Other News

Apple Resources

App Store Connect: every iOS developer’s favorite site to re-login to.
Apple Developer
Human Interface Guidelines (aka the HIG)
- App Icon Sizes
- Dynamic Type Sizes
Screenshot Specifications
Smart App Banners

Software

App Store Connect
Apple Developer: watch WWDC videos.
SF Symbols
Xcode Releases: I don’t like updating from the App Store so I can keep multiple copies of Xcode on my machine. Instead, I use the direct download links on this site.
Postman

Other

SwiftUI: Link phone numbers, emails, URLs in Text without Markdown

Tue, 20 Sep 2022 17:54:51 -0400

SwiftUI provides an easy way to link URLs and emails inside of a Text view using AttributedString’s markdown initializer:

let text = "Jenny's at 867-5309."
    + " Email her at jenny@tutone.net."
    + " Find out more: https://en.wikipedia.org/wiki/867-5309/Jenny"

VStack {
    Text(try! AttributedString(markdown: text))
}

However, this has a few shortcomings:

the phone number isn’t linked/tappable
we may not want all the markdown rendering: bullets (*) and brackets ([]) in the text may end up rendering with unexpected results

We can use NSDataDetector instead to help us construct our own AttributedString that can detect phone numbers and also prevent the user from accidentally injecting markdown:

private let dataDetector: NSDataDetector = {
    let types: NSTextCheckingResult.CheckingType = [.link, .phoneNumber]
    return try! .init(types: types.rawValue)
}()

struct JennyView: View {
    var body: some View {
        VStack {
            Text(attributedString(from: text)!)
        }
    }
    
    private func attributedString(from text: String) -> AttributedString? {
        var attributed = AttributedString(text)
        let fullRange = NSMakeRange(0, text.count)
        let matches = dataDetector.matches(in: text, options: [], range: fullRange)
        guard !matches.isEmpty else { return nil }
        
        for result in matches {
            guard let range = Range<AttributedString.Index>(result.range, in: attributed) else {
                continue
            }
            
            switch result.resultType {
            case .phoneNumber:
                guard
                    let phoneNumber = result.phoneNumber,
                    let url = URL(string: "sms://\(phoneNumber)")
                else {
                    break
                }
                attributed[range].link = url
                
            case .link:
                guard let url = result.url else {
                    break
                }
                attributed[range].link = url

            default:
                break
            }
        }
        
        return attributed
    }
}

Here, I’ve used the sms:// scheme to open the Messaging app when the user taps on a phone number. You could also use the tel:// scheme as well.

Now go forth, tap that phone number, and make Jenny your own.

Additional Resources

CoreData: All that is left to us is honor

Tue, 07 Jun 2022 17:08:51 -0700

My life for Aiur

How to do?

Add -com.apple.CoreData.ConcurrencyDebug 1 to your Xcode launch arguments.
Execute some non-thread safe CoreData code.
Crash, but at least you’ll still have your dignity.

iPhone Upgrade Program vs Buying, Trade In

Sat, 05 Dec 2020 17:22:26 -0700

Every year, when Apple makes its big announcement about the new iPhone being the most amazing device ever, you’re wondering whether you should upgrade or not. You consider whether the new features are worth it or whether you want a better camera or a better battery life.

Maybe your iPhone’s becoming gruelingly slow because you’re 3 years behind. Or maybe you can tell that your battery life is incrementally dying away with each night’s recharge.

On top of all this, worrying about what to do with your old device can add another stress point.

I’m a fan of the iPhone Upgrade Program (IUP) to relieve a lot of the hassle of making these decisions every year.

Is Apple’s iPhone Upgrade Program worth it?

Here’s why I like it:

I want to stay up to date and get the latest iPhone every year. This was a bigger concern when I was a full time iOS developer. I do still have apps with users that depend on me in the App Store, however, and it’s important for me to stay relevant.
Fewer decisions for me to make. Similar to how I’ve designed my capsule wardrobe, I actually would prefer not to make a choice about whether I should upgrade or not. I just do it every year.
I don’t want to own my device. The last iPhone I still own is my 3GS that I keep on my home Computing Museum shelf. I have an old iPad Mini that’s soon to be trash, as it’s way too slow to be worthwhile to use it. I wouldn’t know what to do with an old iPhone.
Less e-waste in the world. If Apple knows how to recycle iPhones to help manufacture the next generation of devices, I’m happy about it.
I don’t care too much about AppleCare, but it’s a nice addition. I don’t keep a case on my iPhone and never have. Even adults have fidget spinners, and the iPhone is one of mine. AppleCare+ lets me care a little less about having a mishap. I like not having to baby my device. Scratches on the screen that naturally develop over time don’t bother me either. That’s one less thing on my mind.

Sounds like some luxury expensive shit

Indeed.

I realize that the above reasons for being enrolled in the IUP are pretty bougie.

I’m not looking at it as just a fully monetary choice. Just like my capsule wardrobe, it’s more than just about the economics. For me to be focused on things that matter to me, I prefer to reduce decisions in one area of my life for an economic price. I’m getting value, and that’s what I’m paying for.

Let’s break it down

Consider the iPhone 12 Pro that Apple released in 2020. The 128GB model retailed full price at $999, and IUP’s monthly for it was $49.91/month. In 2021, Apple will likely release a comparable iPhone 13 for the same price. We can also do some rough estimates of what trade in values may be.

Let’s look at what this looks like compared to other scenarios such as:

Buying the iPhone and trading it in for a new one at a later year
Buying the iPhone, not trading it in, and buying a new one at a later year

We’ll look at how much you’ll have spent as a Lifetime Total for each year over the course of 6 years.

Green is what I value. I think most folks would agree that they want to pay less. I also favor not owning any devices and being able to use more devices.

How bougie is it?

Annually trading in is clearly a bad choice. You pay the most, and you don’t get AppleCare+, but at least you get the latest device every year. With no credit checks, I wonder if this may be the best choice if you’re a high roller with a cash only business. Drug dealers?

If you’re looking for a purely economic choice, going with the IUP and upgrading after 3 years seems like a no brainer. Not only do you pay the least out of these scenarios over time, you also end up with devices that you could sell if you wanted to.

If you want to try the latest iPhone every year, though, IUP with an annual upgrade comes at a premium. You’re not as bad as buying keeping the device for 2 years, but you’re getting diminishing economic returns compared to the other strategies here. And if your credit is bad, this is not going to be the best path for you.

Looking at this laid out, I’m fine with the premium I pay for the annual IUP. And over the longer term, we can see it diverging more and more from the IUP with 3 year upgrade.

Scenarios not considered

I don’t consider the scenarios where you buy your phone and subsequently sell it rather than trade it in. I haven’t ever sold anything on eBay before, so I can’t speak too much for it.

If you have the time to sell your device every few years, it could end up making sense, but I encourage you to do your own math for such a scenario. There’s a bit of risk that should be accounted for, as you may not get the price that you’re expecting when you bought your iPhone.

The best choice is based on your own values

What do you care about?

You want	Optimal choice
More devices at lowest cost	IAP, upgrade annually
Save most money over time	IAP, upgrade @3yrs
No credit checks at lowest cost	Buy, keep for 3 years

If it’s just the economics, the IUP with an upgrade every 3 years is your best bet. If you want to own your devices and have more of them, then buying and keeping for 3 years seems like a good choice. If you’re like me and want to stay up to date with the latest iPhone features and don’t want to actually own the device, then go with the annual IUP cycle.

Hope this helps you out in your own decision process!

Additional Resources

Swift: Immutable Struct Singleton Initialization

Fri, 29 May 2020 11:10:01 -0700

How can you initialize a struct singleton that has dependencies? You likely chose to use a struct because you’re trying to reduce state and keep things immutable in your code. You’re also likely wanting to use the singleton pattern for a shared service or model in your project.

I’m a fan of keeping things immutable if possible, and I default to structs and lets before using classes, or vars.

One place I’ll use this pattern is when making services that depend on an external API like so:

struct ApiClient {
    private let secret: String
    
    init(secret: String) {
        self.secret = secret
    }

    // ...
}

struct LoginService {
    private let apiClient: ApiClient
    
    static let shared: LoginService = {
        let apiClient = ApiClient(secret: "CLIENT_SECRET")
        return LoginService(apiClient: apiClient)
    }()

    // ...
}

Notice that LoginService is immutable (look Ma, no vars!), and we can be sure that our shared instance will always be the same instance when we call LoginService.shared.

Often, our shared assignment is more complex than this. For example, the secret here used to initialize the API Client in a more mature project would not be a magic string like we have here and can instead be dependent on launch arguments or an environment variable.

Fastlane: Downloading AppStore Metadata

Thu, 28 May 2020 10:38:01 -0700

Just like we use git to be able to audit changes to our code over time, doing so with our app’s AppStore metadata lets us keep an eye on changes made to our AppStore page as well.

The first step in getting more control of our metadata is by having it live in our project’s repository. Keeping a copy of our metadata in git lets us keep track of changes to our app’s description, keywords, and even screenshots over time.

To do so, we use Fastlane’s deliver command with the download_metadata subcommand:

fastlane deliver download_metadata

Here’s what a run of this for Little Countdown looks like:

% fastlane deliver download_metadata
[✔] 🚀
[10:52:02]: Login to App Store Connect (appstore@nerdtower.com)
[10:52:03]: Login successful

+--------------------------------------+-------------------------+
|                    deliver 2.148.1 Summary                     |
+--------------------------------------+-------------------------+
| screenshots_path                     | ./fastlane/screenshots  |
| metadata_path                        | ./fastlane/metadata     |
| username                             | appstore@nerdtower.com  |
| app_identifier                       | com.nerdtower.Countdown |
| platform                             | ios                     |
| edit_live                            | false                   |
| use_live_version                     | false                   |
| skip_binary_upload                   | false                   |
| skip_screenshots                     | false                   |
| skip_metadata                        | false                   |
| skip_app_version_update              | false                   |
| force                                | false                   |
| overwrite_screenshots                | false                   |
| submit_for_review                    | false                   |
| reject_if_possible                   | false                   |
| automatic_release                    | false                   |
| phased_release                       | false                   |
| reset_ratings                        | false                   |
| team_id                              | [hidden]                |
| dev_portal_team_id                   | [hidden]                |
| run_precheck_before_submit           | true                    |
| precheck_default_rule_level          | warn                    |
| individual_metadata_items            | []                      |
| ignore_language_directory_validation | false                   |
| precheck_include_in_app_purchases    | true                    |
+--------------------------------------+-------------------------+

[10:52:15]: Writing to './fastlane/metadata/en-US/description.txt'
[10:52:15]: Writing to './fastlane/metadata/en-US/keywords.txt'
[10:52:15]: Writing to './fastlane/metadata/en-US/release_notes.txt'
[10:52:15]: Writing to './fastlane/metadata/en-US/support_url.txt'
[10:52:15]: Writing to './fastlane/metadata/en-US/marketing_url.txt'
[10:52:15]: Writing to './fastlane/metadata/en-US/promotional_text.txt'
[10:52:15]: Writing to './fastlane/metadata/en-US/name.txt'
[10:52:15]: Writing to './fastlane/metadata/en-US/subtitle.txt'
[10:52:15]: Writing to './fastlane/metadata/en-US/privacy_url.txt'
[10:52:15]: Writing to './fastlane/metadata/en-US/apple_tv_privacy_policy.txt'
[10:52:15]: Writing to './fastlane/metadata/copyright.txt'
[10:52:15]: Writing to './fastlane/metadata/primary_category.txt'
[10:52:15]: Writing to './fastlane/metadata/secondary_category.txt'
[10:52:15]: Writing to './fastlane/metadata/primary_first_sub_category.txt'
[10:52:15]: Writing to './fastlane/metadata/primary_second_sub_category.txt'
[10:52:15]: Writing to './fastlane/metadata/secondary_first_sub_category.txt'
[10:52:15]: Writing to './fastlane/metadata/secondary_second_sub_category.txt'
[10:52:15]: Writing to './fastlane/metadata/trade_representative_contact_information/trade_name.txt'
[10:52:15]: Writing to './fastlane/metadata/trade_representative_contact_information/first_name.txt'
[10:52:15]: Writing to './fastlane/metadata/trade_representative_contact_information/last_name.txt'
[10:52:15]: Writing to './fastlane/metadata/trade_representative_contact_information/address_line1.txt'
[10:52:15]: Writing to './fastlane/metadata/trade_representative_contact_information/address_line2.txt'
[10:52:15]: Writing to './fastlane/metadata/trade_representative_contact_information/address_line3.txt'
[10:52:15]: Writing to './fastlane/metadata/trade_representative_contact_information/city_name.txt'
[10:52:15]: Writing to './fastlane/metadata/trade_representative_contact_information/state.txt'
[10:52:15]: Writing to './fastlane/metadata/trade_representative_contact_information/country.txt'
[10:52:15]: Writing to './fastlane/metadata/trade_representative_contact_information/postal_code.txt'
[10:52:15]: Writing to './fastlane/metadata/trade_representative_contact_information/phone_number.txt'
[10:52:15]: Writing to './fastlane/metadata/trade_representative_contact_information/email_address.txt'
[10:52:15]: Writing to './fastlane/metadata/trade_representative_contact_information/is_displayed_on_app_store.txt'
[10:52:15]: Writing to './fastlane/metadata/review_information/first_name.txt'
[10:52:15]: Writing to './fastlane/metadata/review_information/last_name.txt'
[10:52:15]: Writing to './fastlane/metadata/review_information/phone_number.txt'
[10:52:15]: Writing to './fastlane/metadata/review_information/email_address.txt'
[10:52:15]: Writing to './fastlane/metadata/review_information/demo_user.txt'
[10:52:15]: Writing to './fastlane/metadata/review_information/demo_password.txt'
[10:52:15]: Writing to './fastlane/metadata/review_information/notes.txt'
[10:52:15]: Successfully created new configuration files.
[10:52:15]: Successfully downloaded large app icon

After a successful download, you should now have your metadata in your project’s ./fastlane/metadata. Great!

Something to notice above is that things like the app’s description, keywords, and release notes live inside of localized subdirectories for each locale such as en-US. If we had AppStore metadata localized into other locales, we’d see other subdirectories for each of those as well.

At this point, you can consider:

Having your ./fastlane/metadata be the source of truth of your release notes so that they’re bound directly to a commit or tag in your repository
Using deliver’s subcommand submit_build to submit your builds for review with changes you make to metadata in your repository. This opens the door to have our CI/CD pipeline manage submission of our build instead of having to login to AppStore Connect’s website and “pressing the button.”

With your AppStore metadata downloaded and stored in your project’s repository, you gain visibility and control of your presence in the AppStore and the data on your app’s page. Furthermore, you open up the path to automating the management of this metadata as well.

Swift: Converting String to Date

Wed, 20 May 2020 12:20:01 -0700

When consuming an API response, we’ll often see an ISO 8601 formatted date String like this:

2020-04-20T16:20:42+02:00

As a String, it’s not really useful for us, as it’s not really something you want to show your users. We may want to be able to extract just the hour, calculate the time interval between this date and others, or just format it in a way that’s more meaningful for the user. To do that, we can convert the String to a Date object.

Let’s add an extension to String with a new function asDate(). I like doing this so we don’t need to add additional classes or add more to the global namespace.

We can start by adding some tests:

class String_ExtensionsTests: XCTestCase {
    func testAsDate_invalid_notIso() throws {
        let invalidString = "2020-04-20 16:20:42 GMT+02:00"
        let date = invalidString.asDate()
        XCTAssertNil(date, "should not have converted string to date")
    }

    func testAsDate_invalid_missingTimeDelimiter() throws {
        let missingTimeDelimiterString = "2020-04-20 16:20:42+02:00"
        let date = missingTimeDelimiterString.asDate()
        XCTAssertNil(date, "should not have converted string to date")
    }
    
    func testAsDate_valid() throws {
        let isoDateString = "2020-04-20T16:20:42+02:00"
        
        let date = isoDateString.asDate()
        
        XCTAssertNotNil(date, "should have converted string to date")
        
        let calendar = Calendar(identifier: .gregorian)
        let twoHoursInSeconds = 60 * 60 * 2
        let amsterdamTimeZone = TimeZone(secondsFromGMT: twoHoursInSeconds)!
        let components = calendar.dateComponents(in: amsterdamTimeZone, from: date!)
        XCTAssertEqual(components.year, 2020, "has correct year")
        XCTAssertEqual(components.month, 4, "has correect month")
        XCTAssertEqual(components.day, 20, "has correct day 🌲")
        XCTAssertEqual(components.hour, 16, "has correct hour")
        XCTAssertEqual(components.minute, 20, "has correct minute")
        XCTAssertEqual(components.second, 42, "has correct second")
        XCTAssertEqual(components.timeZone, amsterdamTimeZone, "has correct time zone")
    }
}

Some things to note here:

Even though we’re likely OK with using Calendar.current, I like being as explicit as possible in my tests, since we don’t always know if the device running our tests will actually be set to a Gregorian calendar (but, honestly, it’ll likely be so).
I’ve set the time zone to match the String we’re testing. This just makes it more clear and easy to understand without having to do additional math in my own head when asserting (or if the tests fail in the future).

Great, with our tests failing, it’s time to implement the actual code and get those checkmarks green. Luckily for us, Swift gives us ISO8601DateFormatter. This makes things super easy for us:

extension String {
    func asDate() -> Date? {
        let formatter = ISO8601DateFormatter()
        return formatter.date(from: self)
    }
}

What? That’s it? Yup. Not a whole lot of code (vs our test code), but we can be sure we’re handling date Strings properly when we encounter them. Moreover, we’ve documented how we expect asDate should work, so other developers on our team know what to expect when using it.

🌲🌲🌲

Horizontal Stack Content Hugging

Tue, 19 May 2020 11:14:01 -0700

In your iOS app, you’ve got a Horizontal Stack with subviews layed out like so:

override func viewDidLoad() {
    super.viewDidLoad()
    
    let loveLabel = UILabel()
    loveLabel.text = "LOVE"
    loveLabel.backgroundColor = .systemRed
    
    let kissesLabel = UILabel()
    kissesLabel.text = "Kisses"
    kissesLabel.backgroundColor = .systemYellow
    
    let xoxoLabel = UILabel()
    xoxoLabel.text = "XOXO"
    xoxoLabel.backgroundColor = .systemBlue
    
    let stack = UIStackView(arrangedSubviews: [
        loveLabel,
        kissesLabel,
        xoxoLabel,
    ])
    stack.translatesAutoresizingMaskIntoConstraints = false
    stack.axis = .horizontal
    stack.spacing = 4
    
    view.addSubview(stack)
    
    NSLayoutConstraint.activate([
        stack.centerXAnchor.constraint(equalTo: view.centerXAnchor),
        stack.centerYAnchor.constraint(equalTo: view.centerYAnchor),
        stack.leftAnchor.constraint(equalToSystemSpacingAfter: view.leftAnchor, multiplier: 1),
        view.rightAnchor.constraint(equalToSystemSpacingAfter: stack.rightAnchor, multiplier: 1),
    ])
}

Hmm, a bit too much LOVE

But what if you really want is to see less of that LOVE and more of those Kisses?

The LOVE label is taking too much horizontal space: you want Kisses to be streching out as much as possible.

What we need to do is let Auto Layout know how to prioritize our views':

Content Hugging
Compression Resistance

In this case, we care about:

The LOVE label’s Content Hugging priority
On the Horizontal axis

Let’s give LOVE a high Content Hugging priority so we can smother it with our coder love:

    let loveLabel = UILabel()
    loveLabel.text = "LOVE"
    loveLabel.backgroundColor = .systemRed
    loveLabel.setContentHuggingPriority(.defaultHigh, for: .horizontal)

Excellent.

By just adding a single line of code, we were able to tell Auto Layout: “Hey, I want you to prioritize hugging this content (the LOVE label) and let other views on the Horizontal axis to take up more visual space.”

Love and Kisses. XOXO ❤️

Adding an Instructional Overlay for first time users to your app in iOS

Sat, 16 May 2020 13:04:01 -0700

Sometimes called Coachmarks, a Wizard, or an Onboarding Flow, this common UX pattern is used to guide first time users to an app on its features in your UI.

Here’s a quick and simple way to implement this pattern:

private func buildButton(with title: String) -> UIButton {
    let button = UIButton(type: .system)
    button.backgroundColor = .systemOrange
    button.setTitle(title, for: .normal)
    return button
}

override func viewDidLoad() {
    super.viewDidLoad()
    
    let buttonText = "Put me in coach!"
    
    let button = buildButton(with: buttonText)
    button.translatesAutoresizingMaskIntoConstraints = false
    
    let overlay = UIView(frame: .zero)
    overlay.translatesAutoresizingMaskIntoConstraints = false
    overlay.backgroundColor = UIColor.black.withAlphaComponent(0.5)
    
    let coachButton = buildButton(with: buttonText)
    coachButton.translatesAutoresizingMaskIntoConstraints = false
    coachButton.isUserInteractionEnabled = false
    
    let coachLabel = UILabel(frame: .zero)
    coachLabel.translatesAutoresizingMaskIntoConstraints = false
    coachLabel.textColor = .white
    coachLabel.text = "Get player in the game"

    view.addSubview(button)
    view.addSubview(overlay)
    view.addSubview(coachButton)
    view.addSubview(coachLabel)
    
    NSLayoutConstraint.activate([
        button.centerXAnchor.constraint(equalTo: self.view.centerXAnchor),
        button.centerYAnchor.constraint(equalTo: self.view.centerYAnchor),
        
        coachButton.centerXAnchor.constraint(equalTo: button.centerXAnchor),
        coachButton.centerYAnchor.constraint(equalTo: button.centerYAnchor),
        
        coachLabel.centerXAnchor.constraint(equalTo: coachButton.centerXAnchor),
        coachLabel.centerYAnchor.constraint(equalTo: coachButton.bottomAnchor, constant: 20),

        overlay.topAnchor.constraint(equalTo: self.view.topAnchor),
        overlay.bottomAnchor.constraint(equalTo: self.view.bottomAnchor),
        overlay.leftAnchor.constraint(equalTo: self.view.leftAnchor),
        overlay.rightAnchor.constraint(equalTo: self.view.rightAnchor),
    ])
}

The idea here is that you have a duplicate button on top of a semi-transparent overlay. We use Auto Layout to constrain coachButton to the real button, and we also disable isUserInteractionEnabled since we don’t actually want the user to be able to select it in this flow.

Also, note how we’re using buildButton(with:) to instantiate the buttons so we make sure we’re actually constructing the buttons the same way for both button and coachButton.

Bitrise: Mobile CI Service

Thu, 06 Jun 2019 19:53:01 -0700

With the small iOS team at Hipmunk, having to maintain a box to run Xcode Server would have been costly in terms of:

Buying hardware
Upgrading/maintaining the hardware
Keeping the OS/software up to date

Furthermore, we’d have to find a separate solution for our Android team and gain expertise on maintaining their CI as well.

We ended up deciding to use Bitrise, a continuous integration and delivery service designed primarily for mobile platforms.

Which Plan?

We’d started out with the Standard Plan, which gave us:

12-15 minute builds
2 concurrencies
$1200 annual

That’s definitely a lot cheaper than self-hosting our own machine and spending the time to maintain it!

In my mind, generally, a 10 minute build time is a good number to stay under. Furthermore, with 2 engineers on each platform, we generally needed bandwidth for each engineer to run a build concurrently without slowing each other down. Being able to run a build for release during tighter times was important. Maybe we didn’t need 6 concurrents, but we thought 4 would generally give us enough room to work with.

We started looking at Bitrise’s Elite Plan with its beefier boxes, and we were able to do a trial to get some numbers out:

8-9 minute builds
4 concurrencies
$4800 annual

These costs were minor in comparison to the time we were saving on the team and the value we were getting out of quick iteration of our commits. Definitely still cheaper than running and maintaining our own machines.

It made a lot of sense to go ahead and upgrade to the Elite Plan, so we moved forward with that, and months later continued to be happy with our decision.

Running on Multiple Stacks

When Apple releases a new major version of Xcode and accompanying SDKs, you generally need to build your app on the new version and ensure you’ve handled all the warnings, deprecations, and sometimes bugs that crop up because of it.

A strategy I like to use here is to open a PR for the new changes on a branch like xcode11 and start pushing changes there. I can then setup Bitrise to use the new stack and ensure that our CI will continue operating properly with the new version.

Bitrise does a great job of making sure beta versions of Xcode are available as soon as possible, so you can get running on the new versions within days of Apple’s announcements.

UPDATE: John Sundell’s written a great post on not needing to branch to handle the two Xcode versions. Very clever! I haven’t given it a try yet, but I think it makes a lot of sense and will report back after giving it a shot.

Gotchas

We were using a fastlane lane to run our tests, and we would intermittently get failures with the error:

Testing failed:
Command CompileSwift failed with a nonzero exit code
Command CodeSign failed with a nonzero exit code
Testing cancelled because the build failed.
** TEST FAILED **

We switched over to using Bitrise’s own Xcode Test for iOS Step, and haven’t had any issues since. I saw the same phenomenon when using Bitrise for little countdown.

Automated Beta/Internal Change Notes with Fastlane

Sun, 02 Jun 2019 16:51:01 -0700

Do your TestFlight or Crashlytics have change notes that say something useless like Fixed bugs? This is probably as useful as the equally ambiguous commit message fixed.

Or maybe you painstakingly look through your PRs to find out what changes went in since your last release and scribble something out quickly so you can just get the build ready for your product or testing teams.

This process of writing up beta/internal change notes can be streamlined and save devs precious brain cells that can be used for more valuable decision making.

Step 1: Ensure you’re tagging your submission commits

I like to tag submission commits with tags shaped like:

submission/v4.2.0

Tagging with this strategy:

Marks a time in history of exactly what the repo looked like when v4.2.0 was submitted to the App Store
Groups all submissions together so they can be easily referenced in the future

Step 2: Fastlane - Get Change Notes

If you’re not already using fastlane, I highly recommend adding it to your project. If anything, at least use fastlane match to manage your certificates and provisioning profiles to save you and your team’s sanity.

Add this new lane to your Fastfile:

desc "Get current change notes"
lane :get_change_notes do
  # use subject/title of each git commit and bullet each line
  changelog_from_git_commits(
    pretty: '- %s',
    tag_match_pattern: 'submission/*',
    merge_commit_filtering: 'exclude_merges'
   )
end

Step 3: Fastlane - Add Change Notes to Pilot/Crashlytics

Now you can take the output from get_change_notes and use it in your call to pilot or crashlytics:

pilot(changelog: get_change_notes)

crashlytics(notes: get_change_notes)

I helped set this up as part of the Hipmunk iOS app’s release process. It was a preliminary step that was needed in order to have automated releases that could be deployed from CI, and it saved the team countless hours since it was implemented.

There just doesn’t need to be any need to think about what to go into these notes anymore, and teammates outside of the dev team have clear visibility into what’s going into builds.

iOS Development on Ivan: Thinking

Ready Time's on TinyLaunch

Ready Time 3.3: Travel Time

What’s new

Onward

Next Chapter of Little Memory

Ready Time 3.2: Shared Plans and Daily Repeating Plans

Shared Plans

Daily Repeating Plans

Templates

Onward

Technology is not enough

Moving along on Ready Time relaunch

It's like gonna have like this tab

Ready Time

Getting Ready for Ready Time

Time Lock, New Premium Feature

Example

Why This Matters

Development login credentials in Xcode

Development Scheme

Pre-filling the Auth Form

Build and Run

Onward

iOS Developer Resources

Developer News and Community

Developer Blogs

Other News

Apple Resources

Software

Other

SwiftUI: Link phone numbers, emails, URLs in Text without Markdown

Additional Resources

CoreData: All that is left to us is honor

How to do?

See also

iPhone Upgrade Program vs Buying, Trade In

Is Apple’s iPhone Upgrade Program worth it?

Sounds like some luxury expensive shit

Let’s break it down

How bougie is it?

Scenarios not considered

The best choice is based on your own values

Additional Resources

Swift: Immutable Struct Singleton Initialization

Fastlane: Downloading AppStore Metadata

Swift: Converting String to Date

Horizontal Stack Content Hugging

Hmm, a bit too much LOVE

Adding an Instructional Overlay for first time users to your app in iOS

Bitrise: Mobile CI Service

Which Plan?

Running on Multiple Stacks

Gotchas

Automated Beta/Internal Change Notes with Fastlane

Step 1: Ensure you’re tagging your submission commits

Step 2: Fastlane - Get Change Notes

Step 3: Fastlane - Add Change Notes to Pilot/Crashlytics