The last few months have involved a major shift in how I do my work. With things like the Codex app and GPT-5.3+ reaching a level of code quality and consistency which has made them properly helpful. While my use of these tools for general purpose programming is still something I haven’t fully settled my workflow for, there are several uses for these tools which I have found I use very regularly.

These are prompts which I find are just generally useful, without requiring changing the inherent workflows I use for programming my apps. While I’m starting to tactically deploy agents for general programming tasks, I feel like the line of when I manually code and let the agent do it is currently more fluid.

Previews

Add a SwiftUI preview for TrainingBlockDraftEditorView, including data variants for each of the flows through the view

SwiftUI previews are huge benefit for my productivity when iterating on the UI/UX of a view, but I find the setup and creation of the data needed to drive them a bit of a pain to setup. But this is a perfect thing for an LLM to generate. I even had a great use recently where I was working on a weather view and I asked it to create different data blocks for different locations (to see how rainy vs sunny would render) and it worked out the API keys necessary to do some CURL requests to get actual data to use.

Realtime Documentation

Look at the publishSnapshot: method. Identify all the uses of it and determine what it does and how it is used. Describe its function and how it acts in all different uses of it

While I in theory it would be good for every one of my methods to been neatly documented, in practice that almost never happens. I work by myself in the code, so rarely need to document things like I would if I worked as part of a larger team. All the same, sometimes I find old code which I don’t fully remember or am making a change to something which I want to have full understanding of all uses of it. This ‘realtime documentation’ works a treat and has the added advantage over static documentation of being 100% up-to-date (rather than slowly slipping out of sync with reality of time).

Newly Localizable Strings

Look at the git diff since XXXX and locate any newly introduced user visible strings in the app which need to be localized. Add entries for each of these strings to each language supported by this app with relevant translations.

A pattern I’ll use for many of these prompts is the “Look at the diff since XXXX” where XXXX is the git hash of the last released version. This helps narrow down the changes and lets me isolate the updates to the relevant, new code.

In this case I want to have it seek out any newly added user-facing strings which were introduced and then add translations to the .strings files for each supported language. For years I’ve used LLMs to power the baseline translations I use in the app, so this shortcuts the process. It also has helped me to identify spots where I was using strings in a way which wouldn’t actually get triggered by the localization system (like a string literal passed into a view).

Testing plan

Look at the git diff since XXXX and create a recommended testing plan to provide good coverage of the areas of the app which are either new or were changed. Including likely user paths which could now include incorrect behaviour. Generate the export as a nicely formatted PDF checklist.

This works to evaluate all the code which has changed and then it gives me a list of things which I should do to make sure the app update didn’t introduce regressions. This has a few times identified little user paths which I might not have thought to test, or just generally helps me find areas to be more thorough with.

New Bugs

Look at the git diff since XXXX and explore whether the newly added code has introduced any bugs or likely unexpected results. Consider how the newly added code interacts with existing code and whether it will change existing behavior. Also, identify any areas where the newly added code is inconsistent with the general style and design pattern of the related, existing code.

The hit rate for this prompts I relatively low (maybe 20%), but the reality is I am always very grateful for any bug which I can find before it ships to customers, so having a second opinion on things is great.

Release Notes

Look at the git diff since XXXX and identify any new features or changes which would be visible to the user. Write a summarized release notes for the changes organized by size of the change (Major features, minor features, bugfixes).

This isn’t something which I expect to use directly for the user, but is a very helpful baseline for the creation of the real release notes. Also, this has helped me when I’ve been working on a larger, more sprawling update and I forget all of what I’ve done.

In Widgetsmith 8.2 we added the ability to give your widgets a ‘clear’ background. This isn’t actually clear (since iOS doesn’t allow that without private API use), but instead just crops part of your home screen wallpaper and uses that as the background.

In order for that to work I need to know precisely where each and every widget is on each and every iPhone model. This involved a massive process of screenshotting and a custom app for doing pixel precise analysis. There are 31 iPhone models which support iOS 26 (which I required for this update), so for each of these I needed to collect nine screenshots.

That all went well, but then I was faced with a slight dilemma about how/if I should support Display Zoom. This is a feature which increases the effective size of your iPhone’s controls by rendering your iPhone’s screen at a lower resolution and then enlarging it to fill the actual screen.

Since Display Zoom creates a new virtual resolution for the iPhone I would need to duplicate all the work I did to support the regular widget positions for each iPhone. This effort is made doubly tricky because the iOS simulator doesn’t properly render Display Zoom so I’d have to rely on screenshots from devices to which I have physical access.

To better inform this decision I went looking for statistics about the usage of Display Zoom, but couldn’t really find anything. So in a recent update to Widgetsmith I built in analytics code which reported Display Zoom usage.

What I found was that overall usage of Display Zoom was at 1.9%, which was lower than I would have guessed. For Widgetsmith I see 18% of users with their Text Size set to something larger than the default size, so I’d have guessed the number would have been much higher than 1.9%.

But that helps me to feel better about not supporting Display Zoom for this feature. That is simply not enough users for it to be viable to sustain the effort supporting it would require.

Here is a breakdown of the Display Zoom adoption by iPhone model family. It seems to skew heavily towards the smallest and largest iPhones.

Five years ago, a TikTok video changed my life.

And I can say that without any hyperbole.

The run up

In April of 2020, while the world was struggling through the early stages of the COVID pandemic, I launched an app for creating highly customizable complications for the Apple Watch. Watchsmith was my attempt at filling the void left by the lack of 3rd-party watch faces on watchOS.

It let you chose from loads of different colors, fonts and display types to make your watch face your own.

The app did alright commercially at launch—it was a niche app for a niche purpose. Much like many of my other apps at the time, I was building things which I wanted to exist and hoping that they’d find some audience with folks who had similar needs and desires.

Then that June at WWDC Apple announced iOS 14 and with it the introduction of a new widgets system for iOS. For the very first time iPhone users had the ability to personalize the look of their home screens (beyond their choice in wallpaper).

This then kicked off a busy summer for me adapting the work I’d done for Watchsmith to iOS. Because Watchsmith was my first top to bottom SwiftUI app I could actually re-use a lot of the code between the two and so by mid-July I had the early prototypes of this ready:

I’m planning to bring the customization options of @WatchsmithApp to widgets this fall. Since the complications are now all SwiftUI there is a ton of shared code and functionality between them. Got the first few types translated to test out the concept and seems to work great. pic.twitter.com/aYzRiDVRks

— David Smith (@_DavidSmith) July 14, 2020

I was very much viewing this as a project which would have a similar lifespan as Watchsmith. I was building a niche tool for niche users. I thought it was a good idea, and one I’d enjoy using myself, but at this point my expectations for it were still very managed.

When Apple announced that their September event would be on September 15, I thought I was mostly ready. I had a good basic version of the app with most of the feature-set copied over from Watchsmith.

I remember watching the video keynote, enjoying it as it went right up until this moment when Tim said:

…tomorrow! Usually we get a few days between when Apple releases their final “Gold Master” versions of an iOS version and when it will come out to the public. But in this case we had less than 24 hours to get our apps submitted, approved and ready for the world.

So I frantically got to work on final touches and build and at 5:54pm, I got it submitted.

Phew.

Then 6 hours later (at 11:30pm) Widgetsmith was approved by Apple, ready for when iOS 14 would be released the next day.

The Initial Response

So at 4:21PM on Wednesday, September 16, I hit release for Widgetsmith v1.0. The app launched as part of a much wider release schedule I was mananging at the time with updates for Pedometer++, Sleep++ and Watchsmith all going out that same day.

Introducing Widgetsmith. Fully customizable, scheduleable widgets for iOS 14, including widgets for Date, Time, Weather, Calendar, Reminders, Health, Tides & Astronomy. You choose the fonts, colors and appearance. Take control of your home screen. https://t.co/7BLTa31r3z pic.twitter.com/hUIbn01x3I

— David Smith (@_DavidSmith) September 16, 2020

The initial response to the app was warm but nothing out of the ordinary. Widgetsmith was the 59th app I had launched so I’d been through this process a lot over the preceding twelve years of indie app development. Typically you see a little swell of interest in the first few days. Then things settle down into a stable level and you move onto the maintenance and gradual improvement of the app.

This was what I thought would happen with Widgetsmith and the indications for the first few days were that this was exactly what would happen.

So the next day I left home with my family for our first proper holiday since the start of the pandemic, heading down to the beach.

The Turn

That Friday (September 18) I awoke and went about my morning like normal. Checking in on things a bit here and there but mostly enjoying some welcome down-time with my family. We went for a walk in a local nature preserve and generally had a nice quiet day.

It wasn’t until we got back from our walk that I had my first indication that something was up. Someone reached out to me on Twitter saying they’d seen Widgetsmith getting mentioned on TikTok. I click through to the video they linked to and discovered that there was a walkthrough video by Katarina Mogus which was going viral at the moment. Her video showed how to use Widgetsmith to make your home screen look Aesthetic AF.

@katamogz Reply to @an.elementopqrs #ios14 #ios14update #iphonetricks #iphonehack #ios14homescreen #learnontiktok ♬ Daisy (I’m Crazy But You Like That) - Ashnikko

I then opened my helpdesk page and I was shocked by what I saw. There were new emails coming in at a rate of several per second. A literal waterfall of customer outreach. I couldn’t even tap on things because the rate was too high. I was rather bamboozled at to what exactly is happening but at this point I realized something was different.

Widgetsmith had taken off in a way I could never have had the imagination to hope for. It was everywhere. It was being mentioned in the news, I even recall it getting a shout out in Vogue. Complete madness.

Widgetsmith quickly became the #1 App in the App Store, and remarkably stayed there for a couple of weeks.

I will be forever grateful for the App Store for the opportunity it allowed me. It still, to this day, doesn’t seem like it should be possible for a solo, indie developer to build something on their laptop. Hit submit, and then have it end up on over a hundred million people’s phones.

Five Years Since

The initial few weeks after Widgetsmith’s launch are a bit of a blur to me now. I remember frantically coding up requested features, trying to keep up with the outreach, and generally trying to keep holding everything together.

Eventually things settled down out of the frantic stage and into a new only-slightly-frantic stage. The app matured and developed and I was able to craft and adjust it towards the features its newly found audience wanted. What I had built as a niche tool for niche users had become a mainstream tool for mainstream users.

I wasn’t ever really sure if it would be a flash in the pan — a meteoric rise followed by a meteoric crash. Happily, five years on I can report that it was not a flash in the pan. Widgetsmith’s usage and userbase continue to grow. As of my writing this the app has received around 131 million downloads.

I continue to find enjoyment from coming up with ways to enhance and improve the app. Most recently with a fresh new re-design for iOS 26 and support for the new Liquid Glass widget styles.

I have no idea how long Widgetsmith will continue to be relevant, but I do know for sure that I am incredibly grateful for the opportunities and experience it has provided me.

All summer I’ve been chronicling my iOS 26 redesigns. With the September event just around the corner I am delighted to report that I was able to complete my work for both Pedometer++ and Widgetsmith.

The final styling of each redesign is different between the two apps but in both cases I feel like they landed on a solid interpretation of the new Liquid Glass design language.

I figured the best way to explain the design I went with for Pedometer++ was to make a short video walking through the design and narrating my thought processes for some of the major screens in the app:

watchOS 10 Redux

The funny thing about working on my Liquid Glass redesign for the Pedometer++ watchOS app is how very little needs to actually be done. A couple of years ago with watchOS 10 Apple introduced a very similar design language, with edge-to-edge backgrounds and frosted overlays. This redesign also carried with it the underlying nudge to move away from any form of custom navigation and instead rely on system provided mechanisms.

So when I did a simple rebuild of the project with Xcode 26 the result for many of my screens was already pretty close. Here’s the main current steps screen.

Other than the buttons going from the flat frosted material to the glassy sheen there is very little which initially needs to be done here. Similarly, the basic workout screen has a similar result.

Route Planner

Where things start to get slightly more interesting is when I look at some of the more sophisticated screens in the app. For example the route planner screen.

Here the initial step is the same to switch the corner buttons to glass.

But what to do with that distance indicator at the bottom? My instincts here is that there are really two ways to approach an element like this: blend it into the device frame or harmonize it with the glassy buttons.

Blending it into the device frame would look like this:

Which works visually but also feels like it might be contrary to the general watchOS design language where we aren’t supposed to be emphasizing black edges of the device. So let’s try glass instead:

That feels very harmonious. I’m not 100% convinced though as it does feel slightly odd. The glass texture and effect is continuing to be changed and developed with each successive beta, so I don’t want to make any decisions based on its current look. Instead, what I’m thinking I’ll do is leave it there for now and see what it is like in a few betas time.

Workout Chooser

Another place where there are subtle changes which need to be made is in the start workout chooser. Again the starting version has the watchOS 10 frosted material look.

One area I’m still struggling a bit with in Liquid Glass is exactly when to use which variant of the glassy texture. This feels like a place where some glass is in order.

I start with the prominent glass variant.

But that feels too heavy and a visually distracting. So maybe a lightly tinted variant of the regular glassy style.

I like that. It draws colors from the background but still gives each workout type a distinct flavor.

Metric Chooser

I have found that the contrast between the prominent and muted variants of glass really work well for indicating state changes. In the metric chooser there is a list of entries which you can choose between for display, with each either enabled or disabled.

I found that using a prominent style for selected and a muted for unselected visually is really clear.

Additionally, the transition between the two states is visually gorgeous.

Workout Controls

The workout control screen is another place where I found myself wrestling between different button styles and prominences. Here is the starting point:

A straight forward conversion to Liquid Glass buttons would look like this:

Which is pretty solid. The next thing I explored was to have the button icons all the same color.

Nope, don’t like that. Maybe in a brighter button mode?

That actually works pretty well. But maybe they should be circles?

No, I think that makes them visually too small. These buttons are used in a dynamic physical context during workouts, so larger touch targets are almost certainly better.

So here they are all in the bright mode. That works alright, but I think is just too bright and bold. So I think I’ll go back to the initial conversion for now.

Future ideas…

That is it for where I’ll leave the core parts of the app for now. This transition from a watchOS 10 design to watchOS 26 has been relatively straightforward.

Where things start to get interesting is with the longer term ideas I have for the app. These likely won’t ship with the September updates, where I’m expecting to mostly ship an updated variant of the current app. Nevertheless I’m starting to think about them, here’s a little preview of some of the ideas I’m playing with: