iOS Development on Ivan: Thinking

Little Memory 2.1: Fixes from 2.0 Feedback

Wed, 07 Oct 2026 09:45:00 -0700

Little Memory 2.1 is out. Most of the updates for it came from feedback on 2.0:

Fixed the iOS 27 bug I mentioned a few days ago, where the paging dots under the diary didn’t match the top toolbar
The import screen is clearer about the two toggles that need to be turned on to continue
Opening a day in a large diary is faster
When installing on a 2nd device, the app now knows you have memories in iCloud and welcomes you back; the old wording was confusing

Thanks to everyone who sent in bug reports and feedback.

/little-memory #ios-development #nerdtower

Sat, 03 Oct 2026 15:03:55 -0700

There’s a visual bug with Little Memory on iOS 27 in the main diary view. The paging indicators have a different background than the top toolbar. Fix will come in 2.1. Working on bugs that have come in from 2.0 too. Thanks to everyone who’s given me feedback and bug reports.

/little-memory #ios-development

Ready Time 3.9: Live Activities

Fri, 02 Oct 2026 21:06:55 -0700

Ready Time has always had push notifications when it’s time to start each step. But in between each step, you had to unlock your iPhone and open the app to see the status of your plan. Now a running plan stays on your Lock Screen and in the Dynamic Island with Live Activities.

The whole idea of the app has always been to help you stay on time and to know what to do next, but keeping the Ready Time app open constantly doesn’t always make sense. You may be driving on your way to a meeting. You might be dealing with a screaming toddler during your morning routine, trying to juggle texting your babysitter or partner at the same time.

Being able to set your phone down and quickly glance on your Lock Screen to see the status of your plan helps you make sure you’re on track to get to your meeting, your appointment, and any deadline you’ve set on time. It even shows up on your Apple Watch.

Turning it on

Live Activities are part of Premium. With Premium, every plan shows up on its own when it starts. If there’s a plan you’d rather keep off your Lock Screen, tap the Live Activity button on the plan. And if you don’t want them at all, you can disable Live Activities in Settings.

Onward

You can download Ready Time on the App Store.

If you have feedback, we’d love to hear from you. Drop me a note.

/ready-time #ios-development #nerdtower

Ready Time 3.8: Weekdays and Two New Themes

Tue, 29 Sep 2026 19:00:00 -0700

We’ve had daily and weekly repeating plans for Ready Time, but some things we only do on weekdays. Welp, now we’ve got Weekday repeating plans (plans that repeat only Monday through Friday). This is perfect for school drop-off, the commute, the walk to the bus.

Repeat is easier to find

Repeat used to live in the menu in the plan editor, and it was a bit hidden. It now sits at the top of the deadline section in the plan editor, next to the time it applies to. The time row also tells you which days it covers, like “Mon-Fri at 8:15 AM”.

While we were there, we made Buffer a bit easier to find too, so it’s right on the top toolbar.

Two new themes

Kyoto. Sakura, wisteria and pale silk. It’s the softest theme in the app. Inspired by our recent travels to Japan.
COOLMOVES. Synthwave purple with teal steps. So 80’s. What, you don’t know COOLMOVES?

Both are now in Premium.

We also cleaned up some of the existing themes where the contrast would sometimes make it hard to read items in your plans. Sedona and Countdown Classic should now read better in Dark Mode.

Onward

You can download Ready Time on the App Store.

If you have feedback, we’d love to hear from you. Drop me a note.

/ready-time #ios-development #nerdtower

Tue, 29 Sep 2026 13:28:06 -0700

Brent Simmons:

The stock Mac UI is designed by Apple, the best designers in the world, and do you really think you can do better? Really?

The app world is full of people who think they’re better and they’re really, really, really not.

This is the same way I feel whenever I see a Porsche with a giant after-market spoiler on it. Do folks really think they can do better than Porsche?

He’s talking about Mac apps here, and I feel similarly about iOS apps.

/software-development #design #apple #ios-development

Little Memory 2.0: Moving 15 years of memories off my servers

Tue, 22 Sep 2026 10:00:00 -0700

In April, I started inviting folks to test out Little Memory 2.0, a full re-write of the one-sentence-a-day journal I launched in 2011. I had most of the bones of the new app ready at that point, but, as most folks who develop software professionally know, the last 20% can often be the most tricky, difficult, and filled with unforeseen bugs.

What the first testers found

In the first batch of testers, 4 longtime users imported thousands of memories, and the world didn’t crash and burn, yay!
Lilmem previously had a way to write memories via SMS. Twilio sent a webhook request to us when these would arrive, and, for longer messages that were over 160 characters, I would get 2+ requests. However, they wouldn’t always come in chronological order. Moreover, they didn’t have a single message ID to let me know they were a single message. Because of a bug in the backend, this ended up letting some users have multiple entries on a single day (oi!). I cleaned this up in the import into the app, but it did cause some issues for some folks who did their initial imports into the app.
Some users really enjoy writing on their desktop before bed, and being able to add memories only from the iOS app was a problem. I didn’t want to end up back in a place where I was storing entries in my DB again, but I did figure something out: Drafts. Drafts lets Premium users write a memory from the web for the day, and when the iOS app is launched, it fetches the unsaved drafts and reconciles them so they end up living in the app.
There were some users reporting that they didn’t see photos on days where they were sure they had photos saved. There was a concurrency issue where even though a photo would get downloaded, it wouldn’t get properly attached to a memory. After a good amount of logging and tracking this down, I got a build for testers that included a repair pass to get their photos back.
So glad I did a few rounds of testing on TestFlight. These would have been super expensive things to handle after release.

Get off my lawn! And servers!

I’ve generally felt uncomfortable storing people’s memories on my own servers. What if I got hit by a bus today? Someone would have to make sure the servers keep running so folks could keep reading and writing in their personal private journals. That’s definitely not something I’d want for myself or for Lil’memmers.

Not only that, but now that all your memories live on your phone, you can read/write offline, even without internet access. And it opens up the door for some exciting new features. I can’t wait to get 2.0 into people’s hands and start iterating on the app with some ideas I’ve had queued up for years.

On AI, privacy, and your diary

A diary is about the most personal data an app can hold, and every app holding it is one breach, acquisition, or bad decision away from leaking that extremely sensitive and private data. With AI becoming more and more capable every day, the possibility of servers getting hacked grows. I’ve never used any Little Memory data for AI training, but even the possibility that your data could be read or used for training is something I would rather avoid.

With Little Memory 2.0, the iPhone app is offline-first. Memories are written and stored on the phone, you can keep a diary without an account, and your private and personal data stays in your control and in your phone rather than in the cloud.

What’s new?

Your memories are imported into your iPhone
All your memories are now synced across your devices with iCloud
You can now add/edit memories even when offline (yay!)
A ground-up redesign of the whole app
The app is now free to download, and if you already paid for it, you keep Premium
After you update and import your memories, you’ll no longer get email reminders
If you want to write from the web or from your desktop, after importing to the app, you can still visit the website and write an entry for Today with Drafts (Premium feature)
There’s a new Photo Recap feature that lets you view photos for a day alongside your memory for that day
Still here: charts, reminders, streaks, Dropbox backups, export
Little Memory supports Dark Mode now, woo-hoo!

The blast from the past is back again

Little Memory 2.0 is now live in the App Store with all the latest updates.

Longtime users: Your memories are ready to come home to your iPhone. Download the new app and import them to your device so you can read and write without needing to be online.

New users: Welcome! Write one sentence about your day in less than 15 seconds, and start seeing your memories come back to you.

I’m excited to share Little Memory 2.0 with you. It’s been a joy getting it ready for users, and I’ve been wanting to get it into people’s hands to make the meaningful experience of reflection and journaling even easier and more enjoyable.

I think you’re going to really like the new app, and please reach out if you have any feedback or find any issues.

Some thanks

A big thanks to the design and user research done by Ray Inoue. Much of the learnings that came out of Ray’s work informed the design decisions that ultimately went into the 2.0 rebuild. It’s taken me way too long to get these changes into production, but it’s finally here! Sorry it took me so long, Ray!

/software-development /little-memory #ios-development

Fri, 18 Sep 2026 22:53:21 -0700

I, too, have been concerned about the vertical tab bar on the iPhone Duo not having space for labels. But looks like tap and hold reveals them. Nice solution.

/software-development #apple #design #ios-development

Action Runner iOS Architecture

Tue, 15 Sep 2026 15:15:23 -0700

Around mid-2021, I’d started developing SwiftUI apps in a new way. I’d previously considered architectures like MVC, MVVM, VIPER, etc and many of them never felt right. I often found myself spending time considering where to put business logic. With SwiftUI, it wasn’t entirely clear where data-level changes should be taking place.

Controllers?

Most (or any?) business logic certainly shouldn’t be living in the views, but should I be building controllers to manage data? When I did that, I ended up struggling to define the boundaries of each controller. Dependencies would start to get messy, and I’d start getting circular dependencies across controllers that called each other. Controllers would start to get really big, especially for authentication, and I’d often struggle to quickly find code I was looking for.

What’s an `Action`?

In my work using React, the one-way data flow in Redux and how it handled actions was an idea that came to mind to try to tame these large controllers I was noticing in my projects. I started with adding a simple struct in Swift that would work like an action that a view or another action could call:

struct LoginAction {
    let email: String
    let password: String

    func execute() async throws {
        // ...
    }
}

With a call site like:

let action = LoginAction(email: "...", password: "...")
try await action.execute()

I essentially pulled out each function from my controllers and now had them each as their own structure.

Having a dedicated struct for each action gave me some nice things:

I can create helper functions for the main execute() without exposing them to other actions, whereas if this were all part of a controller it would be less isolated
If I wanted to expose that helper function to other actions, I could do so with its own dedicated Action
I could write unit tests for that specific action without needing to worry about dependencies that a full controller might carry
Chaining Actions could be done within an execute like: otherAction.execute() (this gets even cooler later when we pass through RunContext)

What about dependencies? In the case of this LoginAction, I’d have to bring in some sort of API to actually make an HTTP request and execute that request.

Enter `ActionRunner` and `RunContext`

struct ActionRunner: Sendable {
    let runContext: RunContext

    func run<A: RunnableAction>(_ action: A) async throws -> A.Output {
        try await action.execute(in: runContext)
    }
}

protocol RunnableAction: Sendable {
    associatedtype Output
    func execute(in context: RunContext) async throws -> Output
}

struct RunContext: Sendable {
    let services: ApiServices
}

And then we update LoginAction to:

struct LoginAction: RunnableAction {
    let email: String
    let password: String

    func execute(in context: RunContext) async throws -> LoginResult {
        let service = context.services.account
        let response = try await service.login(email: email, password: password)
        // ...
    }
}

An ActionRunner can be added to SwiftUI’s EnvironmentValues to make them easy to get from your views:

struct LoginView: View {
    @Environment(\.actionRunner) private var runner
    // ...

    private func login() async {
        do {
            let loginAction = LoginAction(email: "...", password: "...")
            self.loginResult = try await runner.run(loginAction)
        } catch {
            // ...
        }
    }
}

And this is how chaining would look now:

struct LoginAction: RunnableAction {
    func execute(in context: RunContext) async throws -> LoginResult {
        let service = context.services.account
        let response = try await service.login(email: email, password: password)

        let storeTokenAction = StoreTokenAction(token: response.token)
        try await storeTokenAction.execute(in: context)

        // ...
    }
}

Analytics

I ended up adding a helper function as an extension to RunnableAction:

extension RunnableAction {
    func withAnalytics<Result>(_ event: AnalyticsEvent, _ perform: () async throws -> Result) async rethrows -> Result {
        // ...
    }
}

So we can call it in our Actions thusly:

struct LoginAction: RunnableAction {
    let email: String
    let password: String

    func execute(in context: RunContext) async throws -> LoginResult {
        let service = context.services.account
        return try await withAnalytics(.login) {
            let response = try await service.login(email: email, password: password)
            // ...
        }
    }
}

Action Runners

I’ve been calling this the Action Runner Architecture. It’s served me well across multiple projects in offline-first apps, CoreData apps, API driven apps, and App Clips. I’ve codified it into its own package, and I continue to use it in my projects today.

There are still issues that are not yet fully addressed here:

Infinite recursion can happen with what we have now
We need to define an ActionRunner for testing so that dependencies are stubbed in a testing RunContext
I group related Actions in a single file, but I still need make decisions on where things go

Who else has done this?

I found it interesting that Whatnot, in 2022, came up with a similar pattern that they show in their blog post: Reacting to Native: How we rebuilt a unicorn iOS app in 4 months.

Their example of their BookmarkLivestreamAction smells very similar to what I’ve done with my own pattern:

class BookmarkLivestreamAction {
    // ...

    func run(completion: @escaping FollowLivetreamRequestCompletionHandler) {
       /// ...
    }
}

A more modern implementation would likely use Swift’s structured concurrency rather than the escaped closure, and I prefer to make sure my actions don’t hold state, so mine are always structs.

/software-development #ios-development

Shopify is moving from React Native to native Swift/Kotlin

Mon, 14 Sep 2026 10:20:55 -0700

Native is now the future of mobile at Shopify (via):

Native still means building and maintaining software on two platforms, that cost has not disappeared. What changed is that agents can now do enough of the implementation, translation, testing, and review work that it’s no longer the deciding factor it was in 2020.

React Native apps can be fast. Ours are. We are making this change because agents have reduced the advantages of sharing implementation, while the advantages of building for each platform remain. Native keeps us closer to platform capabilities and first-party tooling, with fewer framework and dependency layers between our code and the platform.

I’ve noted before that React Native can make more sense for larger teams that have more bandwidth for more testers and have expertise in React/JS tooling as well as native code/tooling, which helps manage the “write once, debug everywhere” problem. With smaller teams, I find that it’s harder to manage, as code changes can easily scatter bugs across platforms. And with React Native, you still need platform expertise, but now you need both native expertise and React Native expertise.

From their engineering blog, it also looks like they were bumping into issues managing code re-use between the React Native and native layers:

For the Shop App, this coincided with our next major React Native investment: adopting the New Architecture. That work would have required us to revisit native module integrations, rendering, and the boundaries between shared and platform-specific code.

I imagine some of the code re-use complications come from trying to build native widgets, extensions (looking at you, Notifcation Service Extension), and things like App Clips. It’s already complicated enough to manage and architect modules and shared code for a single platform (with varying platform versions too!): now think about having to consider how to do it across multiple platforms!

/software-development #ios-development #ai

Rewarding the user for wondering and trying

Sun, 06 Sep 2026 15:08:48 -0700

Ivory’s account switching:

There is also something great in seeing an interface that grows with you, or one where you can say “I wonder if…” based on your prior interactions and expectations, and the interface actually rewarding you for that thought.

I can get pretty strict about the use of terms, symbols, and gestures in an app. This kind of discovery of features is what that kind of strictness and consistency allows for. I see it very similar to game design, where you teach the user the rules of your interactions and visual vocabulary, and once they’re in that world they know what to expect.

/software-development #design #ios-development

Ready Time 3.6: Routines and App Clips

Fri, 04 Sep 2026 14:46:30 -0700

Now it’s faster and easier to add a new plan on Ready Time. With Ready Time 3.6, you can now select from 46 pre-defined routines to start your plan, including:

Morning routine. Getting up can be tricky for some of us, and having a regular routine definitely helps out.
Doctor appointment. You scheduled it, so you gotta make sure you get out the door and to the doctor’s office in time.
Concert night. Don’t wanna miss the headliner!

And now, for folks who are discovering Ready Time from the web, if you visit a routine page from Safari on iOS, you can start an App Clip right from the page to quickly start planning for a deadline without even needing to install the full app! Just open a routine page like Getting out of bed and open the App Clip right from Safari.

The App Clip lets you get notifications for each step in your plan, just like the full app. And when you’re ready to create more plans or customize your plans more, you can quickly download the full Ready Time app.

We hope these updates will make using and trying out Ready Time faster and easier.

Let me know if you have any feedback. I love to hear from you.

/ready-time #ios-development #nerdtower

Tue, 25 Aug 2026 21:14:35 -0700

Revisiting using Cursor for trying out more non-Claude agents, which I haven’t done too much of recently. I’ve generally been running Claude Code on my laptop, especially for iOS/Xcode projects, but doing a bit more with cloud agents with my web projects.

/software-development #ai #ios-development

Debugging Little Memory 2.0 Diary View Scrolling

Thu, 20 Aug 2026 14:32:50 -0700

I was working on fixing a bug in Lilmem 2.0 where switching from the diary’s Calendar mode to Memories mode caused a bug where the diary’s content “stuck” in a specific day. When I’d try to swipe between days after switching modes, the same day would re-appear after swiping.

I asked Claude to help me take a look and consider a fix. It came back with its usual vomit of text, and it left me rather confused. Rather than press it to give me even more text, I asked it to give me a visual explanation for what it was trying to do instead.

Here it’s explaining first the layout of the view so that we knew we were on the same page (ha!):

It outlined the various ways selectedPage changes can happen and its effects. And then it brings in a new concept of a “pinned” date key, which wasn’t clear to me in its wall of text:

And then it explains how and where the pinned date key is used:

After seeing Claude’s diagrams and explanation, I was able to get what it was talking about and start collaborating with it from there.

Super helpful getting these visual explanations. I was inspired by how I’ve seen Simon Willison has gotten Claude to make interactive explanations for him to better understand what the agent is talking about.

This view/interaction is a core part of the UX of Little Memory, and getting it right is critical to the experience of the app, so I had to make sure Claude wasn’t just doing something too wild. Having it show me (rather than just tell me) was incredibly useful to make sure I knew what it was trying to accomplish.

/little-memory /software-development #ai #ios-development #nerdtower

iOS Dev Weekly Issue 763 is a game changer

Fri, 14 Aug 2026 12:17:13 -0700

I’ve been reading iOS Dev Weekly for years now. Before this past May, the newsletter was written by Dave Verwer who I’d emailed a handful of times (he responded!) and always had great commentary about the state of the iOS development world. Sometimes, he’d be honest and note he didn’t have much to say that week, but he always brought interesting thoughts and ideas to the table.

Since May, the newsletter was handed over to Mobile Sessions who would take the helm and keep it going. I’ve been skimming the latest issues, as it helps to read about new frameworks or blog posts from the community to keep up with what’s happening on iOS. There’s a rotation of writers who have been taking turns on the newsletter for each week. It wasn’t Dave, but I still felt like I was connecting with people in the community.

The latest issue of iOS Dev Weekly, though, was just riddled with AI/LLM-isms that kept irking me:

A new set of App Store marketing assets arrives this autumn, and the work is design work rather than engineering, which means it probably isn’t on anyone’s board yet.

Ugh, this “and the work is…” just keeps showing up.

Most of us open Instruments, look at the call tree, and quietly close it again. The hierarchy is honest but it buries the answer.

And this “quietly” and “X is Y but Z” pattern as well.

And even in the And Finally…, which, IMO is an easy way to just bust something out by hand:

Somewhere a product manager shouted ship it, nobody asked a follow-up question, and CarPlay is now in a pontoon boat while some automakers are still workshopping their objections.

Oi. This “nobody asked X” pattern that AI loves so much and is so dramatic about.

Looking back at previous issues by Juan Marin, and Issue 759 was also by him. Still pretty AI/agentic.

I’m not against agents writing and helping to write (though, I know some folks are adamantly against any use of AI in writing), but IMO this is a real sloppy use of it. I read enough Claude-isms all day from my agents in Claude Code, and it’s already exhausting there. When I’m reading a newsletter like iOS Dev Weekly, I’m expecting more than just the first pass of what gets spit out. I think it’s lazy and really leaves a bad taste in my mind. A little editing of the original draft can easily clean these up and give the writer a bit more of their own voice and make it lot more interesting to read.

BTW: for my own blog here, I don’t use AI for writing/drafting, but I do have it help with proofreading/editing sometimes. For some of my projects, I do have it help out with marketing copy, but even there I steer it with my own voice guidelines and give a bit more personality/context than just its default generic style of prose.

/software-development #ios-development #ai

0xdead10cc

Thu, 23 Jul 2026 12:46:38 -0700

Debugging a crash on the new Little Memory 2.0 app today, and found a crash report with the termination code: 0xdead10cc. Interesting hex code, or rather, hexspeak. Seems there’s some fun Apple’s done with termination codes:

0xdead10cc - “dead lock” - an application holds on to a system resource while running in the background
0x8badf00d — “ate bad food” — the watchdog kill for blocking the main thread too long at launch/resume
0xc00010ff — “cool off” — killed for thermal pressure
0xdeadfa11 — “dead fall” — user force-quit an unresponsive app
0xbad22222 - “bad too repeatedly” - a VoIP application has been terminated by iOS because it resumed too frequently
0xbaaaaaad — “baaaaad” - the log is a stackshot of the entire system, not a crash report
0xdeadfeed - “dead feed” - crash when a timeout occurs spawning a service

/software-development #ios-development #nerdtower

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 #ios-development #nerdtower

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.

/ready-time #ios-development #nerdtower

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.

/little-memory #ios-development

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!

/ready-time #ios-development #nerdtower

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.

/software-development #ios-development #design

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.

/ready-time #ios-development #nerdtower

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.

/software-development #design #ios-development #parenting #ai

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.

/ready-time #nerdtower #ios-development

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.

/ready-time #ios-development #nerdtower

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!

/ready-time /software-development #nerdtower #ios-development

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.

/software-development #nerdtower #apple #ios-development

Little Countdown 2.0

Thu, 03 Nov 2022 13:28:18 -0400

Little Countdown 2.0 is now available for iOS. Just in time for helping you stay on time and stress free for your holiday travels. We rebuilt the app from the ground up and streamlined adding and editing Countdowns.

Your meeting’s at 9. Packing up for the kids takes 15 minutes. Dropping them off takes half an hour. Getting to the office is another 20 minutes. What time do you head out the door?

Leave math problems for school. Use Little Countdown .

We did a lot of housecleaning to make Countdown better:

Edit Tasks inline in the editor
Swipe to delete Tasks or Countdowns
Hold and drag to reorder Tasks
Alerts now show the next Task
Autocomplete of Countdown title is now more responsive

Mike Watts and I had a blast rebuilding the app from the ground up for a better and more streamlined experience. We hope you enjoy it.

Onward!

Twitter

/software-development /ready-time #nerdtower #ios-development

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

/software-development #nerdtower #apple #ios-development

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

/software-development #nerdtower #apple #ios-development

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.

Beginnings: Birth of Little Memory

Fri, 30 Apr 2021 16:01:51 -0700

In 2011, I was co-founder of Dojo, a startup focused on helping people build and keep habits. We set out to truly make a difference in people’s lives by helping them do the things they always wanted to do: work out, meditate, stop smoking, create art, and a whole list of other practices that we were learning from our early beta testers.

Even though Dojo ultimately didn’t succeed, we were honored to see many of our learnings adopted on other sites (like streaks!).

Sketching on ideas about streaks for Dojo

The most valuable and yet seemingly simple learning I had was that it was really hard for people to start a new habit like “Go to the gym 2 times a week,” but a habit like “Floss everyday” was easy for people to pick up.

The regularity of doing something simple and daily seemed to help a lot in getting the habit sticking.

When I started work on Little Memory, I had the following in my mind:

I want you to spend less than 5 minutes a day using Little Memory and still get value out of using it. The time in your life is important, and I’d rather you be out in the world enjoying your life rather than spending your whole day on your computer/phone.
I’d been following Gretchen Rubin’s blog and had just read her book: The Happiness Project. I loved the idea of a 5-year one sentence journal, as it helps in the practice of daily reflection both for the current day but also in how today relates to the same day in past years.
Do something little that has a lot of meaning in your life. Every day is important, even if we don’t realize it at the time.

I also loved the idea of streaks. :)

Book signing for The Happiness Project with Gretchen Rubin, January 2010

Birth of a Name

With the above in mind, I developed and deployed my first version of the web app. I just called it: diary. Nothing fancy. I would later start telling my friends about how I was working on “my little diary project,” and as I continued sharing it with friends, they would tell me that they enjoyed writing their memories and seeing little memories from their past. I liked the sound of that, and thus, a name was born: The Little Memory.

Remember Reminders?

The first version of the web app was so bare bones that all it was was a website with a simple way to enter and view today’s memory. I’d open up the page every evening, write my memory, and go to bed. Of course, most of us don’t have the kind of memory (little memory?) or discipline to remember to open up the same website every night (OK, except maybe for social media sites).

My friend, Jason Hreha, suggested adding email reminders. It was a great idea and a no brainer to add next. I added reminders to be sent to your inbox in the evenings, and in the reminder, you’d also see a reminder from exactly 1 year, 1 month, or 1 week ago in it.

The Highly Acclaimed iOS App

With my own growing usage of the iPhone, it became apparent that I really wanted an app for Little Memory. Emails and the website were fine, but I could see the potential for a more refined experience within an iPhone app. I brushed up on my Objective-C skills, fired up Xcode, and got to work–launching the first version of iOS app in 2013.

The app would go on to be featured in the Apple App Store in:

iTunes Staff Favorites
Dear Diary
Apps for Writers

I was delightfully surprised to see the amount of love and support from both Apple and from users who sent me emails about how much they enjoyed how simple the design of the iOS app was and also how meaningful the experience of using Little Memory was.

The Story Continues, One Day at a Time

This is by no means a complete history of Little Memory, but it does show how a humble little idea can grow from a tiny kernel. And just as Little Memory keeps growing, so do I. I’ve learned new skills, stepped out of my comfort zone, and also made many friends along this journey.

I recognize that you, as a Lil’memmer, are part of this journey as well, and I’m always grateful to be able to be a part of your personal journey.

I’ve always said I’ve wanted Little Memory to be here for over 100 years, and I continue to work on making it a reality.

Every day is a new beginning, and beginning starts with a single step. I hope to make that first step easier for more people. Self growth doesn’t have to be hard. Your journey of personal growth doesn’t have to be you climbing up a steep cliff every day. It can be simple. Just like writing a single sentence every day.

/little-memory #nerdtower #ios-development

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

#apple #ios-development

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.

/software-development #nerdtower #apple #ios-development

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.

/software-development #nerdtower #apple #ios-development

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.

🌲🌲🌲

/software-development #nerdtower #apple #ios-development

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 ❤️

/software-development #nerdtower #apple #ios-development

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.

/software-development #nerdtower #apple #ios-development #design

Little Countdown iOS app adds alerts for upcoming flights

Thu, 12 Sep 2019 00:00:00 +0000

With latest update to iOS app, Little Countdown users can easily add a new Countdown pre-filled with upcoming flight details

A new update to the Little Countdown app for iOS makes planning even easier for frequent flyers by notifying users of upcoming flights and letting them immediately add a Countdown to get ready for their day of departure.

This latest release of Little Countdown (v1.7.0) furthers its integration with the iOS Calendar. In addition to being able to easily create a Countdown with autocomplete with Calendar events, users will now get notifications to start a Countdown the evening before their upcoming flight.

“Having to remember to start a Countdown is one less thing frequent flyers need to remember now,” says Ivan Tse, creator of Little Countdown. “I’m incredibly excited to share this new update with travelers. We know how schedules can be hectic, and having Little Countdown be aware of your calendars makes planning process simpler and saves time that can be more productively used somewhere else.”

Alerts for upcoming flights are available for users who have enabled iOS Calendar access to Little Countdown on their iPhone or iPad.

Little Countdown is currently available on the iOS App Store for $2.99.

Link to download iOS App
Link to website

/ready-time /software-development #nerdtower #ios-development #apple

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.

/software-development #nerdtower #apple #ios-development

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.

/software-development #nerdtower #apple #ios-development

Little Countdown app integrates with iOS Calendar

Mon, 25 Mar 2019 00:00:00 +0000

Latest Little Countdown update lets users quickly add new Countdowns based on iOS Calendar events

A new version of Little Countdown is now available on the Apple App Store that integrates with the iOS Calendar. Now, when users begin typing a Countdown title, they’ll be presented with a list of upcoming Calendar events that they can select to start the Countdown with.

The latest version of Little Countdown (v1.3.0) makes adding new Countdown entries based off of iOS Calendar events quick and simple. When users select an upcoming Calendar event, Countdown will immediately:

Set the deadline of the Countdown to the time of the selected Calendar event
Set the title of the Countdown to be the name of the Calendar event

“It’s now even easier and faster to add a Countdown,” says Ivan Tse, creator of Little Countdown. “If you have a flight coming up in your Calendar, you won’t have to remember the time or flight number anymore: just let Little Countdown to the work for you. It’s a little thing, but we’re constantly working on ways to make it easier and simpler for users to use Countdown. We think users are really going to love this, and it’ll streamline setting up new Countdowns.”

To see upcoming Calendar events in Little Countdown, users can type a title matching an upcoming Calendar event when adding a new Countdown.

Little Countdown is currently available on the iOS App Store for $1.99.

Link to download iOS App
Link to website

/ready-time /software-development #nerdtower #ios-development #apple

Little Countdown iOS app adds support for Siri Shortcuts

Mon, 07 Jan 2019 00:00:00 +0000

With latest update to iOS app, Little Countdown users can now hear their current task by asking Siri.

A new update to the Little Countdown app for iOS helps users save time by not having to open the app to check their current task. With a simple voice command such as, “Hey Siri, get my current task,” users will hear the task that they’ve scheduled to be working on at that time. Users can also add shortcuts for getting the current Countdown or for creating new Countdowns. Useful shortcuts will be suggested in Spotlight searches.

This latest release of Little Countdown (v1.1.0) includes integration with Siri Shortcuts to perform common useful actions such as:

Getting the current task
Getting the current Countdown
Creating a new Countdown

“This latest update is great for the mornings when you’re rushing around the house and trying to make sure you’ve handled everything you need for the day,” says Ivan Tse, creator of Little Countdown. “When drinking that morning coffee or taking a shower, it’s not always easy to have the phone in hand. It’s so much faster and easier to run a Siri Shortcut to just ask for your current task with your voice. Little Countdown is designed to help streamline your tasks and minimize extra things in your daily life, and this update does exactly that.”

Siri Shortcuts and custom commands for Little Countdown can be activated from the Siri & Search menu in the Settings app for iPhone or iPad.

Little Countdown is currently available on the iOS App Store for $1.99.

Link to download iOS App
Link to website

/ready-time /software-development #nerdtower #ios-development #apple

Introducing the Little Countdown iOS app: helping travelers get to the gate on time

Mon, 10 Dec 2018 00:00:00 +0000

New app from creator of the mindfulness app, Little Memory, helps relieve traveler stress by getting them ready and out the door to the airport on time.

Available today, Little Countdown for iOS helps travelers prepare for their trip and stay on schedule to avoid missing their flight. After entering tasks they need to accomplish before their flight, users of Little Countdown will see when to start their plan and begin receiving alerts for each task when it’s time for each one.

With this release of Little Countdown, users can:

Work back from the flight’s boarding time to schedule when to leave for the airport
Enter and order tasks that need to be accomplished before leaving, such as: packing, calling a car for the airport, and going through security
Alerts for each task to stay on schedule
Save plans to be re-used and modified for future flights

“There’s a lot of stress and anxiety when flying, especially during the holidays,” explains Ivan Tse, creator of Little Countdown. “It’s always tricky to figure out all the things you need to do and when you need to do them before leaving for the airport. Little Countdown is a companion for travelers to help take the mind off the clock, spend some time to breathe, and just enjoy the moment.”

Little Countdown is currently available on the iOS App Store for $1.99.

Link to download iOS App
Link to website

/ready-time /software-development #nerdtower #ios-development

iOS Development on Ivan: Thinking

Little Memory 2.1: Fixes from 2.0 Feedback

Ready Time 3.9: Live Activities

Turning it on

Onward

Ready Time 3.8: Weekdays and Two New Themes

Repeat is easier to find

Two new themes

Onward

Little Memory 2.0: Moving 15 years of memories off my servers

What the first testers found

Get off my lawn! And servers!

On AI, privacy, and your diary

What’s new?

The blast from the past is back again

Some thanks

Action Runner iOS Architecture

Controllers?

What’s an Action?

Enter ActionRunner and RunContext

Analytics

Action Runners

Who else has done this?

Shopify is moving from React Native to native Swift/Kotlin

Rewarding the user for wondering and trying

Ready Time 3.6: Routines and App Clips

Debugging Little Memory 2.0 Diary View Scrolling

iOS Dev Weekly Issue 763 is a game changer

0xdead10cc

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

Little Countdown 2.0

More

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

Beginnings: Birth of Little Memory

Birth of a Name

Remember Reminders?

The Highly Acclaimed iOS App

The Story Continues, One Day at a Time

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

What’s an `Action`?

Enter `ActionRunner` and `RunContext`