DEV Community: Andy Lawler

Building Second Skin in public #2: empty states and the first photos 📸

Andy Lawler — Sat, 07 Nov 2026 20:20:11 +0000

Gooood evening 👋. If you read one of my last posts, you'll know I'm building Second Skin, an app for keeping track of your tattoos, and that I promised the odd update along the way. Well, here's the next one.

At the end of that post I said the Collection tab was next. That's... sort of what happened. I took a little detour first, and then made some pretty good progress on getting the base layers in for the other tabs. Let me show you where I'm at.

📍 Where it's at

Last time there were 18 merged pull requests, now there are 26. It might not sound like much but it's some pretty nice progress. Since the last update I've:

Moved the shared bits (icon rows, the primary button and the empty state) into the design system.
Built an empty state for Ideas, Bookings and Stats, so every tab now has one.
Added a photo importer.
Started the Add a piece sheet, with photos going in and out of it.

🧱 A detour into the design system

Before I touched the Collection grid I wanted the shared pieces in place. Welcome, About you and Collection had all ended up with their own version of the same row (icon on the left, title and a line of text, pretty standard stuff), and they'd slowly drifted apart: some icons were 36pt and some were 40pt, some were centred and some sat at the top. Not a massive problem, but a drift nonetheless.

One thing about personal projects is that you always start with your best intentions at heart but then you end up with code that has a lot of duplication just due to how you are working. At least for me, my personal projects are an escape from the rigidity of working on large scale apps, but that doesn't mean we should let our codebases get into disarray. Especially with AI now I didn't want to keep hacking away at different things and end up with something that was honestly going to be a nightmare to sort out. So I opted to stop and just get the fundamentals down first.

Taking you back to the example I mentioned earlier. This row I had became the IconRow which will be useful on a multitude of screens throughout the app. While I was at it I also shifted over the main button I'd used in the app to be the PrimaryButton and then the EmptyState followed so it could be re-used on the other pages.

One IconRow, plain and tappable.

Having the help of Claude here was pretty handy as I managed to do the main bulk of the shifting and sculpting and then Claude helped me with getting some snapshot testing and documentation in place so when I do code reviews it can prompt me if I've forgotten to reuse something that I'd made earlier.

One thing I picked up while moving the button over was that I'd made its label a plain String, which means it would never get translated.

💡 Tip: Text(someString) with a String shows the text as it is and never looks it up for translation. If you're building a reusable component, take a LocalizedStringKey for the label instead.

I set a rule when I was doing the initial project discovery that I'd aim to shift something into the design system when it needed to be used in more than one place. You may now be thinking, "but Andy, you only had one empty state so far, so why did you move it now?" You are right, but honestly I opted to make the empty states consistent and I just thought it was easier to shift it all now.

🫙 An empty state for every tab

When you first open Second Skin, every tab is empty, so the empty states are really the first thing anyone sees other than the onboarding. They all follow the same pattern: a faint grey preview of what the tab will look like, a title, one line explaining it, a black button and sometimes a pink link underneath. This may change, but honestly this is what I have now and I'm fairly happy with it.

Ideas, Bookings and Stats, before you've added anything.

A few of them changed a bit from the designs once I actually built them:

Ideas lost its "Suggest ideas for me" link. Suggestions are going to use Apple's on-device model, and that's planned for v2, so it didn't make sense to show a link to something that doesn't exist yet.
Bookings originally promised "a reminder the day before". Reminders aren't built yet, you'll be able to turn them off and I haven't decided on the timing either, so now it just says you'll get a reminder if you want one.
Stats swapped "Log a sitting" for a link to add a piece you already have. A new session only counts towards your stats once you've logged how it went, so adding a piece you already have is the quicker way to see something there.

Large text broke everything (a little)

Every screen gets snapshot tests at the biggest accessibility text size, and the empty state didn't hold up very well initially. The title went left aligned when it wrapped, the message was squashed into a narrow column and the "Add a piece" button wrapped onto two lines inside its capsule. The pictures also had fixed sizes, so they stayed tiny while the text around them got huge.

Now the title stays centred, the button fills the width at those sizes and the pictures scale with the text using @ScaledMetric. Every picture shares one little property wrapper for that, PictureScale, so I'm not copying the maths into each screen.

Collection at the biggest text size, before and after.

💡 Tip: If you use SnapshotTesting, adding TEST_RUNNER_SNAPSHOT_TESTING_RECORD=failed to your xcodebuild command re-records only the snapshots that failed, without changing your scheme. It's really handy when you've made a change on purpose.

📸 The first photos go in

Then onto the bit I said I'd do last time, adding a piece. I split it into two parts, so I'll do the same with the write up. First was the photo importer and then the sheet itself.

The photo importer

This is the part that takes a photo you've picked and gets it ready to save. Claude wrote this one while I worked on the sheet as to be honest, I was quite happy to offload the image handling.

When a photo comes in, it:

Gets downsized to a 2048px HEIC, plus a 400px thumbnail for the grids.
Has all of its metadata stripped, including location. The app is private by design, so I don't want where you got tattooed syncing around with your photos.
Gets a suggested colour for the piece's little colour dot, picked from the photo. Black and grey work doesn't get a colour at all, on any skin tone.

It all runs off the main actor, so the app doesn't hang while it's working through a big batch of pictures.

The Add a piece sheet

This was the part I was looking at most, as I think the usability of this screen will make or break the app for a lot of people. The idea is that the top is a photo picker, once you pick images you get one nice cover photo which will be used for the piece once it's in the app, you can then add more pictures which show in a smaller carousel under the main cover. The picker section also has re-ordering, so you can choose to shift something else to be your cover photo if you find a better image of your piece later down the line.

This sheet's been quite tricky and honestly just image handling and uploading took quite a chunk of my time, so I'm still actively working on the other aspects of the page, but I look forward to sharing more of it with you next time.

🧠 Things I learned

.task(id:) restarts when its id changes. I was clearing the picker selection inside the task, which changed the id and cancelled the import halfway through. .onChange with a Task fixed it.
With NonisolatedNonsendingByDefault on, a plain async function runs on the caller's actor. If you want it off the main actor, mark it @concurrent.
@Observable needs @ObservationIgnored on every property wrapper, especially important when using Swift Dependencies like I am.
Shapes fill whatever space they're offered. A RoundedRectangle with only a width will happily grow to the full height, which made for some very tall "lines of text" in the Bookings picture. 😅
- This app is one of the first apps I've truly tried to build for iPhone, iPhone Duo and iPad, and also support localisation, accessibility, basically everything. So I've been learning a lot about the structure of my views and how to best handle things like widths and heights.

🔜 What's next?

Next up is finishing the photo carousel: a message for when a photo can't be added, and a limit on how many you can add in total. Then the rest of the sheet, name and placement, style, colour, the optional history section and finally saving.

There are a few decisions to make before I get there, like how you describe placement (an area plus front or back, or left and right as well?), what colour a black and grey piece gets, and what the minimum is before you can save.

If you've got tattoos, I'd love to know how you'd describe where one is, is "left forearm, inside" enough or would you want something more specific? Let me know in the comments. 👇🏻

My blog is moving home: rebuilding my site in Swift with Ignite 🏡

Andy Lawler — Tue, 03 Nov 2026 19:54:07 +0000

Hi! 👋🏻 If you've read my last few posts, you might not know that they all have a second home now... my own site, andrewlawler.github.io. This post is all about how it got there and why I rebuilt it.

🕰️ A site I forgot I had

Back in October 2023 I built myself a little personal site using John Sundell's Publish, a static site generator written in Swift. This was back before the days of AI so it was definitely a scrappy project and it was honestly fun to see what could be made using Swift. The site itself was pretty barebones, I had one basic post which just outlined a few things about the site but that was it. I then didn't really write anything or touch the site... until now.

When I began writing again, my first thought was to use the site but honestly it just wasn't really in the state to be used, so instead of waiting I opted to use my old dev.to account instead. After a few posts on there, I thought it would be nice to try and get everything onto my own site, plus I had been thinking that I would need somewhere to hold my portfolio and the relevant support pages for Second Skin when it launches so it felt like the best time.

When I came back to the repo, the first thing I did was try and build it again. The good news was it still built on the latest Swift. The bad news was that generating the site failed, because of a file rename I'd clearly started in 2023 and never finished, which is pretty typical of me to be fair. Once I got rid of the changes I'd made the site generated which was a success..... but it still had all the issues that drove me away in 2023 in the first place.

The bigger problem though was Publish itself. Its last release was 0.9.0 back in April 2022, so it's pretty much unmaintained now. I didn't really want to start again on my site, using a library that in reality was never going to get any more updates. So I felt that before I even touched anything, I should consider how I'd even want my site to work.

🔥 So why Ignite?

So, if not Publish, then what? Well I had two real options:

Astro or something similar. Probably the lower maintenance choice, tons of themes and a big community behind it.
Ignite. A static site generator from Paul Hudson, also in Swift, but you build your pages with a SwiftUI style syntax.

In the end, Ignite was the clear winner for me. I'm passionate about Swift and honestly just building things with Swift has always been the goal for me so keeping this website powered by Swift was a priority. When I saw Ignite and how maintained it was, it was really a no brainer.

If you've written any SwiftUI, Ignite will feel quite familiar. Here's a small part of my home page:

struct Home: StaticPage {
    var title = "Home"

    @Environment(\.articles) var articles

    var body: some HTML {
        Section {
            Text {
                "Hi, I'm Andy "
                Span("👋🏻")
                    .class("wave")
            }
            .font(.title1)

            Text("I'm an iOS engineer, currently working at Depop and based in Liverpool.")
                .font(.lead)
        }
        .class("hero")
    }
}

Pages are structs, they have a body, and you style things with modifiers. The whole site is then described in one Site struct, which lists the pages, the layout, the themes and the RSS feed:

struct AndyLawlerSite: Site {
    var name = "Andy Lawler"
    var url = URL(static: "https://andrewlawler.github.io")

    var homePage = Home()
    var layout = MainLayout()

    var staticPages: [any StaticPage] {
        Posts()
        About()
        Apps()
        SecondSkin()
    }

    var articlePages: [any ArticlePage] {
        PostLayout()
    }
}

⚠️ Tip: Ignite is still pre-1.0, so minor releases can break things. I've pinned it to an exact version (exact: "0.7.2") in Package.swift and I'll update it on purpose rather than by accident.

🚀 One repo, deployed for free

The old site had its source in one private repo and the built output in another. I think this was the advice at the time? Honestly, I can't quite remember. This time though, everything is all just in one public repo and a GitHub Actions workflow builds the site on each merge and releases it to GitHub Pages. Making the repo public is what keeps this free. A private repo deploying to Pages needs GitHub Pro, and honestly there's nothing secret in a personal blog anyway.

jobs:
  build:
    runs-on: macos-26
    steps:
      - uses: actions/checkout@v4
      - name: Build site
        run: swift run AndyLawlerSite
      - name: Upload site
        if: github.event_name != 'pull_request'
        uses: actions/upload-pages-artifact@v3
        with:
          path: Build

The build has to run on macOS, as that's where Ignite is developed and tested.

🪜 The bits that tripped me up

It wasn't all smooth sailing, so here are a few things that tripped me up and might save you some time if you try this yourself:

Posts need to live in a subfolder. Ignite puts every Markdown file in Content/ into your RSS feed and tag pages, and a Markdown file sat at the top level of Content/ actually crashed the build for me. So posts live in Content/posts/, and normal pages like my privacy and support pages are Swift StaticPages instead.
Watch your Swift version on CI. GitHub's stable macos-26 runner has Xcode 26 with Swift 6.2, but a newer swift-collections (one of Ignite's dependencies) needs Swift 6.4. Builds were fine on my Mac and failed on CI, so for now I've capped swift-collections in Package.swift until the runner catches up.
Dates and quotes in front matter. Ignite keeps the quotes around front matter values and only reads dates in a y-M-d format, which caught me out when bringing posts across.
Don't keep the repo in iCloud. My repo lived in my ~/Documents, which iCloud syncs. That gave me a weird codesign "detritus" error (swift package reset sorted it) and a pile of duplicate "Site 2.swift" files that broke the build. 🤦‍♂️
Ignite's CSS wins by default. Ignite sets link colours and button backgrounds directly, so if you want your own styles to stick, your overrides need to be just as specific.

✨ What's on the site

Now it's built out a bit more, here's what you'll find:

Posts. Everything I've written, with search and tag filters, going all the way back to my two posts from 2020.
About. A little more about me, what I'm passionate about and where I've worked.
Apps. The apps I've worked on at Jigsaw, Sky Bet and Depop, plus my own ones like Second Skin and some older side projects.
RSS. If you're still an RSS person (I see you 👀), there's a feed too.

I also gave it a bit of a fresh coat of paint, with the iOS system pink as the accent colour and a little bit of motion as you scroll.

📍 So where will my posts live now?

My site is now the home for everything I write. I write the posts in Obsidian, and a little script copies anything marked as published (plus its images) over into the site, so there's only ever one copy of each post to look after.

I'm still going to post on dev.to too, as that's where a lot of you are reading this. Each post there has a canonical_url pointing back to the copy on my site, so search engines know where the original lives.

🔜 What's next?

I always feel wary when I consider what's next with personal websites, I could say I have grand plans and then disappear again. However, I think this time I'll be here for a while. Keep an eye on the site for any upcoming posts and maybe some new designs when I think we need a fresh lick of paint. I'll also hopefully get myself a nice little domain name so I can drop the default GitHub Pages domain but we will see how that goes.

Building Second Skin in public: an app for your tattoos 🌹

Andy Lawler — Sat, 31 Oct 2026 20:03:33 +0000

Hi! 👋🏻 If you've read either of my last two posts, you've probably seen me mention Second Skin and then quickly move on to something else... well, this time it finally gets a post all to itself.

I've decided I'm going to build it in public. So every once in a while i'll do a little write up to say how far i've gotten, which bits I got wrong along the way and what are some things i've learned. This first one is really just an introduction which also aims to show you what i've done so far 🚀.

🌹 So, what is Second Skin?

Second Skin is an iOS app for keeping track of your tattoos. The tagline is "Your tattoos, from idea to healed." and the app is split into four tabs that pretty much follow that journey:

Collection. The pieces you already have, either as a photo grid or dotted around a body map.
Ideas. Moodboards for the tattoos you're thinking about, with references saved from Instagram, Pinterest, Safari or your own photos. Also the aim in the future here is to include foundation models to let the app suggest ideas to you based on the things you've got previously, got saved etc.
Bookings. Your upcoming sessions, and then a quick "How did it go?" once they've happened, so things like time in the chair, cost and a pain score out of 10 are scored.
Stats. Hours in the chair, how much of your skin is covered, your go-to artist, your most painful session and a few more. This should hopefully just be a fun way to keep track and should help when you get the dreaded How many have you got? question.

Running through all of it is aftercare. When you finish a session you can start an aftercare routine (usually the one your artist gave you) and the app will remind you of each step every day until it's healed. This is mainly just to help remind you as the app in no way will be giving medical information.

The Welcome screen, with three of my own pieces. 🌹

🖋️ Why build it?

I'm a bit of a tattoo enthusiast myself, I started really just appreciating tattooing for what it is. I think that all started for me as I've always been into Hardcore & Metal music and tattooing is quite prominent in those scenes. This led to me being interested in traditional tattooing and then has led to me having quite a lot of tattoos myself. Every piece you see in-app as promotion will likely just be one of my own tattos.

Over the years getting tattoo'd i found that it was often hard to keep track of appointments, usually had to just add the booking into my own calendar and hope i'd remember. I then had to remember days before the session to do things like buy aftercare, buy food etc and prep for the session. I then had a bit of a hard time collating ideas I wanted to get in the longer term and also keeping track of pictures of the pieces I had. All of this led to me wishing there was something simple and beautiful in place to do all of this.

🏷️ Why "Second Skin"?

"Second skin" is actually the name for the protective film that goes over a fresh tattoo. I liked that the name also is resonant with tattoos being your second skin and since the app is about collection of your tattoos it makes sense that the app really is your second skin.

🔒 Private by design

Tattoos can be pretty personal, so this was one of the first things I decided on: no sign-up, no ads, no tracking and no servers.

Everything lives on your devices and syncs through your own iCloud account using CloudKit's private database. There are no Second Skin servers for your data to end up on, which also means I never see any of it. If you're signed out of iCloud it all just stays on your device. The aim is for the App Store privacy label to say "Data Not Collected", and for that to actually be true. I also think this is incredibly important as for a lot of us, our tattoos really are a thing we've done for ourselves, so I think storing this type of information should be the same.

The privacy promises you see when you first set up the app.

🎨 The design

Before writing any code I sat down and tried to be inspired by some of my favourite apps. I used the help of AI to just collate a mood board of all different designs the apps I really love have used. This then let me mock up a few different ideas for how Second Skin will look. In the end the clean native look won for me. I think if the app is going to hold lot's of your tattoos, lot's of information and potentially lot's of colourful things, I would prefer that the app itself is quite clean and stripped back so you can see exactly what you are looking for. Thefore....

Photos lead. Your tattoos are the hero, so the app is built around big rounded photo cards and grids.
Liquid Glass for controls only. The tab bar, toolbar buttons and floating controls get glass, and anything sitting on top of a photo gets a plain frosted material instead, as the HIG suggests.
Colour in small doses. The surfaces are neutral, with one rose accent (#D9485F) for primary actions and whatever's coming up next.
Standard iOS type sizes only. No custom font sizes, so Dynamic Type just works.

🧱 The tech

For anyone curious, here's what it's being built with:

SwiftUI, targeting iOS 27 with Liquid Glass, running on iPhone, iPhone Duo and iPad from v1. Supporting the bigger screens from the start keeps my layouts honest.
SQLiteData from Point-Free for the database and CloudKit sync, instead of SwiftData.
Swift Dependencies for swapping in fakes for things like the clock, notifications and photos.
SnapshotTesting for image tests of every screen.

SQLiteData was probably the biggest decision so far. SwiftData would have been the obvious pick, but SQLiteData gives me live queries that work inside my @Observable screen models (not just in views), plain SQL for all the stats sums and counts, and CloudKit sharing. That last one means one day you could share an idea with your artist without me needing to run a backend. The trade-off is writing my migrations by hand in SQL, which to be fair has been a nice refresher.

💡 Tip: CloudKit only lets you add to your schema once it's in production, you can't rename or delete fields. If you're syncing with CloudKit, it's worth spending a bit more time on your data model up front before anything ships.

🤝 How I'm building it

In my last post I mentioned the one rule I set for this project: I write the code. Claude explains things, reviews my work and writes the parts I hand over to it, which is usually the repetitive stuff I don't learn much from. For example, I wrote the first few database tables myself to learn the pattern and then handed the rest over once I had it down.

The rest of the process is pretty much how I'd want a team to work:

A branch and pull request for every change. With a template, no more than 15 files, then squash and merge.
Requirements before code. Before I start a ticket, Claude writes up a list of requirements, kind of like a product manager would. This honestly just helps me stay on track when i'm building things.
Decision records in the repo. Things like "why iPad from v1" or "why the design system grows from screens" get written down in the same PR as the code.
A review before every PR. Claude runs a code review on my changes before I raise them.
A handoff at the end of every session. A skill I wrote saves where I got to in Obsidian, so the next session can pick straight back up.

It's probably a lot of process for a side project, but it means I can put it down for a week and come back without wondering what on earth I was doing.

It's also honestly my first time using AI in a side project. I think for me, using AI is helping because this is a side project. I'm working as an iOS Engineer for 8.5 hours during the day before I even sit down to work on this project. If i didn't at least try and lean into AI to help streamline the process I probably wouldn't reach the MVP stage.

📍 Where it's at

I started on 15 October and as of writing there are 18 merged pull requests. So far that's:

The design, the architecture plan and a release plan for v1.
The whole database schema, plus sample data built from photos of my own tattoos.
The app shell, with all four tabs.
Onboarding: a Welcome screen and an "About you" screen for your name, photo and currency. No account needed.
A debug menu (shake the device in a debug build) to reset onboarding, wipe the data or load the sample data.

Where things are right now, in dark mode: Welcome, About you and an empty Collection.

v1 is going to include all four tabs, aftercare, reminders and the share extension for saving ideas. Things like on-device AI suggestions for ideas, search and widgets will come later. There's also a little Easter egg planned for v1, but I'm going to keep that one quiet for now. 🤫

🔜 What's next?

Next up is the Collection tab: the photo grid, adding a piece and the body map. That means building a proper photo pipeline, which should make for a good post of its own.

Along the way I'm also planning to write about:

Choosing SQLiteData over SwiftData, and what it's like day to day
Designing an app with AI as a sounding board (and the app icon saga)
Building for iPhone, iPhone Duo and iPad from day one
What it's like making a rule that you write the code when AI could just do it

If you've got tattoos, I'd love to know how you keep track of yours right now and what you'd want from an app like this. And if there's a part of the build you'd like me to go deeper on, let me know in the comments. 👇🏻

Once an AI novice, now maybe a little less of one ✨

Andy Lawler — Mon, 26 Oct 2026 22:57:25 +0000

Hi! 👋🏻 It's me again. If you read my last post, you'll know I've just come back to this blog after six years away. A lot has changed in that time, for me and for the landscape of iOS. One of the biggest changes for me has been AI and how I work with it.

So this one is a bit more personal. It's about where I started with AI, the mistakes I made and what I've learned so far. If you're someone who takes pride in knowing your stuff, and AI feels a bit scary, this one's for you.

🧠 Knowledge was my superpower

Before I joined Depop (my current role), my AI usage was pretty much asking ChatGPT a few basic questions when the Apple Documentation, developer forums, Stack Overflow or asking colleagues couldn't help me solve a problem.

For me, knowledge was always my superpower. I wanted to know the syntax for things off by heart, I wanted to know the nuances of different APIs, when to build certain things and when not to. I wanted to be the person who people would look to ask when they needed help or the person that the product manager reached out to when they had an urgent issue. Before the world of AI this was the way I saw to try and push myself forward and this took a lot of outside learning and time.

So when AI first started coming into the iOS landscape, I was like most people: very sceptical. Not only of how good it could be. If I'm honest, I kind of wanted it to not be that good. I took a lot of satisfaction in being the person who knew a lot of the little details about lots of different topics and it just so happened that AI would probably be a little bit better than me at that. It could probably answer all the questions people asked with more detail in less time. This concerned me. It left me asking myself: if AI can do this better than me, what can I do better than AI?

🐣 Getting started

About 14 months ago I joined Depop, and joined a team with a very different mindset than the one I was in before. This team embraced change, it embraced AI and was set out to utilise it as much as possible. Unlike my prior role, I suddenly had access to all the latest and greatest tools and I was surrounded by people who also had much more experience with them than me.

I, on the other hand, was still writing all of my work by hand. I'd never used any of these tools before, and I didn't really know what they could do. To be fair, 14 months ago I don't think many of us knew either.

In my previous role I was a Senior iOS Engineer in a team with lots of varying skill levels. Without AI, it was my job to help, mentor and be the person who solved the tough tasks when they needed solving. I'd completed huge migrations, worked on vast technical challenges and written tons and tons of documentation, and I'd never relied on AI or even thought I wonder how this would have gone if AI did it. The thought of letting go of this and taking a step back to begin using AI was a little daunting to me.

But the team I was joining was much more open minded and this really opened my eyes. My first step was just installing Claude and giving it a go. It felt like a similar experience to the first time I ever used Xcode, I didn't really know what to expect but the results honestly blew me away. I had no real setup, I didn't even know what a context window was, or a skill or anything for that matter but I was still producing work in a more efficient way than I was before. This was honestly quite exciting.

⚡ So, where did I go from there?

Well like everyone probably did, I might have gotten a bit carried away. Even before AI I was always probably known for moving quickly. Even at school my parents would be told by teachers that I just did things very quickly and maybe I needed to slow down. I remember in my first iOS role as a Junior I was told to not bring more than 3 pieces of work onto the board at once as I couldn't manage them all at the same time. So you can probably imagine what I attempted to do when I had AI to basically duplicate myself... I just tried to do too much. I think I found out quickly that you can do it, but it doesn't mean you should. My work was good but it wasn't as high quality as my work before and arguably I hadn't learned as much from the work as I could have.

💡 Tip: I think a key thing someone told me early on is that if AI can do something you would have done before in 60% of the time, at least spend another 10% of the original time reviewing and analysing what you have done, you'll still have saved 30% and it will at least be something good.

🌊 Information overload

Once I had got accustomed to the basics of using Claude I wanted to try and progress a little more. Lucky for me I had people around me who were much further along in their AI journey than I was. We regularly had sessions in which people would share the skills they had been working on, the different use cases for AI they had found and basically everything else weird and wonderful about the AI landscape that maybe we would find interesting. Things like cookbooks, recipes, hooks all sorts.

This was amazing, it was my first real look into what was possible but it was just.... a lot of information? I think the expectation was just that everyone would be on the ball with everything but the landscape changed so much that it almost felt hard to digest, at least for me. So my plan changed to just: can I make one small change at a time?

🪜 One small step at a time

So I took small steps. As with anything, I just needed to at least start.

Using other people's skills. I started by trying the skills others had built and presented, seeing how they worked and how I could best make use of them.
Writing my own. Once I was comfortable with that, I tried creating my own skills. Even to this day it's become a great way to share knowledge within the team and the organisation. Personally I've contributed by writing a few skills such as:
1. A skill to review your Claude usage to give you tips to improve (kind of like what this one small step at a time approach did for me).
2. A skill to help you with end of year reviews, utilising Claude to pull feedback for people you work with.
3. A skill to help write better documentation for a specific architecture we use.
Hooks. One problem I realised after having such a large amount of skills to use was just... how do I know when to use them? We know Claude is supposed to invoke them but that doesn't always happen. For me I had to set up hooks to let Claude tell me when I might want to use a certain skill. This has been really valuable for me and it's something I've shared with others within my team who had similar concerns.
A knowledge base. Most recently, I set up a knowledge base. My notes live in Obsidian, and qmd indexes them so Claude Code can search them for context before asking me. This post actually started life there as a page of raw notes. For me this was probably a mistake I made for the longest time, I didn't realise how little useful context Claude actually had about me in its memory and making a change to actually formalise the storage has had a huge impact.

💡 Tip: A skill is a set of instructions that Claude loads when a task needs it. If you find yourself explaining the same thing to Claude more than once, that's a good sign it should be a skill.

I recently gave a small talk at our iOS guild, and my main suggestion was simply this: make one small improvement to your workflow at a time. With AI it can feel like you should be doing everything at once, but as I've found over the last 14 months, that doesn't really work and my approach has always just been to make one small step at a time.

📱 Putting it into practice: Second Skin

In my last post I mentioned Second Skin, my side project for keeping track of your tattoos. It's where I've been putting all of this into practice outside of work.

I made one rule early on: I write the code. Claude explains things, reviews my work and only writes parts when I ask it to, which is usually the repetitive stuff I don't learn much from.

Before I start a ticket, Claude writes up a list of requirements (Kind of like a product manager might do). Before I raise a pull request, it reviews my changes. At the end of each session, a handoff skill I wrote saves where I got to inside Obsidian, so the next session can pick straight back up.

I've also used it as a sounding board for design, exploring different directions for the app and going through round after round of app icon ideas. I'll be writing more about building it soon. 👀

✨ Where I am now

14 months on, I feel a lot more confident when it comes to AI and speaking about my experiences (which is what inspired this post). AI has become a core part of how I work, it can act as a sounding board for ideas, work as a partner when thinking about large technical problems or solutions, it can work as a planner helping me split things up and articulate them in ways to share with different stakeholders and much much more. Over time I've learned more and more use cases and honestly there's probably way more I haven't even realised yet.

I'd say I'm still getting used to adapting my thinking about where I sit in the landscape now. I've definitely shifted from being focused on every piece of syntax and nuance and now I'm more focused on engineering solutions and following good software principles. I've found this is the best way to work with AI to get the best solutions but overall I've realised that AI isn't this scary thing, even for those of us who saw the knowledge we had before AI as our superpower.

So, what can I do better than AI? I can be the guide: the person enforcing good architecture and software principles, and steering AI towards the best solutions. We should use AI to our advantage, and let it take the things that would take us the most time for the least benefit. That creates the space for the things AI can't do on its own, like thinking about the larger scale problems we have and how we can transform the areas we work in.

💡 If you're where I was

Make one small improvement at a time. You don't need to adopt everything at once.
Start with what other people have built. Try your team's skills and tools before writing your own.
Learn the tools before speeding up. Spend some time learning how they actually work before trying to do more, faster.
Give the tools you have a go. Whether they're personal tools or tools at work, AI gives us so many amazing ones. It's on us to try them and see what works for us.

🌱 Still a bit of a novice?

I'm still maybe considered a novice, and I'm still getting used to this world of AI, but I'm proud of where I'm at now with it compared to last year. It definitely feels like I'm getting somewhere, and I want to keep exploring. If you're on the same journey, I'd love to hear how you're finding it, or the one small improvement that made the biggest difference for you, in the comments.

Back after 6 years: my SwiftLeeds 2026 best bits 🎤

Andy Lawler — Sat, 17 Oct 2026 20:08:34 +0000

Hi! 👋🏻 I'm Andy. It's been over 6 years now since I last wrote on this blog, it baffles me too that it's been that long... When I started writing here I was just a university student who had found iOS development and started doing tons and tons of YouTube tutorials and courses (shoutout to Sean Allen for those). Over time I felt like I learned something and I wanted to share it with others.

📍 Where have I been?

After a short while of learning iOS on my own, I wanted to at least see what the real world of work was like so I began spending my free-time at an app agency, this let me see how teams functioned and what a real working environment was like. Off the back of that, I managed to get a placement year during my degree working for Jigsaw which at the time was a dating app based in Manchester.

This was my first real insight into what working on a real app was like. I managed to work on and ship my own features, test releases and really feel part of a team.

After going back to university and finishing my degree, I then moved on to work for Sky Bet in Leeds. There I worked on the main Sky Bet iOS app each day, building things like the dynamic content system to show different things on the home screen to users and then later became quite a key part in a huge migration to a brand new Sky Bet app which saw us re-do 70% of the app.

That was quite a challenge and I definitely wanted to try something new after that experience, so now I'm working at Depop as part of the Better Matching Experience team. Here I get to work daily on improving the experience for our users on the home, discover, search screens and much more. Enough about me anyway... why am I back?

Well, I just attended the SwiftLeeds iOS conference for a whopping 6th time. Yes, you read that right, 6th time. It left me with the motivation to share and that's what has led me to revive this blog. So without further ado, here is a little round-up of the conference, my favourite bits and some takeaways.

Boarding pass number six. ✈️

🏆 My two favourite talks

Delightful Text-Driven Experiences with SwiftUI's TextRenderer (Eli Perkins)

Eli works on Particle and showed how SwiftUI's TextRenderer lets you bring your text to life and really delight your users. Eli's talk made me realise that we often think about animating our screens and creating interesting things for our users, but I don't often consider doing the same with the text as well.

So how do text renderers work and how do we use one? Well first, to use them you can add the .textRenderer modifier to your text, passing in a renderer.

Text("Hello, World!")
    .textRenderer(Passthrough())

To create a renderer, you conform your struct to the TextRenderer protocol and implement draw(layout:in:). The simplest one just draws every line as normal:

struct Passthrough: TextRenderer {
    func draw(layout: Text.Layout, in context: inout GraphicsContext) {
        for line in layout {
            context.draw(line)
        }
    }
}

SwiftUI hands your renderer the text broken into lines, and each line into runs. A run is a chunk of the line that's styled differently from the text around it, so a bold word or an inline icon, for example, ends up in its own run. Inside each run are the glyphs: every letter, space and punctuation mark.

You can apply operations like opacity and colour to any of those levels, and group them, much like you would with images. Every TextRenderer is also Animatable, so if you add an animatableData property and animate it, you can reveal text line by line or glyph by glyph.

Here's a quick example of that. This renderer fades each glyph in and slides it up into place, one after the other:

struct AppearRenderer: TextRenderer {
    var progress: Double

    var animatableData: Double {
        get { progress }
        set { progress = newValue }
    }

    func draw(layout: Text.Layout, in context: inout GraphicsContext) {
        // Lines → runs → glyphs
        let glyphs = layout.flatMap { $0 }.flatMap { $0 }
        let count = Double(glyphs.count)

        for (index, glyph) in glyphs.enumerated() {
            let start = Double(index) / count * 0.7
            let amount = min(max((progress - start) / 0.3, 0), 1)

            var copy = context
            copy.opacity = amount
            copy.translateBy(x: 0, y: (1 - amount) * 20)
            copy.draw(glyph)
        }
    }
}

Animate progress from 0 to 1 and you get this:

💡 Tip: Paul Hudson's Prismic is a collection of ready-made renderers to play with. I'm starting there while exploring ways to bring some text renderers to my personal projects and also at work.

Building Beyond Mistakes (Frank Solleveld)

My favourite talk on day two had no code in it. Frank wasn't even supposed to be doing a talk at the conference but as one of the other speakers fell ill, Frank was ready in the wings to give us his talk.

This talk was different from the others. Frank talked about his start with iOS development, how he found the love for building things but as most of us did, he struggled when he had his first real taste of working in a company. I still remember myself the first time I worked on a real app as part of a company and how different that experience was compared to the apps I'd spent my own time building, so I could relate to this part of the talk.

Frank took us on a journey, where he talked about his doubts and confidence knocks he had during the early start of his career but then how he managed to really excel and eventually find his way to where he is today. A few things from his talk that I'm taking with me:

💬 People are just people, even conference speakers. Everyone is just part of the community.

This talk really resonated with me, and I think it did for everyone else too, as after speaking to other attendees it seemed to be everyone's favourite of the conference. I'm looking forward to seeing this one published online.

Some other talks I really enjoyed...

🤖 Working with AI without losing the craft

Bringing back the love of Swift (Antoine van der Lee)

Antoine opened the conference with this one. This talk hit the mark with everyone in the room, as I think we all ask ourselves quite often if the vast change to our careers due to AI has made us love the code we are writing less.

💬 Are we losing our love of Swift as we write less of the code ourselves?

Antoine raised the concern that developers aren't really taking as many courses anymore. People are even reading fewer articles which doesn't bode well for me beginning to write more on this blog. He also went on to say that developers are exploring code less, but in reality we are shipping more than ever.

I can only speak from my own experience but I feel that. I've always been a relatively high-output engineer and I'm a fan of having a few things on the go, but AI has made that a different ball game.

The sheer amount of code output I see per week now with AI does mean that we aren't as close to the code we are writing and I know for myself, I'm reading less and exploring less online as a result. This talk made me reflect, and I think the outcome for me is that I want to ground myself more in the technology I'm using every day.

Alongside these topics, Antoine shared some tips for working with AI, such as:

He also shared some handy tools:

RocketSim and RocketTrace, a CLI and agent skill for driving the simulator, plus Xcode Instruments for AI agents.
sosumi.ai, Apple's docs (including the Human Interface Guidelines) in a form agents can read.
His post on reducing token usage in Claude Code, Codex and Cursor.

Overall, I really enjoyed this one and I think we can all take something from it.

From Code to Outcomes (Natalija Marcinska)

Natalija (BBC Mobile) closed day one, and her talk felt like a nice follow-on from Antoine's, as it came at AI from the product side. Her point was that AI has made it easier than ever to build the wrong thing really quickly. You can build an amazing technical solution, but if your users don't actually need it then all of that time has been wasted.

She talked about how engineers already make product decisions every day, so we should also be asking whether something should be built at all, and that discovery is part of engineering too. The line that stuck with me was this one:

💬 The best code to delete is the code for a feature that would have wasted months.

My takeaways from this one:

🗄️ You might not need a backend yet

CloudKit Public Database as a Backend (Danijela Vrzan)

Danijela opened day two, and her main advice was to avoid building a backend for as long as possible. So before reaching for one, ask yourself:

If you do need shared data, the CloudKit Public Database might be the answer. It's managed by Apple, shared across all the users of your app and doesn't need an account system of your own. It's best for static-ish content though, and it isn't the place to store anything sensitive.

⚠️ Tip: Development and Production are separate environments in CloudKit. Don't forget to deploy your schema changes from Development to Production, and be aware that any records you upload to Development won't be carried across. If you've uploaded lots of data, you'll have to upload it all again.

This one got me thinking about my own app. Rather than baking configuration straight into the app, I could use the public database alongside the private one to store key content. Definitely one to explore.

📣 Building an audience

Building an Audience for Your Apps (Joe Allen)

Joe, who makes Teleprompter Pro, closed out the conference. For years Joe slowly built up an email list from within his apps, so when he released something new, he let his audience know and got a huge influx of downloads. His point was that an audience is your unfair advantage:

💬 Your competitors don't have your audience.

The obvious worry is "I don't want to spam my users", and Joe's answer to that was... you could just not spam them. 😄 You do need to think about GDPR when you contact users though, and you shouldn't hold your content or features hostage just to get someone's email address.

💡 Tip: Register the domains and addresses you send email from in your Apple Developer account (Certificates, Identifiers & Profiles, under Sign in with Apple for Email Communication). Users who Sign in with Apple may be using Private Relay, and without that setup your emails won't reach them.

I'd love to think more about how we do this at Depop. For my own apps, I'm keeping things private with no email list, so this blog is going to be my way of building an audience instead.

⚡ The quickfire round

There were plenty of other great talks too, so here's a quick look at the rest:

Unleash the power of Swift Charts (Francesco Marini). This one was all about making your charts readable and accessible. Check your colour palette with Viz Palette, use a font you know is readable like Lexend or OpenDyslexic, format your legend and axes, and pick the right mark for the job (bar or line?). He also showed TabularData, which is really handy for loading CSV and JSON into a DataFrame.
CarPlay from Zero (Eyad Kelleh & Maurice Pfurr). Eyad and Maurice built Charge a Smile to compare EV charging prices. CarPlay apps are built from Apple's templates rather than custom UI, and the entitlement you request decides which ones you get.
Vapor 5 is actually here (Tim Condon). Vapor 4 has been around since 2020 with over 300 releases, so this is a big one! Vapor 5 focuses on performance, structured concurrency throughout and macro-based routing. The beta is out now and I'm keen to give the macro-based routing a go.
Beyond Boilerplate: Production-Ready Swift Macros (Kevin Morales). Macros are great for stable, repeated patterns, but if the code changes often, or you'd only be saving a few lines, it's probably not worth it. I'm wondering whether there are some custom macros I could use for validation. Sample code here.
Who Let the App Intents Out? (Claire Sivadier). App Intents let your app's actions run from Siri, Shortcuts and Apple Intelligence, and with the new Siri relying on them they're well worth a look. Claire's app Peticle shows them off well.
Why Does Our Swift Code Work? (Yuki Aki). I loved the analogy here: the compiler is the safe road and the runtime is the car driving along it. Yuki walked us through the pipeline from .swift to AST, type-checked AST, raw SIL, canonical SIL, LLVM IR and finally a .o file. It made me think more about how I structure my code, and how much the compiler has to work out in a single expression.
Getting physical: Using Swift for 3D printing (Eric Bariaux). With Cadova you can design 3D-printable models in Swift, SwiftUI-style, and watch them update in real time in CadovaViewer, a bit like a SwiftUI preview. This one is purely for fun, but I'm definitely giving it a go.
Swift Meets Kotlin (Yeskendir Salgara). Trackman shares its Domain and Data layers through Kotlin Multiplatform and keeps the UI and Presentation layers in native Swift, using SKIE to make the bridge between them feel more like Swift. Even if you never use KMP, it's a good reminder that getting your layering right matters in any architecture.

🛠️ What I'm going to try

So after two days of talks, here's what I'm taking away to try:

Playing around with TextRenderer effects, starting with Prismic
Adding App Intents for the main actions in my own app, and thinking about how I can future-proof it with all the Siri changes coming in
Considering the CloudKit Public Database for storing information that all users can use
Building an audience through this blog (no spam, I promise)
The Vapor 5 beta, and maybe a 3D print designed in Swift
And after Frank's talk, releasing something new in 2026

A lot of these are going to end up in my side project, Second Skin. It's an iOS app for keeping track of your tattoos: the pieces you have, the ideas you're collecting, the sessions you've booked and your aftercare routine. It's built in SwiftUI with no accounts and no servers, as everything syncs through your own iCloud, so Danijela's talk came at a pretty good time. It's still early days, but hopefully this is the something new that Frank's talk pushed me to release. I'll be writing more about building it here, so watch this space! 👀

Built by humans. A fitting way to close a conference where AI came up in so many of the talks.

Thanks to everyone who organised, spoke at and came along to SwiftLeeds this year, it was another great one. See you all at number seven! If you were there, I'd love to hear what your favourite talk was in the comments.

Introduction to Swift! 🚀 (for complete beginners)

Andy Lawler — Wed, 26 Feb 2020 15:53:30 +0000

So you want to get started with swift but don't know where to start? 🤔

This will be the perfect introduction to Swift. Firstly, let's open up a playground so we have a space to practice writing our code. To do this, open Xcode and then click 'create new playground'. Just name your playground and you are off.

The first thing you will spot is the line at the very top. UIKit is simply the framework which holds all of the components to build the apps you love. UIKit holds all the information on components such as buttons, labels, views and even controllers.

Let's get into the code! 🛠

Quickly before we start. I will not be covering printing out values. In Swift it's as easy as doing.

One extra tip: You can use () in swift to add variables inside of speech marks.

var a = "Hello World!🚀"
print(a)
// Hello World!🚀
var a = 10
print("This is the number \(a)")
// This is the number 10

Variables 🌦

You might notice the var keyword instantly. Swift uses both variables and constants. Unlike languages like Java for example, swift can recognise types of variables so they do not always need to be pre-defined. You can instead use 'var' for variables that can change and 'let' for constants that will not change. Let's see an example of this!

var canChange = 3
let notChanging = 4
// we could now do 
canChange = 5
// this would change the variable. Whereas, if we did
notChanging = 5
// we would get an error

One thing to note, you can pre-define variables in Swift, if you want to do so, use this general syntax.

var a: Int = 3
// or
var b: String = "Hello"

Now that I've introduced variables the best way to go next is to talk about data types in Swift.

Data Types ✍️

Data types are always important in any programming language. With this blog, I'm assuming you have no prior programming knowledge so I will explain exactly what each type is with examples.

Integers

Integers in Swift are the exact same as integers in real life. If we want to store an integer we simply use the same process as specified above. We use either var or let and then assign an integer to that variable. Integers need to be wholes numbers. Luckily, if you need to represent as a decimal you could also use floats which we will cover later.

let age = 21
// assigning the integer 21 to the variable age

Important note: If you would like to represent binary numbers, hex numbers or even octal numbers. You can do this! I will link to the Swift documentation which has more information on this. https://docs.swift.org/swift-book/LanguageGuide/TheBasics.html

Strings

Strings are used to store words/character. In Swift we will use them to store text we can then use throughout our apps. Strings in swift are fairly simple. Remember, Swift can detect what data type a variable is so you do not need to define it if you don't want to.

let name = "Andrew"
// my name is now Andrew

Floats

Floating Point numbers are used when you want to store numbers that have decimal places. We use them to show off these numbers and they are often used for mathematics inside languages.

let pi = 3.14
// pi is now a float, not an integer

Booleans

Booleans are used in Swift to store either True or False values. Booleans are useful when you want to check conditions. The main thing to remember with Booleans is that they are always either True or False, nothing else.

let thisArticleIsAwesome = true
// as you can see this is now true

Optionals

Optionals are one of the key features of Swift which most people will not have seen before! An optional is when a value could or could not have a value. Optionals are really useful when defining variables that may be null. I won't go into any more detail than this. I'll show you what defining an optional will look like. With optionals, you have to define the type of the variable before hand.

var a: Int?
// a is now an optional integer
a = 5
// a = Optional(5) <- this 5 needs to be unwrapped.

Just remember that if you define an optional and then assign a value to it, you will need to unwrap it. Let's see what unwrapping is!

Unwrapping Optionals

We have three different methods for unwrapping optionals that we could use. Force-Unwrapping, Optional-Chaining or Nil Coalescing. There are other ways of unwrapping but these are the main ones. Let's see what they are all about.

Force Unwrapping

Force unwrapping is when you append a ! onto the end of an optional to unwrap it to obtain its true value. The one thing to be aware of with force unwrapping is that it's very risky. It's only really a good idea to unwrap it using this method if you know the variable should have a value. If it doesn't and you force unwrap your program will crash. Let's look at an example!

var a:Int?
a = 10
print(a)
// prints Optional(10)
print(a!)
// prints 10

Optional Chaining

Optional chaining is using the ? operator to carry the optional value to retrieve some other value. This may not make complete sense so let's take a look at an example!

class Programmer {
    var favouriteWebsite: DevTo?
}

class DevTo {
    var favouriteArticle = "this current article"
}

let Andy = Programmer()
Andy.favouriteWebsite = DevTo()

let example = Andy.favouriteWebsite?.favouriteArticle 
print(example!)
// prints this current article

A few things to understand with this. We are chaining the optional of favouriteWebsite to then access the favourite Article. As you can see, we have assigned Andy.favouriteWebsite to DevTo. If you don't do this, the optional would still be nil, imagine the code without that line. Favourite website wouldn't be linked to anything at all. If you now look at the example line you can see us use the ?. This simply means we're chaining the optional. You can then see me use ! in the print statement to unwrap the optional. Even though favouriteArticle isn't an optional, as we've chained the value will be an optional.

Nil Coalescing

Nil Coalescing is using the double ?? operator to give a default value to a variable when you attempt to unwrap it. If the variable turns out to be nil, the default value specified is used instead. Let's look at an example!

var a:Int?
a = 10
print(a ?? 5)
// prints 10 as a is not nil
var b:Int?
print(b ?? 6)
// prints 6 as b is currently nil

Collection Types 📦

Arrays

Arrays are simply storage areas where you can store items/values to then use throughout your code. Arrays can be of many types and you can even create types to store in them. Let's take a look at an example.

var integerStorage = [Int]()
integerStorage.append(5)
integerStorage.append(10)

// or

let integerStorage = [5, 10]

// you could specify type 'var integerStorage: [Int]'

let chosenInt = integerStorage[0]

Note: Array values can be indexed as shown above, array indexes start at 0 and not 1. So your index values are always '0 .. count-1'.

Dictionaries

Dictionaries are used when you want a key:value pair. This means you can store one value that links to another value. Let's take a look!

let ages: [String:Int] = ["Andy":21, "Sophia":20]
let myAge = ages["Andy"]
print(myAge!)
// prints out 21

Note: Values taken from dictionaries are always optional. You will need to unwrap them.

Sets

Sets are useful when dealing with types that you would like to query and or use mathematical set theory. Let's look at some basic examples and then look at the theory we could use.

var ourSet = Set<Int>()
ourSet.insert(10)
print("Does our set contain 10? \(ourSet.contains(10))")
// prints does our set contain 10? true
print("Set count: \(ourSet.count)")
// prints set count: 1

Examples of set theory: Union, Intersection, Subtracting.

Union allows you to join two sets together
Intersection allows you to find common elements
Subtraction allows you to subtract one set from another

Tuples

Tuples are useful when you need to store values quickly but don't need something like an array or dictionary. As you can see, they look different to the other storage types but they are incredibly useful.

let thisCourse = (type: "Swift Tutorial", rating: 10)
print("This course is a \(thisCourse.type) and it has a rating of \(thisCourse.rating)")
// This course is a Swift Tutorial and it has a rating of 10

Operators ➕

Now that you know how to define and store your values, we should talk about what you can do with them!

Addition/Subtraction

I won't say much about addition and subtraction. In Swift it's fairly simple. Let's jump straight into the examples.

let a = 3
let b = 4
print(a+b)
// prints 7
print(b-a)
// prints 1

Multiplication/Division

Same as above. Multiplication and Division is fairly simply inside Swift. Let's look at the examples.

let a = 2
let b = 5
print(a*b) 
// prints 10
print(b/a)
// prints 2.5

W?T:F (Ternary)

This operator get's the name W?T:F this stands for what, true, false. This is a good way to remember it! This operator is used when you want to check something and then apply different values for true or false. Let's take a look at an example!

var bool = true
let example = bool ? "True" : "False"
print(example)
// prints True

Unary

The unary operator is simply used as a NOT operator. You use it show that you wan't the opposite of what it's used in conjunction with. Let's look at an example.

var a = true
print(!a)
// prints false

Compound Assignment Operator

This is where swift is a tiny bit different to some other languages. In lot's of other programming languages there is a ++ or -- operator. This operator is used to add 1 or remove 1 from a variable. In swift this is not the case. Instead you must use += or -=. Let's look at some examples for this.

var a = 10
a += 10
print(a)
// prints 20
a -= 11
print(a)
// prints 9

There are plenty of other operators in Swift but they are all similar to other programming languages. For the full list, check out the documentation below. https://docs.swift.org/swift-book/LanguageGuide/BasicOperators.html

Control Flow 🌊

Control flow is something you will be using all the time when writing code in any language. It allows you to query, look through values and do so much more. Let's take a look at it in Swift.

For loop

For loops are used to loop through certain values. You can loop through arrays, dictionaries, sets or just through ranges. Let's take a look at some examples to see how they work!

In our first example we loop through our names array using 'name' as the iterator. It could be called anything, it's doesn't have to be called names. We just call it names to the code itself is more readable. This loop will now go through each value in this loop and print them out.

let names = ["Andy", "Brad", "John"]
for name in names {
    print(name)
}
// prints Andy Brad John

In this second example we are using ranges to print out numbers in a specified range. You can clearly see how the code below is printing from 0 to 4. This occurs because we use the 0..<5 operator. This simply says go from 0 to less than 5. You could change this to anything for example ... or ..> etc.

for i in 0..<5 {
    print(i)
}
// prints 0 1 2 3 4

While loop

While statements are loops that run based on a condition. For example, if you start a loop that says 'while a>5' the loop will keep running until a is <=5. These loops really useful. Let's look at how we could use them!

var a = 10
while a > 5 {
    print(a)
    a -= 1
}
// prints 10 9 8 7 6

Tip: You can use 'break' inside loops to stop them at any time. Let's look at an example.

var a = 10
while a > 5 {
    print(a)
    if a==10 {
         break
    }
}
// prints 10 and then breaks

If statement

If statements are really important when it comes to checking conditions and making decisions. Let's take a look at some examples.

Syntax: If, else if, else.

var a = 10
var b = 5

if a==10 {
    print("Yes, a is 10")
}
else {
    print("No, a is not 10")
}

if b==3 {
    print("b is 3")
}
else if b==4 {
    print("b is 4")
}
else {
    print("b is something else")
}

// prints Yes, a is 10 and b is something else

If you are interested in learning a more advanced version of control flow that acts like an if statement, take a look at this documentation to learn about guard statements. https://docs.swift.org/swift-book/ReferenceManual/Statements.html

Switch statement

Switch statements are statements just like the others but they use control expressions and then cases. You can assign a default case and then cases for any possible value you want. This may not make complete sense so let's look at a basic example!

var a = 10
switch a {
case 10:
    print("Yes a is 10")
default:
    print("No a is not 10")
}
// prints Yes a is 10

The example above is a really simple example of Switch statements. You can also use enums for Switch statements and I haven't covered enums in this article. If you want to learn more, check it out here: https://docs.swift.org/swift-book/LanguageGuide/ControlFlow.html

Challenge Yourself! 🤓

I'll include some challenges here to see how much you have learned throughout. I'll post the code below the conclusion so you can check your work!

Task 1️⃣

For this task, I would like to to write a simply program that can take an input of a shopping list and print out it's contents. The printed out list should look like this. Tip, use an array to manage the items.

1. Apples
2. Pears
3. Lemons
4. Oranges

extension: Could you print how many items the user has overall?

Conclusion 🥳

I hope this was a good introduction to the language so you can now play around! If enough people are interested I'll make a video introducing Xcode and how to use it if you've never used it before. I hope everyone enjoyed this post!

Answers to the tasks 👨‍🏫

Task 1️⃣

Just remember, the loop may print in a different order. This is perfectly fine!

let shoppingList = ["Apples": 1, "Pears": 2, "Lemons": 3, "Oranges": 4]

for (item,counter) in shoppingList {
    print("\(counter). \(item)")
}

// extension: print(shoppingList.count)

Programmatic Constraints in Swift 📏

Andy Lawler — Thu, 20 Feb 2020 22:48:12 +0000

Have you always wanted to learn how to constrain your views and elements in Swift programatically and want to use no-libraries, well you are in the best place. This method of writing constraints is quite tedious in comparison to the likes of SnapKit but you will learn the fundamentals of constraints and then you can apply this knowledge to libraries like SnapKit in the future.

Let's get started 😀

Firstly, we need to understand the key types of Anchors and what they all mean! Let's list the types out.

Types of Anchors ⚓️

To constrain programmatically you must constrain to the pre-specified anchors that are provided for us to use. These are:

Top (Anchor at the top of the view)
Bottom (Anchor at the bottom of the view)
Leading (Anchor at the left of the view)
Trailing (Anchor at the right of the view)
CenterX (Anchor on the centre of the X axis)
CenterY (Anchor on the centre of the Y axis)
Width (Anchor determining Width)
Height (Anchor determining Height)

Remember: Usually you will need four constraints, never less. If you have more than four constraints you should see if you can improve the way you are constraining your elements.

Now, let's look at the process of adding constraints and we can then explore examples of each type!

Process of adding constraints 👷🏼‍♂️

It's usually good practice to add your constraints directly under your view.addSubview(view) code. I usually have a process for adding constraints to elements. It looks a little bit like this.

You should always remember to make sure to add the new view as a subView of the main view and then make sure you change the bool as shown above. This bool allows us to write out our own custom programmatic constraints. A common mistake is to not make this false.

Examples of constraints using our Anchors

tip: Something I learned from Sean Allen is that you can define a padding type as a CGFloat and use this variable instead of manually inputting your constants. This allows you to change your UI from one position. Example below!

Now we can delve into the examples. We will go through some examples and show different ways they could be implemented. Take into account there are many different types of constraints, eg: constants, multipliers. We are going to use constants, just take into account that where you see constant it could also be a multiplier if you needed it to.

Top Anchor

This example below links the example view to the top of the main view with a distance of 40. this is a common way of setting up this type of constraint.

tip: add safeAreaLayoutGuide in between view and topAnchor to pin to the safe area not the top of the view!

Bottom Anchor

This example below constrains the example view to the bottomAnchor with a distance of 10. Take into account that the number needs to be negative as we want the view to be away from the anchor not past it. This will make more sense when we do leading and trailing anchors.

tip: add safeAreaLayoutGuide in between view and bottomAnchor to pin to safe area once again.

Leading Anchor

The leading anchor is the anchor on the left hand side of the screen. The left hand side is the leading anchor as we imagine we are looking from left to right. With this knowledge we can verify that the trailing anchor is the anchor to the right. Leading anchor constants do not need to be negative as we want our view to be pinned to the right of the anchor.

Trailing Anchor

Key thing with trailing anchors is that the constant must be negative not positive as you are wanting your view to be x pixels behind the Anchor itself. The example below is the line we would add to make this possible. This examples shows us pinning a trailing anchor

CenterX Anchor / CenterY Anchor

CenterX and CenterY Anchors are fairly self explanatory. We use them to center views when we need them to be fixed in an axis. These two anchors are useful for having an image in the exact center of the screen. I will show examples of pinning to the CenterX Anchor and also the CenterY Anchor but with a constant.

Width Anchor / Height Anchor

Width and Height Anchors are quite self explanatory. These constraints allow you to add a width and height to your views. I will show you an example below.

Full Examples using what we have learned! ✍️

Now let's put into practice what we've learned! I will include three full examples below showing valid constraints along with what they look like on the device!

Example 1

This example shows how we can create a View and then pin the view to the edges of the phone. I've made the view red so you can see what's happening.

Here you can see what's happening on the phone in red!

Example 2

This example shows how we can pin a view to the centre of the phone and then add a width and height to it, you could use this for main screen logos! I used a variable for the box size so we can easily resize it if needed.

Here you can see what's happening on the phone in blue!

Example 3

This example shows how we can create two views and stack them without using a stack view. This could be used to create some interesting designs! Look at the way I've pinned to the first views bottom anchor in the second views top anchor constraint.

Here you can see what's happening on the phone in green and pink!

Review 🥳

Now you have seen examples of how to add constraints programmatically in Swift!

If you have any additions for this post please do leave it in the comments, this is my first ever post so feedback would be appreciated!